不正同意が出たときの是正 Runbook（revoke → 追跡 → 報告書）
- 山崎行政書士事務所
- 2025年12月28日
- 読了時間: 6分
本Runbookは、Microsoft 365 / Entra ID 環境で 不正（または不要）な OAuth 同意（アプリ同意・権限付与） が発生した際に、止血（revoke）→ 追跡（ログ）→ 報告（説明責任） を一気通貫で終わらせるための手順書です。
山崎行政書士事務所のクラウド法務の観点では、ここで重要なのは「直した」よりも、**“なぜ起き、何をし、何が残ったかを第三者に説明できる形にする”**ことです。
0. 適用範囲と前提
適用範囲
ユーザーが OAuth 同意した（本人が承認操作した）
不審な Enterprise Application / Service Principal が増えた
“Consent to application” 系の監査ログがアラートになった
取引先・監査で「このアプリ同意は何？」と指摘された
役割（最低限）
IR責任者（司令塔：判断・指揮）
Entra管理者（設定・revoke・無効化）
SOC/監視担当（ログ追跡・証跡保全）
法務/コンプラ窓口（報告範囲・対外説明）
現場窓口（情シス）（対象ユーザー連絡・業務影響整理）
1. 初動トリアージ（5分で決める）
1-1. “不正同意”判定の目安
次のいずれかなら 不正同意（高） として扱う（＝止血優先）
ユーザーが「覚えがない」「メール/QRで誘導された」
付与権限が強い（メール/ファイル/ディレクトリ広範囲）
Publisher が不明、名前が紛らわしい、作成直後
同意の直前直後に不審サインインがある（海外/深夜/短時間多発）
1-2. 優先度（Severity）
SEV1：全社影響・高権限・拡散疑い（即停止）
SEV2：特定ユーザー/部門・中権限（即停止＋追跡）
SEV3：低権限・誤同意疑い（停止＋確認）
2. 止血（Containment）— まず revoke（15分以内）
ここは “迷ったら強め” が基本です。あとで戻せますが、漏えいは戻りません。
2-1. 対象アプリの即時措置（最優先）
対象アプリを無効化（Disable）
組織全体の同意／権限を取り消し（Revoke）
可能なら Service Principal の削除（削除は最終判断）
ポイント：最初は Disable + Revoke で止める。削除は証跡確保後に。
2-2. 対象ユーザーの即時措置
サインアウト強制（セッション失効）
パスワード変更（必要時）
MFA 再登録（疑いが強い場合）
ポイント：OAuth同意は “トークンで継続利用” が要点。セッション失効はセット。
2-3. 追加の安全弁（状況により）
条件付きアクセスで 該当ユーザーを一時的にブロック
影響が大きい場合は 同意ポリシー（ユーザー同意）を一時的に絞る（管理者承認のみ など）
3. 追跡（Investigation）— “誰が・いつ・何を”を固める（60〜180分）
3-1. 最低限の証跡を確保する（最初に保存）
Entra Audit logs：同意・Service Principal 作成・権限付与のイベント
Entra Sign-in logs：当該ユーザーのサインイン（異常地点/Client/App）
対象アプリの権限画面：付与権限の一覧（スクショ/エクスポート）
重要：スクショは「画面全体が写る」こと。監査で“切り抜き”は弱いです。
3-2. 追跡で必ず押さえる観点（監査で聞かれる）
同意した ユーザーID と 日時
対象アプリの AppId / Service Principal（識別子）
付与された権限（Scope / Role）
同意直前直後のサインイン位置（国・IP・デバイス）
そのアプリが実際にアクセスした痕跡（可能な範囲で）
3-3. “横展開”の確認（再発・拡大の芽を摘む）
同じアプリが 他ユーザーにも同意されていないか
同意を誘発したメール/チャットが 社内に拡散していないか
似た名前のアプリが 複数増えていないか
4. 根絶（Eradication）— revokeを“完全に終わらせる”（当日中）
止血で止めただけだと、再発しやすいです。ここで “残骸” を消します。
4-1. 権限の根絶チェックリスト
組織全体の Admin consent を取り消したか
ユーザー単位の Delegated permission grant が残っていないか
アプリロール割当（AppRoleAssignment）が残っていないか
対象ユーザーのセッションが失効できているか（再サインイン要求になるか）
4-2. 追加対策（再発防止の“技術側”）
ユーザー同意の制御（原則禁止/制限、管理者承認へ）
Admin consent workflow の適用（申請・承認・記録）
Device Code Flow など認証フローの利用制限（条件付きアクセス）
監視ルール（Consentイベント）をアラート化
5. 復旧（Recovery）— 業務影響を整理しながら戻す
5-1. 業務影響の整理
当該アプリが業務に使われていた場合：代替手段を提示
“正当なアプリだった”可能性がある場合：再承認は 管理者経由で実施
重要：復旧は「元に戻す」ではなく「統制を強めた上で通す」。
6. 報告書（Report）— 監査・取引先で一撃回答する書き方
ここがクラウド法務の本丸です。「直しました」で終わらず、説明責任に耐える形にします。
6-1. 報告書テンプレ（そのままコピペ可）
件名：OAuth 不正同意インシデント報告書（一次／最終）
概要（Executive Summary）
何が起きたか（1〜3行）
影響範囲（暫定）
実施した止血措置（Disable / Revoke / セッション失効 など）
検知経路（Detection）
監視アラート／ユーザー申告／監査指摘 など
検知日時
事象の詳細（What happened）
同意されたアプリ名（表示名）
識別子（AppId / Service Principal）
付与された権限（主要なもの）
同意実行者（ユーザー）と日時
タイムライン（Timeline）
T0：同意
T1：検知
T2：止血（Disable / Revoke / セッション失効）
T3：追跡・影響調査
T4：恒久対策反映
影響評価（Impact Assessment）
対象データ（メール／ファイル／ディレクトリ等）
実際にアクセスが発生した確度（高/中/低）
影響ユーザー数・部署
原因分析（Root Cause）
直接原因：ユーザーが同意操作を実施 等
背景要因：ユーザー同意許可、承認フロー未整備、監視不足 等
再発要因：例外運用、教育不足 等
実施した対策（Actions Taken）
即時：Disable / Revoke / セッション失効
追跡：ログ保全、横展開確認
恒久：同意ポリシー変更、CA強化、監視ルール追加
再発防止策（Preventive Measures）
同意ポリシー（管理者承認のみ等）
Admin consent workflow（レビューア／承認記録）
Device Code Flow 制限
監視と教育（1文ルール）
添付資料（Evidence Pack）
Audit logs（該当イベント）
Sign-in logs（該当期間）
対象アプリの権限画面（スクショ）
実施した設定変更の証跡（スクショ/変更記録）
6-2. Evidence Pack（提出ファイルの型）
監査で強い提出物は “型” が決まっています。
00_Readme（提示資料一覧）
01_Logs（Audit / Sign-in）
02_App（権限画面・識別子）
03_Actions（Disable/Revoke/セッション失効の証跡）
04_Prevention（同意ポリシー・承認フロー・CAの設定証跡）
7. “よくある失敗”と回避策（短く）
削除を先にやる → ログ・識別子が追えなくなる→ 原則：Disable → 証跡確保 → Revoke → 最終削除
「同意を取り消した」だけ → 既存セッションが残る→ セッション失効を必ずセット
報告書に識別子がない → 後から同一性が証明できない→ AppId / SP を必ず記録
山崎行政書士事務所のクラウド法務としての位置づけ
OAuth同意は、技術的には「権限付与」ですが、統制的には “権限委任の意思決定” です。したがって、事故対応で最も重要なのは 「技術で止めた」＋「説明できる証跡で閉じた」 という形にすることです。
参照リンク集
アプリ同意攻撃のインシデント対応プレイブック（Microsoft）
Enterprise applications の権限レビューと取り消し（管理センター手順）
ユーザー同意の設定（制御方針）
同意要求の管理と評価（推奨事項）
ユーザーのアクセス剥奪（緊急時の基本
Graph：ユーザーのサインインセッション失効（revokeSignInSessions）
Graph：Delegated permission grant の削除（oAuth2PermissionGrant delete）
Graph PowerShell：API権限の付与・取り消し（実務手順）
統合監査ログでの OAuth 悪用調査（Microsoft Security Experts Blog）
山崎行政書士事務所（クラウド法務）https://www.shizuoka-yamazaki-jimusho.com/
コメント