Microsoft Entra、Google Workspace、GitHubで管理者権限が急に付与された時の確認方法を、監査ログ、付与理由、影響範囲、失効、記録テンプレートまで整理する。
冒頭要約
管理者権限が急に付与された、または身に覚えのないロール変更通知が届いた場合、それだけで侵害が確定するわけではありません。異動、障害対応、委託先作業、PIM / JIT運用、監査対応など、正当な理由で発生することもあります。
一方で、管理者権限は認可の境界を大きく変える操作です。Microsoft Entra、Google Workspace、GitHub、Slack、クラウド管理基盤では、1つのロール付与がメール、ファイル、リポジトリ、外部共有、OAuthアプリ、ログ設定に波及します。
まず確認することは、誰が、誰に、どのロールを、どの範囲で、いつ、なぜ付与したかです。監査ログ、チケット、変更申請、承認者、対象ユーザーの状態を同じ時系列で見ます。説明できない場合は、権限を消す前に証跡を保全し、セッション失効や一時停止、関連SaaSの確認へ進みます。
この記事は、情シス、IdP管理者、SaaS管理者、開発組織の管理者向けに、管理者権限付与を見つけた時の確認順序と初動判断を整理します。攻撃手順、認証回避、侵入再現、悪用コードは扱いません。
読者別の影響：誰が何を確認するか
管理者権限の付与は、ID管理だけで完結しません。IdP、SaaS、開発基盤、監査ログ、インシデント対応をつないで見る必要があります。
| 読者・担当者 | まず見ること | 放置したときのリスク |
|---|---|---|
| 情シス・IdP管理者 | Microsoft Entra、Google Workspace、Oktaなどのロール付与、グループ、PIM/JIT履歴 | 恒久的な特権や外部ユーザー権限が残る |
| SaaS管理者 | Microsoft 365、Google Workspace、Slack、CRM、会計SaaSの管理者ロール | メール、ファイル、請求、ユーザー管理へ波及する |
| 開発者・DevOps | GitHub Organization owner、security manager、repo admin、CI/CD管理者 | コード、Secret、リリース、クラウド権限へ波及する |
| CSIRT・SOC | 監査ログ、サインインログ、操作ログ、直後の設定変更 | 単なる変更作業として処理し、不正利用を見逃す |
| 監査・管理部門 | 変更申請、承認者、期限、再レビュー日、証跡 | 後から「なぜ付与したか」を説明できない |
Microsoft Entraの監査ログは、アプリケーション、グループ、ユーザーなどの変更を記録し、変更の時刻、操作、状態、主体、対象、変更前後の値を確認する入口になります。Google Workspaceでは管理者ロールの割り当てがAdmin consoleへのアクセスを与え、GitHubではOrganization ownerやSecurity managerなどの組織ロールが権限境界になります。
まず確認すること：10分で切り分けるチェックリスト
最初の10分で目指すのは、正当な変更か、説明不能な高リスク変更かを分けることです。いきなり削除や無効化へ進むと、証跡や正当な作業の文脈を失うことがあります。
| 確認項目 | 見るポイント |
|---|---|
| 1. 検知経路 | アラート、監査ログ、チケット、本人申告、定期棚卸しのどれで気づいたか |
| 2. 付与時刻 | 業務時間内か、深夜・休日・障害対応時間帯か、他のログと時刻が合うか |
| 3. 付与した主体 | 人間の管理者か、グループ同期か、API/サービスプリンシパルか、自動化か |
| 4. 付与された対象 | 社員、委託先、外部ゲスト、退職予定者、サービスアカウントのどれか |
| 5. ロール名 | Global Administrator、Super Admin、Organization owner、請求管理者、セキュリティ管理者など強い権限か |
| 6. スコープ | テナント全体、特定アプリ、特定組織、特定リポジトリ、OU、グループなど範囲はどこか |
| 7. 付与方法 | 直接付与、グループ経由、PIM/JITの有効化、SCIM同期、カスタムロールのどれか |
| 8. 変更申請 | チケット、承認者、期限、作業目的、作業完了後の失効予定があるか |
| 9. 直後の操作 | MFA変更、OAuth同意、外部共有、トークン発行、ログ設定変更、ユーザー作成が続いていないか |
| 10. 関連ログ | サインインログ、SaaS監査ログ、GitHub監査ログ、メール転送、共有リンク、APIキーを同じ時間軸で見たか |
Google WorkspaceやGitHubのように管理者ロールや監査ログがサービスごとに分かれる環境では、IdPのロール一覧だけでは足りません。SSO後のSaaS側で、別の管理者ロールやアプリ権限が付与されていないかも確認します。
初動対応：やること、やらないこと、記録すること
やること
- 監査ログの該当イベントを保存し、時刻、主体、対象、ロール、スコープ、変更前後の値を記録する。
- 変更申請、障害対応記録、上長承認、システムオーナー承認と突き合わせる。
- 付与された対象の直近サインイン、MFA/パスキー変更、セッション、端末、場所を確認する。
- 付与直後に、外部共有、OAuth同意、APIトークン、GitHub App、リポジトリ権限、メール転送などが変わっていないか見る。
- 正当な作業であっても、期限、作業完了後の失効、再レビュー日をチケットへ残す。
- 説明できない場合は、証跡を保全したうえで一時停止、セッション失効、ロール剥奪、パスワード/MFA再確認を検討する。
やらないこと
- 「管理者が付与したから安全」と判断してログ確認を省略しない。
- 証跡を保存する前に、ロール、ユーザー、トークン、ログ設定をまとめて削除しない。
- Slackや口頭だけの承認を、後から追えないまま放置しない。
- 外部ユーザーやサービスアカウントへの付与を、通常ユーザーと同じ優先度で扱わない。
- 侵害が未確認の段階で、攻撃者名、被害規模、原因を断定しない。
記録すること
| 記録項目 | 書き方の例 |
|---|---|
| 検知 | 2026-06-18 10:24 JST、Microsoft Entra監査ログでロール付与を確認 |
| 対象 | [email protected]、付与ロール、スコープ、付与元グループ |
| 付与主体 | 管理者名、サービスプリンシパル名、自動化ジョブ名、チケット番号 |
| 正当性 | 変更申請、承認者、作業目的、期限、未確認事項 |
| 直後の操作 | サインイン、MFA変更、OAuth同意、外部共有、GitHub操作、メール設定 |
| 初動 | 証跡保存、関係者確認、権限一時停止、セッション失効、再レビュー予定 |
記録は、後続の漏えい疑い初動テンプレートへそのまま転記できる粒度にしておくと、CSIRTや法務・広報への引き継ぎが速くなります。
判断基準：高優先で扱う条件
次のいずれかに当てはまる場合は、通常の権限棚卸しではなく、セキュリティ初動として扱います。
| 優先度 | 条件 | 取るべき対応 |
|---|---|---|
| 高 | Global Administrator、Super Admin、Organization owner、クラウド管理者など全体権限 | 証跡保存、承認確認、対象アカウント確認、必要なら即時失効 |
| 高 | 外部ゲスト、委託先、退職者、休職者、長期未利用アカウントへの付与 | 契約・所属・利用目的を確認し、説明できなければ一時停止 |
| 高 | 付与主体が不明、API/サービスプリンシパル経由、深夜・休日、想定外の場所からの操作 | サインインログ、トークン、MFA、セッション、関連SaaS操作を確認 |
| 高 | 付与直後にMFA変更、OAuth同意、外部共有、ログ設定変更、トークン発行が続く | 漏えい疑いとして初動記録へ切り替える |
| 中 | チケットはあるが期限・承認者・失効予定がない | 期限付き権限へ変更し、承認者と再レビュー日を追記 |
| 中 | グループ経由で意図せず広い権限が付いた | グループ所有者、同期元、メンバー変更履歴を確認 |
| 低 | 承認済みの一時作業で、PIM/JIT履歴と期限が一致する | 作業完了後の失効とレビューを記録 |
特に、PAM、JIT Access、Zero Standing Privilegeを導入している組織では、「一時的な権限付与」と「恒久的な管理者追加」を分けて記録します。PIM/JITの有効化履歴があるから安全、ではなく、承認者、理由、実施操作、失効まで確認します。
よくある誤解
「管理者が操作したなら問題ない」
管理者アカウント自体が乗っ取られている可能性、委託先作業の範囲が広すぎる可能性、自動化が誤設定された可能性があります。操作主体だけでなく、理由、対象、スコープ、直後の操作を見ます。
「権限を消せば終わり」
ロールを剥奪しても、付与中に作成されたトークン、外部共有、OAuth同意、GitHub App、メール転送、追加ユーザーが残ることがあります。剥奪前後の操作を確認し、必要に応じて監査ログとログ保管の対象を広げます。
「一時ロールだから記録はいらない」
一時ロールほど、なぜ付与したか、誰が承認したか、いつ失効したかを残す必要があります。監査や事後確認では、実際に付与された期間と操作内容が説明できることが重要です。
「IdPだけ見れば十分」
IdPは入口ですが、SaaS側の管理者ロール、GitHub Organization role、リポジトリ権限、OAuthアプリ、APIトークンは別管理の場合があります。IdPログとSaaS監査ログを同じ時間軸でつなぎます。
関連用語・関連ページ
| 目的 | ページ |
|---|---|
| 実務チェックへ落とす | SaaS権限棚卸しチェックリスト、退職者アカウント確認チェックリスト |
| ログの読み方を整理する | セキュリティログの読み方、監査ログ保管期間の決め方 |
| 関連する棚卸しを読む | SaaS権限棚卸しの進め方、緊急用管理者アカウントの棚卸し、条件付きアクセス例外の棚卸し |
| 漏えい疑いへ進む | 漏えい疑い初動テンプレート |
| 用語を理解する | IAM、PAM、JIT Access、Access Review、RBAC |
| 権限判断の基礎 | 認証と認可の違い、最小権限の原則 |
| 手を動かして学ぶ | アクセスログ解析ミニCTF、認証・認可ミニCTF |
公式情報・参考情報
- Microsoft Learn: What are Microsoft Entra audit logs? — Microsoft Entraの監査ログで確認できる変更、主体、対象、変更前後の値を確認できる。
- Microsoft Learn: List Microsoft Entra role assignments — Microsoft Entraのロール割り当て、対象、スコープの確認方法を確認できる。
- Google Workspace Admin Help: About administrator roles — Google WorkspaceのSuper Admin、限定管理者、カスタムロールの考え方を確認できる。
- Google Workspace Admin Help: Admin log events — Google Workspaceの管理者操作ログと監査・調査カテゴリを確認できる。
- GitHub Docs: Roles in an organization — GitHub Organizationのロールと権限境界を確認できる。
- GitHub Docs: Reviewing the audit log for your organization — GitHub Organizationの監査ログで、誰が何をいつ実行したかを確認できる。
まとめ
管理者権限の付与は、日常運用でも発生します。しかし、強い権限が正規の機能として追加されるからこそ、侵害や誤設定と見分けるには記録が必要です。
最初に見るべき軸は、誰が、誰に、どのロールを、どのスコープで、いつ、なぜ付与したかです。説明できる場合でも、期限と失効予定を残します。説明できない場合は、証跡を残してから権限停止、セッション失効、関連SaaS操作の確認へ進みます。
次の作業として、SaaS権限棚卸しチェックリストに「新規管理者ロール付与」「グループ経由の付与」「PIM/JIT履歴」「外部ユーザーへの高権限付与」を追加し、四半期レビューとインシデント初動の両方で使える状態にしておくとよいでしょう。
