Planen einer Bereitstellung für bedingten Zugriff

  • Artikel

Die Planung Ihrer Bereitstellung für bedingten Zugriff ist wichtig, um sicherzustellen, dass Sie die Zugriffsstrategie Ihrer Organisation für Apps und Ressourcen umsetzen. Richtlinien für bedingten Zugriff bieten hohe Flexibilität bei der Konfiguration. Diese Flexibilität setzt aber auch eine sorgfältige Planung voraus, um unerwünschte Ergebnisse zu vermeiden.

Der bedingte Zugriff von Microsoft Entra kombiniert Signale wie Benutzer, Gerät und Standort, um Entscheidungen zu automatisieren und organisatorische Zugriffsrichtlinien für Ressourcen durchzusetzen. Diese Richtlinien für bedingten Zugriff helfen Ihnen dabei, Sicherheit und Produktivität auszugleichen und bei Bedarf Sicherheitskontrollen zu erzwingen und dem Benutzer vorzuenthalten, wenn diese nicht erforderlich sind.

Bedingter Zugriff ist die Grundlage der Zero Trust-Sicherheitsrichtlinien-Engine von Microsoft.

Diagramm: Allgemeine Übersicht über den bedingten Zugriff.

Microsoft stellt Sicherheitsstandards bereit, die gewährleisten, dass ein grundlegendes Sicherheitsniveau in Mandanten aktiviert ist, die nicht über Microsoft Entra ID P1 oder P2 verfügen. Mit bedingtem Zugriff können Sie Richtlinien erstellen, die den gleichen Schutz bieten wie Sicherheitsstandards – aber mit Granularität. Bedingter Zugriff und Sicherheitsstandards sollten nicht kombiniert werden, da das Erstellen von Richtlinien für bedingten Zugriff Sie daran hindert, Sicherheitsstandards zu aktivieren.

Voraussetzungen

Änderungen kommunizieren

Kommunikation ist entscheidend für den Erfolg jeder neuen Funktion. Sie sollten proaktiv mit Ihren Benutzern darüber kommunizieren, wie sich ihre Erfahrung ändern wird, wann es sich ändert und wie sie Unterstützung erhalten, wenn sie auf Probleme stoßen.

Komponenten der Richtlinie für bedingten Zugriff

Richtlinien für bedingten Zugriff geben Antwort auf folgende Frage: Wer kann unter welchen Bedingungen auf welche Ressourcen zugreifen. Richtlinien können entworfen werden, um Zugriff zu gewähren, Zugriff mit Sitzungssteuerungen zu beschränken oder den Zugriff zu blockieren. Sie erstellen eine Richtlinie für bedingten Zugriff, indem Sie die If-Then-Anweisungen wie folgt definieren:

Bei erfüllter Zuweisung Zugriffssteuerungen anwenden
Sie sind ein Benutzer der Finanzabteilung und greifen auf die Payroll-Anwendung zu Multi-Faktor-Authentifizierung und kompatibles Gerät erforderlich
Sie sind kein Mitglied der Finanzabteilung und greifen auf die Payroll-Anwendung zu Zugriff blockieren
Das Benutzerrisiko ist hoch Multi-Faktor-Authentifizierung und sichere Kennwortänderung erforderlich

Ausschluss von Benutzern

Richtlinien für bedingten Zugriff sind leistungsstarke Tools, daher wird empfohlen, die folgenden Konten von Ihren Richtlinien auszuschließen:

  • Notfallzugriffs- oder Break-Glass-Konten, um eine mandantenweite Kontosperrung zu vermeiden. In dem unwahrscheinlichen Fall, dass alle Administrator*innen aus dem Mandanten ausgeschlossen sind, können Sie sich mit Ihrem Administratorkonto für den Notfallzugriff beim Mandanten anmelden und Maßnahmen ergreifen, um den Zugriff wiederherzustellen.
  • Dienstkonten und Dienstprinzipale, z. B. das Konto für die Microsoft Entra Connect-Synchronisierung. Dienstkonten sind nicht interaktive Konten, die nicht an einen bestimmten Benutzer gebunden sind. Sie werden normalerweise von Back-End-Diensten verwendet, die den programmatischen Zugriff auf Anwendungen ermöglichen, aber auch für die Anmeldung bei Systemen zu Verwaltungszwecken. Derartige Dienstkonten sollten ausgeschlossen werden, weil die MFA nicht programmgesteuert abgeschlossen werden kann. Aufrufe, die von Dienstprinzipalen getätigt werden, werden nicht durch Richtlinien für den bedingten Zugriff blockiert, die für Benutzer gelten. Verwenden Sie den bedingten Zugriff für Workload-Identitäten, um Richtlinien für Dienstprinzipale zu definieren.
    • Wenn Ihre Organisation diese Konten in Skripts oder Code verwendet, sollten Sie in Betracht ziehen, diese durch verwaltete Identitäten zu ersetzen. Als vorübergehende Problemumgehung können Sie diese spezifischen Konten aus der Basisrichtlinie ausschließen.

Die richtigen Fragen stellen

Hier finden Sie einige häufig gestellte Fragen zu Zuweisungen und Zugriffssteuerungen. Dokumentieren Sie die Antworten auf die einzelnen Fragen für jede Richtlinie, bevor Sie sie erstellen.

Benutzer oder Workloadidentitäten

  • Welche Benutzer, Gruppen, Verzeichnisrollen oder Workloadidentitäten sind in die Richtlinie eingeschlossen oder aus der Richtlinie ausgeschlossen?
  • Welche Konten oder Gruppen für den Notfallzugriff sollen aus der Richtlinie ausgeschlossen werden?

Cloud-Apps oder -aktionen

Gilt diese Richtlinie für eine Anwendung, eine Benutzeraktion oder einen Authentifizierungskontext? Wenn ja:

  • Für welche Anwendungen oder Dienste gilt die Richtlinie?
  • Welche Benutzeraktionen unterliegen dieser Richtlinie?
  • Auf welche Authentifizierungskontexte wird diese Richtlinie angewendet?
Filtern nach Anwendungen

Verwenden von Filtern für Anwendungen, um Anwendungen einzuschließen oder auszuschließen, anstatt sie einzeln anzugeben, hilft Organisationen:

  • Einfache Skalierung und Ziel einer beliebigen Anzahl von Anwendungen.
  • Verwalten Sie einfach Anwendungen mit ähnlichen Richtlinienanforderungen.
  • Verringern Sie die Anzahl einzelner Richtlinien.
  • Reduzieren Sie Fehler beim Bearbeiten von Richtlinien: Sie müssen keine Anwendungen manuell aus der Richtlinie hinzufügen/entfernen. Verwalten Sie einfach die Attribute.
  • Überwinden von Richtliniengrößeneinschränkungen.

Bedingungen

  • Welche Geräteplattformen sind in die Richtlinie eingeschlossen oder aus ihr ausgeschlossen?
  • Über welche bekannten Netzwerkstandorte verfügt die Organisation?
    • Welche Standorte sind in die Richtlinie eingeschlossen oder aus ihr ausgeschlossen?
  • Welche Client-App-Typen sind in die Richtlinie eingeschlossen oder aus der Richtlinie ausgeschlossen?
  • Müssen Sie bestimmte Geräteattribute als Ziel festlegen?
  • Sollte bei Verwendung von Identity Protection das Anmelde- oder Benutzerrisiko einbezogen werden?
Benutzer- und Anmelderisiko

Organisationen mit Microsoft Entra ID P2-Lizenzen können das Benutzer- und Anmelderisiko in ihre Richtlinien für bedingten Zugriff einschließen. Diese Ergänzungen können dazu beitragen, die Reibungsverluste von Sicherheitsmaßnahmen zu reduzieren, da eine Multi-Faktor-Authentifizierung oder eine sichere Kennwortänderung nur erforderlich ist, wenn ein Benutzer oder eine Anmeldung mit Risiko behaftet ist.

Weitere Informationen zu Risiken und deren Verwendung in einer Richtlinie finden Sie im Artikel Was bedeutet Risiko?

Blockierungs- oder Gewährungssteuerelemente

Möchten Sie Zugriff auf Ressourcen gewähren, indem Sie mindestens eine der folgenden Maßnahmen für erforderlich erklären?

  • Mehrstufige Authentifizierung
  • Gerät als konform markiert
  • Verwenden eines hybrid in Microsoft Entra eingebundenen Geräts
  • Genehmigte Client-App erforderlich
  • App-Schutzrichtlinie angewendet
  • Kennwortänderung
  • Nutzungsbedingungen akzeptiert

Zugriff blockieren ist ein leistungsstarkes Steuerelement, das nur mit entsprechenden Kenntnissen eingesetzt werden sollte. Richtlinien mit Blockanweisungen können unbeabsichtigte Nebeneffekte haben. Ordnungsgemäße Tests und Überprüfungen sind wichtig, bevor Sie das Steuerelement im großen Stil aktivieren. Administratoren sollten bei Änderungen Tools wie den Modus Nur Bericht und das What if-Tool für den bedingten Zugriff verwenden.

Sitzungssteuerelemente

Möchten Sie eine der folgenden Zugriffssteuerungen für Cloud-Apps erzwingen?

  • Verwenden von App-erzwungenen Einschränkungen
  • Verwenden der App-Steuerung für bedingten Zugriff
  • Anmeldehäufigkeit erzwingen
  • Persistente Browsersitzungen verwenden
  • Fortlaufende Zugriffsevaluierung anpassen

Kombinieren von Richtlinien

Beim Erstellen und Zuweisen von Richtlinien müssen Sie die Funktionsweise von Zugriffstoken berücksichtigen. Zugriffstoken gewähren oder verweigern den Zugriff anhand des Autorisierungs- und Authentifizierungsstatus des Benutzers, der eine Anforderung übermittelt. Wenn der Anforderer nachweisen kann, dass er die vorgegebene Entität ist, kann er auf die geschützten Ressourcen oder Funktionen zugreifen.

Zugriffstoken werden standardmäßig ausgestellt, wenn eine Bedingung der Richtlinie für bedingten Zugriff keine Zugriffssteuerung auslöst.

Diese Richtlinie verhindert nicht, dass die App den Zugriff selbst blockieren kann.

Nehmen Sie beispielsweise eine vereinfachte Richtlinie mit folgenden Bedingungen:

Benutzer: FINANCE GROUP
Zugriff auf: PAYROLL-APP
Zugriffssteuerung: Multi-Faktor-Authentifizierung

  • Benutzer A gehört zur FINANCE GROUP. Er muss die Multi-Faktor-Authentifizierung ausführen, um auf die PAYROLL-APP zuzugreifen.
  • Benutzer B gehört nicht zur FINANCE GROUP, erhält ein Zugriffstoken und darf ohne Multi-Faktor-Authentifizierung auf die PAYROLL-APP zugreifen.

Um sicherzustellen, dass Benutzer außerhalb der FINANCE GROUP nicht auf die Payroll-App zugreifen können, sollte zum Blockieren aller anderen Benutzer eine separate Richtlinie ähnlich der folgenden vereinfachten Richtlinie erstellt werden:

Benutzer: Alle Benutzer einschließen/FINANCE GROUP ausschließen
Zugriff auf: PAYROLL-APP
Zugriffssteuerung: Zugriff blockieren

Wenn Benutzer B nun versucht, auf die PAYROLL-APP zuzugreifen, wird er blockiert.

Empfehlungen

Unter Berücksichtigung der Erkenntnisse bei Verwendung des bedingten Zugriffs und der Unterstützung anderer Kunden finden Sie hier einige erfahrungsbasierte Empfehlungen.

Anwenden von Richtlinien für bedingten Zugriff auf alle Apps

Stellen Sie sicher, dass auf jede App mindestens eine Richtlinie für bedingten Zugriff angewendet wird. Aus Sicherheitsgründen ist es besser, eine Richtlinie zu erstellen, die alle Cloud-Apps umfasst, und dann Anwendungen auszuschließen, für die die Richtlinie nicht gelten soll. Durch diese Praxis wird sichergestellt, dass Sie Richtlinien für bedingten Zugriff nicht jedes Mal aktualisieren müssen, wenn Sie eine neue Anwendung integrieren.

Tipp

Gehen Sie bei der Verwendung von Blockieren und allen Apps in einer einzigen Richtlinie sehr vorsichtig vor. Dadurch können Administratoren ausgesperrt werden, und Ausschlüsse können nicht für wichtige Endpunkte wie Microsoft Graph konfiguriert werden.

Minimieren der Anzahl von Richtlinien für bedingten Zugriff

Das Erstellen einer Richtlinie für jede App ist nicht effizient und führt zu einer schwierigen Verwaltung. Der bedingte Zugriff hat ein Limit von 195 Richtlinien pro Mandant. Dieser Richtliniengrenzwert von 195 umfasst Richtlinien für bedingten Zugriff in jedem Zustand, einschließlich der Modus „Nur melden“, „ein“ oder „aus“.

Unsere Empfehlung: Analysieren Sie Ihre Apps, und gruppieren Sie sie zu Anwendungen mit den gleichen Ressourcenanforderungen für die gleichen Benutzer. Wenn beispielsweise alle Microsoft 365-Apps oder alle HR-Apps die gleichen Anforderungen für die gleichen Benutzer haben, erstellen Sie eine einzelne Richtlinie, und schließen Sie alle Apps ein, für die sie gilt.

Richtlinien für bedingten Zugriff sind in einer JSON-Datei enthalten, und diese Datei ist an eine Größenbeschränkung gebunden. Es wird nicht erwartet, dass sich eine einzelne Richtlinie darüber hinaus entwickelt. Wenn Sie eine lange Liste von GUIDs in Ihrer Richtlinie verwenden, könnten Sie diesen Grenzwert erreichen. Wenn Sie auf diese Grenzwerte stoßen, empfehlen wir Alternativen wie:

Konfigurieren des Modus „Nur Bericht“

Standardmäßig wird jede auf Basis einer Vorlage erstellte Richtlinie im reinen Berichtsmodus erstellt. Wir haben Organisationen empfohlen, die Nutzung zu testen und zu überwachen, um vor dem Aktivieren der einzelnen Richtlinien das beabsichtigte Ergebnis sicherzustellen.

Aktivieren von Richtlinien im reinen Berichtsmodus. Wenn Sie die Richtlinie im reinen Berichtsmodus gespeichert haben, können Sie die Wirkung auf Echtzeitanmeldungen in den Anmeldeprotokollen anzeigen. Wählen Sie in den Anmeldeprotokollen ein Ereignis aus, und navigieren Sie zu der Registerkarte Nur Bericht, um das Ergebnis aller Richtlinien im reinen Berichtsmodus anzuzeigen.

Sie können die aggregierten Auswirkungen Ihrer Richtlinien für bedingten Zugriff in der Arbeitsmappe „Erkenntnisse und Berichterstellung“ anzeigen. Für den Zugriff auf die Arbeitsmappe benötigen Sie ein Azure Monitor-Abonnement. Außerdem müssen Sie Ihre Anmeldeprotokolle in einen Log Analytics-Arbeitsbereich streamen.

Planen von Unterbrechungen

Um das Risiko einer Sperrung bei unvorhergesehenen Unterbrechungen zu verringern, sollten Sie Resilienzstrategien für Ihre Organisation planen.

Festlegen von Benennungsstandards für Ihre Richtlinien

Ein Benennungsstandard erleichtert die Suche nach Richtlinien und gibt Aufschluss über ihren Zweck, ohne sie im Azure-Verwaltungsportal öffnen zu müssen. Es wird empfohlen, beim Benennen von Richtlinien die folgendem Angaben u berücksichtigen:

  • Eine laufende Nummer
  • Die Cloud-Apps, für die sie gilt
  • Die Antwort
  • Für wen sie gilt
  • Wann sie gilt

Diagramm: Beispielbenennungsstandards für Richtlinien.

Beispiel: Eine Richtlinie, die eine Multi-Faktor-Authentifizierung (MFA) für Marketingbenutzer erfordert, die von externen Netzwerken auf die Dynamics CRP-App zugreifen, könnte wie folgt lauten:

Diagramm: Ein Benennungsstandard.

Ein beschreibender Name hilft Ihnen dabei, einen Überblick über die Implementierung von bedingtem Zugriff zu behalten. Die Sequenznummer ist hilfreich, wenn Sie auf eine Richtlinie in einer Konversation verweisen müssen. Wenn Sie beispielsweise mit einem anderen Administrator telefonieren, können Sie ihn auffordern, die Richtlinie CA01 zu öffnen, um ein Problem zu lösen.

Benennungsstandards für Notfallzugriffssteuerungen

Neben Ihren aktiven Richtlinien sollten Sie auch deaktivierte Richtlinien implementieren, die als sekundäre resiliente Zugriffssteuerungen für Ausfall-/Notfallszenarien fungieren. Ihr Benennungsstandard für die Notfallplan-Richtlinien sollte Folgendes enthalten:

  • IM NOTFALL AKTIVIEREN am Anfang, damit sich der Name von denen anderer Richtlinien unterscheidet.
  • Der Name der Störungen, auf die sie angewandt werden soll.
  • Mithilfe einer Sequenznummer für die Sortierung wissen Administratoren sofort, in welcher Reihenfolge die Richtlinien aktiviert werden sollen.

Beispiel: Der folgende Name gibt an, dass diese Richtlinie die erste von vier Richtlinien ist, die bei einer MFA-Unterbrechung aktiviert werden soll:

  • EM01 – IM NOTFALL AKTIVIEREN: MFA-Unterbrechung [1/4] – Exchange SharePoint – Microsoft Entra-Hybrideinbindung erforderlich für VIP-Benutzer*innen

Blockieren von Ländern/Regionen, aus denen nie eine Anmeldung erwartet wird

Mit Microsoft Entra ID können Sie benannte Speicherorte erstellen. Erstellen Sie die Liste der zulässigen Länder/Regionen und anschließend eine Netzwerkblockierungsrichtlinie, mit der Sie diese „zulässigen Länder/Regionen“ ausschließen. Diese Option bedeutet weniger Aufwand für Kunden, die an kleineren geografischen Standorten ansässig sind. Stellen Sie sicher, dass Sie Ihre Konten für den Notfallzugriff von dieser Richtlinie ausnehmen.

Bereitstellen von Richtlinien für bedingten Zugriff

Stellen Sie nach der Fertigstellung Ihre Richtlinien für den bedingten Zugriff in Phasen bereit.

Erstellen von Richtlinien für bedingten Zugriff

Informationen zum Einstieg finden Sie unter Vorlagen für Richtlinien für bedingten Zugriff und Allgemeine Sicherheitsrichtlinien für Microsoft 365-Organisationen. Diese Vorlagen sind eine bequeme Möglichkeit, Microsoft-Empfehlungen umzusetzen. Achten Sie darauf, dass Sie Ihre Konten für den Notfallzugriff ausschließen.

Auswerten der Auswirkungen der Richtlinie

Es wird empfohlen, die folgenden Tools zu verwenden, um die Auswirkungen Ihrer Richtlinien sowohl vor als auch nach dem Vornehmen von Änderungen zu bewerten. Eine simulierte Ausführung gibt Ihnen eine gute Vorstellung davon, welche Auswirkungen eine Richtlinie für bedingten Zugriff hat. Sie ersetzt jedoch keinen realen Testlauf in einer ordnungsgemäß konfigurierten Entwicklungsumgebung.

Testen Ihrer Richtlinien

Testen Sie unbedingt die Ausschlusskriterien einer Richtlinie. Sie können beispielsweise einen Benutzer oder eine Gruppe aus einer Richtlinie ausschließen, die eine mehrstufige Authentifizierung (MFA) erfordert. Testen Sie, ob ausgeschlossene Benutzer zur Verwendung der MFA aufgefordert werden, weil die Kombination anderer Richtlinien möglicherweise die Verwendung der MFA für diese Benutzer vorschreibt.

Führen Sie jeden Test im Testplan mit Testbenutzern aus. Der Testplan ist wichtig, um die erwarteten Ergebnisse mit den tatsächlichen Ergebnissen vergleichen zu können. Die folgende Tabelle enthält einige Beispiele für Testfälle. Passen Sie die Szenarien und die erwarteten Ergebnisse auf der Grundlage der Konfiguration Ihrer Richtlinien für bedingten Zugriff an.

Richtlinie Szenario Erwartetes Ergebnis
Riskante Anmeldungen Ein Benutzer meldet sich bei der App über einen nicht genehmigten Browser an. Berechnet eine Risikobewertung basierend auf der Wahrscheinlichkeit, dass die Anmeldung nicht vom Benutzer durchgeführt wurde. Der Benutzer muss das Problem selbstständig mittels MFA beheben.
Geräteverwaltung Ein autorisierter Benutzer versucht, sich über ein autorisiertes Gerät anzumelden. Der Zugriff wird gewährt.
Geräteverwaltung Ein autorisierter Benutzer versucht, sich über ein nicht autorisiertes Gerät anzumelden. Der Zugriff wird blockiert.
Kennwortänderung für riskante Benutzer Ein autorisierter Benutzer versucht, sich mit kompromittierten Anmeldeinformationen anzumelden (Anmeldung mit hohem Risiko). Der Benutzer wird aufgefordert, das Kennwort zu ändern, oder der Zugriff wird blockiert (auf der Grundlage Ihrer Richtlinie).

Bereitstellen in der Produktion

Nachdem Sie die Auswirkungen anhand des reinen Berichtsmodus überprüft haben, kann ein Administrator den Umschalter Richtlinie aktivieren von Nur Berichtauf Ein einstellen.

Rollback von Richtlinien

Sollte für Ihre neu implementierten Richtlinien ein Rollback erforderlich sein, verwenden Sie mindestens eine der folgenden Optionen:

  • Deaktivieren der Richtlinie Durch das Deaktivieren einer Richtlinie wird sichergestellt, dass sie nicht angewendet wird, wenn ein Benutzer versucht, sich anzumelden. Die Richtlinie kann bei Bedarf jederzeit erneut aktiviert werden.

  • Ausschließen eines Benutzers oder einer Gruppe aus einer Richtlinie. Falls ein Benutzer nicht auf die App zugreifen kann, können Sie ihn aus der Richtlinie ausschließen.

    Achtung

    Ausnahmen sollten sparsam verwendet werden und nur in Situationen zum Einsatz kommen, in denen Sie dem Benutzer vertrauen. Der Benutzer sollte baldmöglichst wieder der Richtlinie oder Gruppe hinzugefügt werden.

  • Wenn eine Richtlinie deaktiviert ist oder nicht mehr benötigt wird, sollten Sie sie löschen.

Behandeln von Problemen mit Richtlinien für bedingten Zugriff

Wenn ein Benutzer ein Problem mit einer Richtlinie für bedingten Zugriff hat, sammeln Sie die folgenden Informationen, um die Problembehandlung zu vereinfachen.

  • Benutzerprinzipalname
  • Anzeigename des Benutzers
  • Betriebssystemname
  • Zeitstempel (ungefähre Angabe ist OK)
  • Zielanwendung
  • Clientanwendungstyp (Browser oder Client)
  • Korrelations-ID (diese ID ist für die Anmeldung eindeutig)

Wenn der Benutzer eine Nachricht mit einem Link zu weiteren Details erhalten hat, kann er die meisten dieser Informationen für Sie erfassen.

Screenshots: Beispielfehlermeldung und weitere Details.

Sobald Sie die Informationen sammeln, sehen Sie sich die folgenden Ressourcen an:

  • Anmeldeprobleme bei bedingtem Zugriff: Anhand von Fehlermeldungen und dem Microsoft Entra-Anmeldeprotokoll können Sie Probleme bei unerwarteten Anmeldeergebnissen im Zusammenhang mit bedingtem Zugriff beheben.
  • Verwenden des Was-wäre-wenn-Tools: Verstehen Sie, warum eine Richtlinie in einem bestimmten Szenario auf einen Benutzer angewendet oder nicht angewendet wurde oder ob eine Richtlinie in einem bekannten Zustand angewendet würde.

Zugehöriger Inhalt