ロールベースのアクセス制御 (RBAC) を使用すると、特定のユーザーまたはグループがリソースにアクセスして管理するための特定のアクセス許可を持つことができます。 アプリケーション RBAC は 、Azure ロールベースのアクセス制御 と Microsoft Entra ロールベースのアクセス制御とは異なります。 Azure カスタム ロールと組み込みロールはどちらも Azure RBAC の一部であり、Azure リソースの管理に使用されます。 Microsoft Entra RBAC は、Microsoft Entra リソースを管理するために使用されます。 この記事では、アプリケーション固有の RBAC について説明します。 アプリケーション固有の RBAC の実装の詳細については、「 アプリケーションにアプリ ロールを追加し、トークンで受け取る方法」を参照してください。
ロールの定義
RBAC は、アプリケーションで承認を適用するための一般的なメカニズムです。 組織が RBAC を使用する場合、アプリケーション開発者は、個々のユーザーまたはグループを承認するのではなく、ロールを定義します。 管理者は、さまざまなユーザーとグループにロールを割り当てて、コンテンツと機能にアクセスできるユーザーを制御できます。
RBAC は、アプリケーション開発者がリソースとその使用状況を管理するのに役立ちます。 RBAC を使用すると、アプリケーション開発者は、ユーザーがアクセスできるアプリケーションの領域を制御することもできます。 管理者は、ユーザー 割り当て必須 プロパティを使用して、アプリケーションにアクセスできるユーザーを制御できます。 開発者は、アプリケーション内の特定のユーザーと、アプリケーション内でユーザーが実行できる操作を考慮する必要があります。
アプリケーション開発者は、まず、Microsoft Entra 管理センターのアプリケーションの登録セクション内にロール定義を作成します。 ロール定義には、そのロールに割り当てられているユーザーに返される値が含まれます。 開発者は、この値を使用してアプリケーション ロジックを実装し、ユーザーがアプリケーションで実行できることとできないことを判断できます。
RBAC オプション
アプリケーションにロールベースのアクセス制御承認を含める場合は、次のガイダンスを適用する必要があります。
- アプリケーションの承認ニーズに必要なロールを定義します。
- 認証されたユーザーに関連するロールを適用、格納、および取得します。
- 現在のユーザーに割り当てられているロールに基づいて、アプリケーションの動作を決定します。
ロールが定義されると、Microsoft ID プラットフォームでは、認証されたユーザーのロール情報の適用、格納、取得に使用できるいくつかの異なるソリューションがサポートされます。 これらのソリューションには、アプリ ロール、Microsoft Entra グループ、ユーザー ロール情報のカスタム データストアの使用が含まれます。
開発者は、ロールの割り当てをアプリケーションのアクセス許可として解釈する方法について、独自の実装を柔軟に提供できます。 このアクセス許可の解釈では、アプリケーションまたは関連するライブラリのプラットフォームによって提供されるミドルウェアやその他のオプションを使用できます。 通常、アプリケーションはユーザー ロール情報を要求として受け取り、それらの要求に基づいてユーザーのアクセス許可を決定します。
アプリの役割
Microsoft Entra ID を使用すると、アプリケーションの アプリ ロールを定義 し、それらのロールをユーザーや他のアプリケーションに割り当てることができます。 ユーザーまたはアプリケーションに割り当てるロールは、アプリケーション内のリソースと操作へのアクセスレベルを定義します。
認証されたユーザーまたはアプリケーションに対して Microsoft Entra ID がアクセス トークンを発行すると、アクセス トークンの roles 要求にエンティティ (ユーザーまたはアプリケーション) を割り当てたロールの名前が含まれます。 要求でそのアクセス トークンを受け取る Web API などのアプリケーションは、 roles 要求の値に基づいて承認の決定を行うことができます。
グループ
開発者は 、Microsoft Entra グループ を使用してアプリケーションに RBAC を実装することもできます。この場合、特定のグループ内のユーザーのメンバーシップはロール メンバーシップとして解釈されます。 組織がグループを使用する場合、トークンには グループ要求が含まれます。 グループ要求は、テナント内のユーザーの割り当てられたすべてのグループの識別子を指定します。
Von Bedeutung
グループを使用する場合、開発者は 超過分要求の概念を認識する必要があります。 既定では、ユーザーが超過分の制限を超えるメンバーである場合 (SAML トークンの場合は 150、JWT トークンの場合は 200、暗黙的フローを使用する場合は 6)、Microsoft Entra ID はトークンにグループ要求を出力しません。 代わりに、トークンのコンシューマーが Microsoft Graph API にクエリを実行してユーザーのグループ メンバーシップを取得する必要があることを示す "超過分要求" がトークンに含まれています。 超過分の要求の操作の詳細については、「 アクセス トークンの要求」を参照してください。 アプリケーションに割り当てられているグループのみを出力できますが、 グループベースの割り当て には Microsoft Entra ID P1 または P2 エディションが必要です。
カスタム データ ストア
アプリ ロールとグループの両方に、ユーザーの割り当てに関する情報が Microsoft Entra ディレクトリに格納されます。 開発者が使用できるユーザー ロール情報を管理するもう 1 つのオプションは、カスタム データ ストア内のディレクトリの外部に情報を保持することです。 たとえば、SQL データベース、Azure Table Storage、または Azure Cosmos DB for Table などです。
カスタム ストレージを使用すると、開発者はロールをユーザーに割り当てる方法とその表現方法をカスタマイズして制御できます。 ただし、柔軟性が高いほど、より多くの責任も生まれます。 たとえば、現在、Microsoft Entra ID から返されるトークンにこの情報を含めるメカニズムはありません。 ロール情報がカスタム データ ストアに保持されている場合、アプリケーションはロールを取得する必要があります。 通常、ロールの取得は、アプリケーションの開発に使用されているプラットフォームで使用できるミドルウェアで定義された拡張ポイントを使用して行われます。 開発者は、カスタム データ ストアを適切にセキュリティで保護する必要があります。
アプローチを選択する
一般に、アプリ ロールが推奨されるソリューションです。 アプリ ロールは最も単純なプログラミング モデルを提供し、RBAC 実装の目的です。 ただし、特定のアプリケーション要件は、別のアプローチがより優れたソリューションであることを示している可能性があります。
開発者は、アプリ ロールを使用して、ユーザーがアプリケーションにサインインできるか、アプリケーションが Web API のアクセス トークンを取得できるかを制御できます。 アプリ ロールは、開発者がアプリケーションで承認のパラメーターを記述および制御する場合に、Microsoft Entra グループよりも優先されます。 たとえば、承認にグループを使用するアプリケーションは、グループ識別子と名前の両方が異なる可能性があり、次のテナントで中断します。 アプリ ロールを使用するアプリケーションは安全なままです。
承認にはアプリロールまたはグループを使用できますが、それらの主な違いは、特定のシナリオに最適なソリューションに影響を与える可能性があります。
| アプリ ロール | Microsoft Entra グループ | カスタム データ ストア | |
|---|---|---|---|
| プログラミング モデル | 最も単純です。 これらはアプリケーションに固有であり、アプリケーションの登録で定義されます。 これらはアプリケーションと共に移動します。 | より複雑です。 グループ識別子はテナントによって異なり、超過分の要求を考慮する必要がある場合があります。 グループは、アプリケーションに固有のものではなく、Microsoft Entra テナントに固有のものです。 | 最も複雑です。 開発者は、ロール情報を格納および取得する手段を実装する必要があります。 |
| ロールの値は Microsoft Entra テナント間で静的です | イエス | いいえ | 実装によって異なります。 |
| ロール値は複数のアプリケーションで使用できます | いいえ (各アプリケーションの登録でロールの構成が重複していない場合)。 | イエス | イエス |
| ディレクトリ内に格納されている情報 | イエス | イエス | いいえ |
| 情報はトークンを介して配信されます | はい (ロール要求) | はい (超過分の場合は、 実行時にグループ要求 を取得する必要がある場合があります) | いいえ (カスタム コードを使用して実行時に取得されます)。 |
| 有効期間。 | ディレクトリ内のアプリケーション登録に存在します。 アプリケーションの登録が削除されると削除されます。 | ディレクトリ内に存在します。 アプリケーションの登録が削除された場合でも、そのまま残ります。 | カスタム データ ストアに存在します。 アプリケーションの登録に関連付けされていません。 |
次のステップ
- Azure の ID 管理とアクセス制御セキュリティのベスト プラクティス
- トークン クレームを使用した適切な認可については、「クレームを検証してアプリケーションと API をセキュリティで保護する」を参照してください