Rollenbasierte Access Control für Anwendungen in Exchange Online

Dieser Artikel führt Sie durch die Verwendung einer präzisen und skalierbaren, ressourcenbezogenen Zugriffssteuerung: Rollenbasierte Access Control (RBAC) für Anwendungen in Exchange Online.

Übersicht

RBAC für Anwendungen in Exchange Online ermöglicht Administratoren das Erteilen von Berechtigungen für eine Anwendung, die unabhängig auf Daten in Exchange Online zugreift. Diese Gewährung kann mit einem Zugriffsbereich (Ressourcenbereich) gekoppelt werden, um anzugeben, auf welche Postfächer eine App zugreifen kann. Dieses Feature erweitert das aktuelle RBAC-Modell in Exchange Online und ersetzt Anwendungszugriffsrichtlinien. Diese Berechtigungserteilungen sind unabhängig von den Zuweisungen ohne Bereich in Microsoft Entra ID.

Der Kern dieses Systems ist die Konfiguration der Verwaltungsrollenzuweisung, die die Absicht eines Administrators zum Ausdruck bringt, einem Prinzipal den Zugriff auf Daten zu ermöglichen. In diesem Fall ermöglicht es einer App, eine Bestimmte Rolle für eine Gruppe von Zielressourcen auszuführen. Beispielsweise kann ein Administrator mithilfe eines Verwaltungsbereichs ein Raumbuchungssystem mit Zugriff auf Kalenderdaten nur in bestimmten Regionen konfigurieren. Das folgende Diagramm veranschaulicht das Rollenzuweisungsmodell:

Konfigurationsanweisungen

Die folgenden Schritte führen Sie zum Erstellen dieser Anwendungs-RBAC-Zuweisungen:

1. Erstellen eines neuen Ressourcenbereichs (optional)
2. Erstellen eines Zeigers auf einen Microsoft Entra Dienstprinzipal
3. Auswählen der geeigneten Anwendungsrolle
4. Erstellen einer neuen Rollenzuweisung
5. Testen des neuen Dienstprinzipals

Anforderungen

Die Rollengruppe Organisationsverwaltung verfügt über die delegierende Rollenzuweisung für die neuen Anwendungs-RBAC-Rollen. Sie müssen Mitglied der Rollengruppe Organisationsverwaltung sein, um diese Berechtigungen zuweisen zu können. Alternativ können Sie Exchange Online RBAC verwenden, um delegierende Zuweisungen an diese Anwendungsrollen nach Bedarf zu gewähren. In Microsoft Entra ID benötigen Sie die Exchange-Administratorrolle, um diese Berechtigungen zuzuweisen.

Definieren des Ressourcenbereichs

• Verwaltungsbereiche: Eine Exchange-Entität , die eine Gruppe von Postfächern darstellt, die einen Filterausdruck für die Eigenschaften dieser Postfächer verwenden.
• Admin-Einheiten: Eine Microsoft Entra Ressource, die ein Container für andere Microsoft Entra Ressourcen sein kann, der nur Benutzergruppen oder Geräte enthält. Weitere Informationen finden Sie unter Administrative Einheiten in Microsoft Entra ID und Erstellen oder Löschen von Verwaltungseinheiten.

Verwaltungsbereiche

Verwaltungsbereiche ermöglichen es einem Administrator, einen Satz von Postfächern basierend auf den Eigenschaften dieser Objekte festzulegen. Informationen zum Hinzufügen, Entfernen, Festlegen finden Sie in der Dokumentation zum Verwaltungsbereich. Hier ist eine Liste der filterbaren Eigenschaften in einem Verwaltungsbereich.

Dienstprinzipale

Dienstprinzipale stellen eine instance einer Anwendung innerhalb Ihres organization dar. Sie sollten den Dienstprinzipal in Exchange als Zeiger auf einen vorhandenen Dienstprinzipal in Microsoft Entra ID betrachten. Dienstprinzipale können nicht direkt mit Exchange Online Tools erstellt werden. Microsoft Entra Tools werden zum Verwalten von Dienstprinzipalregistrierungen in Organisationen verwendet. Exchange verhindert die Erstellung eines ungültigen Zeigers und spiegelt alle Löschungen von Dienstprinzipalen in Microsoft Entra ID automatisch wider.

Neuer Dienstprinzipal

New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>

Der folgende Screenshot hilft Ihnen, diese IDs in Microsoft Entra ID zu finden:

Sie können einen anderen Ansatz verwenden, um diese IDs mithilfe von Get-MgServicePrincipal zu finden.

Dienstprinzipal entfernen

Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName>

Dienstprinzipal festlegen

Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>

Anwendungsrollen

Anwendungsrollen sind eine spezielle Art von Verwaltungsrolle in Exchange Online, die nur einer Anwendung zugewiesen werden kann. Diese Rollen können mithilfe von Get-ManagementRole aufgelistet werden.

Rollenzuweisungen

Verwaltungsrollenzuweisungen verknüpfen einen Prinzipal-, Rollen- und benutzerdefinierten Ressourcenzugriffsbereich. Diese Zuweisung fungiert als Berechtigungszuweisung für einen Dienstprinzipal, der eine Rolle über einen Bereich hinweg ausführt.

Neue Rollenzuweisung

New-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Festlegen der Rollenzuweisung

Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Entfernen der Rollenzuweisung

Informationen zum Entfernen einer Rollenzuweisung finden Sie unter Entfernen der Verwaltungszuweisung.

Testen der Autorisierung

Ein Test-Cmdlet kann verwendet werden, um das Verhalten zu simulieren, das durch RBAC-Zuweisungen für einen bestimmten Dienstprinzipal aktiviert wird.

Beim Testen der Autorisierung können Sie einen optionalen Ressourcenparameter einschließen, um auszuwerten, welche bereichsbezogenen Berechtigungen für dieses Zielpostfach gelten. InScope will = true or false um darzustellen, wenn, true, dass die Berechtigung für dieses Postfach für diesen Dienstprinzipal gilt, oder false, dass dieser Dienstprinzipal über diese Berechtigung verfügt, aber nicht für dieses bestimmte Postfach. Das Auslassen dieses Flags führt zu "Nicht ausführen".

Testergebnisse enthalten immer den zulässigen Ressourcenbereich für eine bestimmte zugewiesene Berechtigung.

Testen des Dienstprinzipalzugriffs

Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>

Beispiele

Führen Sie nach der Verwendung von Connect-ExchangeOnline in PowerShell die folgenden Schritte aus:

Beispiel 1: Konfigurieren des Kalenderlesezugriffs für kanadische Benutzer mithilfe eines Verwaltungsbereichs

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 users" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

Name                 ScopeRestrictionType      Exclusive      RecipientRoot          RecipientFilter
----                 --------------------      ---------      -------------          ---------------
Canadian users    RecipientScope            False                                CustomAttribute1 -eq '012332'

New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian users"

Name                      Role                 RoleAssigneeName       RoleAssigneeType        AssignmentMethod
----                      ----                 ----------------       ----------------        ----------------
Application Calendar...   Application Ca...    6233fba6-0198-...      ServicePrincipal        Direct

Beispiel 2: Konfigurieren von Mail.Read für alle Postfächer von Europe Admin Unit

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

Beispiel 3: Testen von Berechtigungen, die einem Dienstprinzipal zugewiesen sind

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

Begrenzungen

• Anwendungen können nicht Mitglied einer Rollengruppe werden.
• Anwendungsrollen können nur Dienstprinzipalen zugewiesen werden.
• Anwendungsrollen können nicht kopiert oder abgeleitet werden.
• Exklusive Verwaltungsbereiche schränken den App-Zugriff nicht ein.
• Änderungen an App-Berechtigungen unterliegen der Cachewartung, die je nach aktueller Nutzung der App zwischen 30 Minuten und 2 Stunden variiert. Wenn Sie Konfigurationen testen, umgeht der Testbefehl diesen Cache. Der Cache einer App ohne eingehende Aufrufe von APIs wird nach 30 Minuten zurückgesetzt. Der Cache einer aktiven App wird bis zu 2 Stunden lang aktiv gehalten.

Unterstützte Protokolle

• MS Graph
• EWS

Unterstützte Anwendungsrollen

Möglicherweise stellen Sie fest, dass diese Rollen Microsoft Graph-Berechtigungen darstellen, denen Sie an anderer Stelle im Azure Identity Platform zustimmen können. Diese Berechtigungen haben die gleiche Auswirkung wie die Graph-Berechtigungen, mit Ausnahme dieser Rollenzuweisungen, die einen präzisen Zugriff auf Ressourcenbereiche ermöglichen.

Häufig gestellte Fragen

Warum hat meine Anwendung weiterhin Zugriff auf Postfächer, die nicht durch den Bereich gewährt werden, den ich in Exchange Online Application RBAC verwendet habe?

Sie müssen sicherstellen, dass Sie die in Microsoft Entra ID zugewiesenen organization-weiten Berechtigungen ohne Bereich entfernt haben. Die mithilfe der Anwendungs-RBAC zugewiesenen Berechtigungen gelten zusätzlich zu den Berechtigungen, die Sie in Microsoft Entra ID vornehmen. Microsoft Entra Berechtigungen können nur mithilfe von Anwendungszugriffsrichtlinien eingeschränkt werden. Anders ausgedrückt: Die zugewiesenen Berechtigungen sind ein Union-Vorgang für die Berechtigungen von Microsoft Entra ID und die berechtigungen, die in Exchange Online RBAC zugewiesen sind. Jede Autorität kann unabhängig handeln.

Wenn Ihr Dienstprinzipal z. B. in Microsoft Entra ID erteilt hat Mail.Read und Sie eine ressourcenbezogene Mail.Read Berechtigung in RBAC für Anwendungen konfigurieren, ist es wichtig, dass Sie die Zuweisung von Mail.Read aus Microsoft Entra ID entfernen. Andernfalls führt die Vereinigung einer Nichtbereichszuweisung Mail.Read aus Microsoft Entra und einer ressourcenbezogenen Mail.Read Gewährung in Application RBAC zu keinem effektiven Ressourcenbereich.

Wie kann ich alle Anwendungsberechtigungen in einer Schnittstelle anzeigen und ändern?

Um sicherzustellen, dass Administratoren über eine konsolidierte Ansicht der App-Berechtigungen verfügen, werden diese Berechtigungen in Exchange Online in einer Microsoft Entra Administratorumgebung angezeigt. Dieses Feature ist in Kürze verfügbar, bleiben Sie dran.

Migrieren von Anwendungszugriffsrichtlinien zu RBAC für Anwendungen

Mit Anwendungszugriffsrichtlinien verfügen Sie über einen Dienstprinzipal, die Berechtigungsgenehmigung in Azure und eine Richtlinie, die einem Dienstprinzipal in Exchange Online zugeordnet ist. Während Sie Ihren Bereichsmechanismus mithilfe von Exchange-Verwaltungsbereichen oder Verwaltungseinheiten neu strukturieren können, finden Sie hier einige Anleitungen zur Wiederverwendung von Gruppen in einer App-Zugriffsrichtlinie als Bereich für Ihre RBAC for Applications-Gewährung. Dieser Prozess führt nicht zu einer Unterbrechung der Verwendung Ihrer App.

Migrationsschritte:

1. Erstellen Sie einen neuen Verwaltungsbereich, der auf die Bereichsgruppe aus der Anwendungszugriffsrichtlinie verweist.

2. Erstellen Sie das Dienstprinzipalzeigerobjekt.

3. Weisen Sie dem Dienstprinzipal die erforderlichen Berechtigungen in Exchange Online mit der Verwaltungsbereichseinschränkung zu.

4. Entfernen Sie die Zustimmung zur Berechtigung in Azure.

5. Entfernen Sie die Anwendungszugriffsrichtlinie.

   Beim Erstellen des Verwaltungsbereichs in Schritt 1 verwenden Sie einen Empfängerfilter mit dem Filterparameter MemberOfGroup. Hier ist ein Beispiel:

   "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

Begrenzungen:

• Geschachtelte Gruppenmitglieder werden als außerhalb des Gültigkeitsbereichs betrachtet. Nur die direkte Gruppenmitgliedschaft führt dazu, dass das Mitglied im Bereich der Autorisierung berücksichtigt wird.
• Microsoft 365-Gruppen, Mail-Enabled Sicherheitsgruppen und Verteilerlisten werden unterstützt.

Wie funktioniert RBAC für Anwendungen zusammen mit Anwendungszugriffsrichtlinien?

Kompatibilität mit der App-Zugriffsrichtlinie:

RBAC für Anwendungen ersetzt Anwendungszugriffsrichtlinien.

Die Autorisierungsinteroperabilität kann wie folgt beschrieben werden:

• Anwendungszugriffsrichtlinien schränken NUR die in Microsoft Entra ID zugewiesenen Berechtigungen ein.

• RBAC für Anwendungen bietet einen alternativen Autorisierungsausdruck mit einem zugeordneten Ressourcenbereich.

• Eine App kann sowohl über Microsoft Entra einwilligungsbasierte Berechtigungen als auch über RBAC-Zuweisungen verfügen. Wir erwarten diesen Fall, wenn eine App (z. B.) organization und bereichsweit Mail.ReadMail.Sendaufweist.

• Berechtigungszustimmungen sind additiv.

Beispiel 1: Zustimmungen von 2 Systemen:

• Eine App hat Mail.Read in Microsoft Entra ID.
• Diese App ist mit einer Anwendungszugriffsrichtlinie auf die E-Mail-aktivierte Sicherheitsgruppe 1 ausgerichtet.
• Dieselbe App hat Calendar.Read für Den Verwaltungsbereich 1 in RBAC for Applications zugestimmt.
• Postfach A befindet sich in der E-Mail-aktivierten Sicherheitsgruppe 1.
• Postfach B befindet sich im Verwaltungsbereich 1.

MS Graph-Zugriff auf einen Endpunkt, der sowohl als Calendar.Read auch Mail.Read für App 1 erfordert:

• Zielpostfach A: Schlägt fehl.
• Zielpostfach B: Schlägt fehl.

Dieser Endpunkt benötigt sowohl als Calendar.Readauch Mail.Read . Obwohl die App diese Berechtigungen einzeln für zwei separate Postfächer besitzt, verfügt sie nicht über beide Berechtigungen für ein Postfach.

Beispiel 2: Zweimal dieselbe Berechtigung zuweisen:

• Eine App hat Mail.Read in Microsoft Entra ID.
• Diese App ist mit einer Anwendungszugriffsrichtlinie auf die E-Mail-aktivierte Sicherheitsgruppe 1 ausgerichtet.
• Dieselbe App hat Mail.Read mit RBAC for Applications für Den Verwaltungsbereich 1 zugestimmt.
• Postfach A befindet sich in der E-Mail-aktivierten Sicherheitsgruppe 1.
• Verwaltungsbereich 1 ermöglicht den Zugriff auf jedes Postfach mit Ausnahme von Postfach A (gemäß einigen Filtern wie Alias -ne mbxa).

MS Graph-Zugriff auf einen Endpunkt, der für App 1 erforderlich ist Mail.Read :

• Zielpostfach A: zulassen.
• Zielpostfach B: zulassen.

Während der Mail.Read von Microsoft Entra nur Zugriff auf Postfach A zulässt, ermöglicht die RBAC-Zuweisung den Zugriff auf alles außer A. Tatsächlich ermöglicht diese Zuweisung den Zugriff auf alles, da "A und nicht A" alles bedeutet.

Obwohl wir diese Edgefälle aus Gründen der Vollständigkeit beschrieben haben, erwarten wir nicht, dass Anwendungszugriffsrichtlinien in der Regel mit RBAC für Anwendungen verwendet werden. Organisationsweite Berechtigungen sollten in Microsoft Entra ID zugewiesen werden, während ressourcenbezogene Berechtigungen mithilfe von RBAC for Applications erteilt werden sollten.

Wie viele Anwendungen werden von RBAC for Applications unterstützt?

Mit RBAC for Applications können bis zu 10.000 Anwendungen pro organization verwendet werden. Lassen Sie uns wissen, ob dieser Grenzwert ein Problem für Sie darstellt. Wir haben RBAC für Anwendungen auf hochgradig skalierbare Weise erstellt, um die Anforderungen unserer größten Kunden zu erfüllen.

Warum funktioniert die AutoErmittlung nicht?

Derzeit kann nicht auf den AutoErmittlungsdienst zugegriffen werden, wenn RBAC-Anwendungsrollen verwendet werden.

Was geschieht in Exchange, wenn ich einen Dienstprinzipal in Microsoft Entra lösche?

Gelöschte Dienstprinzipale in Microsoft Entra werden auch automatisch in Exchange entfernt. Durch diese Entfernung werden alle Zuweisungen für diese Dienstprinzipale gelöscht, verwaltungsbezogene Bereiche bleiben jedoch unberührt.

Feedback zu diesem Feature

Feedback zu diesem Feature kann mit exoapprbacpreview@microsoft.comgeteilt werden.