Microsoft Entra IDのRBACとは？
Microsoft のクラウド環境では、「RBAC（ロールベースのアクセス制御）」という仕組みを用いて、誰にどんな権限を与えるかを管理します。
Microsoft のクラウド環境で使われる RBAC には、「Microsoft Entra ID の RBAC（以下、Entra RBAC）」と「Azure RBAC」がありますが、その制御対象や適用範囲が以下のように異なっています。
- Entra RBAC：Microsoft Entra ID 内のユーザー・グループ・アプリなど、ID や認証の管理を対象
- Azure RBAC：Azure 上の仮想マシンやストレージなど「リソースへのアクセス管理」を対象
まず、この RBAC の基本的な考え方を整理したうえで、それぞれの RBAC の違いや具体的な使い方、よくある混同ポイントについて詳しく解説していきます。
そもそもRBACとは？
RBAC（Role-Based Access Control／ロールベースのアクセス制御）は、ユーザーに直接アクセス権限を与えるのではなく、「役割（ロール）」を通じて権限を割り当てる仕組みです。
RBACの具体的な運用イメージは以下のとおりです。
RBACの運用イメージ画像
1. 例えば、次のようなロールを用意します。
- 管理者ロール：すべての操作が可能
- 編集者ロール：データの作成や編集が可能
- 閲覧者ロール：閲覧のみ可能
2. そのロールを社員に割り当てます。
- Aさん → 管理者ロール
- Bさん → 編集者ロール
- Cさん → 閲覧者ロール
このようにロールに対して権限を割り当てることで管理を行います。
RBACのメリット
RBACのモデルのメリットは以下の通りです。
- 一元管理が可能：ユーザーごとに設定するのではなく、ロール単位でまとめて管理することができるので、大規模環境でも効率的な運用が可能です。
- 最小権限の原則を実現：ユーザーごとに必要最低限の権限だけを付けることができるので、セキュリティリスクを減らすことが可能です。
- ガバナンスの強化：誰が何をできるかを明確にでき、監査ログとの連携がスムーズになります。
Microsoft Entra IDのRBACとAzure RBACとの違い
Microsoft のクラウド環境で使われる RBAC には、「Microsoft Entra ID の RBAC（Entra RBAC）」と 「Azure RBAC」 の2種類があります。
両者は同じRBACという仕組みを使いますが、管理対象と目的が以下のように異なります。
- Entra RBAC：ユーザーやグループ、アプリケーションなど、「ID や認証基盤の管理権限」を制御する仕組みです（例：人事部だけユーザーの追加・削除を行えるようにする）。
- Azure RBAC：仮想マシンやストレージなど、「Azure リソース自体の操作権限」を制御する仕組みです（例：開発環境のサブスクリプションで VM の起動・停止を許可する）。
つまり、Entra RBAC は「誰をどう管理できるか」、Azure RBAC は「どのリソースをどこまで操作できるか」を決める仕組みだと考えると分かりやすいでしょう。
以下が両者の比較を表にまとめると以下のようになりますす。
比較ポイント | Entra RBAC（Entra ID用） | Azure RBAC（Azureリソース用） |
|---|---|---|
対象 | ユーザー、グループ、アプリ、認証ポリシーなど「IDと認証の管理 | 仮想マシン、ストレージ、データベースなど「クラウドリソースの管理」 |
スコープの範囲 | 組織全体（テナント）、部署単位（管理単位）、Microsoft Entra リソース | 管理グループ、サブスクリプション、リソースグループ、リソース |
目的 | 「誰がEntraを管理できるか」「どのIDやアプリを対象にできるか」を決める | 「どのAzureリソースを操作できるか」「操作範囲をどこまでにするか」を決める |
代表ロール例 | ユーザー管理者、アプリ管理者、条件付きアクセス管理者など | 閲覧者、共同作成者、リーダーなど |
このように、RBACという仕組みは共通でも、適用範囲が異なることを押さえておくことが、セキュリティや運用管理における第一歩です。
Microsoft Entra RBACの構造とロールの種類
ここでは、Microsoft Entra RBAC の適用範囲やロールの種類についてご紹介します。
Microsoft Entra RBAC で、鍵となるのが以下の3要素です。
- セキュリティ プリンシパル：アクセス権を割り当てられる対象。ユーザー、グループ、またはアプリケーション（サービスプリンシパル）を指します。
- ロールの定義：実行できる操作の集合。「ユーザー管理者」や「閲覧者」といった役割（Job function）を定義します。
- スコープ：その権限が有効になる範囲。組織全体、特定の部署（管理単位）、または個別のアプリケーションなどが対象です。
ここからは、こうした概念を軸に、Microsoft Entra RBAC の適用範囲と代表的なロールの種類などについて詳しく解説していきます。
Microsoft Entra RBACの構造
例として、「Aさん（ユーザー）に、アプリケーション管理者（ロール）の権限を、特定の業務アプリ（スコープ）の範囲に限定して割り当てる」というシナリオで考えてみましょう
この場合、権限は以下のように割り当てられます。
1. 誰に（セキュリティ プリンシパル）： 管理者は「Aさん」というユーザーを選択します。
2. 何を（ロールの定義）： Aさんに「アプリケーション管理者」という権限セットを割り当てます。
3. どこで（スコープ）：その権限が有効な範囲を「特定の業務アプリ」に限定します。
このように3つの要素を組み合わせることで、必要最小限の権限を、必要な範囲にのみ付与することができます。
Microsoft Entra RBACの構造（参考：Microsoft）
セキュリティ プリンシパルの種類
権限を割り当てる対象となる「セキュリティ プリンシパル」には、以下の3種類があります。
種類 | 対象 | 主な用途 |
|---|---|---|
ユーザー | 人（従業員、ゲストなど） | 個々のユーザーアカウントに直接権限を割り当てます。 |
グループ | 人の集まり（部門、プロジェクトチームなど） | グループに権限を割り当てることで、所属メンバーを一括で管理できます。 |
サービス プリンシパル | アプリケーションや自動化スクリプト | 人を介さず、システムがリソースにアクセスする際のIDとして利用されます。 |
Entra RBACの適用対象（スコープ）
ロールを付与する際には、そのロールをどの範囲で有効にするか（スコープ） を決めます。
指定できるスコープの種類は大きく分けて次の3種類があります。
- テナント：組織全体に有効です（例：Aさんのロールをテナント全体に割り当てた場合、Aさんの権限は全社に及びます）。
- 管理単位：部署や部門などの単位に限定します（例：Aさんのロールを人事部（管理単位）に割り当てた場合、Aさんの権限は人事部だけに及びます。他の営業部などには及びません）。
- Microsoft Entra リソース（グループ／アプリ）：個別のオブジェクト（アプリやグループなど）に限定します（例：Aさんの権限の範囲を「Salesforceアプリ」に割り当てた場合、AさんはSalesforceの設定だけ管理できる。他のアプリには影響なし）。
※ポイント：Entra RBAC は、「誰を管理できるか」や「どのIDに対して何ができるか」を制御するための仕組みであり、Azureリソースそのものへのアクセス制御は対象外です。
主な組み込みロール（Built-in Roles）
Microsoft Entra IDには、よくある管理シナリオに合わせて最初から多くのロールが用意されています。これを組み込みロールと言います。
代表的なロールは以下の通りです。
ロール名 | できること |
|---|---|
グローバル管理者（Global Administrator） | すべての権限を持つ「最高権限者」。全社的な設定やリソースの管理 |
ユーザー管理者（User Administrator） | ユーザーやグループの作成／削除、パスワードリセットなど |
アプリケーション管理者（Application Administrator） | アプリの登録や設定、エンタープライズアプリの管理 |
セキュリティ閲覧者／管理者（Security Reader / Administrator | セキュリティ関連のアラートやポリシーの確認・管理 |
カスタムロールの作成
組み込みロールで足りない場合は、自分で「この操作だけ許可する」ロールを作成することも可能です。
例えば「ユーザーを作ることはできるが、削除はできない」など、細かく調整することができます。
Azure RBACの構造と特徴
Azure RBAC（Role-Based Access Control for Azure）は、Microsoft Azure のリソース（仮想マシン、ストレージ、SQL データベースなど）へのアクセスを制御するための仕組みです。Azureリソースに対して「誰が、何を、どの範囲で操作できるか」を明確に管理するために利用されます。
セキュリティ プリンシパル
Microsoft Entra RBAC と Azure RBAC の仕組みは基本的に同じですが、違いは「マネージド ID」が Azure RBAC にだけ登場する点です。
マネージド IDとは、Azure が自動で発行・管理してくれるアプリ用の IDのことです。
Azureセキュリティ プリンシパル（参考：Microsoft）
Azure RBACのスコープ階層
Azure RBACでは「どの範囲で権限を効かせるか（スコープ）」を階層で指定することができます。上の階層で付けた権限は、下の階層にも引き継がれます。
スコープ | 説明 |
|---|---|
管理グループ | 複数のサブスクリプションをまとめた最上位の単位。大企業や複数部門のAzure環境で使う。 |
サブスクリプション | 請求・課金の基本単位。複数のリソースグループを含む。 |
リソースグループ | 関連するリソースをまとめるフォルダのような単位。アプリごと・環境ごとにまとめることが多い。 |
リソース | 実際に操作する個々のサービス（仮想マシン、ストレージ、DBなど）。 |
例えば、あるユーザーに「サブスクリプション」のスコープでロールを割り当てた場合、その権限は下位にあるすべての「リソースグループ」および「リソース」に継承されます。
一方で、その権限が上位の「管理グループ」に影響することはありません。
Azureスコープ（参考：Microsoft）
主な組み込みロール
Azure RBACにも、以下のようなよく利用される組み込みロールが提供されています。特に最初の3つは、Azureの権限管理における基本的なロールです。
ロール名 | 説明 |
|---|---|
所有者 (Owner) | すべてのリソースに対するフルアクセス権を持ち、他のユーザーへの権限割り当ても含めて、すべての操作が可能 |
共同作成者 (Contributor) | リソースの管理に関するすべての操作が可能ですが、他のユーザーへの権限割り当て（アクセス制御の変更）は不可 |
閲覧者 (Reader) | リソースの構成や設定を閲覧だが、変更は不可 |
カスタムロールの作成
組み込みロールで足りないときは、独自の操作権限を定義したカスタムロールを作成することも可能です。
たとえば、「特定のストレージアカウントだけに読み取り権限を与える」といった細かい制御ができます。
RBACとPIMの関係：最小権限をどう実現するか
RBAC（ロールベースのアクセス制御）は、ユーザーに必要な権限を「ロール単位」で割り当てる優れた仕組みです。しかし、この方法では権限が恒久的に割り当てられるため、「業務で必要なとき以外でも強力な権限を行使できてしまう」という課題が残ります。この状態は、必要最低限の権限のみを付与するという「最小権限の原則（Least Privilege）」を厳密に適用する上では、課題となる場合があります。
そこで役立つのが、PIM（Privileged Identity Management）です。
PIMの概要
PIMは、特権的な権限を「必要なときだけ、一時的に有効化できる」仕組み です。承認フローやMFA（多要素認証）とも組み合わせることができるので、「恒常的に強い権限を持ち続けるリスク」を減らすことが可能です。
たとえば、Entra ID の「グローバル管理者」ロールを持つ必要がある担当者でも、常にそのロールを持たせるのではなく、PIMを使って「必要になったときだけ申請・承認して有効化」することができます。
PIMを利用するためのライセンス要件
PIMは、Microsoft Entra IDの高度な機能であり、利用するには以下のいずれかのライセンスが必要です。
- Microsoft Entra ID P2
- Microsoft Entra ID Governance
これらのライセンスを契約することで、権限の一時的な有効化、承認ワークフロー、アクティブ化時の多要素認証（MFA）要求、アクセスレビューといったPIMの全ての機能を利用できるようになります。
RBACとPIMの使い分け方
RBACのみを用いる場合と、RBAC＋PIMによる運用の違いは以下のとおりです。
項目 | RBACのみ | RBAC＋PIM（推奨） |
|---|---|---|
権限の割当 | 常に有効（恒久的な割り当て | 必要な時に有効化（一時的な割り当て） |
承認プロセス | なし | 権限を有効にする際に、承認者の許可を必須にできる |
MFA（多要素認証 | なし（サインイン時のポリシーに依存） | 権限を有効にする際に、多要素認証（MFA）を強制できる |
監査ログ | 基本的な割り当てログ | 詳細ログ（昇格・承認の履歴も記録） |
このように、RBACとPIMを組み合わせることで、セキュリティと利便性のバランスが取れた運用が可能になります。
Microsoft Entra ID RBACの設定手順
ここでは、Microsoft Entra ID RBACの基本的な操作手順をご紹介します。
ロールの割り当て
1. Entra 管理センターに「特権ロール管理者」またはそれ以上の権限でサインインします。
管理センター
2. 左メニューの「Entra ID」から、「役割と管理者」をクリックします。
役割と管理者
3.組み込みロール（ユーザー管理者、アプリ管理者など）が一覧表示されるので、その中から割り当てたいロールを選択します。
①検索窓でロールを検索し（ここでは「ユーザー管理者」）、②（□にチェックするのではなく）「ユーザー管理者」の表示をクリックします。
ユーザー管理者
4. 「割り当ての追加」をクリックします。
割り当ての追加
5.検索窓で割り当てたい人の名前を検索し、チェックをしたら、下の「追加」ボタンをクリックします。
割り当ての追加ボタン
管理単位スコープでロールを割り当て
ここでは 管理単位スコープのロール割り当てについて、ご紹介します。
1. 以下の前提条件を満たしているか確認をします。
- 各管理単位管理者に Microsoft Entra ID P1 または P2 ライセンスが必要です。
- 管理単位のメンバーは Entra ID 無料ライセンスで利用可能です。
- 「特権ロール管理者」ロールを持つユーザーが設定を実行する必要があります。
※管理単位を作成していない場合は、Microsoftの公式ドキュメントを参考に作成してください。
2. 左側のメニューから 「役割と管理者」 → 「管理単位」 を選択します。
その後、ロールを割り当てたい対象の 管理単位 （ここでは人事部（テスト））をクリックします。
管理単位テスト
3. 管理単位の画面で、左メニューから 「ロールと管理者」を開きます。すると、管理単位スコープで割り当て可能なロールの一覧が表示されます。
ロールの一覧
4. 一覧から目的のロールを選択します。ここでは、パスワード管理者を例として選択します。
パスワード管理者
5. パスワード管理者を選択したら、先ほどの「ロールの割り当て」の4以降と同様の手順で「割り当ての追加」 をクリックし、管理単位にスコープされたロールを割り当てます。
アプリ登録スコープでロールを割り当て
ここでは、アプリ登録スコープでロールを割り当てる方法についてご紹介します。
1. 「アプリケーション開発者」以上の権限でサインインして、左ナビゲーションから「Entra ID」 > 「アプリ登録」 を選択します。
アプリ登録
2. 「すべてのアプリケーション」 を選択し、管理したいアプリをクリックします。見つからない場合は検索ボックスを利用してください。この例では、「Sample App」を使用します。
すべてのアプリケーション選択
3. 対象アプリの画面で、左メニューから ①「ロールと管理者」 を開きます。すると②そのアプリに対して割り当て可能なロールの一覧が表示されます。
割り当て可能なロールの一覧
4. 割り当てたいロールを選択し、上記「基本的な使い方手順（ロールの割り当て）4以降」と同様の手順で、「割り当ての追加」 をクリックし、管理単位にスコープされたロールを割り当てます。
よくある設計ミスとその回避策
権限設計の現場では、いくつかの典型的なミスが見られます。代表的な例と、その回避策を以下に整理します。
グローバル管理者を安易に多用してしまうケース
グローバル管理者は非常に強力な権限を持つため、過剰な付与はセキュリティリスクを高めます。
この問題を避けるには、業務内容に応じて「ユーザー管理者」「アプリ管理者」など適切な管理者ロールを細分化して割り当てることが重要です。
全社一括でロールを付与してしまうケース
この方法では、組織変更や人事異動の際に管理が煩雑になり、不要な権限が残るリスクが生じます。
部門別・役職別のグループを定義することで、組織の変化にも柔軟に対応できます。
ロールを付与したまま放置してしまうケース
退職者や異動者のアカウントに権限が残り続けるのは大きなリスクです。
これを防ぐには、定期的な権限棚卸しを実施し、さらに自動化ツールを使ったレビューサイクルを導入することで、不要な権限を確実に排除できます。
まとめ
本記事では、Microsoft Entra ID におけるロールベースのアクセス制御（RBAC）について、Azure RBAC との違いを含めて解説しました。Entra RBAC は、ユーザーやグループ、アプリケーション、ディレクトリ全体といった「ID管理」に関わる権限をコントロールします。一方で Azure RBAC は、仮想マシンやストレージといった「Azureリソースの操作権限」を管理する仕組みであり、両者の対象範囲は異なります。
RBAC の仕組みでは、権限を直接ユーザーに与えるのではなく、ロール（役割）を通じてまとめて付与するため、誰が何をできるかを整理しやすくなります。この仕組みにより、必要最小限の権限だけを与える「最小権限の原則」を実現し、組織全体のセキュリティと管理性を高めることができます。また実際の運用では、グループを使った管理や、PIM（Privileged Identity Management）による一時的な権限付与を組み合わせることで、利便性を保ちながらセキュリティをさらに強化できます。
Microsoft Entra ID の RBAC を正しく理解して活用することは、ゼロトラスト時代に求められる安全で柔軟な ID 管理の基盤をつくることにつながります。
東京エレクトロンデバイスでは、Microsoft Entra ID をはじめとする Azure のセキュリティ設計・運用を支援しています。
RBACの設計に不安がある方、導入をご検討中の方はぜひお気軽にご相談ください。
