Freigeben über


Bedingter Zugriff: Zielressourcen

Zielressourcen (früher Cloud-Apps, Aktionen und Authentifizierungskontext) sind wichtige Signale in einer Richtlinie für bedingten Zugriff. Mit Richtlinien für bedingten Zugriff können Administratoren bestimmten Anwendungen, Diensten, Aktionen oder Authentifizierungskontext Steuerelemente zuweisen.

  • Administratoren können aus einer Liste von Anwendungen oder Diensten wählen, die integrierte Microsoft-Anwendungen sowie alle integrierten Microsoft Entra-Anwendungen umfassen, einschließlich Katalog-, nicht im Katalog geführter und über Application Proxy veröffentlichter Anwendungen.
  • Administratoren können eine Richtlinie basierend auf einer Benutzeraktion wie "Sicherheitsinformationen registrieren " oder "Registrieren" oder "Verbinden von Geräten" definieren, sodass der bedingte Zugriff Steuerelemente für diese Aktionen erzwingen kann.
  • Administratoren können Datenverkehrsweiterleitungsprofile von Global Secure Access für erweiterte Funktionalität ausrichten.
  • Administratoren können den Authentifizierungskontext verwenden, um eine zusätzliche Sicherheitsebene in Anwendungen bereitzustellen.

Screenshot einer Richtlinie für bedingten Zugriff und des Fensterbereichs mit den Zielressourcen.

Microsoft Cloud-Anwendungen

Administratoren können Apps in der Microsoft-Cloud eine Richtlinie für bedingten Zugriff zuweisen, wenn der Dienstprinzipal im Mandanten verfügbar ist. Ausgenommen ist Microsoft Graph. Microsoft Graph fungiert als Dachressource. Verwenden Sie die Zielgruppenberichterstattung , um die zugrunde liegenden Dienste anzuzeigen und diese Dienste in Ihren Richtlinien zu verwenden. Einige Apps wie die Office 365- und Windows Azure-Dienstverwaltungs-API umfassen mehrere verwandte untergeordnete Apps oder Dienste. Wenn neue Microsoft-Cloud-Anwendungen erstellt werden, erscheinen sie in der App-Auswahlliste, sobald das Dienstprinzipal im Mandant erstellt wird.

Office 365

Microsoft 365 bietet cloudbasierte Produktivitäts- und Zusammenarbeitsdienste wie Exchange, SharePoint und Microsoft Teams. Microsoft 365-Clouddienste sind umfassend integriert, um nahtlose Funktionen für die Zusammenarbeit zu gewährleisten. Diese Integration kann beim Erstellen von Richtlinien Verwirrung verursachen, da einige Apps, z. B. Microsoft Teams, von anderen abhängig sind, z. B. SharePoint oder Exchange.

Die Office 365-App-Gruppierung ermöglicht es, diese Dienste auf einmal anzusprechen. Es wird empfohlen, die Office 365-Gruppierung zu verwenden, anstatt einzelne Cloud-Apps zu verwenden, um Probleme mit Dienstabhängigkeiten zu vermeiden.

Eine Ausrichtung auf diese Gruppe von Anwendungen trägt dazu bei, Probleme zu vermeiden, die aufgrund inkonsistenter Richtlinien und Abhängigkeiten auftreten können. Beispiel: Die Exchange Online-App ist an herkömmliche Exchange Online-Daten wie E-Mail-, Kalender- und Kontaktinformationen gebunden. Zugehörige Metadaten können über verschiedene Ressourcen wie die Suche verfügbar gemacht werden. Um sicherzustellen, dass alle Metadaten wie beabsichtigt geschützt sind, sollten Administratoren der Office 365-App Richtlinien zuweisen.

Administratoren können die gesamte Office 365-Suite oder bestimmte Office 365-Cloud-Apps von Richtlinien für bedingten Zugriff ausschließen.

Eine vollständige Liste aller enthaltenen Dienste finden Sie im Artikel Apps, die in der Office 365-App-Suite für bedingten Zugriff enthalten sind.

Windows Azure Dienstverwaltungs-API

Wenn Sie auf die Windows Azure Service Management API-Anwendung abzielen, wird die Richtlinie für Token erzwungen, die an eine Gruppe von Diensten ausgestellt wurden, die eng an das Portal gebunden sind. Diese Gruppierung umfasst die Anwendungs-IDs von:

  • Azure Resource Manager
  • Azure-Portal, das auch das Microsoft Entra Admin Center und das Microsoft Engage Center abdeckt
  • Azure Data Lake
  • Application Insights-Programmierschnittstelle
  • Log Analytics-API

Da die Richtlinie auf das Azure-Verwaltungsportal und die API angewendet wird, können alle Dienste oder Clients, die von der Azure-API abhängen, indirekt betroffen sein. Beispiel:

  • Azure CLI
  • Azure Data Factory-Portal
  • Azure Event Hubs
  • Azure PowerShell
  • Azure-Servicebus
  • Azure SQL-Datenbank
  • Azure Synapse
  • APIs für das klassische Bereitstellungsmodell
  • Microsoft 365 Admin Center
  • Microsoft IoT Central
  • Verwaltete SQL-Instanz
  • Administratorportal für Visual Studio-Abonnements

Vorsicht

Richtlinien für bedingten Zugriff, die der Windows Azure Service Management-API zugeordnet sind, decken Azure DevOps nicht mehr ab.

Note

Die Windows Azure Service Management API-Anwendung gilt für Azure PowerShell, die die Azure Resource Manager-API aufruft. Sie gilt nicht für Microsoft Graph PowerShell, die die Microsoft Graph-API aufruft.

Tip

Für Azure Government sollten Sie die Anwendung „Azure Government Cloud Management API“ auswählen.

Microsoft-Verwaltungsportale

Wenn eine Richtlinie für bedingten Zugriff auf die Microsoft Admin Portals-Cloud-App ausgerichtet ist, wird die Richtlinie für Token erzwungen, die an Anwendungs-IDs der folgenden Microsoft-Verwaltungsportale ausgegeben werden:

  • Azure portal
  • Exchange Admin Center
  • Microsoft 365 Admin Center
  • Microsoft 365 Defender-Portal
  • Microsoft Entra Admin Center
  • Microsoft Intune Admin Center
  • Grundlegendes zum Microsoft Purview-Complianceportal
  • Microsoft Teams Admin Center

Wir fügen der Liste kontinuierlich weitere Verwaltungsportale hinzu.

Andere Anwendungen

Administratoren können jede registrierte Microsoft Entra-Anwendung zu Richtlinien für bedingten Zugriff hinzufügen. Dazu können folgende Anwendungen zählen:

Note

Da die Richtlinie für bedingten Zugriff die Anforderungen für den Zugriff auf einen Dienst festlegt, können Sie sie nicht auf eine Clientanwendung (öffentlich/native) anwenden. Anders ausgedrückt: Die Richtlinie wird nicht direkt auf einer Clientanwendung (öffentlich/systemeigene Anwendung) festgelegt, sondern angewendet, wenn ein Client einen Dienst aufruft. Eine Richtlinie, die für den SharePoint-Dienst festgelegt wurde, gilt beispielsweise für alle Clients, die SharePoint aufrufen. Eine Richtlinie, die für Exchange festgelegt wurde, gilt für den Zugriffsversuch auf E-Mail mithilfe des Outlook-Clients. Aus diesem Grund sind Clientanwendungen (öffentlich/systemeigene) nicht für die Auswahl in der App-Auswahl verfügbar, und die Option für bedingten Zugriff ist in den Anwendungseinstellungen für die in Ihrem Mandanten registrierte Clientanwendung (öffentlich/systemeigene Anwendung) nicht verfügbar.

Einige Anwendungen werden in der Auswahl überhaupt nicht angezeigt. Die einzige Möglichkeit, diese Anwendungen in eine Richtlinie für bedingten Zugriff einzuschließen, besteht darin, alle Ressourcen (früher "Alle Cloud-Apps") einzuschließen oder den fehlenden Dienstprinzipal mithilfe des New-MgServicePrincipal PowerShell-Cmdlets oder mithilfe der Microsoft Graph-API hinzuzufügen.

Grundlegendes zum bedingten Zugriff für verschiedene Clienttypen

Bedingter Zugriff gilt für Ressourcen, die keine Clients sind, außer wenn der Client ein vertraulicher Client ist, der ein ID-Token anfordert.

  • Öffentlicher Client
    • Öffentliche Clients sind solche, die lokal auf Geräten wie Microsoft Outlook auf dem Desktop oder mobilen Apps wie Microsoft Teams ausgeführt werden.
    • Richtlinien für bedingten Zugriff gelten nicht für öffentliche Clients selbst, sondern basieren auf den von ihnen angeforderten Ressourcen.
  • Vertraulicher Client
    • Der bedingte Zugriff gilt für die vom Client angeforderten Ressourcen und den vertraulichen Client selbst, wenn er ein ID-Token anfordert.
    • Beispiel: Wenn Outlook Web ein Token für Bereiche Mail.Read und Files.Readanfordert, wendet der bedingte Zugriff Richtlinien für Exchange und SharePoint an. Wenn Outlook Web ein ID-Token anfordert, wendet der bedingte Zugriff auch die Richtlinien für Outlook Web an.

Ansicht der Anmeldedatenprotokolle für diese Clienttypen aus dem Microsoft Entra Admin Center:

  1. Melden Sie sich mindestens als Berichtsleser beim Microsoft Entra Admin Center an.
  2. Navigieren Sie zu Entra ID>Überwachung & Gesundheit>Sign-in-Protokollen.
  3. Fügen Sie einen Filter für den Clientanmeldeinformationstyp hinzu.
  4. Passen Sie den Filter an, um einen bestimmten Satz von Protokollen basierend auf den Clientanmeldeinformationen anzuzeigen, die in der Anmeldung verwendet werden.

Weitere Informationen finden Sie im Artikel "Öffentlicher Client und vertrauliche Clientanwendungen".

Alle Ressourcen

Das Anwenden einer Richtlinie für bedingten Zugriff auf alle Ressourcen (früher "Alle Cloud-Apps") ohne App-Ausschlüsse erzwingt die Richtlinie für alle Tokenanforderungen von Websites und Diensten, einschließlich der Weiterleitungsprofile für globalen sicheren Zugriff. Diese Option umfasst Anwendungen, die in der Richtlinie für bedingten Zugriff nicht einzeln als Ziel bestimmt werden können, z. B. Windows Azure Active Directory (0000002-00000-0000-c000000000000).

Important

Microsoft empfiehlt, eine grundlegende mehrstufige Authentifizierungsrichtlinie für alle Benutzer und alle Ressourcen (ohne App-Ausschlüsse) zu erstellen, wie die unter "Mehrstufige Authentifizierung für alle Benutzer erforderlich" erläutert wird.

Verhalten des bedingten Zugriffs, wenn eine Richtlinie für alle Ressourcen einen App-Ausschluss aufweist

Wenn eine App aus der Richtlinie ausgeschlossen ist, um den Benutzerzugriff nicht versehentlich zu blockieren, werden bestimmte Bereiche mit niedriger Berechtigung von der Richtlinienerzwingung ausgeschlossen. Diese Bereiche ermöglichen Aufrufen der zugrunde liegenden Graph-APIs wie Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) und Microsoft Graph (00000003-0000-0000-c0000-00000000000), um im Rahmen der Authentifizierung häufig von Anwendungen verwendeten Benutzerprofil- und Gruppenmitgliedschaftsinformationen zuzugreifen. Beispiel: Wenn Outlook ein Token für Exchange anfordert, wird auch der User.Read Bereich aufgefordert, die grundlegenden Kontoinformationen des aktuellen Benutzers anzuzeigen.

Die meisten Apps weisen eine ähnliche Abhängigkeit auf, weshalb diese geringen Berechtigungsbereiche automatisch ausgeschlossen werden, wenn in einer Richtlinie "Alle Ressourcen" ein App-Ausschluss vorhanden ist. Diese Ausschlussbereiche mit geringen Rechten erlauben keinen Datenzugriff über grundlegende Benutzerprofil- und Gruppeninformationen hinaus. Die ausgeschlossenen Bereiche werden wie folgt aufgeführt, die Zustimmung ist weiterhin erforderlich, damit Apps diese Berechtigungen verwenden können.

  • Native-Clients und Einzelseitenanwendungen (Single Page Applications, SPAs) haben Zugriff auf die folgenden Berechtigungsstufen mit niedriger Privilegierung:
    • Azure AD Graph: email, offline_access, openid, , profileUser.Read
    • Microsoft Graph email, offline_access, openid, profile, User.Read, People.Read
  • Vertrauliche Clients haben Zugriff auf die folgenden Berechtigungsstufen mit niedrigen Privilegien, wenn sie von einer „Alle Ressourcen“-Richtlinie ausgeschlossen sind:
    • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All
    • Microsoft Graph: email, , offline_access, openid, profileUser.Read, User.Read.All, User.ReadBasic.AllPeople.ReadPeople.Read.AllGroupMember.Read.AllMember.Read.Hidden

Weitere Informationen zu den genannten Berechtigungen und Bereichen finden Sie in der Microsoft Graph-Berechtigungsreferenz und unter Berechtigungen und Bereiche in der Microsoft Identity Platform.

Schützen von Verzeichnisinformationen

Wenn die empfohlene MFA-Basisrichtlinie ohne App-Ausschlüsse aus geschäftlichen Gründen nicht konfiguriert werden kann und die Sicherheitsrichtlinie Ihrer Organisation verzeichnisbezogene Low-Privilege-Berechtigungen (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden) umfassen muss, erstellen Sie eine separate Richtlinie für den bedingten Zugriff auf Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). Windows Azure Active Directory (auch Azure AD Graph genannt) ist eine Ressource, die daten darstellt, die im Verzeichnis gespeichert sind, z. B. Benutzer, Gruppen und Anwendungen. Die Windows Azure Active Directory-Ressource ist in allen Ressourcen enthalten, kann jedoch mithilfe der folgenden Schritte einzeln in Richtlinien für bedingten Zugriff gezielt werden:

  1. Melden Sie sich beim Microsoft Entra Admin Center als Attributdefinitionsadministrator und Attributzuweisungsadministrator an.
  2. Navigieren Sie zu Entra-ID>benutzerdefinierten Sicherheitsattributen.
  3. Erstellen Sie eine neue Attributsatz- und Attributdefinition. Weitere Informationen finden Sie unter Hinzufügen oder Deaktivieren von benutzerdefinierten Sicherheitsattributedefinitionen in microsoft Entra ID.
  4. Navigieren Sie zu Entra ID>Enterprise-Apps.
  5. Entfernen Sie den Anwendungstypfilter , und suchen Sie nach Anwendungs-ID , die mit 00000002-0000-0000-c000-00000000000 beginnt.
  6. Wählen Sie Windows Azure Active Directory>Benutzerdefinierte Sicherheitsattribute>Zuweisung hinzufügen aus.
  7. Wählen Sie den Attributsatz und den Attributwert aus, den Sie in der Richtlinie verwenden möchten.
  8. Navigieren Sie zu Entra ID-Richtlinien> fürbedingten Zugriff>.
  9. Erstellen oder Ändern einer vorhandenen Richtlinie.
  10. Unter Zielressourcen>Ressourcen (früher Cloud-Apps)>Einschließen, wählen Sie >Ressourcen auswählen>Filter bearbeiten.
  11. Passen Sie den Filter an, um den Attributsatz und die Definition aus früheren Versionen einzuschließen.
  12. Speichern der Richtlinie

Note

Konfigurieren Sie diese Richtlinie wie in den obigen Anleitungen beschrieben. Alle Abweichungen beim Erstellen der Richtlinie wie beschrieben (z. B. das Definieren von App-Ausschlüssen) können dazu führen, dass bereiche mit geringen Rechten ausgeschlossen werden und die Richtlinie nicht wie beabsichtigt angewendet wird.

Alle Internetressourcen mit globalen sicheren Zugriff

Die Option Alle Internetressourcen mit Globalem Sicherem Zugriff ermöglicht Administratoren, das Internet-Zugriffsverkehrsweiterleitungsprofil von Microsoft Entra Internet Access gezielt anzusprechen.

Mit diesen Profilen in globalen sicheren Zugriff können Administratoren definieren und steuern, wie Datenverkehr über Microsoft Entra Internet Access und Microsoft Entra Private Access weitergeleitet wird. Datenverkehrsweiterleitungsprofile können Geräten und Remotenetzwerken zugewiesen werden. Ein Beispiel zum Anwenden einer Richtlinie für bedingten Zugriff auf diese Datenverkehrsprofile finden Sie im Artikel "Anwenden von Richtlinien für bedingten Zugriff" auf das Microsoft 365-Datenverkehrsprofil.

Weitere Informationen zu diesen Profilen finden Sie im Artikel Datenverkehrsweiterleitungsprofile von Global Secure Access.

Benutzeraktionen

Benutzeraktionen sind Aufgaben, die von einem Benutzer ausgeführt werden. Bedingter Zugriff unterstützt zwei Benutzeraktionen:

  • Registrieren von Sicherheitsinformationen: Mit dieser Benutzeraktion können Richtlinien für bedingten Zugriff Regeln erzwingen, wenn Benutzer versuchen, ihre Sicherheitsinformationen zu registrieren. Weitere Informationen finden Sie unter "Kombinierte Registrierung von Sicherheitsinformationen".

Note

Wenn Administratoren eine Richtlinie für Benutzeraktionen zum Registrieren von Sicherheitsinformationen anwenden und das Benutzerkonto ein Gast von einem persönlichen Microsoft-Konto (MSA) ist, erfordert das Steuerelement "Mehrstufige Authentifizierung erforderlich", dass der MSA-Benutzer Sicherheitsinformationen bei der Organisation registriert. Wenn der Gastbenutzer von einem anderen Anbieter wie Google stammt, wird der Zugriff blockiert.

  • Registrieren oder Beitreten von Geräten: Diese Benutzeraktion ermöglicht Administratoren das Erzwingen der Richtlinie für bedingten Zugriff, wenn Benutzer Geräte bei Microsoft Entra-ID registrieren oder beitreten . Administratoren können die Multifaktor-Authentifizierung für die Registrierung oder den Beitritt von Geräten in feinerer Detaillierung konfigurieren als eine mandantenweite Richtlinie. Bei dieser Benutzeraktion sind drei wichtige Punkte zu beachten:
    • Require multifactor authentication und Require auth strength sind die einzigen Zugriffssteuerelemente, die mit dieser Benutzeraktion verfügbar sind, und alle anderen sind deaktiviert. Durch diese Einschränkung werden Konflikte mit Zugriffssteuerungen verhindert, die entweder von der Microsoft Entra-Geräteregistrierung abhängig sind oder nicht für die Microsoft Entra-Geräteregistrierung gelten.
      • Windows Hello for Business und gerätegebundene Kennungen werden nicht unterstützt, da in diesen Szenarien das Gerät bereits registriert werden muss.
    • Client apps, Filters for devicesund Device state Bedingungen sind bei dieser Benutzeraktion nicht verfügbar, da sie von der Microsoft Entra-Geräteregistrierung abhängig sind, um Richtlinien für bedingten Zugriff zu erzwingen.

Warning

Wenn eine Richtlinie für bedingten Zugriff mit der Benutzeraktion "Geräte registrieren" oder "Verbinden " konfiguriert ist, legen Sie entra ID>Devices>Overview>Device Settings - Require Multifactor Authentication to register or join devices with Microsoft Entra to No fest. Anderenfalls werden die Richtlinien für bedingten Zugriff bei dieser Benutzeraktion nicht ordnungsgemäß erzwungen. Weitere Informationen zu dieser Geräteeinstellung finden Sie unter "Geräteeinstellungen konfigurieren".

Authentifizierungskontext

Der Authentifizierungskontext schützt Daten und Aktionen in Anwendungen, einschließlich benutzerdefinierter Anwendungen, Branchenanwendungen, SharePoint und Anwendungen, die durch Microsoft Defender für Cloud-Apps geschützt sind.

Beispielsweise kann eine Organisation Dateien auf SharePoint-Websites speichern, z. B. ein Mittagessen oder ein geheimes GRILL-Saucenrezept. Jeder kann auf die Mittagsmenü-Website zugreifen, aber Benutzer, die auf die geheime GRILL-Sauce Rezeptseite zugreifen, müssen möglicherweise ein verwaltetes Gerät verwenden und bestimmten Nutzungsbedingungen zustimmen.

Der Authentifizierungskontext funktioniert mit Benutzern oder Workload-Identitäten, aber nicht innerhalb derselben Richtlinie für bedingten Zugriff.

Authentifizierungskontexte konfigurieren

Verwalten Sie Authentifizierungskontexte, indem Sie zu Entra ID>Bedingter Zugriff>Authentifizierungskontext wechseln.

Screenshot der Verwaltung von Authentifizierungskontexten.

Wählen Sie "Neuer Authentifizierungskontext " aus, um eine Authentifizierungskontextdefinition zu erstellen. Organisationen können bis zu 99 Authentifizierungskontextdefinitionen (c1-c99) erstellen. Konfigurieren Sie diese Attribute:

  • Der Anzeigename ist der Name, der verwendet wird, um den Authentifizierungskontext in der Microsoft Entra-ID und in allen Anwendungen zu identifizieren, die Authentifizierungskontexte nutzen. Es wird empfohlen, Namen zu verwenden, die über verschiedene Ressourcen hinweg genutzt werden können, wie z. B. vertrauenswürdige Geräte, um die Anzahl der erforderlichen Authentifizierungskontexte zu verringern. Durch einen reduzierten Satz an Namen wird die Anzahl der Umleitungen eingeschränkt, und die Endbenutzererfahrung wird verbessert.
  • Beschreibung enthält weitere Informationen zu den Richtlinien. Diese Informationen werden von Administratoren und von Benutzern verwendet, die Authentifizierungskontexte auf Ressourcen anwenden.
  • Aktivieren Sie das Kontrollkästchen "In Apps veröffentlichen", wenn es ausgewählt ist, gibt den Authentifizierungskontext für Apps bekannt und macht ihn zur Verfügung, um zugewiesen werden zu können. Wenn diese Option nicht ausgewählt ist, steht der Authentifizierungskontext für nachgeschaltete Ressourcen nicht zur Verfügung.
  • ID ist schreibgeschützt und wird in Tokens und Apps für anforderungsspezifische Authentifizierungskontextdefinitionen verwendet. Er ist hier zu Zwecken der Problembehandlung und für Anwendungsfälle in der Entwicklung aufgeführt.

Hinzufügen zur Richtlinie für bedingten Zugriff

Administratoren können veröffentlichte Authentifizierungskontexte innerhalb von Richtlinien für bedingten Zugriff auswählen, indem sie zu Zuordnungen>Cloud-Apps oder -Aktionen gehen und Authentifizierungskontext aus dem Menü Select what this policy applies to auswählen.

Screenshot zum Hinzufügen eines Authentifizierungskontexts für bedingten Zugriff zu einer Richtlinie

Löschen eines Authentifizierungskontexts

Stellen Sie vor dem Löschen eines Authentifizierungskontexts sicher, dass keine Anwendungen sie verwenden. Andernfalls ist der Zugriff auf App-Daten nicht geschützt. Bestätigen Sie dies, indem Sie Anmeldeprotokolle für Fälle überprüfen, in denen Authentifizierungskontext-Richtlinien für bedingten Zugriff angewendet werden.

Um einen Authentifizierungskontext zu löschen, stellen Sie sicher, dass er keine Richtlinien für bedingten Zugriff zugewiesen hat und nicht für Apps veröffentlicht wird. Dadurch wird verhindert, dass ein Authentifizierungskontext versehentlich gelöscht wird.

Ressourcen mit Authentifizierungskontexten markieren

Erfahren Sie mehr über die Verwendung von Authentifizierungskontexten in Anwendungen in diesen Artikeln.