Rollenbasierte Zugriffssteuerung für Anwendungen in Exchange Online

Dieser Artikel führt Sie durch die Verwendung einer präzisen und skalierbaren, ressourcenbezogenen Zugriffssteuerung: Rollenbasierte Zugriffssteuerung (Role Based 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.

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. Sehen Sie sich das folgende Diagramm an, das das Rollenzuweisungsmodell veranschaulicht:

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 nach Bedarf an diese Anwendungsrollen zu gewähren. In Microsoft Entra ID benötigen Sie die Rolle Exchange-Administrator, 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.
• Administratoreinheiten: 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 Instanz einer Anwendung innerhalb Ihres Mandanten 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 innerhalb von Mandanten 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 Mitarbeiter 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 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

Beispiel 2: Konfigurieren von Mail.Read für alle Postfächer der Europäischen Verwaltungseinheit

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. Beim Testen von Konfigurationen umgeht der Testbefehl diesen Cache. Für eine App ohne eingehende Aufrufe von APIs wird der Cache in 30 Minuten zurückgesetzt, während eine aktiv verwendete App den Cache bis zu 2 Stunden lang aktiv hält.

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 auf der Azure Identity Platform zustimmen können. Diese Berechtigungen haben die gleiche Auswirkung wie diese Graph-Berechtigungen, mit Ausnahme dieser Rollenzuweisungen, die einen präzisen Zugriff auf ressourcenbezogene Ressourcen ermöglichen.

Häufig gestellte Fragen

Warum hat meine Anwendung weiterhin Zugriff auf Postfächer, die nicht über RBAC gewährt werden?

Sie müssen sicherstellen, dass Sie die mandantenweiten Nichtbereichsberechtigungen entfernt haben, die Sie in Microsoft Entra ID zugewiesen haben. Die über 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.

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 in Exchange Online erteilten Berechtigungen 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, eine Berechtigungsgenehmigung in Azure und eine Richtlinie, die einem Dienstprinzipal in Exchange Online zugeordnet ist. Sie können Ihren Bereichsmechanismus zwar mithilfe von Exchange-Verwaltungsbereichen oder Verwaltungseinheiten auf eine beliebige Weise neu strukturieren, aber hier finden Sie einige Anleitungen zum Wiederverwenden 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 Nutzung Ihrer App.

Migrationsschritte:

1. Erstellen Sie einen neuen Verwaltungsbereich, der auf die Bereichsgruppe aus der Anwendungszugriffsrichtlinie verweist.
2. Erstellen des Dienstprinzipalzeigerobjekts
3. Zuweisen der erforderlichen Berechtigungen zum Dienstprinzipal in Exchange Online mit der Einschränkung des Verwaltungsbereichs
4. Entfernen der Zustimmung zur Berechtigung in Azure
5. Entfernen der 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=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 von Microsoft Entra erteilte Berechtigungen als auch über RBAC-Zuweisungen verfügen. Wir erwarten diesen Fall, wenn eine App beispielsweise über mandantenweite Mail.Read und bereichsbezogene Mail.Send verfügt.

• Berechtigungszustimmungen sind additiv.

Beispiel 1: Zustimmungen von 2 Systemen

• Eine App verfügt über Mail.Read in Microsoft Entra ID
• Diese App ist mit einer Anwendungszugriffsrichtlinie auf die E-Mail-aktivierte Sicherheitsgruppe 1 ausgerichtet.
• Dieselbe App verfügt über die Zustimmung von Calendar.Read für Verwaltungsbereich 1 in RBAC for Applications
• 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 Mail.Read als auch Calendar.Read für App 1 erfordert:

• Zielpostfach A: Fehler
• Zielpostfach B: Fehler

Dieser Endpunkt benötigt sowohl Mail.Read als auch Calendar.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 verfügt über Mail.Read in Microsoft Entra ID
• Diese App ist mit einer Anwendungszugriffsrichtlinie auf die E-Mail-aktivierte Sicherheitsgruppe 1 ausgerichtet.
• Für dieselbe App ist Mail.Read für Verwaltungsbereich 1 mit RBAC for Applications einverstanden.
• 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äß einem Filter wie "Alias -ne mbxa")

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

• Zielpostfach A: zulassen
• Zielpostfach B: Zulassen

Während mail.Read von Microsoft Entra nur den Zugriff auf Postfach A zulässt, ermöglicht die RBAC-Zuweisung den Zugriff auf alles außer A. Dies ermöglicht 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. Mandantenweite 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?

Sie können bis zu 10.000 Anwendungen pro Mandant verwenden, indem Sie RBAC for Applications verwenden. Bitte teilen Sie uns mit, 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.

Feedback zu diesem Feature

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