Exchange Online 中應用程式的角色型訪問控制
本文將引導您使用細微且可調整的資源範圍訪問控制：角色型訪問控制 (Exchange Online 中應用程式的 RBAC) 。
概觀
Exchange Online 中的 RBAC for Applications 可讓系統管理員將許可權授與獨立存取 Exchange Online 中數據的應用程式。 此授與可與存取範圍 (資源範圍) 配對，以指定應用程式可以存取的信箱。 這項功能會擴充 Exchange Online 中目前的 RBAC 模型，並取代應用程式存取原則。
注意事項
使用 RBAC 應用程式角色時，無法存取 自動探索服務 。 如果您需要對 Exchange Online 執行自動探索要求，請利用Microsoft應用程式存 取 原則的 Entra ID 許可權來限制信箱存取。
此系統的核心是管理角色指派設定，表示系統管理員允許主體存取數據的意圖。 在此情況下，允許應用程式對一組目標資源執行某些角色。 例如，系統管理員可能會使用 管理範圍，設定只能在特定區域存取行事曆數據的會議室預約系統。 請參閱下圖說明角色指派模型：
設定指示
下列步驟將引導您建立這些應用程式 RBAC 指派：
需求
組織 管理 角色群組具有新應用程式 RBAC 角色的委派角色指派。 您必須是組織管理角色群組的成員，才能指派這些許可權。 或者，您可以使用 Exchange Online RBAC 授與委派指派給這些應用程式角色，如您所見。 在 Microsoft Entra ID 中，您需要 Exchange 系統管理員角色來指派這些許可權。
定義資源範圍
- 管理範圍：Exchange 實體，表示在這些信箱屬性上使用篩選表達式的一組信箱。
- 系統管理單位： Microsoft Entra 資源，可以是僅包含使用者群組或裝置之其他 Microsoft Entra 資源的容器。 若要深入瞭解，請 參閱 Microsoft Entra ID 中的管理單位和 建立或刪除管理單位。
管理範圍
管理範圍可讓系統管理員根據這些物件的屬性，設定一組信箱的範圍。 如需 新增、 移除、 設定，請參閱管理範圍檔。 以下是管理範圍中 可篩選屬性 的清單。
注意事項
雖然有一個稱為管理單位的屬性，但建議您在角色指派上使用原生管理單位參數，以避免將範圍建立為中繼指針對象。
服務主體
服務主體代表租用戶內應用程式的實例。 您應該將 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 中找到這些識別碼：
注意事項
請勿使用 [應用程式註冊] 頁面中的標識碼，因為它會顯示不同的值。 紅色外框的「應用程式標識碼」是 AppID，而「物件標識碼」則是 ServiceID。
您可以使用另一種方法，使用 Get-MgServicePrincipal 來尋找這些識別碼。
拿掉服務主體
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)
拿掉角色指派
如需移除角色指派，請參閱 移除管理指派。
測試授權
測試 Cmdlet 可用來模擬特定服務主體的 RBAC 指派所啟用的行為。
注意事項
此方法會排除可能在 Microsoft Entra ID 中個別授與的許可權。
測試授權時，您可以包含選擇性的資源參數，以評估哪些範圍許可權套用至該目標信箱。
InScope will = true or false 表示如果該許可權適用於該服務主體的信箱，則為 true;如果為 true，則表示該服務主體具有該許可權，但不適用於該特定信箱。 省略此旗標會導致「未執行」。
測試結果一律包含特定指派許可權的允許資源範圍。
測試服務主體存取
Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>
範例
在 PowerShell 中使用 Connect-ExchangeOnline 之後，請遵循下列步驟：
範例一：使用管理範圍為加拿大員工設定行事曆讀取許可權
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
範例二：設定所有歐洲系統管理單位信箱的 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
範例三：測試指派給服務主體的許可權
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
支援的應用程式角色
| 名稱 | Protocol (通訊協定) | 許可權清單 | 描述 |
|---|---|---|---|
| Application Mail.Read | MS Graph | Mail.Read | 允許應用程式在沒有登入用戶的情況下讀取所有信箱中的電子郵件。 |
| Application Mail.ReadBasic | MS Graph | Mail.ReadBasic | 允許應用程式在所有信箱中讀取電子郵件，但內文、預覽Body、附件和任何擴充屬性除外，而不需要登入的使用者 |
| 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 | 允許應用程式建立、讀取、更新和刪除所有信箱中的電子郵件，並以任何使用者的身分傳送郵件，而不需要登入的使用者。 |
| 應用程式 Exchange 完整存取 | MS Graph | Mail.ReadWrite、Mail.Send、MailboxSettings.ReadWrite、Calendars.ReadWrite、Contacts.ReadWrite | 沒有登入的使用者：允許應用程式建立、讀取、更新和刪除所有信箱中的電子郵件，並以任何使用者的身分傳送郵件。 允許應用程式在所有信箱中建立、讀取、更新和刪除使用者的信箱設定。 允許應用程式建立、讀取、更新和刪除所有行事曆的事件。 允許應用程式建立、讀取、更新和刪除所有信箱中的所有聯繫人。 |
| 應用程式 EWS。AccessAsApp | EWS | EWS。AccessAsApp | 允許應用程式使用具有所有信箱完整存取權的 Exchange Web 服務。 |
您可能會注意到這些角色代表可在 Azure 身分識別平臺中其他位置同意的 Microsoft Graph 許可權。 這些許可權的效果會與這些圖形許可權相同，但允許細微資源範圍存取的角色指派除外。
常見問題集
為什麼我的應用程式仍然能夠存取未使用 RBAC 授與的信箱？
您必須確定您已移除您在 Microsoft Entra ID 中指派的全租使用者未限定範圍許可權。 除了您在 Microsoft Entra ID 中所做的授與之外，使用 RBAC 動作指派的許可權。 Microsoft只能使用應用程式存取原則來限制 Entra 許可權。
如何在一個介面中檢視和修改所有應用程式許可權？
為了確保系統管理員具有應用程式許可權的合併檢視，我們將以Microsoft Entra 系統管理員體驗呈現 Exchange Online 中授與的這些許可權。 這項功能即將推出，請持續微調。
如何從應用程式存取原則移轉至應用程式的 RBAC？
透過應用程式存取原則，您有服務主體、Azure 中的許可權同意，以及與 Exchange Online 中服務主體相關聯的原則。 雖然您可以使用 Exchange 管理範圍或管理單位，以任何適合您的方式重新建構範圍機制，但以下是在應用程式存取原則中重複使用群組作為 RBAC for Applications 授與範圍的一些指引。 此程式不會對您的應用程式造成任何使用中斷。
移轉步驟：
- 建立新的管理範圍，從應用程式存取原則指向範圍群組
- 建立服務主體指針對象
- 使用管理範圍限制，將所需的許可權指派給 Exchange Online 中的服務主體
- 拿掉對 Azure 中許可權的同意
- 拿掉應用程式存取原則
在步驟 1 中建立管理範圍時，您將使用具有篩選參數 的收件者篩選器 MemberOfGroup。
以下是範例：「MemberOfGroup -eq 'CN=mesga20220818210551，OU=Fabrikam346.onmicrosoft.com，OU=Microsoft Exchange 託管組織，DC=NAMPR00A001，DC=prod，DC=outlook，DC=com'」
注意事項
此篩選參數會使用群組的 辨別名稱 ，您可以使用 Get-Group Cmdlet 找到此名稱。
局限性：
- 巢狀群組成員會被視為超出範圍。 只有直接群組成員資格才會在授權範圍內考慮成員。
- 支援Microsoft 365 群組、Mail-Enabled 安全組和通訊組清單。
RBAC for Applications 如何與應用程式存取原則搭配運作？
與應用程式存取原則的相容性
RBAC for Applications 會取代應用程式存取原則。
授權互操作性可如下所述：
應用程式存取原則只會限制在 Microsoft Entra ID 中指派的許可權。
RBAC for Applications 提供具有相關聯資源範圍的替代授權表達式。
應用程式可以同時擁有Microsoft同意的許可權和 RBAC 指派。 例如，當應用程式具有全租使用者的 Mail.Read 和範圍為 Mail.Send 時，我們預期會發生這種情況。
許可權同意是加法的。
範例一：來自 2 個系統的同意
- 應用程式具有Mail.Read in Microsoft Entra ID
- 此應用程式的範圍是使用應用程式存取原則啟用郵件的安全組 1
- 相同的應用程式已同意 RBAC for Applications 中的管理範圍 1 的 Calendar.Read
- 信箱 A 位於啟用郵件功能的安全組 1 中
- 信箱 B 位於管理範圍 1 的範圍內
MS Graph 存取需要 Mail.Read 和 Calendar.Read for App 1 的端點：
- 以信箱 A 為目標：失敗
- 目標信箱 B： 失敗
此端點需要Mail.Read和Calendar.Read。 雖然應用程式針對兩個不同的信箱個別擁有這些許可權，但它沒有一個信箱的兩個許可權。
範例二：指派相同的許可權兩次
- 應用程式具有Mail.Read in Microsoft Entra ID
- 此應用程式的範圍是使用應用程式存取原則啟用郵件的安全組 1
- 相同的應用程式已使用 RBAC for Applications 同意管理範圍 1 的 Mail.Read
- 信箱 A 位於啟用郵件功能的安全組 1 中
- 管理範圍 1 允許存取信箱 A (以外的每個信箱，根據像是 『Alias -ne mbxa』)
MS Graph 存取需要 Mail.Read for App 1 的端點：
- 以信箱 A 為目標：允許
- 以信箱 B 為目標：允許
雖然 Mail.Read from Microsoft Entra-only 允許存取信箱 A，但 RBAC 指派允許存取 A 以外的所有專案。實際上，這允許存取所有項目，因為「A」和「非 A」代表一切。
雖然我們已針對完整性概述這些邊緣案例，但我們並不預期應用程式存取原則通常會與 RBAC for Applications 搭配使用。 應在 Microsoft Entra ID 中指派全租用戶許可權，而資源範圍的許可權應使用 RBAC for Applications 來授與。
RBAC for Applications 支援多少個應用程式？
使用 RBAC for Applications，每個租使用者最多可以有 10,000 個應用程式。 請讓我們知道此限制是否會對您造成問題。 我們已以可高度擴充的方式建置 RBAC for Applications，以符合我們最大客戶的需求。
此功能的意見反應
您可以與 exoapprbacpreview@microsoft.com分享此功能的意見反應。