Exchange Online でのアプリケーションのロールベースのアクセス制御
この記事では、詳細でスケーラブルなリソーススコープのアクセス制御: Exchange Online のアプリケーションのロールベースのアクセス制御 (RBAC) を使用する方法について説明します。
概要
Exchange Online のアプリケーションの RBAC を使用すると、管理者は Exchange Online のデータに個別にアクセスするアプリケーションにアクセス許可を付与できます。 この許可をアクセス範囲 (リソース スコープ) と組み合わせて、アプリがアクセスできるメールボックスを指定できます。 この機能により、Exchange Online の現在の RBAC モデルが拡張され、アプリケーション アクセス ポリシーが置き換えられます。
注:
RBAC アプリケーション ロールを使用している場合、 自動検出サービス にアクセスできません。 Exchange Online に対して自動検出要求を実行する必要がある場合は、 アプリケーション アクセス ポリシー で Microsoft Entra ID アクセス許可を利用してメールボックスへのアクセスを制限してください。
このシステムの中核となるのは、管理ロールの割り当て構成であり、プリンシパルがデータにアクセスすることを許可する管理者の意図を表します。 この場合、アプリが一連のターゲット リソースに対して何らかのロールを実行できるようにします。 たとえば、管理者は、 管理スコープを使用して特定のリージョンでのみ予定表データにアクセスできる会議室予約システムを構成できます。 ロールの割り当てモデルを示す次の図を参照してください。
構成手順
次の手順では、これらのアプリケーション RBAC 割り当てを作成する方法について説明します。
- 新しいリソース スコープを作成する (省略可能)
- Microsoft Entra サービス プリンシパルへのポインターを作成する
- 適切なアプリケーション ロールを選択する
- 新しいロールの割り当てを作成する
- 新しいサービス プリンシパルをテストする
要件
Organization Management ロール グループには、新しいアプリケーション RBAC ロールの委任ロールの割り当てがあります。 これらのアクセス許可を割り当てるには、組織管理役割グループのメンバーである必要があります。 または、Exchange Online RBAC を使用して、必要に応じてこれらのアプリケーション ロールに委任割り当てを付与することもできます。 Microsoft Entra ID では、これらのアクセス許可を割り当てるために Exchange 管理者ロールが必要です。
リソース スコープの定義
- 管理スコープ: これらのメールボックスのプロパティでフィルター式を使用してメールボックスのセットを表す Exchange エンティティ 。
- 管理ユニット: ユーザー グループまたはデバイスのみを含む他の Microsoft Entra リソースのコンテナーとして使用できる Microsoft Entra リソース。 詳細については、「 Microsoft Entra ID の管理単位 」および「 管理単位の作成または削除」を参照してください。
管理スコープ
管理スコープを使用すると、管理者は、これらのオブジェクトのプロパティに基づいて一連のメールボックスのスコープを設定できます。 追加、削除、設定については、管理スコープのドキュメントを参照してください。 管理スコープの フィルター可能なプロパティ の一覧を次に示します。
注:
管理単位と呼ばれるプロパティがありますが、中間ポインター オブジェクトとしてスコープを作成しないように、ロールの割り当てにネイティブの Admin Units パラメーターを使用することをお勧めします。
サービス プリンシパル
サービス プリンシパルは、テナント内のアプリケーションのインスタンスを表します。 Exchange のサービス プリンシパルは、Microsoft Entra ID の既存のサービス プリンシパルへのポインターであると考える必要があります。 サービス プリンシパルは、Exchange Online ツールを使用して直接作成することはできません。 Microsoft Entra ツールは、テナント内のサービス プリンシパルの登録を管理するために使用されます。 Exchange は無効なポインターの作成を防ぎ、Microsoft Entra ID のサービス プリンシパルの削除を自動的に反映します。
新しいサービス プリンシパル
New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>
次のスクリーンショットは、Microsoft Entra ID でこれらの ID を見つけるのに役立ちます。
注:
異なる値が表示されるため、[アプリの登録] ページの ID は使用しないでください。 赤いアウトラインの "アプリケーション ID" は AppID、"オブジェクト ID" は ServiceID です。
別の方法を使用して、 Get-MgServicePrincipal を使用してこれらの ID を見つけることができます。
サービス プリンシパルの削除
Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName>
サービス プリンシパルの設定
Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>
アプリケーション ロール
アプリケーション ロールは、Exchange Online の特殊な種類の管理ロールであり、アプリケーションにのみ割り当てることができます。 これらのロールは 、Get-ManagementRole を使用して列挙できます。
ロールの割り当て
管理ロールの割り当ては、アクセスのプリンシパル、ロール、およびカスタム リソース スコープを結び付けます。 この割り当ては、スコープ全体でロールを実行するサービス プリンシパルのアクセス許可の割り当てとして機能します。
新しいロールの割り当て
New-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)
ロールの割り当てを設定する
Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)
ロールの割り当てを削除する
ロールの割り当てを削除する方法については、「 管理割り当ての削除」を参照してください。
承認のテスト
テスト コマンドレットを使用すると、特定のサービス プリンシパルに対する RBAC 割り当てによって有効な動作をシミュレートできます。
注:
このメソッドは、Microsoft Entra ID で個別に付与される可能性があるアクセス許可を除外します。
承認をテストするときに、オプションのリソース パラメーターを含め、そのターゲット メールボックスに適用されるスコープ付きアクセス許可を評価できます。
InScope will = true or false
を表す場合は true、そのアクセス許可はそのサービス プリンシパルのメールボックスに適用されます。または、そのサービス プリンシパルにそのアクセス許可を持っているが、その特定のメールボックスに対してはアクセス許可がない場合は false を指定します。 このフラグを省略すると、"Not Run" になります。
テスト結果には、特定の割り当てられたアクセス許可に対して許可されるリソース スコープが常に含まれます。
サービス プリンシパル アクセスのテスト
Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>
例
PowerShell で Connect-ExchangeOnline を 使用した後、次の手順に従います。
例 1: 管理スコープを使用してカナダの従業員の予定表の読み取りアクセスを構成する
New-ServicePrincipal -AppId 71487acd-ec93-476d-bd0e-6c8b31831053 -ObjectId 6233fba6-0198-4277-892f-9275bf728bcc -DisplayName "example"
DisplayName ObjectId AppId
----------- --------- -----
example 6233fba6-0198-4277-892f-9275bf728bcc 71487acd-ec93-476d-bd0e-6c8b3183105
New-ManagementScope -Name "Canadian employees" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"
Name ScopeRestrictionType Exclusive RecipientRoot RecipientFilter
---- -------------------- --------- ------------- ---------------
Canadian employees RecipientScope False CustomAttribute1 -eq '012332'
New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian Employees"
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod
---- ---- ---------------- ---------------- ----------------
Application Calendar... Application Ca... 6233fba6-0198-... ServicePrincipal Direct
例 2: すべてのヨーロッパ管理ユニット メールボックスの Mail.Read の構成
New-ServicePrincipal -AppId eb19847b-5563-42ea-b719-ea47cb0cf4b3 -ObjectId 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -DisplayName "example"
DisplayName ObjectId AppId
----------- --------- -----
example 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 eb19847b-5563-42ea-b719-ea47cb0cf4b3
New-ManagementRoleAssignment -App 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -Role "Application Mail.Read" -RecipientAdministrativeUnitScope 4d819ce9-9257-44d7-af20-68a49e6697f4
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod
---- ---- ---------------- ---------------- ----------------
Application Mail.Rea... Application Ma... 59b7c6cb-58d3-... ServicePrincipal Direct
例 3: サービス プリンシパルに割り当てられたアクセス許可のテスト
Test-ServicePrincipalAuthorization -Resource b -Identity "DemoB" | Format-Table
RoleName GrantedPermissions AllowedResourceScope ScopeType InScope
-------- ------------------ -------------------- --------- ------
Application Mail.Read Mail.Read Scope-MESGaDN CustomRecipientScope False
Application Calendars.Read Calendars.Read Scope-DL1 CustomRecipientScope False
Application Contacts.Read Contacts.Read Scope-MESGa CustomRecipientScope False
制限事項
- アプリケーションはロール グループのメンバーになることはできません。
- アプリケーション ロールは、サービス プリンシパルにのみ割り当てることができます。
- アプリケーション ロールをコピーまたは派生することはできません。
- 排他的管理スコープでは、アプリのアクセスは制限されません。
- アプリのアクセス許可の変更は、アプリの最近の使用状況に応じて 30 分から 2 時間の間で異なるキャッシュ メンテナンスの対象となります。 構成をテストする場合、テスト コマンドはこのキャッシュをバイパスします。 API への受信呼び出しがないアプリでは、キャッシュが 30 分後にリセットされますが、アクティブに使用されているアプリはキャッシュを最大 2 時間保持します。
サポートされているプロトコル
- MS Graph
- EWS
サポートされているアプリケーション ロール
名前 | プロトコル | アクセス許可の一覧 | 説明 |
---|---|---|---|
Application Mail.Read | MS Graph | Mail.Read | サインインしているユーザーなしで、アプリがすべてのメールボックスのメールを読み取ることができます。 |
Application Mail.ReadBasic | MS Graph | Mail.ReadBasic | サインインしているユーザーがいないすべてのメールボックスの本文、previewBody、添付ファイル、および拡張プロパティを除く電子メールをアプリで読み取ることができます |
Application Mail.ReadWrite | MS Graph | Mail.ReadWrite | サインインしているユーザーがいないすべてのメールボックスで、アプリでメールの作成、読み取り、更新、削除を行うことができます。 メールを送信するためのアクセス許可は含まれません。 |
Application Mail.Send | MS Graph | Mail.Send | サインインしているユーザーなしで、任意のユーザーとしてアプリでメールを送信できるようにします。 |
Application MailboxSettings.Read | MS Graph | MailboxSettings.Read | サインインしているユーザーなしで、すべてのメールボックスでユーザーのメールボックス設定を読み取ることができます。 |
Application MailboxSettings.ReadWrite | MS Graph | MailboxSettings.ReadWrite | サインインしているユーザーがいないすべてのメールボックスで、アプリがユーザーのメールボックス設定を作成、読み取り、更新、削除できるようにします。 |
Application Calendars.Read | MS Graph | Calendars.Read | サインインしているユーザーなしで、すべてのカレンダーのイベントをアプリで読み取れるようにします。 |
Application Calendars.ReadWrite | MS Graph | Calendars.ReadWrite | サインインしているユーザーなしで、すべての予定表のイベントをアプリで作成、読み取り、更新、および削除できるようにします。 |
アプリケーションの連絡先.Read | MS Graph | Contacts.Read | サインインしているユーザーなしで、すべてのメールボックス内のすべての連絡先をアプリで読み取りできるようにします。 |
Application Contacts.ReadWrite | MS Graph | Contacts.ReadWrite | サインインしているユーザーなしで、すべてのメールボックス内のすべての連絡先をアプリで作成、読み取り、更新、および削除できるようにします。 |
アプリケーション メールのフル アクセス | MS Graph | Mail.ReadWrite, Mail.Send | アプリがすべてのメールボックスでメールを作成、読み取り、更新、削除し、サインインしているユーザーなしで任意のユーザーとしてメールを送信できるようにします。 |
Application Exchange のフル アクセス | MS Graph | Mail.ReadWrite、Mail.Send、MailboxSettings.ReadWrite、Calendars.ReadWrite、Contacts.ReadWrite | サインインしているユーザーなし: アプリがすべてのメールボックスでメールを作成、読み取り、更新、削除し、任意のユーザーとしてメールを送信できるようにします。 アプリがすべてのメールボックスでユーザーのメールボックス設定を作成、読み取り、更新、削除できるようにします。 アプリがすべての予定表のイベントを作成、読み取り、更新、および削除できるようにします。 アプリがすべてのメールボックス内のすべての連絡先を作成、読み取り、更新、削除できるようにします。 |
アプリケーション EWS。AccessAsApp | EWS | EWS。AccessAsApp | アプリが Exchange Web サービスを使用して、すべてのメールボックスへのフル アクセスを許可します。 |
これらのロールは、Azure Identity プラットフォームの他の場所で同意できる Microsoft Graph のアクセス許可を表している場合があります。 これらのアクセス許可は、リソース スコープの詳細なアクセスを許可するこれらのロールの割り当てを除き、Graph のアクセス許可と同じ効果を持ちます。
FAQ
RBAC を使用して付与されていないメールボックスにアプリケーションが引き続きアクセスできるのはなぜですか?
Microsoft Entra ID で割り当てたテナント全体のスコープ外のアクセス許可が削除されていることを確認する必要があります。 RBAC を使用して割り当てられたアクセス許可は、Microsoft Entra ID で行った許可に加えて機能します。 Microsoft Entra のアクセス許可は、アプリケーション アクセス ポリシーを使用してのみ制限できます。
1 つのインターフェイスですべてのアプリケーションのアクセス許可を表示および変更するにはどうすればよいですか?
管理者がアプリのアクセス許可を統合して表示できるように、Microsoft Entra 管理者エクスペリエンスで Exchange Online で付与されたこれらのアクセス許可を確認します。 この機能は今後予定されています。ご期待ください。
アプリケーション アクセス ポリシーからアプリケーションの RBAC に移行する方法
アプリケーション アクセス ポリシーでは、サービス プリンシパル、Azure でのアクセス許可の同意、および Exchange Online のサービス プリンシパルに関連付けられているポリシーがあります。 Exchange 管理スコープまたは管理単位を使用して、有効な方法でスコープ メカニズムを再構築できますが、アプリケーションの RBAC 許可のスコープとして、アプリ アクセス ポリシーのグループを再利用する方法に関するガイダンスを次に示します。 このプロセスにより、アプリの使用が中断されることはありません。
移行手順:
- アプリケーション アクセス ポリシーからスコープ グループを指す新しい管理スコープを作成する
- サービス プリンシパル ポインター オブジェクトを作成する
- 管理スコープの制限を使用して、Exchange Online のサービス プリンシパルに必要なアクセス許可を割り当てる
- Azure のアクセス許可に対する同意を削除する
- アプリケーション アクセス ポリシーを削除する
手順 1 で管理スコープを作成する場合は、フィルター パラメーター MemberOfGroup
の受信者フィルターを使用します。
"MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com' の例を次に示します。
注:
このフィルター パラメーターは、グループの 識別名 を使用します。この名前は、Get-Group コマンドレットを使用して確認できます。
制限:
- 入れ子になったグループ メンバーはスコープ外と見なされます。 直接グループ メンバーシップのみが、承認のスコープ内でメンバーと見なされます。
- Microsoft 365 グループ、Mail-Enabled セキュリティ グループ、配布リストがサポートされています。
アプリケーションの RBAC は、アプリケーション アクセス ポリシーと共にどのように機能しますか?
アプリ アクセス ポリシーとの互換性
アプリケーションの RBAC は、アプリケーション アクセス ポリシーに代わるものになります。
承認の相互運用性は、次のように記述できます。
アプリケーション アクセス ポリシーは、Microsoft Entra ID で割り当てられたアクセス許可のみを制限します。
アプリケーションの RBAC は、関連付けられたリソース スコープを持つ承認の代替式を提供します。
アプリには、Microsoft Entra の同意されたアクセス許可と RBAC 割り当ての両方を使用できます。 たとえば、アプリにテナント全体の Mail.Read があり、スコープが Mail.Send である場合に、このケースが想定されます。
アクセス許可の同意は追加的です。
例 1: 2 つのシステムからの同意
- アプリに Microsoft Entra ID の Mail.Read が含まれる
- このアプリのスコープは、アプリケーション アクセス ポリシーを使用してメールが有効なセキュリティ グループ 1 です
- 同じアプリに、アプリケーションの RBAC の管理スコープ 1 に対する Calendar.Read の同意がある
- メールボックス A がメールが有効なセキュリティ グループ 1 内にある
- メールボックス B が管理スコープ 1 のスコープ内にある
アプリ 1 の Mail.Read と Calendar.Read の両方を必要とするエンドポイントへの MS Graph アクセス:
- メールボックス A のターゲット設定: 失敗する
- メールボックス B のターゲット設定: 失敗する
このエンドポイントには、Mail.Read と Calendar.Read の両方が必要です。 アプリには、2 つの個別のメールボックスに対してこれらのアクセス許可が個別に付与されますが、1 つのメールボックスに対する両方のアクセス許可はありません。
例 2: 同じアクセス許可を 2 回割り当てる
- アプリに Microsoft Entra ID の Mail.Read が含まれる
- このアプリのスコープは、アプリケーション アクセス ポリシーを使用してメールが有効なセキュリティ グループ 1 です
- 同じアプリに、アプリケーションの RBAC を使用した管理スコープ 1 に対する Mail.Read の同意がある
- メールボックス A がメールが有効なセキュリティ グループ 1 内にある
- 管理スコープ 1 では、メールボックス A を除くすべてのメールボックスにアクセスできます ('Alias -ne mbxa' のようなフィルターに従います)
Mail.Read for App 1 を必要とするエンドポイントへの MS Graph アクセス:
- メールボックス A のターゲット設定: 許可
- メールボックス B のターゲット設定: 許可
Microsoft Entra からの Mail.Read ではメールボックス A へのアクセスのみが許可されますが、RBAC 割り当てでは A 以外のすべてのアクセスが許可されます。実際には、"A と Not A" はすべてを意味するため、これによりすべてのアクセスが許可されます。
これらのエッジ ケースを完全に説明しましたが、通常、アプリケーションの RBAC でアプリケーション アクセス ポリシーが使用されるとは考えていません。 テナント全体のアクセス許可は Microsoft Entra ID で割り当てる必要があります。リソーススコープのアクセス許可は、アプリケーションの RBAC を使用して付与する必要があります。
RBAC for Applications でサポートされているアプリケーションの数はいくつですか?
RBAC for Applications を使用して、テナントごとに最大 10,000 個のアプリケーションを使用できます。 この制限によって問題が発生した場合は、お知らせください。 大規模な顧客のニーズに対応するために、高度にスケーラブルな方法でアプリケーションの RBAC を構築しました。
この機能に関するフィードバック
この機能に関するフィードバックは、 exoapprbacpreview@microsoft.comと共有できます。