認可の全体像：Entra・M365・Power Platform・Azure の権限はどこで決まるか
「誰が何をできるか」は1か所では決まらず、Entra ID、各サービスの中、アプリへの同意という複数の場所に分かれています。このガイドは、第3部 守りの運用ガイド：記録・可視化とデータ・活動の保護 の「事後の守り」に対する「事前の守り」として、権限の置き場所と役割分担を整理します。第I部で共通の考え方と Entra の役割を、第II部で M365・Power Platform・Azure の各世界を、第III部で権限を正しく保つ運用を扱います。
## 第I部 共通の基礎1. 認可の基本モデル
どのサービスの権限も、「誰が（主体）、何に対して（リソース）、何をできるか（操作）、どの範囲で（スコープ）」の4要素で説明できます。名前や画面が違っても、この4つに分解すれば比較できます。
| 要素 | 意味 | 例 |
|---|---|---|
| 主体（誰が） | 権限を持つ側。人だけでなくアプリも含む | 社員、ゲスト、グループ、アプリ、マネージド ID |
| リソース（何に） | 操作される対象 | メールボックス、SharePoint サイト、Power Apps のアプリ、仮想マシン |
| 操作（何を） | 許される動作 | 読む、書く、削除する、共有する、設定を変える、権限を与える |
| スコープ（どの範囲で） | 権限が及ぶ広さ | テナント全体、管理単位、環境、サブスクリプション、特定のサイト |
ロールは「操作のまとまり」に名前を付けたものです。権限の付与は、「主体に、あるスコープで、ロールを割り当てる」という形で行われます。
管理操作とデータ操作を分けて考える
権限には「仕組みの設定を変える」ものと「中身のデータを読み書きする」ものがあります。Azure では前者を管理プレーン、後者をデータプレーンと呼びますが、考え方はどの世界でも役に立ちます。
- Exchange 管理者はメールボックスの設定を変えられるが、それだけでは他人のメールを開けない（ただし「自分にアクセス権を与える」操作はできる）。
- SharePoint 管理者はサイトを作れるが、個々のサイトの中身を見るにはそのサイトの権限が別に要る。
- Azure の「所有者」はストレージアカウントを削除できるが、ブロブの中身を Entra 認証で読むにはデータ用のロールが別に要る。
ここで大事なのは「管理操作で自分にデータ操作の権限を与えられる」ことです。管理者権限が「実質的に全部見られる」と言われるのはこのためで、管理者権限を厳しく管理し、その操作を記録する理由がここにあります。
権限の「継承」
多くの世界で、上位のスコープで与えた権限は下位に継承されます（Azure の管理グループ→サブスクリプション→リソース、SharePoint のサイト→ライブラリ→ファイル）。上位で広く与えると全てに及ぶため、権限は「必要な一番下のスコープ」で与えるのが原則です。
2. 全体像：4つの世界と権限の置き場所
Entra ID は、すべての世界に共通する「主体の台帳」と「テナント全体の管理者の役割」を持ちます。一方、「このメールボックス、このサイト、この環境、この仮想マシンに何ができるか」は、それぞれの世界の中で決まります。
各世界は Entra の利用者やグループを使って権限を付与しますが、権限の中身は独自の仕組みで持ちます。この「主体は共通、権限は各世界」という構造が、全体像をつかみにくくしている正体です。
Entra と各世界をつなぐ 3つの経路
| 経路 | 中身 | 例 |
|---|---|---|
| 主体の利用 | 各世界は Entra の利用者・グループ・アプリに権限を付与する | SharePoint サイトに Entra のセキュリティグループを追加 |
| ロールの連動 | Entra のディレクトリロールが各世界の管理者権限になる | Entra の「Exchange 管理者」「Power Platform 管理者」 |
| テナントの頂点 | グローバル管理者はどの世界も最終的に支配できる | Azure への「アクセスの昇格」（第9章） |
ただし Azure だけは、Entra のディレクトリロールが自動では効きません。Azure の権限は Azure RBAC で別に付与する必要があり、この違いは第9章で扱います。
3. 主体の種類：「誰が」は人だけではない
権限を持つ主体は、大きく「人」と「人以外（ワークロード ID）」に分かれます。人の権限は退職や異動で見直されますが、人以外の権限は誰も見ないまま何年も残りがちです。
| 主体 | 実体 | 注意点 |
|---|---|---|
| 社員（メンバーユーザー） | Entra のユーザー。多くは ADDS から同期 | 異動のたびに権限が「足されるだけ」になりやすい |
| ゲスト（B2B） | 他組織の ID を自社テナントに招待したもの | 招待した人がいなくなっても残る。期限とレビューが必要 |
| 管理者アカウント | 管理作業専用に分けたユーザー | メールや Web 閲覧に使わない。ロールは PIM で必要時のみ |
| 緊急用アカウント | 条件付きアクセスの外に置いたグローバル管理者 | 使えば必ずアラート（第3部） |
| グループ | 主体を束ねたもの。自身も権限の対象になる | メンバーを変える権限が、実質的に権限を配る権限になる（第4章） |
| アプリ登録とサービスプリンシパル | アプリの設計図（登録）と、テナント内での実体（サービスプリンシパル） | 秘密キーや証明書で認証。管理者がいないまま強い権限を持つことがある |
| マネージド ID | Azure のリソース（仮想マシンや関数）に付く ID | 秘密キー管理が不要で安全。付与した権限の棚卸しは必要 |
| Power Platform の接続 | Flow やアプリが外部サービスに接続するための資格情報 | 作成者本人の権限で動くことが多い（第8章） |
「アプリ登録」と「サービスプリンシパル」の関係
アプリ登録は、アプリがどんな権限を求めるかを書いた設計図です。サービスプリンシパル（Entra の画面では「エンタープライズアプリケーション」）は、そのアプリが自社テナントに存在する実体で、実際の権限はこちらに付与されます。他社の SaaS を使い始めると、自社テナントにサービスプリンシパルだけが作られます。つまり「自社で作っていないアプリも、自社のデータへの権限を持ちうる」ということです。
4. グループ：すべての世界をつなぐ「つなぎ役」
Entra のグループは、どの世界でも権限付与の対象に使える共通部品です。便利な反面、「グループに1人追加する」だけで、そのグループが使われているすべての場所の権限が増えます。グループのメンバーを変えられる人（所有者や管理者）は、実質的に「権限を配れる人」です。
グループの種類
| 種類 | 用途 | 特徴・注意点 |
|---|---|---|
| セキュリティグループ | アクセス権の付与、ポリシーの割り当て | 権限の入れ物として最も汎用的。ADDS から同期されたものはオンプレで管理 |
| M365 グループ | チームでの共同作業 | Teams・SharePoint・メールボックスなどがセットで作られる。所有者は利用者自身であることが多い |
| メールが有効なセキュリティグループ／配布リスト | メールの一斉送信 | 配布リストは権限付与には使えない |
| 動的グループ | 部署や勤務地などの属性でメンバーを自動決定 | 異動で自動的に入れ替わる。属性を変えられる人が権限を左右できる |
| ロール割り当て可能グループ | Entra の管理者ロールをグループで付与 | 作成時にしか指定できず、動的にはできない。メンバー変更できる人が限定される（第5章） |
グループ設計の考え方
- 用途で分ける：「部署を表すグループ」と「権限を表すグループ（例：経理システム編集者）」を分け、権限は後者に付与する。部署グループを直接使うと、異動や組織変更のたびに権限が大きく動く。
- 用途を名前に書く：「CA-」「INT-」「AZ-」のような接頭辞で、どの世界で何に使われているかが名前からわかるようにする。
- 所有者を決める：所有者不在のグループは誰もメンバーを見直さない。所有者は「権限を配る人」として扱う。
- M365 グループは共同作業用：Teams を作ると M365 グループができる。これを業務システムや Azure の権限付与に流用すると、チーム所有者（一般社員）がその権限を配れてしまう。
5. Entra の役割：テナント全体の管理者を決める
Entra のディレクトリロールは「テナントの設定や各サービスを管理する権限」です。一般利用者が業務データに触る権限は、ここではなく各世界の中で決まります。
ロールの主な分類
| 分類 | 代表的なロール | できること | 危険度 |
|---|---|---|---|
| テナント全体 | グローバル管理者 | すべて。Azure も自分で権限を取れる | 最高。常時付与しない |
| 権限を配る権限 | 特権ロール管理者、特権認証管理者 | 他人に管理者ロールを付与、管理者の認証方法を変更 | グローバル管理者と実質同等 |
| 入口の制御 | 条件付きアクセス管理者、セキュリティ管理者 | 条件付きアクセスやセキュリティ設定の変更 | 高。入口の守りを外せる |
| アプリ管理 | アプリケーション管理者、クラウドアプリケーション管理者 | アプリの設定、資格情報の追加、同意の付与 | 高。強い権限を持つアプリになりすませる |
| 利用者・グループ管理 | ユーザー管理者、グループ管理者、ヘルプデスク管理者 | ユーザー作成、パスワードリセット、グループのメンバー変更 | 中〜高。権限付きグループの操作で権限が広がる |
| 各サービスの管理 | Exchange、SharePoint、Teams、Intune、Power Platform の各管理者 | そのサービスの全体設定 | 中〜高。その世界の「グローバル管理者」 |
| 参照のみ | グローバル閲覧者、セキュリティ閲覧者、レポート閲覧者 | 設定やレポートの閲覧 | 低。監査や外部委託先に使う |
Entra の画面では、権限昇格につながりうるロールに「特権（PRIVILEGED）」の印が付いています。名前が「管理者」でなくても、「自分や他人の権限を増やせる操作」を含むロールは特権として扱います。
スコープを絞る仕組み
| 仕組み | 内容 | 使いどころ |
|---|---|---|
| 管理単位（Administrative Unit） | ユーザー・グループ・デバイスを範囲で区切り、ロールをその範囲だけに付与 | 拠点やグループ会社ごとのヘルプデスクに委譲 |
| 制限付き管理の管理単位 | その管理単位に紐づかない管理者には、中のオブジェクトを変更させない | 役員や管理者アカウントを一般のユーザー管理者から守る |
| カスタムロール | 必要な操作だけを組み合わせたロール | 組み込みロールでは強すぎるとき |
| ロール割り当て可能グループ | グループ経由でロールを付与。一般のグループ管理者はメンバーを変えられない | 管理者チームへのロール付与。PIM と組み合わせる |
ロール割り当て可能グループが特別扱いなのは、第4章の問題を防ぐためです。普通のグループに管理者ロールを付与できると、グループ管理者が自分をメンバーに加えるだけでグローバル管理者になれてしまいます。
6. アプリの権限：同意で生まれる「もう一つの権限」
M365 のデータは、画面からだけでなく Microsoft Graph などの API 経由でも読み書きできます。API を使うアプリが持つ権限は「同意（Consent）」で与えられ、委任とアプリケーションの2種類があります。この違いを知らないと、「便利なツール」に全社データを渡してしまうことがあります。
| 観点 | 委任（Delegated） | アプリケーション（Application） |
|---|---|---|
| 誰として動くか | サインインした利用者の代理 | アプリ自身（サービスプリンシパル） |
| 影響範囲 | その利用者が元々できる範囲まで | 権限の対象全体（多くはテナント全体） |
| 同意できる人 | 設定次第で利用者自身。強い権限は管理者 | 常に管理者 |
| 条件付きアクセス | 利用者のサインインとして効く | 利用者向けポリシーは効かない（ワークロード ID 向けの制御が別に必要） |
| 典型例 | Outlook アドイン、会議ツールの予定表連携 | バックアップ製品、アーカイブ、人事システム連携 |
同意の管理で決めること
- 利用者同意の範囲：Microsoft は「検証済み発行元のアプリと自社アプリについて、低リスクの権限だけ利用者が同意できる」設定を推奨しています。利用者同意を全面禁止にすることもできます。
- 管理者同意のワークフロー：利用者が同意できないアプリを申請し、管理者が審査する流れを用意する。禁止だけだとシャドー IT を招く。
- 「割り当てが必要」の設定：エンタープライズアプリごとに、割り当てたユーザー・グループだけが使えるようにできる。
- アプリの資格情報と所有者：秘密キーの有効期限、誰が資格情報を追加できるか。アプリの所有者や「アプリケーション管理者」は、そのアプリの強い権限を使える立場にある。
アプリケーション権限の範囲を絞る
Exchange Online では「アプリケーション向け RBAC」で、アプリが読めるメールボックスを管理単位やフィルターで絞れます。ただし Entra 側の権限と Exchange 側の権限は「足し算」で評価されるため、Entra でテナント全体の Mail.Read を同意したままだと絞り込みは効きません。「広い方の権限を外してから、狭い方を付ける」が原則で、これは世界をまたぐ権限全般に当てはまります。SharePoint にもサイト単位でアプリに権限を与える Sites.Selected という仕組みがあります。
第II部 各世界の権限
7. M365 の世界
M365 は「サービスの集合体」で、Exchange・SharePoint・Teams などがそれぞれ独自の権限モデルを持ちます。共通するのは、管理者の権限が Entra のロールと連動し、一般利用者の権限は各サービスの中で決まることです。さらに「利用者自身が権限を配れる」（共有、チームへの招待）のが他の世界との大きな違いです。
| サービス | 管理者の権限 | 利用者・データの権限 | 誰が権限を配れるか |
|---|---|---|---|
| Exchange Online | Exchange の役割グループ（Organization Management など）。Entra の Exchange 管理者と連動 | メールボックスの「フルアクセス」「代理送信」「送信者として送信」、予定表の共有 | Exchange 管理者。予定表は利用者自身も |
| SharePoint / OneDrive | SharePoint 管理者（テナント設定、サイト作成） | サイトの所有者・メンバー・閲覧者、フォルダーやファイル単位の共有 | サイト所有者、そして共有リンクを作る利用者 |
| Teams | Teams 管理者（ポリシー、外部アクセス設定） | チームの所有者・メンバー・ゲスト。実体は M365 グループ | チーム所有者 |
| Purview | Purview の役割グループ（コンプライアンス管理者、eDiscovery 管理者など） | ラベルを使える人の範囲、暗号化されたファイルの閲覧権 | Purview 管理者、ラベルを付ける利用者 |
| Intune | Intune の RBAC ロールとスコープタグ（第2部） | ―（端末管理のため利用者データ権限はない） | Intune 管理者 |
| Defender | Defender の統合 RBAC（アラートの閲覧、端末隔離などの対応操作） | ― | セキュリティ管理者 |
SharePoint の権限が複雑になる理由
SharePoint は、テナント → サイト → ライブラリ → フォルダー → ファイルの順に権限が継承されます。そこに共有リンクが加わると、「サイトのメンバーではないのに、このファイルだけは見える」人が生まれます。
| 共有リンクの種類 | 開ける人 | 危険度 |
|---|---|---|
| すべての人（Anyone） | リンクを知っている誰でも。サインイン不要 | 最高。転送されると追跡できない |
| 組織内のユーザー | リンクを知っている社員全員 | 中。社内での過度な公開になりやすい |
| 特定のユーザー | 指定した人だけ | 低 |
| アクセス権を持つユーザー | すでに権限がある人（場所を知らせるだけ） | 最低 |
共有の上限は、テナント全体の設定→サイトごとの設定の順で「より厳しい方」が効きます。第3部のコンテナーラベルを使うと、「社外秘サイトは社外共有不可」をラベルで強制できます。
Teams と M365 グループの関係
チームを作ると、M365 グループと SharePoint のチームサイトが同時に作られ、チームの所有者＝グループの所有者＝サイトの所有者になります（第4章の図）。プライベートチャネルや共有チャネルはそれぞれ別の SharePoint サイトを持ち、チーム全体とは異なるメンバーで権限が決まります。チームの作成を誰に許すか、所有者不在のチームをどう扱うかは、M365 の権限管理で最も決めておきたい方針の1つです。
Exchange の注意点
- 共有メールボックスの「フルアクセス」は、会社組織の変更で見直されずに残りがち。
- Exchange 管理者は自分に他人のメールボックスへのフルアクセスを付与できる（第1章の管理操作→データ操作）。この操作は監査ログで確認できるようにする。
- メールの自動転送を利用者が設定できると、社外への持ち出し経路になる。外部への自動転送は既定で制限されているが、例外設定の有無を確認する。
8. Power Platform の世界
Power Platform（Power Apps、Power Automate、Copilot Studio など）は、一般社員が「作る側」になれるのが最大の特徴です。そのため権限の考え方も、「管理者が配る」だけでなく「作った人が共有する」「作った人の資格情報で動く」が前提になります。
| 層 | 権限の持ち方 | 主なロール | 決めること |
|---|---|---|---|
| ① テナント | Entra のディレクトリロール | Power Platform 管理者、Dynamics 365 管理者 | 誰が環境を作れるか、テナント全体のデータポリシー |
| ② 環境 | 環境ごとのロール、セキュリティグループでの制限 | 環境管理者、環境作成者（Dataverse なしの環境） | 環境の分け方（開発・テスト・本番、部門別） |
| ③ Dataverse | セキュリティロール、ビジネスユニット | システム管理者、システムカスタマイザー、Basic User | テーブルごと・行ごとに誰が読み書きできるか |
| ④ アプリ・Flow | 作成者による共有、共同所有者 | 所有者、共同所有者、利用者 | 共有できる範囲、所有者不在時の引き継ぎ |
| 接続 | 接続を作った人の資格情報（またはサービスプリンシパル） | ― | 個人の資格情報で動かしてよい業務か |
管理者ロールとデータ権限は別物
Power Platform 管理者やグローバル管理者でも、それだけでは Dataverse のデータには触れません。データを扱うには、その環境で「システム管理者」のセキュリティロールを別に付与される必要があります。第1章の「管理操作とデータ操作の分離」が、ここでは「テナントの管理者ロール」と「環境内のセキュリティロール」という形で現れています。ただしテナント管理者は自分にそのロールを付与できるため、やはり特権として扱います。
接続が生む「見えない権限」
Flow が SharePoint や Outlook に書き込むとき、多くの場合は作成者本人の接続（資格情報）が使われます。このため次のようなことが起きます。
- 作成者が共有したアプリを使う人が、アプリの設計次第で作成者の権限を借りてデータに触れてしまう。
- 作成者が退職すると接続が切れ、業務の Flow が止まる。逆に、異動しても作成者の権限で Flow が動き続ける。
- 個人のクラウドストレージや SNS への接続を作れると、業務データの持ち出し経路になる。
これを抑えるのがデータポリシーです。コネクタを「業務用」「非業務用」「ブロック」に分け、業務用と非業務用を同じアプリ・Flow で混ぜられないようにします。変更は通常数時間以内に反映され、違反した既存の Flow は停止されます。本番業務の Flow は、個人ではなくサービスアカウントやサービスプリンシパルの接続で動かすのが原則です。
環境戦略
全社員が使える「既定の環境」は個人の生産性向けと割り切り、部門の本番業務は専用の環境に分けるのが一般的です。専用環境はセキュリティグループで入れる人を限定し、より厳しいデータポリシーを掛けます。マネージド環境を使うと、共有範囲の制限や利用状況の可視化など、管理機能を追加できます。
9. Azure の世界
Azure の権限は Azure RBAC で管理され、「主体に、あるスコープで、ロールを割り当てる」という第1章のモデルが最もそのままの形で現れます。他の世界との最大の違いは、Entra のディレクトリロールが Azure の権限にはならないことです。Entra のグローバル管理者でも、そのままでは Azure のリソースは見えません。
代表的なロール
| ロール | できること | 注意点 |
|---|---|---|
| 所有者（Owner） | すべての管理操作と、他人へのロール付与 | 権限を配れるため、実質的にそのスコープの頂点 |
| 共同作成者（Contributor） | リソースの作成・変更・削除 | ロールの付与はできない。開発チームの標準 |
| 閲覧者（Reader） | 構成の閲覧 | 監査やセキュリティ担当向け |
| ユーザーアクセス管理者 | ロールの付与だけ | 自分に所有者を付与できるため、所有者と同等に扱う |
| データ用ロール（例：ストレージ BLOB データ閲覧者、Key Vault シークレットユーザー） | データプレーンの読み書き | 管理ロールとは別に付与する |
管理プレーンとデータプレーン
Azure では「リソースを管理する権限」と「中のデータを扱う権限」が明確に分かれています。例えば共同作成者はストレージアカウントを削除できますが、Entra 認証でブロブを読むにはデータ用ロールが別に必要です。ただし「アクセスキー」などの共有キーが有効な場合、管理権限でキーを取得してデータに触れられてしまうため、共有キーを無効化して Entra 認証に寄せるのが推奨です。
Entra と Azure の境界：アクセスの昇格
Entra のグローバル管理者は、設定1つで自分を Azure のルート（「/」）スコープの「ユーザーアクセス管理者」にできます。これは、Azure の所有者がいなくなったときの救済手段ですが、裏を返せば「グローバル管理者＝すべての Azure の支配者になれる」ことを意味します。この操作は Entra の監査ログに記録されるため、第3部の仕組みで必ずアラート対象にします。
人以外の主体と Azure ポリシー
- マネージド ID：Azure 上のアプリは、秘密キーを持たずにマネージド ID で他のリソースにアクセスする。付与するロールは「そのリソースの、そのデータ用ロール」に限定する。
- サービスプリンシパル：CI/CD のデプロイに使われることが多く、サブスクリプションの所有者など強い権限を持ちがち。
- Azure Policy：RBAC が「誰が操作できるか」を決めるのに対し、Azure Policy は「どんな設定なら許すか」を決める（例：公開 IP の付与禁止、共有キー禁止）。権限があっても危険な設定はできない、という第2の壁。
10. 4つの世界の比較
ここまでの内容を、第1章の観点で並べます。「この権限はどこで決まっているのか」に迷ったときの早見表として使えます。
| 観点 | Entra ID | M365 | Power Platform | Azure |
|---|---|---|---|---|
| 主なスコープ | テナント、管理単位 | サービス、サイト、メールボックス、ファイル | テナント、環境、テーブル・行 | 管理グループ、サブスクリプション、リソースグループ、リソース |
| 管理者の権限の置き場所 | ディレクトリロール | Entra ロールと各サービスの役割グループ | Entra ロールと環境ロール | Azure RBAC（Entra ロールは効かない） |
| データの権限の置き場所 | ― | サイト権限、共有リンク、メールボックス権限 | Dataverse セキュリティロール、アプリの共有 | データ用 RBAC ロール |
| 一般利用者が権限を配れるか | グループ所有者として | 配れる（共有、チーム招待） | 配れる（アプリや Flow の共有） | 通常は配れない |
| 人以外の主体 | アプリ、サービスプリンシパル | Graph 経由のアプリ権限 | 接続（作成者の資格情報） | マネージド ID、サービスプリンシパル |
| 「権限があってもできない」仕組み | 条件付きアクセス | 秘密度ラベル、DLP、共有設定の上限 | データポリシー | Azure Policy |
| 頂点にいる人 | グローバル管理者 | 各サービス管理者（さらに上にグローバル管理者） | Power Platform 管理者 | ルートの所有者（グローバル管理者は昇格で到達可能） |
表から読み取れるのは次の3点です。
- どの世界も「権限」と「できることの上限」の2枚重ね。RBAC だけでなく、条件付きアクセス、ラベル、データポリシー、Azure Policy といった「上限」を併せて設計する。
- M365 と Power Platform は利用者が権限を配れる世界。管理者が全部を把握するのは不可能なので、上限の設定と定期レビューが中心になる。
- どの世界の頂点にも Entra のグローバル管理者がいる。だからこそグローバル管理者は最少人数にし、常時付与しない。
第III部 権限を正しく保つ運用
11. 権限を正しく保つ仕組み
権限は「与えるとき」より「外すとき」に漏れます。異動しても古い権限が残り、プロジェクトが終わってもゲストが残り、管理者権限は「念のため」付けっ放しになります。Entra ID Governance（一部は Entra ID P2）の機能は、この「外し忘れ」を仕組みで防ぐためのものです。
| 仕組み | 役割 | 対象にできる世界 | 防ぐもの |
|---|---|---|---|
| Privileged Identity Management（PIM） | 管理者権限を「資格」として持たせ、必要なときだけ申請・承認・MFA で有効化。期限で自動解除 | Entra ロール、Azure RBAC、グループ（PIM for Groups 経由で各世界の権限も） | 常時特権、管理者アカウント乗っ取り時の被害 |
| アクセスパッケージ（エンタイトルメント管理） | グループ、アプリ、SharePoint サイトなどを「業務に必要な一式」としてまとめ、申請・承認・期限付きで付与 | M365、アプリ、グループ経由で Power Platform・Azure も | 権限の個別依頼、期限なしのゲスト |
| アクセスレビュー | グループメンバーやロール保持者を定期的に所有者や上長が確認。未回答は自動で外す設定も可能 | Entra ロール、グループ、アプリ、Azure RBAC、ゲスト | 異動後の残存権限 |
| ライフサイクルワークフロー | 入社・異動・退職のイベントで、グループ追加・削除やアカウント無効化を自動実行 | Entra（グループ経由で各世界） | 手作業の外し漏れ |
| 動的グループ | 人事属性に応じてメンバーを自動更新 | Entra（グループ経由で各世界） | 部署単位の権限の更新漏れ |
「グループを介して管理する」という設計の意味
上の仕組みの多くは Entra のグループを対象にします。そのため、各世界の権限を「個人に直接」付けるのではなく「用途別のグループに」付けておくと、アクセスパッケージやレビュー、PIM を M365・Power Platform・Azure にまとめて効かせられます。第4章で「危険」と書いたグループの広がりを、逆に「一元管理の入口」として使う考え方です。
この仕組みが前提とするのは、第2部で扱った「人事を正本とする ID の自動管理」です。部署や役職などの属性が正しく流れていないと、動的グループもライフサイクルワークフローも正しく動きません。
12. よくある落とし穴
実際の事故や監査指摘は、「世界の境目」や「人以外の主体」で起きるものが多くあります。
| 落とし穴 | 何が起きるか | 関係する世界 | 対策 |
|---|---|---|---|
| 異動しても古い権限が残る | 前部署のサイトや共有メールボックスに触れ続ける | M365、Power Platform | 動的グループ、アクセスレビュー、異動時ワークフロー |
| 「すべての人」リンクが転送される | 社外の誰でも開け、追跡もできない | M365 | テナントで無効化または有効期限、秘密度ラベルで制限 |
| 「組織内」リンクで全社公開状態 | 人事資料などが検索や AI アシスタントで社内の誰にでも見つかる | M365 | 既定のリンク種類を「特定のユーザー」に、過度な共有の定期棚卸し |
| 所有者不在のチーム・グループ | 誰もメンバーやゲストを見直さない | M365、Entra | 所有者は2人以上、所有者不在の検出と引き継ぎ |
| 退職者の Flow が止まる／動き続ける | 業務が止まる、または誰の管理も受けずにデータを動かし続ける | Power Platform | 本番 Flow はサービス用の接続、共同所有者の設定 |
| 個人クラウドへの接続 | Flow 経由で業務データを自動で持ち出せる | Power Platform | データポリシーで非業務用またはブロック |
| 過剰な権限を持つアプリ | 外部ツールが全メールボックスや全サイトを読める | Entra、M365 | 管理者同意の審査、Sites.Selectedや Exchange のアプリ向け RBAC で絞る、定期棚卸し |
| アプリの所有者が資格情報を追加 | 一般社員が強いアプリの権限を使えてしまう | Entra | 強い権限のアプリの所有者を管理者に限定、資格情報追加のアラート |
| グローバル管理者の常時付与 | 乗っ取られると全世界が奴られる | 全体 | PIM、最少人数、フィッシング耐性 MFA |
| CI/CD のサービスプリンシパルが所有者 | パイプラインの秘密キー漏えいで Azure が奴られる | Azure | 共同作成者以下に絞る、ワークロード ID フェデレーションで秘密キーをなくす |
| 部門の Teams グループを Azure 権限に流用 | チーム所有者（一般社員）が Azure 権限を配れる | M365、Azure | 権限用のセキュリティグループを分ける |
「組織内」リンクの問題は、M365 Copilot のような AI アシスタントの導入で特に重要になっています。AI は利用者がアクセスできる範囲のデータを使うため、「権限上は見られるが、誰も気づいていなかった」データが表に出てきます。導入前に過度な共有を棚卸しするのは、本書の「事前の守り」そのものです。
13. 設計原則とチェックリスト
7つの設計原則
- 権限は「必要な一番下のスコープ」で与える。継承で下に広がることを前提に考える。
- 管理操作とデータ操作を分けて考える。ただし管理者は自分にデータ権限を与えられるので、管理者権限そのものを絞る。
- 「権限を配れる権限」を特権として扱う。グループ所有者、アプリ所有者、Azure の所有者・ユーザーアクセス管理者も含む。
- 権限は個人ではなく用途別のグループに付ける。部署グループや Teams の M365 グループを流用しない。
- 人以外の主体にも所有者と期限を持たせる。アプリ、サービスプリンシパル、Flow の接続を台帳で管理する。
- 「権限」と「できることの上限」を組み合わせる。条件付きアクセス、ラベル、データポリシー、Azure Policy。
- 付与より剥奪を自動化する。期限付きの付与、定期レビュー、人事連携。
確認チェックリスト
- グローバル管理者は緊急用を含め最少人数で、緊急用以外は PIM で必要時のみ有効化している
- 特権ロール（PRIVILEGED 印）の保持者一覧を四半期ごとにレビューしている
- 管理者ロールをグループで付与する場合はロール割り当て可能グループを使っている
- 利用者同意は「検証済み発行元・低リスク権限のみ」または禁止で、管理者同意の申請フローがある
- アプリケーション権限を持つアプリの一覧と所有者、秘密キーの期限を把握している
- SharePoint の「すべての人」リンクの方針（禁止・期限付き）を決めている
- Teams（M365 グループ）の作成者、ゲスト招待、所有者不在時の方針がある
- Power Platform のデータポリシーがテナント全体にあり、本番用の環境が分かれている
- 本番業務の Flow が個人の接続に依存していない
- Azure の所有者・ユーザーアクセス管理者の割り当てを管理グループ以下すべてで棚卸ししている
- 「アクセスの昇格」とグローバル管理者の付与がアラート対象になっている（第3部）
- ゲストには有効期限か定期レビューがある
用語集（本書で初めて登場するもの）
| 用語 | 意味 |
|---|---|
| Azure Policy | Azure 上で許す設定・禁止する設定を強制する仕組み |
| Azure RBAC | Azure のリソースに対するロールベースの権限管理 |
| Dataverse | Power Platform のデータ基盤。テーブルと行単位の権限を持つ |
| Microsoft Graph | M365 や Entra のデータを扱う共通 API |
| PIM | 管理者権限を必要なときだけ有効化する仕組み |
| Sites.Selected | アプリに特定の SharePoint サイトだけの権限を与える仕組み |
| アクセスパッケージ | 業務に必要な権限一式を申請・承認・期限付きで付与する仕組み |
| アクセスの昇格 | グローバル管理者が Azure のルートでユーザーアクセス管理者になる操作 |
| アプリケーション権限 | 利用者を介さずアプリ単独で動く権限。管理者同意が必要 |
| 委任権限 | サインインした利用者の代わりにアプリが動く権限 |
| 管理単位 | Entra のロールの範囲を一部のユーザー・デバイスに限定する入れ物 |
| 管理プレーン／データプレーン | 仕組みを管理する操作と、中のデータを扱う操作の区別 |
| サービスプリンシパル | アプリがテナント内で持つ実体。権限はここに付く |
| データポリシー | Power Platform のコネクタを業務用・非業務用・ブロックに分類する制御 |
| マネージド ID | Azure リソースに付く、秘密キー不要の ID |
| ロール割り当て可能グループ | Entra の管理者ロールを付与できる、保護されたグループ |