同意のChange管理を“提出物”として仕上げる

山崎行政書士事務所
3月28日
読了時間: 14分

Microsoft Entra ID の Admin Consent を、台帳テンプレ＋承認フロー＋棚卸し運用で「監査に出せる変更管理」に変える

※本記事は一般的な情報提供を目的とするもので、個別案件に対する法的助言・代理交渉・紛争対応を行うものではありません。個別事案では、社内規程・契約・実際の運用体制に応じて、必要に応じ弁護士等と連携して整理してください。

1. まず結論：「同意しました」ではなく「この変更パッケージが証跡です」に変える

事業会社の情シスが本当に困るのは、Admin Consent を付与した事実そのものではありません。困るのは、その後にこう聞かれた瞬間です。

誰が、どのアプリに、どの権限を、いつ、なぜ許可したのか
その権限は今も必要なのか
期限はあるのか
どのログで確認できるのか
不要になったら、どうやって取り消すのか

Microsoft は、テナント全体の管理者同意を付与すると、そのアプリは「組織全体に代わって」要求されたアクセス許可にアクセスできるようになり、これは機密性の高い操作だと明記しています。例として、ロール管理、全メールボックスや全サイトへのフルアクセス、完全なユーザー偽装などが挙げられており、同意前に要求権限を慎重に確認すべきとされています。さらに、付与できるロールも限定されており、特権ロール管理者は任意の API 権限に同意できる一方、クラウドアプリケーション管理者やアプリケーション管理者は Microsoft Graph のアプリケーション権限を除く範囲に制約されています。

山崎行政書士事務所の「Admin Consent を Change as Code にする」という整理も、まさにここを突いています。Admin Consent は「一度通ると影響が長く残りやすい」ため、PR・承認・証跡に落とし、「誰が・何のアプリに・どの権限を・いつ・なぜ許可したか」を“提出物”で即答できる状態にする、という考え方です。また、valid_until を必須化して“同意の永久化”を防ぎ、提出演習で提出 SLA を言い切れる状態まで持っていくべきだとしています。

2. なぜ「同意」をChange管理に格上げすべきなのか

理由は3つあります。

2-1. 同意は“設定変更”ではなく“権限委任”だから

同意は、ただの UI 操作ではありません。Microsoft の Zero Trust 観点のドキュメントでも、スコープやアクセス許可の要求はリソース所有者が許可または拒否し、Microsoft Entra ID ではその所有者はユーザーか、すべてのユーザーに代わって同意できる管理者だと整理されています。つまり、同意は認証の補助操作ではなく、認可の意思決定です。

2-2. アプリの要求権限は後から変わる

アプリは最初に要求した権限のまま一生固定されるわけではありません。Microsoft は、アプリの要求アクセス許可を更新するシナリオとして、追加・削除・置き換えの3つを示しており、しかも重要なのは、要求アクセス許可を更新しても自動では許可も取り消しもされないことです。新たに追加された権限には管理者や顧客が同意する必要があり、不要になった権限も手動で取り消す必要があります。つまり、「最初に通したから終わり」ではありません。

2-3. 監査ログは残るが、“理由”は勝手に補完してくれない

Microsoft Entra には監査ログがあり、アプリ権限に関しては、

サービスプリンシパルにアプリロールの割り当てを追加する
サービスプリンシパルからアプリロールの割り当てを削除する
委任されたアクセス許可の付与の追加
アプリケーションへの同意

といった監査アクティビティを追えます。つまり「何が起きたか」はかなり追えます。ですが、なぜ許可したのか、誰が業務必要性を認めたのかは、ログだけでは埋まりません。そこを埋めるのが Change 管理の提出物です。

3. ゴールは「ポータル操作の記録」ではなく「提出パッケージの完成」

情シスが目指す完成形は、次の状態です。

新規付与・増権・減権・撤回のすべてが、チケット→審査→承認→実行→証跡化の流れに乗る
同意台帳（Consent Registry）が “正” になっていて、今の正しい状態を一発で説明できる
未登録の同意や手動変更を ドリフト として拾える
すべての同意に 期限（valid_until） と再承認条件がある
監査や取引先照会に対して、Evidence Pack をそのまま提出できる

この設計思想は、Microsoft の機能とも整合します。ユーザー同意は組織全体に対するグローバル設定として管理され、アプリ同意ポリシーは「どのような場合に同意を許可できるか」を制御できます。しかもこれらは Microsoft Graph や Graph PowerShell でも管理可能です。つまり、同意ポリシー自体を“変更管理の対象”にできるわけです。

4. まず作るべき提出物は5つだけ

ここは情シス向けに、最小構成で示します。最初から大きく作らず、この5点を先に固定すると回りやすいです。

4-1. Consent Registry（同意台帳）

現時点で有効な同意の正本。「何が許可されているか」を示す台帳です。

4-2. Change One-Pager

その変更1件を1枚で説明する紙。監査・上長・取引先に最も効きます。

4-3. Approval Record

誰が承認したか、どの観点で見たかの記録。監査ログではなく、判断の根拠を残す場所です。

4-4. Execution Log

実際に誰がどこで同意・取り消し・設定変更を行ったかの記録。

4-5. Evidence Pack

チケット、差分、承認、実行ログ、監査ログ、画面証跡を束ねた提出用パッケージ。

山崎行政書士事務所の記事でも、最終的には Change Evidence（提出パッケージ） を整備し、「監査・取引先の質問はこの提出物ですで終わる」状態を作ることが重要だと整理されています。

5. 台帳テンプレ：最低限この列を持てば、提出物になる

以下は、そのまま社内台帳に使える最小テンプレです。Excel でも SharePoint List でも Git 管理の YAML/CSV でも構いませんが、列の意味を固定することが大事です。

5-1. 台帳の推奨列

record_idenvironmentapp_display_nameapp_idservice_principal_object_idpublisher_nameverified_publisherapp_typeconsent_scopepermission_modepermissions_grantedbusiness_purposedata_classificationbusiness_ownertechnical_ownerrequest_ticket_idchange_typerisk_levelcompensating_controlsapproved_by_businessapproved_by_securityapproved_by_privileged_adminapproved_atexecuted_byexecuted_atvalid_untilrenewal_requiredrollback_planmonitoring_rulecurrent_statuslast_review_atnext_review_atevidence_pack_idnotes

5-2. この列が必要な理由

app_id / service_principal_object_id

表示名は変わるので、識別子が必要
consent_scope / permission_mode

テナント全体か、特定ユーザーか。委任かアプリケーションか
permissions_granted

“何を許したか” の本体
business_owner / technical_owner

所有者不明の同意は、実質的に無管理
valid_until

期限なし同意は、ほぼ必ず増殖する
evidence_pack_id

監査に出すファイル束との紐付け

Microsoft の Entra 管理センターでは、アプリごとに [管理者の同意] タブ と [ユーザーの同意] タブ で、組織全体に付与された権限か、特定ユーザー/グループに付与された権限かを確認できます。したがって、台帳でもこの違いを分けて持つべきです。なお、ポータルから取り消せるのは管理者同意側であり、ユーザー同意の取り消しは Graph API または PowerShell が必要です。

5-3. YAML で持つならこの形

app_key: "sp:Contoso-CRM"environment: "prod"app_display_name: "Contoso CRM Connector"app_id: "11111111-2222-3333-4444-555555555555"service_principal_object_id: "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"publisher_name: "Contoso Ltd."verified_publisher: trueconsent_scope: "tenant"permission_mode: "application"permissions_granted:  - "Mail.Read"  - "Files.Read.All"business_purpose: "CRM連携に必要な顧客案件メールと関連資料の参照"data_classification: "Internal"business_owner: "営業企画部"technical_owner: "情報システム部"request_ticket_id: "CHG-2026-0315-01"change_type: "new"risk_level: "HIGH"compensating_controls:  - "月次棚卸し"  - "Defender監視"  - "アクセス権の最小化"approved_by_business: "営業企画部長"approved_by_security: "情報セキュリティ責任者"approved_by_privileged_admin: "特権ロール管理者"approved_at: "2026-03-15"executed_by: "Cloud Application Administrator"executed_at: "2026-03-15"valid_until: "2026-09-30"renewal_required: truerollback_plan: "不要時は権限取り消し→動作確認→台帳更新"monitoring_rule: "OAuth-App-Review-HIGH"current_status: "approved"last_review_at: "2026-03-15"next_review_at: "2026-06-30"evidence_pack_id: "EV-2026-0315-CRM-01"notes: "次回更新時にFiles.Read.Allの縮小可否を再評価"

山崎行政書士事務所の Change as Code 記事でも、Consent Registry（同意台帳）を SSOT（正）にすること、valid_until を必須化すること、Change OnePager に対象アプリ・権限・変更種別・承認者・期限・変更後検証を書くことが強調されています。

6. 承認フローは「情シスだけで抱えない」ほうが強い

管理者同意ワークフローを使うと、ユーザーが自分で同意できない場合に管理者承認を要求でき、レビュー担当者には通知が届きます。ユーザーは「承認が必要」画面から理由を入力して承認要求を送り、その後の承認・拒否・ブロックの結果も通知されます。

しかもレビュー担当者は、要求を処理するときに

アクセス許可と同意の確認
アプリの詳細
要求者と要求理由

を確認でき、承認・拒否・ブロックを選べます。ブロックすると、以後そのアプリについて同意要求が上がらないようにでき、サービスプリンシパルは無効状態で作成されます。

6-1. 推奨フロー

Step 0. 申請

利用部門または開発担当が申請フォームを出す。申請に必要な項目は最低でも以下です。

アプリ名 / 提供元 / URL
利用目的
対象データ
要求権限
利用部門
希望期限
代替手段の有無

Step 1. 情シス一次審査

技術的に見るポイントは4つです。

委任権限か、アプリケーション権限か
Microsoft Graph のアプリケーション権限を含むか
業務目的に対して過剰な権限がないか
既存アプリで代替できないか

Step 2. 業務責任者承認

必要性の承認は、データオーナーが持つべきです。情シスだけで「業務上必要」と断言しない方が強いです。

Step 3. セキュリティ/ガバナンス承認

データ区分、委託先、越境、保存先、監視ルールを確認。

Step 4. 特権承認

ここが重要です。Microsoft の仕様では、管理者同意ワークフローのレビュー担当者は要求を表示・ブロック・拒否できますが、Microsoft Graph のアプリケーション権限を要求するアプリの要求を承認できるのはグローバル管理者だけです。また、テナント全体の管理者同意そのものは、特権ロール管理者が任意の API に対して付与でき、クラウドアプリケーション管理者/アプリケーション管理者は Microsoft Graph のアプリケーション権限を除く範囲です。

Step 5. 実行

承認後に、Entra 管理センターで実行。ただし、手順そのものより、実行結果を台帳と Evidence Pack に落とすことが重要です。

Step 6. 証跡生成

チケット、承認記録、前後の権限スナップショット、監査ログ、ロールバック手順を束ねる。

7. RACI はこう切ると現実的

申請者（利用部門）              : R業務責任者（データオーナー）     : A（業務必要性）情報システム部（一次審査・実行） : R情報セキュリティ責任者           : C / A（高リスク時）特権管理者 / グローバル管理者    : A（特権同意）監査証跡担当（閲覧系ロール）     : R（提出物収集）

ここで地味に重要なのは、証跡収集の担当者にフル管理権限を持たせなくてよいことです。アプリ権限のアクティビティログを見るだけなら、Microsoft は前提ロールとして レポート閲覧者、セキュリティ閲覧者、セキュリティ管理者、グローバル閲覧者 を挙げています。つまり、証跡収集と特権実行を分離しやすいわけです。

8. Change One-Pager テンプレ：これが“提出物の顔”になる

監査や取引先に一番効くのは、長い説明ではなく1枚物です。以下のテンプレをそのまま使えます。

件名：Admin Consent 変更申請 One-Pager1. 対象アプリ- app_display_name:- app_id:- service_principal_object_id:- publisher_name:- verified_publisher:2. 変更種別- 新規 / 増権 / 減権 / 撤回3. 要求・付与対象の権限- delegated:- application:- admin consent required:- 高権限判定:4. 利用目的- 対象業務:- 対象部門:- 想定利用者:- 代替手段:5. 取り扱うデータ- data_classification:- 個人情報:- 社外共有:- 委託/越境:6. リスク評価- 想定影響:- 補助統制:- 監視ルール:- ロールバック手順:7. 承認- 業務責任者:- セキュリティ責任者:- 特権承認者:- 承認日時:8. 有効期限- valid_until:- 再承認要否:- 次回レビュー日:9. 証跡- request_ticket_id:- evidence_pack_id:- 関連監査ログ:

山崎行政書士事務所の記事でも、1ページ＋差分データで説明できる形が重要とされており、Change Evidence 側では Plan diff、承認記録、期限、変更後検証などを必須化する方針が示されています。

9. Evidence Pack テンプレ：監査・取引先にそのまま出せる構成

ChangeEvidence/  00_Readme.txt  01_Request/    request_form.pdf    ticket_export.pdf  02_Assessment/    permission_review.csv    risk_assessment.md  03_Approval/    approval_record.md  04_Execution/    pre_permissions_snapshot.csv    post_permissions_snapshot.csv    execution_log.md  05_Audit/    entra_audit_log.csv    app_permission_activity_log.csv  06_Rollback/    rollback_plan.md  07_Review/    next_review_schedule.txt

9-1. この構成が強い理由

00_Readme

「何を見ればいいか」を相手に考えさせない
04_Execution

実行前後の差分があるので、増権・減権が一目で分かる
05_Audit

“誰がいつ何をしたか” を監査ログで裏打ちできる
07_Review

一度きりでなく、期限付きで運用されていることを示せる

山崎行政書士事務所の是正 Runbook でも、提出物の型として00_Readme / 01_Logs / 02_App / 03_Actions / 04_Preventionのように整理し、「直しました」で終わらず説明責任に耐える形を求めています。

10. 棚卸し運用は「年1回」では弱い。月次＋四半期で回す

同意管理で事故る会社は、台帳を作って終わります。必要なのは、更新され続ける運用です。

10-1. 月次運用

毎月見るべき項目はこの5つです。

Unknown Consent

台帳にない同意が発生していないか
期限切れ同意

valid_until を過ぎたものが残っていないか
Owner 不明

business_owner / technical_owner が空欄のもの
高権限の残存

Graph アプリケーション権限や高リスク権限が必要以上に残っていないか
要求権限と現行権限の差分

アプリ側の変更を追えているか

Microsoft Entra では、アプリ権限の監査ログをフィルタして

アプリ専用アクセス権の付与/削除
委任アクセス権の付与
アプリケーションへの同意

を追跡できます。月次棚卸しでは、この監査ログを台帳と突合するのが基本です。

10-2. 四半期運用

四半期ごとにやるべきは、**再承認（recertification）**です。

この同意はまだ業務上必要か
権限は縮小できないか
期限を延長する合理性があるか
代替アプリや内製化で外せないか

“今も必要です” を毎回口頭で済ませないこと。再承認結果は Approval Record に追記し、valid_until を更新します。

10-3. 年次運用

年1回だけやるのは、ポリシーの棚卸しです。

ユーザー同意は今のままでよいか
検証済み発行元＋低リスク権限だけ許す運用に寄せられないか
開発者向け例外ポリシーが増殖していないか
権限分類を見直す必要はないか

Microsoft は、既定ではユーザーが管理者同意不要の権限に同意できる一方、悪意あるアプリにだまされるリスク軽減のため、検証済みの発行元によるアプリにのみユーザー同意を許可することを推奨しています。また、低リスクポリシーや AdminOnly のような permission grant policy を使い分けられます。

11. 監視は2系統で持つと強い：Entra と Defender

11-1. Entra 側：正本確認

Entra 側は、本当に何が付与されているかを見る場所です。

Enterprise applications > Permissions
Admin consent タブ
User consent タブ
App permissions activity logs
Graph / PowerShell による取得と取り消し

特に重要なのは、ポータルでは User consent タブの権限を取り消せない点です。ユーザー同意の撤回は Microsoft Graph または PowerShell が必要なので、撤回系の Change には「どのコマンド/どの API で消すか」を実行計画に含めるべきです。

11-2. Defender for Cloud Apps 側：見える化と止血

Defender for Cloud Apps では、OAuth アプリごとに

承認者数
アクセス許可レベル（高・中・低）
アプリ状態（承認済み、禁止済み等）
CSV エクスポート
承認者の詳細エクスポート
禁止/承認操作

が可能です。禁止時はユーザー通知も選べますし、承認済みマークはエンドユーザー挙動を変えず、運用上の識別に使えます。

ただし重要な注意があります。Defender for Cloud Apps の OAuth アプリ一覧は、委任されたアクセス許可を要求するアプリのみを識別します。つまり、アプリケーション権限（app-only）中心の棚卸しは Entra 側で補完が必要です。ここを見落とすと、「Defenderで見えているから全件見えている」と誤解します。

12. よくある失敗と、その直し方

失敗1：台帳が“結果”ではなく“メモ”になっている

表示名だけ、担当者メモだけ、期限なし。これでは提出物になりません。識別子、権限、承認者、期限、証跡ID を固定列にしてください。

失敗2：承認フローが“情シスの善意”に依存している

技術審査と業務必要性の承認を、同じ人がやってしまう。これだと後から「誰が必要性を認めたのか」が曖昧になります。

失敗3：撤回フローがない

新規付与の手順だけあって、減権・撤回の手順がない。しかもユーザー同意の撤回がポータルでできないことを知らずに止まる。最初から revoke 用テンプレ を別で用意してください。

失敗4：同意ポリシー変更で既存ポリシーを消す

Graph/PowerShell で authorizationPolicy を更新する際、既存の permissionGrantPoliciesAssigned を見ずに上書きすると、別の必要ポリシーまで消しやすいです。Microsoft も、更新前に現在の authorizationPolicy を必ず取得し、既存ポリシーを保持するよう注意しています。