Admin Consent（同意）をChange as Codeにする誰が何の権限を許可したかを“提出物”で即答する「同意しました」ではなく「この変更パッケージが証跡です」で終わらせる

※本稿は一般的な情報提供であり、個別案件の法的助言ではありません。取引先審査・監査提出・委託（MSP）・個人情報/越境・ログ保管の扱いは、社内規程および専門家と連携して整理してください。

※本稿の目的は“安全に速い運用の型”を作ることです。特定の環境/ライセンス/組織構造により手順は調整が必要です。

────────────────────────────────

0. この記事のゴール（最終形）

────────────────────────────────

Admin Consent（管理者同意）は、Entra IDの中でも「一度通ると影響が長く残りやすい」領域です。

だからこそ、Change as Code（PR・承認・証跡）に落とし、監査・取引先に即答できる状態を作ります。

ゴール（完成形）

・Admin Consentの新規付与/変更/撤回が、必ずチケット→PR→承認→適用→証跡生成の流れに乗る

・「誰が」「何のアプリに」「どの権限を」「いつ」「なぜ」許可したかが、1ページ＋差分データで説明できる

・未知の同意（勝手な同意）をドリフト検知で拾い、Auto PRで“是正提案”まで自動化できる

・期限（valid_until）と再承認（延長）を必須化し、“同意の永久化”を防ぐ

・演習（提出演習）で提出SLAを言い切れる（例：通常2営業日、インシデント24h一次提出）

────────────────────────────────

Admin Consentで起きがちな“事故の型”

────────────────────────────────

事故A：権限が過剰なまま固定される

・本当は読み取りだけで良いのに、書き込み・全社スコープの権限が付く

・後から縮めたいが「怖くて触れない」→永住化

事故B：誰が許可したか説明できない

・ポータルで操作したが、チケットもPRも無い

・監査ログを掘っても、根拠（理由・承認）が出せない

事故C：取引先審査で詰む

・「どんな権限を付与していますか？」に、一覧と判断根拠が出せない

・個人情報/委託/越境の論点（どこに何が流れるか）が整理されていない

事故D：例外が増殖する

・「一時的に必要」で同意したが、期限が無い

・延長が無限に続き、棚卸し不能

結論：Admin Consentは “例外債務” になりやすい。

だから「同意の台帳」「期限」「再承認」「止血」を最初から仕込むのが現実的です。

────────────────────────────────

2. “同意”をChange as Codeにする基本思想（自動是正ではなく提案PR）

────────────────────────────────

Admin Consentは、いきなり自動撤回すると業務停止の別事故を作りがちです。

そこで、Auto PRの思想をそのまま適用します。

・検知：新規同意/変更/撤回を検知

・提案：同意台帳の更新、期限付与、縮小案、撤回案をPRとして提示

・承認：A（最終責任）＋Security（必要なら法務/プライバシー）

・適用：承認後にパイプラインで実施（手動変更を減らす）

・証跡：Change Evidence（提出パッケージ）を自動生成

“止血は自動（検知・起票・提案PR）”

“治療は承認付き（適用はPRマージ後）”

────────────────────────────────

3. SSOT（正）を作る：Consent Registry（同意台帳）をリポジトリで管理

────────────────────────────────

Change as Codeを成立させるには、「望ましい状態（意図）」が必要です。

それが Consent Registry（同意台帳）です。

推奨リポジトリ構成（最小）

IdentityRepo/

01_registry/

consent_registry.yaml

consent_exceptions_registry.yaml

02_baseline/

consent_baseline_policy.yaml

high_risk_permissions.yaml

03_autopr/

consent_autopr_rules.json

templates/

PR_Template_Consent_Request.txt

PR_Template_Consent_Drift.txt

Change_OnePager_Consent.template.txt

04_jobs/

detect_consent_drift.ps1

generate_consent_autopr.ps1

apply_consent_changes.ps1

05_evidence/

build_consent_change_evidence.ps1

build_consent_monthly_evidence.ps1

06_docs/

Runbook_Consent_Change.txt

Evidence_Navigation_Consent.txt

ポイント

・同意の“意図”は01_registryに集約（SSOT）

・同意の“危険判定”は02_baselineで共通化（権限辞書・閾値）

・検知→Auto PR→適用→証跡、の製造ラインを04/05で固定

────────────────────────────────

4. consent_registry.yaml（同意台帳）の設計：最小フィールドで“提出できる”

────────────────────────────────

同意台帳は、監査・取引先の質問に即答できる形が大切です。

以下はそのまま使える最小テンプレです。

consent_registry.yaml（例：コピペ用）

app_key: "sp:Contoso-CRM"

environment: "prod"

owner: "team-crm"

vendor: "Contoso"

app_type: "enterprise_app" （enterprise_app / app_registration / multi_tenant 等）

data_classification: "Internal" （例：Public/Internal/Confidential）

consent_scope: "tenant" （tenant / specific_users 等）

permissions:

delegated_scopes:

- "User.Read"

- "Mail.Read"

application_roles:

- "Directory.Read.All"

justification: "CRM連携のため。メール参照は特定業務のみ。"

risk_level: "HIGH" （LOW/MEDIUM/HIGH/CRITICAL）

compensating_controls:

"最小権限（必要な権限のみ）"

"ログ提出パッケージで月次棚卸し"

ticket: "CHG-2026-0701-01"

status: "approved" （pending/approved/retired/rejected）

approved_by: ["A", "Security"]

approved_at: "2026-07-01"

valid_until: "2026-12-31"

renewal_required: true

notes: "次回更新時にDirectory.Read.Allの縮小可否を評価"

app_key: "sp:Vendor-Analytics"

environment: "prod"

owner: "team-secops"

vendor: "VendorX"

app_type: "enterprise_app"

data_classification: "Confidential"

permissions:

delegated_scopes: []

application_roles:

- "AuditLog.Read.All"

justification: "監査ログ収集（SIEM連携）"

risk_level: "CRITICAL"

ticket: "CHG-2026-0615-02"

status: "pending"

approved_by: []

valid_until: "2026-06-22"

notes: "承認前。法務/委託/ログ保管方針の整合確認が必要。"

運用の肝（言い切りルール）

・status=pending は期限（valid_until）必須

・approved も期限必須（同意の永久化を防ぐ）

・高リスク権限は必ずrisk_levelをHIGH以上にして承認線を引き上げる

・「誰が何の権限を許可したか」は、台帳＋Change Evidenceで答える

────────────────────────────────

5. “高リスク権限”を辞書化する（レビューが速くなる）

────────────────────────────────

同意レビューが揉めるのは「危険度の基準」がないからです。

基準を辞書にします。

high_risk_permissions.yaml（例）

・Directory.Write 系

・User.Write 系

・RoleManagement.* 系

・Application.Write 系

・Policy.* 系

・Mail.*（範囲に応じて）

・offline_access（運用次第で扱いを固定）

・AuditLog.Read.All などの監査・ログ系（用途は正当化されやすいが、漏えい時の影響は大きい）

ポイント

・辞書があると「これはCRITICALだからA＋Security＋追加承認が必要」が機械で言える

・辞書がないと“空気で判断”になり、属人化します

────────────────────────────────

6. Changeの型：同意変更は“3種類”に分類して運用する

────────────────────────────────

同意変更は実務上、3種類に分けると整理が速いです。

タイプ1：新規同意（New Consent）

・新しいアプリに権限を許可する

→ 原則、必ずPRでレビュー（例外はBreak-glass扱い）

タイプ2：変更（Expand / Reduce）

・権限の追加（Expand）

・権限の削減（Reduce）

→ Expandは承認線を強く、Reduceは計画（Plan）と影響確認を丁寧に

タイプ3：撤回（Revoke）

・同意/権限を撤回して無効化する

→ 影響が大きいのでPlan（差分）とロールバック方針を必ず付ける

この分類をPRラベルとテンプレに埋め込むと運用が安定します。

────────────────────────────────

7. 同意リクエストPRテンプレ（そのまま使える）

────────────────────────────────

PRタイトル（例）

[Consent][New][HIGH] Admin consent request for Vendor-Analytics (CHG-2026-0701-01)

PR本文テンプレ（コピペ用）

────────────────────

【Admin Consent Request / Change Proposal】

Change type

New / Expand / Reduce / Revoke : （選択）

App information

app_key: sp:（名称）

vendor: （ベンダ）

owner: （責任チーム）

environment: prod / nonprod

Requested permissions

A) Delegated scopes（ユーザー委任）

（列挙）

B) Application roles（アプリ権限）

（列挙）

Purpose / Justification（目的）

何のために必要か（業務機能・範囲・頻度）

代替案はあるか（より小さい権限、別方式）

Risk assessment（リスク）

risk_level: LOW/MEDIUM/HIGH/CRITICAL

想定影響（漏えい時・誤用時）

補助統制（監視、最小権限、利用レビュー、ログ提出）

Data & compliance notes（必要なら）

取り扱うデータ区分（data_classification）

委託/取引先/越境の留意点（社内規程に従う）

Expiry / Review（期限と見直し）

valid_until: YYYY-MM-DD（必須）

renewal_required: YES/NO

次回見直しで縮小/撤回する条件

Rollback plan（失敗時）

Reduce/Revokeの場合：復旧手順（戻す条件・手順・期限付き復旧の可否）

New/Expandの場合：問題発生時の撤回手順

Evidence（提出物）

Plan diff（権限差分）：04_Plan_Diff/plan_diff.csv（生成予定）

Change Evidence（マージ後自動生成）：Entra_Consent_ChangeEvidence_CHG-XXXX/

Required approvals

Accountable（A）：必須

Security：HIGH以上は必須

Privacy/Legal：データ区分や委託条件により必須（社内規程に従う）

────────────────────

このテンプレの狙い

・同意の「理由」「権限」「期限」「承認線」「ロールバック」をPRに固定

・監査の質問がPRだけで半分終わる

────────────────────────────────

8. PIMのPlanと同じ発想で“Consent Plan（差分）”を作る

────────────────────────────────

同意変更も、結局は「現状→望ましい状態」の差分です。

PIM Planと同様に、監査が読める形に整えます。

Consent Planパッケージ（例）

Entra_Consent_Plan_CHG-XXXX_YYYYMMDD/

00_Readme/Plan_OnePager.txt

01_Request/request.json

02_Before/permissions_before.csv

03_Desired/consent_registry.yaml

04_Plan_Diff/plan_diff.csv

05_Approvals/approvals_required.txt

06_Integrity/sha256sums.txt build_manifest.txt

plan_diff.csv（推奨列）

・delta_type（ADD_PERMISSION / REMOVE_PERMISSION / UPDATE_EXPIRY / CONTROL_ONLY 等）

・change_direction（IncreasePrivilege / DecreasePrivilege / ControlOnly）

・app_key

・permission_kind（delegated/application）

・permission_name

・risk_level

・before（present/absent）

・after（present/absent）

・valid_until_after

・approval_required（A/Security/…）

・reason（短文）

・ticket

ポイント

・IncreasePrivilegeが混ざったら承認線が上がる（自動判定）

・期限更新だけのChange（ControlOnly）も監査では重要（棚卸しが回っている証拠）

────────────────────────────────

9. ドリフト検知：勝手な同意（Unknown Consent）を拾う

────────────────────────────────

Change as Codeを作っても、現場で起きがちなのはこれです。

「誰かがポータルで同意してしまう」「ベンダ作業で増える」

だから、同意もドリフト検知します。

ドリフト種別（Finding）

・Unknown Consent：台帳にない同意/権限が存在

・Permission Expand：台帳より権限が増えている

・Expiry Missing/Expired：期限なし、または期限切れの同意が残っている

・High Risk Added：高リスク権限が追加された

・Owner Missing：責任者不明のアプリ/同意

これを日次または週次で集計し、Auto PRにつなげます。

────────────────────────────────

10. Auto PR（提案PR）の出し方：勝手な同意を“握りつぶさず追跡”する

────────────────────────────────

同意ドリフトに対して、Auto PRは次のどちらかを提案します。

提案A：正当化できる場合

・consent_registry.yaml に pending で登録（期限は短め、例：7日）

・承認線（A＋Security）を付ける

・最小権限へ縮小案があれば併記（次のPR候補）

提案B：正当化できない場合

・撤回（Revoke）計画PR（Plan付き）を提案

・影響評価（利用状況・依存）を先に行う手順を添付

重要

・Auto PRは“いきなり撤回”しない（業務停止の別事故を避ける）

・ただし、高リスクが無断追加された場合は「即起票＋止血」まで自動で行う

────────────────────────────────

11. “止血モード”を同意にも適用する（例外バーンダウンの統合）

────────────────────────────────

同意は例外債務になりやすいので、例外予算と止血が効きます。

例外予算（例）

・CRITICAL権限を含む同意：最大 N（小さく）

・期限なし同意：0

・期限切れ同意：0

・Owner不明：0

止血トリガー（例）

・Unknown Consentが1件でも発生（高リスクなら即止血）

・期限切れ同意が1件でも残存

・CRITICAL権限の新規同意が短期間で増加

・承認線無しで増権が発生（＝手動変更の疑い）

止血中に止めること（現場で効く順）

・新規のAdmin Consent PRを原則止める（Break-glass以外）

・例外はA＋Security＋期限短め＋事後Evidence必須

・既存の是正（縮小・撤回・期限付与）だけ通す

これで「増える速度＞直す速度」に負けなくなります。

────────────────────────────────

12. Change Evidence（同意版）：監査・取引先に“そのまま出す”提出物

────────────────────────────────

同意変更は、証跡が薄いと一気に説明が苦しくなります。

だからChange Evidenceを標準化します。

Entra_Consent_ChangeEvidence_CHG-XXXX/

00_Readme/Change_OnePager.txt

01_Request_Approval/

Ticket_Snapshot.txt

PR_Summary.txt

Approval_Record.txt

02_Plan/

permissions_before.csv

permissions_after.csv

plan_diff.csv

diff_summary.txt

03_Audit/

audit_events_last24h.csv

04_Validation/

validation_summary.csv

postcheck_unknown_consents.txt

05_Integrity_Custody/

sha256sums.txt

build_manifest.txt

custody_record.txt

Change_OnePager.txt に必ず書く（短文でOK）

・対象アプリ（app_key）

・許可した権限（delegated/application）

・変更の種別（新規/増権/減権/撤回）

・承認者（A/Security/必要なら法務等）と日時

・期限（valid_until）と見直し条件

・変更後検証（Unknown Consent=0 など）

────────────────────────────────

13. 取引先・監査の質問に即答する“想定問答”（Evidence Navigation）

────────────────────────────────

想定問答を固定すると、毎回の提出が速くなります。

Q：どのアプリに、どの権限を許可していますか？

→ consent_registry.yaml（承認済み一覧）

Q：誰がいつ承認しましたか？

→ ChangeEvidence/01_Request_Approval/Approval_Record.txt

Q：今回、権限は増えましたか？

→ ChangeEvidence/02_Plan/plan_diff.csv（change_direction）

Q：期限はありますか？期限切れはありませんか？

→ consent_registry.yaml（valid_until）＋月次Evidenceの期限切れ一覧

Q：勝手な同意（未知の同意）はありませんか？

→ ChangeEvidence/04_Validation/postcheck_unknown_consents.txt

→ 月次Evidence/judgement.json（PASS/FAIL）

Q：委託（MSP）でも統制できていますか？

→ custody_record.txt（証跡庫の主語）＋RACI（社内規程/運用資料）

────────────────────────────────

14. 委託（MSP）でも主語が崩れない置き方（同意は特に重要）

────────────────────────────────

同意は「委託先が勝手に許可した」状態が最悪です。

最小限、次を固定します。

固定ルール（最小）

・最終責任（A）：自社（同意の可否、期限、提出判断）

・実行（R）：MSP可（検知ジョブ、Auto PR生成、Evidence生成）

・証跡庫（Evidence Store）：自社管理（原本は自社に残す）

・緊急例外（Break-glass相当）：最小化＋事後Evidence必須（例：24h以内）

────────────────────────────────

15. 最短導入（7日で“同意をChange as Code”にする）

────────────────────────────────

Day1：同意台帳（consent_registry.yaml）テンプレ確定、期限必須ルール決定

Day2：高リスク権限辞書（high_risk_permissions.yaml）と承認線（A/Security）を固定

Day3：同意リクエストPRテンプレ導入（チケット・理由・期限・ロールバック必須）

Day4：Consent Plan（差分）生成（before/after/plan_diff）を作る

Day5：Change Evidence（同意版）の雛形を作り、sha256/build_manifest/custodyを必須化

Day6：ドリフト検知（Unknown Consent/増権/期限切れ）→Auto PR生成まで繋げる

Day7：提出演習（取引先想定）を1回回し、提出SLAを言い切れる状態にする

────────────────────────────────

まとめ：Admin Consentは“台帳＋期限＋差分＋証跡”で初めて統制できる

────────────────────────────────

・Admin Consentは影響が長く残りやすい。だからChange as Code（PR＋承認＋証跡）に落とす

・同意台帳（consent_registry）で「意図」を固定し、Plan（差分）で「何が変わるか」を提出物にする

・ドリフト検知で“勝手な同意”を拾い、Auto PRで握りつぶさず追跡する

・期限と再承認を必須化し、例外予算と止血モードで増殖を防ぐ

・Change Evidence（同意版）があると、監査・取引先の質問は「この提出物です」で終わる