Microsoft Entra RBACの今回の更新で管理者がまず確認すべき点は、「誰にどのロールを割り当てているか」だけでなく、「どのスコープで有効なのか」「ユーザー以外のサービスプリンシパルやアプリも統制できているか」まで点検することです。Microsoft Entra IDのロール割り当ては、権限を付与する相手、ロール定義、スコープの3要素で決まります。スコープを誤ると、特定アプリだけに許可したつもりがテナント全体に効く、またはグループ内メンバーまで権限が及ぶと誤解する、といった運用ミスにつながります。(Microsoft Learn)
2026年6月更新の公式情報では、RBACの基本構造に加えて、アクセス可視化、アクセスレビュー、PIM、ワークロードIDの統制、ライセンス要件がより実務寄りに整理されています。この記事では、Microsoft Entra RBACの変更点、影響範囲、管理者・開発者が確認すべき設定、移行や展開時の注意点を、実務で使えるチェック観点に落とし込んで解説します。(GitHub)
Microsoft Entra RBACとは何か
Microsoft Entra RBACは、Microsoft Entra ID上のユーザー、グループ、アプリケーションなどのリソースに対して、管理操作の権限を細かく制御する仕組みです。Microsoft EntraロールはMicrosoft Graph APIを通じたEntraリソースの操作を制御し、Azureロールは仮想マシンやストレージなどAzure Resource Manager配下のAzureリソースを制御します。両者は似た概念を使いますが、Microsoft Entraロールの権限をAzureカスタムロールへ流用することはできず、その逆もできません。(Microsoft Learn)
実務では、ここを混同しないことが重要です。たとえば、Azureサブスクリプションで「所有者」ロールを持っている担当者でも、Microsoft Entra IDのアプリ登録やユーザー管理を自由に変更できるとは限りません。逆に、Microsoft Entraの特権ロールを持っていても、Azure VMの操作権限を当然に持つわけではありません。
Microsoft Entra RBACを理解するうえで中心になるのは、次の3つです。
| 要素 | 意味 | 実務での確認ポイント |
|---|---|---|
| セキュリティプリンシパル | 権限を受け取る対象。ユーザー、グループ、サービスプリンシパルなど | 個人アカウントに直接付与していないか、退職者や不要なアプリに残っていないか |
| ロール定義 | 実行できる操作の集合。組み込みロールまたはカスタムロール | 必要以上に強いロールを選んでいないか |
| スコープ | 権限が有効になる範囲 | テナント全体なのか、管理単位なのか、特定アプリなのか |
この3要素がそろって初めて「誰が、何を、どこまで操作できるか」が決まります。RBACの見直しでは、ロール名だけで判断せず、必ず割り当てスコープまで確認してください。(Microsoft Learn)
2026年6月更新で押さえるべき主な変更点
今回の公式情報は、単なる用語説明ではなく、Microsoft Entra RBACを実際に監査・統制するための観点が強化されています。GitHub上の履歴では、2026年5月下旬から6月1日にかけて、アクセス可視化、ワークロードID、ライセンス要件に関する更新が行われています。(GitHub)
| 更新された観点 | 変更・整理された内容 | 管理者への影響 |
|---|---|---|
| アクセス可視化 | 「誰が何にアクセスできるか」を、ロール割り当てだけでなく、アプリ割り当て、同意、カスタムセキュリティ属性、アクセスレビュー、ログと組み合わせて把握する考え方が整理 | 棚卸し対象をロール一覧だけに限定すると不十分 |
| ワークロードID | アプリ、サービスプリンシパル、マネージドIDなど、人以外のIDも統制対象として明確化 | 自動化ツールやCI/CD、外部連携アプリの権限確認が必要 |
| PIMとアクセスレビュー | ユーザーだけでなく、サービスプリンシパルのレビューにも触れられている | 特権アクセスの常時付与を減らし、期限付き・レビュー付き運用へ移行しやすい |
| ライセンス要件 | カスタムロール、PIM、アクセスレビュー、ワークロードID関連機能で必要なライセンスの確認が重要に | 設計段階でライセンス不足による展開失敗を避ける必要がある |
| ログ活用 | 監査ログ、サインインログ、Microsoft Graph activity logs、Log Analytics連携がアクセス分析の文脈で整理 | 大規模テナントではCSV管理だけでは限界がある |
重要なのは、今回の更新を「RBACの仕様が大きく変わった」と読むのではなく、「RBACだけでは見えないアクセス実態まで含めて統制する方向が明確になった」と読むことです。すでにMicrosoft Entra IDを運用している組織では、ロール割り当て一覧だけを見て安心せず、アプリへの同意、サービスプリンシパル、ログ、レビューの状態まで確認する必要があります。(Microsoft Learn)
影響範囲は管理者、開発者、セキュリティ担当に広がる
Microsoft Entra RBACの影響は、Entra管理者だけに限られません。アプリ開発、業務システム運用、セキュリティ監査、IDガバナンスに関わる担当者すべてに影響します。
テナント管理者への影響
テナント管理者は、全体管理者や特権ロール管理者などの強い権限が、常時・広範囲に割り当てられていないかを確認する必要があります。特に、退職者、異動者、一時プロジェクト参加者に付与したロールが残っているケースはよくあります。
確認すべき代表例は次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| テナント全体スコープのロール | 本当に全社範囲の権限が必要か |
| 個人への直接割り当て | グループベースやPIMに移せないか |
| 長期間使われていない特権アカウント | サインインログと監査ログで利用実態を確認する |
| カスタムロール | 権限が過剰になっていないか、用途が不明なロールがないか |
Microsoft Entra IDでは、ロール割り当てをMicrosoft Entra管理センター、Microsoft Graph PowerShell、Microsoft Graph APIで作成・一覧化できます。一方、Microsoft Entraロール割り当てにはAzure CLIはサポートされないと公式情報で明記されています。運用手順書や自動化スクリプトを見直す際は、この点を前提にしてください。(Microsoft Learn)
アプリ開発者への影響
開発者にアプリ登録の管理権限を渡す場合、「アプリ登録を管理できるロール」を付与するだけでは不十分です。必ずスコープを特定アプリに限定できるかを検討してください。
たとえば、ある開発者に「経費精算アプリのアプリ登録だけを管理させたい」場合、テナント全体のアプリ管理権限を与えるのではなく、そのアプリ登録をスコープにしたロール割り当てを検討します。公式情報でも、同じロールを一方のユーザーには組織全体で、別のユーザーには特定アプリだけで割り当てる例が示されています。(Microsoft Learn)
開発チームで特に注意したいのは、次のようなケースです。
| ケース | リスク | 対応ポイント |
|---|---|---|
| 検証用アプリの管理権限を広く付与 | 本番アプリや他部門アプリまで変更できる可能性 | アプリ単位のスコープを使う |
| CI/CD用サービスプリンシパルに強い権限を付与 | 自動化ツールの侵害時に影響範囲が広がる | 最小権限、証明書・フェデレーション、条件付きアクセスを検討 |
| アプリ同意を棚卸ししていない | 不要なGraph権限が残る | 管理者同意とアプリ権限を定期確認する |
セキュリティ担当・監査担当への影響
セキュリティ担当者は、ロール割り当てだけでなく、「付与されたアクセス」と「実際に使われたアクセス」を分けて確認する必要があります。公式情報では、監査ログは構成変更を記録し、サインインログはサインインイベントを記録するため、両方を組み合わせることで、付与済みアクセスと行使されたアクセスを区別できると説明されています。(Microsoft Learn)
監査で見るべき観点は、次の3段階に分けると整理しやすくなります。
| 段階 | 確認内容 | 使う情報 |
|---|---|---|
| 権限があるか | 誰にどのロールが割り当てられているか | ロール割り当て一覧、CSV、Microsoft Graph API |
| 利用できる経路があるか | アプリ割り当てや管理者同意が残っていないか | エンタープライズアプリ、同意済みアクセス許可 |
| 実際に使われたか | サインインやAPI呼び出しが発生しているか | サインインログ、監査ログ、Microsoft Graph activity logs |
大規模テナントでは、手作業のCSV確認だけでは限界があります。公式情報でも、大規模テナントではLog Analyticsワークスペースへログをストリーミングし、アクセスパターンを分析する方法が示されています。(Microsoft Learn)
ロール割り当てのスコープで失敗しやすいポイント
Microsoft Entra RBACで最も誤解されやすいのがスコープです。スコープは、ロールの権限がどの範囲に適用されるかを制限する仕組みです。指定できる主なスコープには、テナント、管理単位、Microsoft Entraリソースがあります。Microsoft Entraリソースとしては、Microsoft Entraグループ、エンタープライズアプリケーション、アプリ登録が挙げられています。(Microsoft Learn)
テナントスコープは最後の選択肢にする
テナントスコープは、組織全体に影響する強力な範囲です。便利ですが、最小権限の原則から見ると、最初に選ぶべき選択肢ではありません。
たとえば、ヘルプデスク担当者にパスワードリセット権限を与える場合、全社の全ユーザーを対象にする必要があるとは限りません。地域、部門、子会社ごとに管理範囲を分けられるなら、管理単位の利用を検討します。
判断基準はシンプルです。
| 判断基準 | 推奨される考え方 |
|---|---|
| 全社の全リソースを管理する必要がある | テナントスコープを検討 |
| 特定部門や地域だけを管理する | 管理単位を検討 |
| 特定アプリだけを管理する | アプリ登録やエンタープライズアプリのリソーススコープを検討 |
| 一時的な作業だけ必要 | PIMで期限付き付与を検討 |
リソーススコープは「そのリソース自体」に効く
公式情報では、テナントや管理単位のようなコンテナスコープにロールを割り当てると、その中に含まれるオブジェクトに対して権限が付与されます。一方、リソーススコープにロールを割り当てた場合は、そのリソース自体に対して権限が付与され、範囲はその先に広がりません。特に、Microsoft Entraグループをリソーススコープにしても、グループのメンバーにまで権限が及ぶわけではない点に注意が必要です。(Microsoft Learn)
これは実務上かなり重要です。たとえば、「営業部グループに対する管理権限」を付けたつもりでも、その権限が営業部メンバー全員のユーザー属性管理に及ぶとは限りません。グループ自体の管理なのか、グループに含まれるユーザーの管理なのかを分けて設計してください。
管理者がすぐ確認すべき設定チェックリスト
Microsoft Entra RBACの見直しでは、最初から完璧な権限設計を目指すより、影響が大きい項目から順番に潰すほうが現実的です。まずは次の順で確認してください。
| 優先度 | 確認項目 | 具体的な作業 |
|---|---|---|
| 高 | 全体管理者など強いロール | 常時割り当てを減らし、必要に応じてPIM化する |
| 高 | テナントスコープのロール | 特定アプリ、管理単位、グループ単位に絞れないか確認する |
| 高 | サービスプリンシパルの権限 | 自動化や外部連携アプリに過剰権限がないか確認する |
| 中 | カスタムロール | 作成目的、権限内容、割り当て先、利用状況を棚卸しする |
| 中 | アプリ同意とアプリ割り当て | 不要な委任権限・アプリケーション権限が残っていないか確認する |
| 中 | ログ保管と分析 | 監査ログ、サインインログ、Graph activity logsを確認できる状態にする |
| 低 | 命名規則と運用手順 | ロール名、グループ名、申請フローを統一する |
特に優先したいのは、サービスプリンシパルです。近年のクラウド運用では、管理者ユーザーよりもCI/CD、監視ツール、連携アプリなどのワークロードIDが広い権限を持つケースがあります。公式情報でも、アプリ、サービスプリンシパル、マネージドIDを含むワークロードIDまで認可戦略に含める必要があるとされています。(Microsoft Learn)
ワークロードIDの権限管理で確認すべきこと
ワークロードIDとは、人間のユーザーではなく、アプリケーションやサービスがMicrosoft Entraで認証・認可されるためのIDです。公式情報では、アプリ登録、マネージドID、ワークロードIDフェデレーション、Flexible federated identity credentialsが、機械IDを確立する方法として整理されています。(Microsoft Learn)
管理者や開発者は、次の観点で点検してください。
アプリ登録とサービスプリンシパルを棚卸しする
まず、使われていないアプリ登録やサービスプリンシパルを洗い出します。名前だけでは判断できないことが多いため、所有者、作成日、最後の利用状況、付与済みAPI権限、シークレットや証明書の有効期限を確認します。
特に危険なのは、次のような状態です。
| 状態 | 問題点 |
|---|---|
| 所有者が空欄、または退職者のみ | 問い合わせ先がなく、権限見直しが進まない |
| 長期有効なクライアントシークレットが残っている | 漏えい時の影響が長期化する |
| Directory.ReadWrite.Allなど広いGraph権限が残っている | 侵害時にディレクトリ全体へ影響する可能性がある |
| テスト用アプリが本番テナントに残っている | 管理対象外の抜け道になりやすい |
可能な範囲でシークレットレス化を検討する
Azure上で動くワークロードであれば、マネージドIDを使うことで、コードや構成ファイルにシークレットを保存せずに認証できます。Azure外やGitHub、GitLab、Terraform Cloudなど外部環境からMicrosoft Entra保護リソースへアクセスする場合は、ワークロードIDフェデレーションの利用を検討できます。公式情報では、これらがワークロードIDの確立方法として示されています。(Microsoft Learn)
ただし、既存システムを一度に移行する必要はありません。まずは新規開発や更新頻度の高いCI/CDから、シークレットレスな構成へ寄せるのが現実的です。
ワークロードID向け条件付きアクセスの対象範囲を誤解しない
公式情報では、ワークロードID向け条件付きアクセスにより、サービスプリンシパルがいつ・どこで認証できるかを制限できると説明されています。ただし、この機能にはWorkload Identities Premiumライセンスが必要で、対象はテナント内に登録されたシングルテナントのサービスプリンシパルです。マネージドIDやマルチテナントアプリ、サードパーティSaaSアプリは対象外とされています。(Microsoft Learn)
展開時は「すべてのワークロードIDに条件付きアクセスを適用できる」と考えず、対象外のIDについては別の統制策を組み合わせてください。
PIMとアクセスレビューは「常時権限」を減らすために使う
Microsoft Entra ID P2では、Microsoft Entra Privileged Identity Managementを使い、必要なときだけ時間制限付きでロールを有効化できます。公式情報では、PIMは恒久的なアクセスではなく、必要なユーザーに期限付きアクセスを付与し、詳細なレポートと監査機能を提供すると説明されています。(Microsoft Learn)
PIMを使うべき代表的なロールは、次のようなものです。
| 対象ロールの例 | PIM化を検討すべき理由 |
|---|---|
| 全体管理者 | 侵害時の影響が最大級になるため |
| 特権ロール管理者 | 他の管理者権限を変更できるため |
| アプリケーション管理者 | アプリ登録や資格情報の変更が重大な影響を持つため |
| 認証管理者 | MFAや認証方法に関わるため |
| 条件付きアクセス管理者 | セキュリティポリシーを変更できるため |
アクセスレビューは、付与した権限が今も必要かを定期的に確認する仕組みです。公式情報では、アクセスレビューにより、グループメンバーシップやエンタープライズアプリへの割り当てを継続して必要とするかを確認でき、PIMアクセスレビューではMicrosoft EntraまたはAzureリソースロールに割り当てられたユーザーやサービスプリンシパルをレビューできると説明されています。(Microsoft Learn)
運用では、次のように使い分けると効果的です。
| 目的 | 推奨する仕組み |
|---|---|
| 特権ロールを必要時だけ有効化したい | PIM |
| 付与済み権限を定期的に見直したい | アクセスレビュー |
| 部門やプロジェクト単位でアクセス申請を管理したい | エンタイトルメント管理 |
| 監査証跡を残したい | 監査ログ、PIM履歴、アクセスレビュー結果 |
カスタムロールを使う前に確認すべきライセンスと設計
Microsoft Entra IDの組み込みロールは無料で利用できますが、カスタムロールを使う場合は、カスタムロール割り当てを受けるユーザーごとにMicrosoft Entra ID P1ライセンスが必要です。公式情報では、このライセンス要件が明記されています。(Microsoft Learn)
カスタムロールは便利ですが、増やしすぎると管理が難しくなります。作成前に、次の3点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 組み込みロールで代替できないか | 既存ロールで過不足が小さいなら、まず組み込みロールを検討する |
| スコープで制御できないか | ロールを細分化する前に、スコープを絞れないか確認する |
| 継続的に管理できるか | 作成者、利用目的、対象者、レビュー周期を記録する |
おすすめは、カスタムロール名に用途と対象範囲を含めることです。たとえば、「AppReg-ExpenseApp-Developer」や「Helpdesk-Japan-PasswordReset」のように、何のための権限かが分かる名前にしておくと、半年後の棚卸しで迷いにくくなります。
移行・展開時の注意点
Microsoft Entra RBACを見直すときは、いきなり既存権限を削除しないでください。特に、アプリ登録、プロビジョニング、SSO、ID同期、監視ツールに関わる権限は、削除すると業務影響が出る可能性があります。
安全に進めるには、次の手順が現実的です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 現状把握 | ロール割り当て、アプリ同意、サービスプリンシパル、ログを確認 | ロール一覧だけで判断しない |
| 分類 | 常時必要、一時的に必要、不要、不明に分ける | 不明なものは所有者確認を優先 |
| 影響確認 | 対象システム、運用担当、利用頻度を確認 | 本番運用時間帯の変更は避ける |
| 代替設計 | PIM、管理単位、リソーススコープ、カスタムロールを検討 | ライセンス要件も同時に確認 |
| 段階展開 | 少数ユーザーや検証環境から適用 | ロール削除前に復旧手順を用意 |
| 継続監査 | アクセスレビューとログ分析を定期化 | 棚卸しを年1回だけにしない |
特に移行で失敗しやすいのは、「使われていないように見える権限」をログだけで不要と判断することです。月次処理、四半期処理、障害対応時だけ使う権限もあります。サインインログや監査ログの期間、対象システムの運用サイクル、担当者への確認を組み合わせて判断してください。
開発者が実装前に確認すべきポイント
Microsoft Entra RBACは管理者だけの設定ではありません。Microsoft Graph APIを使うアプリ、管理自動化スクリプト、CI/CDパイプラインを作る開発者も、RBACの挙動を理解しておく必要があります。
公式情報では、Microsoft Entra IDがアクセス可否を判断する流れとして、ユーザーまたはサービスプリンシパルがMicrosoft Graphエンドポイント向けトークンを取得し、そのトークンでAPI呼び出しを行い、ロールメンバーシップやロール割り当て、要求されたアクションとスコープを評価すると説明されています。(Microsoft Learn)
開発時に確認すべきことは次のとおりです。
| 確認項目 | 実務上の意味 |
|---|---|
| API権限とRBACを混同していないか | Graph APIのアクセス許可とEntraロールは別の観点で確認する |
| サービスプリンシパルに必要以上のロールを付けていないか | 自動化対象のリソースだけにスコープを絞る |
| エラー時に権限不足かスコープ不足か切り分けられるか | 403や認可エラー時に、ロール、API権限、同意、スコープを順に確認する |
| 本番と検証で同じ権限を使っていないか | 環境ごとにアプリ登録や資格情報を分離する |
| シークレットをコードに保存していないか | マネージドIDやワークロードIDフェデレーションを検討する |
権限エラーの調査では、「ロールを持っているのに操作できない」と見えることがあります。その場合、ロール定義に対象アクションが含まれているか、ロール割り当てのスコープが対象リソースに届いているか、Microsoft Graphのアクセス許可と管理者同意が適切かを分けて確認してください。
まず実施すべき実務アクション
Microsoft Entra RBACの見直しは、範囲が広いため後回しにされがちです。まずは、次の5つだけでも着手すると効果があります。
- 全体管理者、特権ロール管理者、アプリケーション管理者の割り当てを一覧化する
- テナントスコープのロールを、管理単位やリソーススコープへ絞れないか確認する
- サービスプリンシパルとアプリ登録の所有者、資格情報、API権限を棚卸しする
- 常時必要ない特権ロールはPIM化を検討する
- 監査ログ、サインインログ、Microsoft Graph activity logsを確認できる運用にする
Microsoft Entra RBACの要点は、強い権限を一律に禁止することではありません。必要な人やアプリに、必要な操作だけを、必要な範囲と期間で与えることです。今回の更新をきっかけに、ロール割り当て、スコープ、ワークロードID、アクセスレビュー、ログ分析をセットで見直すことで、過剰権限を減らしながら運用の手戻りも防ぎやすくなります。
コメント