top of page
検索

同意（Consent）を「提出物」に変える：Consent Registry 完成版（台帳テンプレ＋OnePager＋Evidence Pack）

※ここでいう「同意」は Microsoft EntraIDにおける OAuth/OIDC の同意（＝アプリに API 権限を付与する操作） の話です。Cookie同意やマーケ同意とは別物です。

1. 情シスが本当に詰まるのは「同意の中身」ではなく「説明できる形になっていない」こと

事業会社の情シスで、SaaS 連携や拡張導入が進むほど、現場はこうなりがちです。

  • 「このアプリ、誰が、いつ、どの権限を、なぜ付けた？」

  • 「今も使ってる？ 期限は？ 棚卸しした？」

  • 「取引先のセキュリティチェックシートに、“証跡付き”で出せるか？」

多くの組織で、ログや画面は“存在”します。でも 提出できる形（＝台帳・承認・証跡の束） に整っていない。だから監査・取引先照会・インシデント時に詰まります。

Microsoft 側も、同意や権限の付与は 機密性が高い操作で、付与前に要求権限をよく確認すべき と明確に注意しています。

2. 「提出物」として完成させると、監査も取引先照会も一気に通る

同意（Consent）Change管理で、提出物として強いのは次の3点セットです。

  1. Consent Registry（同意台帳）

  2. Change One-Pager（審査紙：誰が見ても判断できる1枚）

  3. Evidence Pack（証跡パック：承認・設定・ログが一箇所に揃う）

これを回す運用（棚卸しの習慣化）まで設計すると、情シスの“説明責任”が成立します。

今回のExcelは、これをそのまま実務に落とすためのテンプレです（上のリンク）。

3. Microsoft Entra の機能は「統制の部品」──提出物に変えるのは“運用設計”

Microsoft Entra には、同意や権限を統制する部品が揃っています。

3.1 アプリ同意ポリシー（誰が同意できるかを制御）

アプリ同意ポリシーは「ユーザーが同意できる条件」を制御する仕組みで、Graph/PowerShell から管理できます。

ポイント

  • 「全部禁止」ではなく、低リスクだけ許す・それ以外は管理者承認に寄せる、が現実解

  • そして、その判断根拠が 提出物（台帳・OnePager） で残るようにする

3.2 アクセス許可の分類（低/中/高）で“ルール化”する

Entra では権限を「低・中（プレビュー）・高（プレビュー）」に分類できます。 さらに、最小サインインに必要な権限として openid / profile / email / offline_access が例示されています。

情シス的に刺さる使い方

  • 「低」だけユーザー同意OK（ただし検証済み発行元など条件付き）

  • 「中/高」は原則：承認フロー必須

  • 「高」は期限付き・代替策検討・棚卸し頻度を上げる

3.3 管理者の同意ワークフローで “申請→審査→承認” を Entra 側に寄せる

ユーザー同意ができない状況でも、管理者同意ワークフローを有効にすることで、ユーザーは「承認要求」を送れます。 また Microsoft は 最小権限ロールの利用 を推奨し、グローバル管理者は緊急時に限定すべきとしています。

つまりワークフロー＝承認の“入り口”は用意できる。でも、承認の“中身（判断材料・証跡化）”はテンプレと運用で作る必要がある。

3.4 「アプリ権限のアクティビティログ」を、台帳の“更新トリガー”にする

Entra のアクティビティログは、アプリの権限付与/削除のイベントを追える仕組みです。 ここを週次・月次で見るだけで、台帳が“生きる” ようになります。

3.5 いざという時に “取り消し” できる設計にしておく

重要な実務ポイント：ポータル上で「ユーザーの同意」タブの権限は、ポータルから取り消せない（Graph/PowerShellが必要）という制約があります。

また、Microsoft Learn には アクセス許可の確認・取り消しの具体的な PowerShell / Graph 手順 が掲載されています。

「承認したら終わり」ではなく、取り消し（ロールバック）が手順化されている ことが提出物として強いです。

3.6 Defender for Cloud Apps で OAuth アプリを“見える化・制御”する

Defender for Cloud Apps では、ユーザーがインストールした OAuth アプリを確認でき、付与権限や付与ユーザーも追えます。 また OAuth アプリ ポリシーで制御ルールを作る設計も可能です。

情シス視点の価値

  • 「野良SaaS連携」を見つける

  • “高権限アプリだけ”を優先的に棚卸し対象にする

  • 禁止/許可の運用が回る

3.7 “不正な同意”は週次レビューが推奨される（提出物が効く）

Microsoft は不正な同意許可（illicit consent grants）の検出に監査ログ検索を挙げ、組織規模によっては 同意許可を週単位で確認する ことを推奨しています。 ここでもやはり「週次レビューの証跡＝提出物」が効きます。

4. 添付Excelテンプレの中身（そのまま運用に載せる設計）

ダウンロードしたExcelは、次の構成です。

00_Readme

最短の使い方と更新履歴。「青字＝入力、黒字＝計算」のルールを明記しています。

01_Consent_Registry（同意台帳の本体）

“監査で出せる粒度” を意識して列を切っています。特に重要なのは以下です。

  • App表示名 / AppID / ServicePrincipal ObjectID


    → 画面のスクショだけだと同名アプリで事故るので、IDで固定する

  • 同意スコープ（Tenant/User/Group）


    → 全社一括か、個別同意か、統制の強さが変わる

  • 権限モード（Delegated/Application）


    → アプリケーション権限（App-only）は特に高リスクになりやすい

  • 付与権限（;区切り）＋権限数（自動計算）


    → まずは量で当たりを付ける（“多い＝要レビュー”の入口）

  • 権限分類（低/中/高）


    → 「承認マトリクス」に直結

  • オーナー3点セット（業務/技術/セキュリティ）


    → 情シスだけにしない。主語を割らない

  • 有効期限・棚卸日・次回棚卸予定


    → 同意を“永続化”させない

  • 証跡パス/URL


    → Evidence Pack にワンクリックで飛べるようにする

さらに、テンプレ内では以下を仕込んでいます。

  • 有効期限が過ぎた/30日以内ならハイライト

  • 業務オーナー/技術オーナーが空欄ならハイライト

  • 権限分類「高」を強調表示

  • Status/環境/YesNo 等はプルダウンで入力ゆれ抑止

02_Change_OnePager（審査紙）

「承認する側が判断できる1枚」を目的にしています。“なぜ必要か（Why）” と “最小権限の検討” を必須にしています。

  • 変更種別（新規/更新/失効/取消）

  • 付与権限（Delegated/Application、権限名、理由）

  • データ種別（個人情報/機密 等）

  • リスク評価と代替策（削れる権限がないか）

  • 実施・ロールバック手順（取り消しができる状態に）

03_Approval_Matrix（承認マトリクス）

権限分類（低/中/高）に応じて、誰が承認するかを固定します。現場で揉めやすいのは「高権限なのに情シス判断だけで通ってしまう」ことなので、ここは明文化が効きます。

04_Review_Checklist（棚卸し運用）

週次／月次／四半期／年次で、最低限やることを整理しています。週次に「新規同意・権限付与イベント」を入れているのは、Microsoft の推奨（週次レビュー）とも整合します。

05_Evidence_Pack_Index（証跡チェック）

Evidence Pack を「何が揃っているか」で点検する表です。監査で強いのは、“揃っていないことが分かること” です（未整備＝是正計画に落とせる）。

06_Reference_URLs

Microsoft公式URLを集約しています（URLは更新されるので、ここをメンテしてください）。

5. Evidence Pack（証跡パック）は“フォルダ設計”が勝ちます

Evidence Pack を強くするコツは、「何を保存するか」以上に 置き場所のルールです。

おすすめのフォルダ構成（例）：

  • /Evidence/CNS-0001/01_Approval/

    • 稟議/ワークフロー承認ログ、チケット履歴、承認メール

  • /Evidence/CNS-0001/02_Screenshots/

    • Entra のアクセス許可画面（付与前後）、発行元情報

  • /Evidence/CNS-0001/03_Exports/

    • Graph/PowerShell で取得した権限一覧（CSV/JSON）

  • /Evidence/CNS-0001/04_Logs/

    • アクティビティログ抽出、監査ログ検索結果

  • /Evidence/CNS-0001/05_Reviews/

    • 月次/四半期レビュー記録、是正チケット

この “固定” があるだけで、監査や取引先照会の速度が変わります。

6. まず1ヶ月で回す「最小実装」ロードマップ（情シス向け）

Week 1：母集団を決める（全部やらない）

  • 高権限（権限分類「高」）

  • 重要業務（経理/人事/営業の基幹連携）

  • 外部SaaS連携（発行元が社外）


    を優先して 上位20件だけ台帳に入れる。

Week 2：承認の入口を固定する

  • 管理者同意ワークフローを有効化し、レビュー担当者を決める（ただしレビュー担当者に権限が自動付与されない点に注意）。

  • “高権限は必ずOnePager” をルール化

Week 3：Evidence Pack を束ねる

  • OnePager → 承認ログ → 設定エクスポート → ログ、の順に揃える

  • 「揃っていない項目」は是正チケット化（05シートで管理）

Week 4：週次レビューを始める

  • アプリ権限のアクティビティログで、付与・削除イベントを追い、台帳を更新する。

  • 週次レビューの記録（チケット）を残す


    （Microsoftも週次確認を推奨している文脈がある）

7. 「取り消し（ロールバック）」を、承認前に設計しておくのが上級者

情シス的に一番怖いのは、

  • 付与したあとで「やっぱり危ない」

  • でも 誰も取り消し手順を持っていない

  • しかも「ユーザー同意」はポータルから取り消せないケースがある

この状態です。

Microsoft Learn には、Entra PowerShell / Graph PowerShell / Graph API による取り消し例が示されています。 OnePager の「ロールバック手順」に、最低限この方向性を固定しておくと、提出物としての強度が段違いになります。

8. 規格・監査目線での「刺さる翻訳」（NIST/ISMSに寄せる）

このテンプレ運用は、ざっくり言うと次を満たします。

  • 資産管理（誰が何を使ってる）：台帳（Consent Registry）

  • アクセス制御（最小権限）：権限分類＋承認マトリクス

  • 変更管理（変更の正当性）：OnePager＋承認ログ

  • 監査証跡（後追い可能）：Evidence Pack

  • 継続監視（放置しない）：週次/月次レビュー

NISTでもISOでも、要求されるのは「ツール名」より 統制が回ること・証跡が出せることです。情シスが最短で勝つには「製品追加」より先に、ここを 提出物 に落とすのが早い。

9. 山崎行政書士事務所が支援できる範囲（非弁の範囲で）

山崎行政書士事務所では、Azure/Entra/M365 の現場運用と、契約・規程・監査提出の“文書側”を噛み合わせる支援を掲げています。

具体的には（※行政書士の業務範囲内として）

  • 台帳・規程・運用手順・RACI・提出用説明文の整備支援

  • 取引先チェックシートに耐える「根拠の揃え方」の設計

  • 技術構成（Entra/ログ/権限）と文書（規程/委託/責任分界）の整合レビュー


    など、“提出できる形”に整えるところを伴走します。

免責

本記事およびテンプレは一般的な情報提供を目的としたもので、個別案件に対する法的助言、紛争の見通し、代理交渉等を行うものではありません。個別具体の法的判断が必要な場合は弁護士等の専門家へご相談ください。

参考リンク（URLそのまま）

 
 
 

最新記事

すべて表示
自動是正は「何を自動にするか」で9割決まる

〜情シス向け：Azure運用の“自動是正対象”をA〜Dで分類して、事故らないルールに落とす〜 ※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。※当事務所（行政書士）は、規程・台帳・運用設計・証跡整備など「ガバナンスの型づくり」を中心に支援します（個別紛争・訴訟等は弁護士領域です）。 1. 情シスの現実：自動化は“正しく怖がらないと”事故装置になる Azureの自動是正（Azur

 
 
 

コメント

Instagram​​

x

note

You Tube

info@shizuoka-yamazaki-jimusho.com

Microsoft、Azure、Microsoft 365、Entra は米国 Microsoft Corporation の商標または登録商標です。
本ページは一般的な情報提供を目的とし、個別案件は状況に応じて整理手順が異なります。

※本ページに登場するイラストはイメージです。
Microsoft および Azure 公式キャラクターではありません。

Microsoft, Azure, and Microsoft 365 are trademarks of Microsoft Corporation.
We are an independent service provider.

​所在地：静岡市

©2024 山崎行政書士事務所。Wix.com で作成されました。

bottom of page