Google Workspaceのprivileged account監視が、super adminだけからすべてのadministrator roleへ広がった。新しいAdmin password reset alertは既定でONとなり、旧ruleのrecipient設定を引き継ぐ。検知範囲が広がるため安全性は高まるが、delegated adminが多い組織では通知量も増える。recipient、on-call、正当なhelpdesk reset、侵害時のsession・権限確認を更新する必要がある。

何が変わったか

Alert Centerの既存「Super Admin password reset」ruleが、より広い「Admin password reset」alertへ自動的に置き換わった。これまでsuper adminのpassword変更だけだった対象が、organization内のすべてのadministrator roleのresetへ広がる。featureは既定ONで、旧ruleのrecipient listを変更していた場合はその設定が新ruleへ引き継がれる。全Google Workspace customerが対象である。

変更前後の差

従来はdelegated adminやcustom role管理者のpassword resetを同じalertで一貫監視できなかった。新ruleでprivileged account全体をカバーできる。一方password resetが即侵害を意味するわけではなく、helpdesk、本人回復、planned rotationも含まれる。旧recipientが狭すぎる、退職者を含む、24時間監視されない場合、その問題も引き継がれる。

誰に影響するか

super admin、groups admin、user management admin、security admin、custom roleなどを委任している組織が対象である。SOCはalert増加とtriage ruleを、IT helpdeskは正当resetの記録を、IAM ownerはadmin inventoryとleast privilegeを見直す。end user向け設定はないが、管理者account侵害は全user・dataへ波及し得る。

対応期限

rolloutは2026年6月22日から最大15日で開始され、現在は対象環境で有効になっている想定である。強制作業期限はないが、既定ONかつrecipient引継ぎのため「設定不要」として放置せず、実際のAlert Center ruleと通知先を確認する。incident testを早期に行う。

必要な対応

Admin consoleからすべてのadmin roleとassignmentをexportし、alert recipient・on-call・SIEM連携を照合する。helpdesk resetにはticket ID、実施者、本人確認、時刻を残す。不審resetではlogin event、source IP、device、MFA、recovery情報、role変更、OAuth grant、sessionを調査し、必要に応じてsession revoke、password再reset、role一時解除を行う。

実装・移行手順

  1. Admin password reset ruleとrecipientを確認する。
  2. admin role inventoryとownerを更新する。
  3. Alert Center連携でtest alertの受信経路を確認する。
  4. 正当resetのticket情報とalertを相関する。
  5. 相関できないalertをhigh priorityでSOCへ送る。
  6. quarterlyにrecipientとadmin assignmentをreviewする。

失敗しやすい点

旧ruleのrecipientが自動継承されるため、現在のon-callが通知されるとは限らない。alertが増えた結果、すべてをlow priorityへ落とすと重要resetを見逃す。passwordを再変更するだけで調査を終え、既存session、MFA、recovery、OAuth token、admin role変更を確認しないのも不十分である。

リスク

通知疲れ、誤った自動lockによる管理業務停止、Alert Center連携の遅延がある。super adminを自動で即時無効化すると、break-glass accountや復旧能力を失う可能性がある。逆にdelegated adminを低riskとみなすと、user作成、group変更、security setting変更などの権限悪用を見逃す。

評価方法

全admin roleに対するcontrolled reset testを行い、alert生成、notification、SIEM ingestion、ticket作成、on-call受信までの時間を測る。正当ticketとの自動相関率、false escalation、未所有admin、平均確認時間、session revoke完了時間を記録する。recipient変更後も定期testする。

ロールバック

検知範囲自体を旧super-admin-onlyへ戻すより、routingとautomationを調整する。誤った自動disableが起きる場合は自動actionだけを停止し、alert受信と人手triageを維持する。recipient変更は前設定を記録して戻せるようにし、break-glass accountを別経路で監視する。

編集部の見解

全admin roleのpassword resetを監視するのは妥当な拡張である。ただし既定ONとrecipient継承は運用が完成したことを意味しない。最も重要なのはadmin inventory、正当resetの証跡、sessionまで含むinvestigationであり、alert件数だけを増やさない設計が必要だ。

実務チェックリスト

  • ruleの状態を確認した
  • 旧recipientの継承結果を確認した
  • 全admin roleとownerを棚卸しした
  • helpdesk resetへticket IDを必須化した
  • SIEM・on-call経路をtestした
  • session・MFA・OAuthまで調査する
  • break-glass accountを別監視した
  • quarterly reviewを予定した

一次情報