Fortlaufende Zugriffsevaluierung
Tokenablauf und -aktualisierung sind standardmäßige Mechanismen der Branche. Wenn eine Clientanwendung wie Outlook eine Verbindung mit einem Dienst wie Exchange Online herstellt, werden die API-Anforderungen mithilfe von OAuth 2.0-Zugriffstoken autorisiert. Zugriffstoken sind standardmäßig eine Stunde lang gültig. Nach Ablauf dieser Zeit wird der Client zu Microsoft Entra umgeleitet, um sie zu aktualisieren. Die Aktualisierung bietet eine Möglichkeit, Richtlinien für den Benutzerzugriff neu auszuwerten. Es kann Fälle geben, in denen das Token nicht aktualisiert werden soll – zum Beispiel aufgrund einer Richtlinie für bedingten Zugriff oder weil der Benutzer im Verzeichnis deaktiviert ist.
Kunden haben Bedenken hinsichtlich der Verzögerung zwischen der Änderung der Bedingungen für einen Benutzer und der Erzwingung von Richtlinienänderungen. Microsoft hat mit dem als „Blunt Object“ (stumpfer Gegenstand) bezeichneten Ansatz mit reduzierten Tokenlebensdauern experimentiert, dabei aber festgestellt, dass die Benutzerfreundlichkeit und Zuverlässigkeit beeinträchtigt wurden, ohne die Risiken auszuschließen.
Eine zeitnahe Reaktion auf Richtlinienverletzungen oder Sicherheitsprobleme erfordert eine „Konversation“ zwischen dem Token-Aussteller (Microsoft Entra) und der vertrauenden Seite (aufgeklärte Anwendung). Dieser bidirektionale Austausch bietet zwei wichtige Funktionen. Die vertrauende Partei kann sehen, wenn sich Eigenschaften ändern, wie z.B. der Standort im Netz, und dies dem Token-Aussteller mitteilen. Außerdem kann der Tokenaussteller der vertrauenden Seite veranlassen aufzuhören, die Token für einen bestimmten Benutzer zu respektieren, weil das Konto kompromittiert oder deaktiviert wurde oder andere Bedenken bestehen. Der Mechanismus für diese Konversation ist fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE), ein Branchenstandard, der auf dem Open ID Continuous Access Evaluation Profile (CAEP) basiert. Das Ziel für die Bewertung kritischer Ereignisse ist es, nahezu in Echtzeit zu reagieren, aber durch die Dauer der Ereignisweitergabe ist eine Wartezeit von bis zu 15 Minuten zu beobachten. Die Erzwingung von Richtlinien für IP-Standorte erfolgt jedoch sofort.
Die anfängliche Implementierung der fortlaufenden Zugriffsevaluierung konzentriert sich auf Exchange, Teams und SharePoint Online.
Informationen zum Vorbereiten Ihrer Anwendungen auf die Verwendung der fortlaufenden Zugriffsevaluierung finden Sie unter Verwenden von APIs mit aktivierter fortlaufender Zugriffsevaluierung in Ihren Anwendungen.
Hauptvorteile
- Benutzerkündigung oder Kennwortänderung oder -zurücksetzung: Die Sperrung der Benutzersitzung wird nahezu in Echtzeit erzwungen.
- Änderung der Netzwerkadresse: Standortrichtlinien für den bedingten Zugriff werden nahezu in Echtzeit erzwungen.
- Der Export von Token auf einen Computer außerhalb eines vertrauenswürdigen Netzwerks kann mit Standortrichtlinien für den bedingten Zugriff verhindert werden.
Szenarien
Zwei Szenarien ermöglichen die fortlaufende Zugriffsevaluierung: die Auswertung kritischer Ereignisse und die Auswertung von Richtlinien für bedingten Zugriff.
Auswertung kritischer Ereignisse
Eine fortlaufende Zugriffsbewertung wird implementiert, indem Dienste wie Exchange Online, SharePoint Online und Teams in die Lage versetzt werden, kritische Microsoft Entra-Ereignisse zu abonnieren. Diese Ereignisse können dann ausgewertet und nahezu in Echtzeit durchgesetzt werden. Die Auswertung kritischer Ereignisse basiert nicht auf Richtlinien für bedingten Zugriff und ist daher in jedem Mandanten verfügbar. Derzeit werden folgende Ereignisse ausgewertet:
- Benutzerkonto wird gelöscht oder deaktiviert
- Kennwort für einen Benutzer wird geändert oder zurückgesetzt
- Multi-Faktor-Authentifizierung ist für den Benutzer aktiviert
- Administrator sperrt explizit alle Aktualisierungstoken für einen Benutzer.
- Hohes Benutzerrisiko von Microsoft Entra ID Protection erkannt
Durch diesen Prozess wird ein Szenario ermöglicht, bei dem Benutzer innerhalb von wenigen Minuten nach einem dieser kritischen Ereignisse den Zugriff auf SharePoint Online-Dateien, E-Mails, Kalender, Aufgaben und Teams über Microsoft 365-Client-Apps verlieren.
Hinweis
SharePoint Online unterstützt keine Benutzerrisikoereignisse.
Auswertung von Richtlinien für bedingten Zugriff
Exchange Online, SharePoint Online, Teams und MS Graph können wichtige Richtlinien für den bedingten Zugriff zur Bewertung innerhalb des Dienstes selbst synchronisieren.
Dies ermöglicht ein Szenario, bei dem Benutzer unmittelbar nach Änderungen der Netzwerkadresse den Zugriff auf Dateien, E-Mails, Kalender oder Aufgaben aus Microsoft 365-Client-Apps oder SharePoint Online verlieren.
Hinweis
Nicht alle Kombinationen aus Client-App und Ressourcenanbieter werden unterstützt. Weitere Informationen finden Sie in den folgenden Tabellen. Die erste Spalte dieser Tabelle bezieht sich auf Webanwendungen, die über einen Webbrowser gestartet werden (also PowerPoint im Webbrowser gestartet). Die restlichen vier Spalten beziehen sich auf native Anwendungen, die auf der jeweils beschriebenen Plattform ausgeführt werden. Verweise auf „Office“ umfassen Word, Excel und PowerPoint.
| Outlook Web | Outlook Win32 | Outlook iOS | Outlook Android | Outlook Mac | |
|---|---|---|---|---|---|
| SharePoint Online | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Exchange Online | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Office-Web-Apps | Office Win32-Apps | Office für iOS | Office für Android | Office für Mac | |
|---|---|---|---|---|---|
| SharePoint Online | Nicht unterstützt* | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Exchange Online | Nicht unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| OneDrive Web | OneDrive Win32 | OneDrive iOS | OneDrive Android | OneDrive Mac | |
|---|---|---|---|---|---|
| SharePoint Online | Unterstützt | Nicht unterstützt | Unterstützt | Unterstützt | Nicht unterstützt |
| Teams (Webversion) | Teams (Win32) | Teams iOS | Teams Android | Teams Mac | |
|---|---|---|---|---|---|
| Teams-Dienst | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt |
| SharePoint Online | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt |
| Exchange Online | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt | Teilweise unterstützt |
* Die Tokengültigkeitsdauer für Office-Web-Apps verkürzt sich auf eine Stunde, wenn eine Richtlinie für bedingten Zugriff festgelegt wird.
Hinweis
Teams besteht aus mehreren Diensten. Unter diesen Diensten entsprechen die Anruf- und Chatdienste nicht den Richtlinien für IP-basierten bedingten Zugriff.
Die fortlaufende Zugriffsauswertung ist auch in Azure Government-Mandanten (GCC High und DOD) für Exchange Online verfügbar.
Clientfunktionen
Clientseitige Anspruchsaufforderung
Vor der fortlaufenden Zugriffsevaluierung verwendeten die Clients das Zugriffstoken aus ihrem Cache wieder, solange es noch nicht abgelaufen war. Mit CAE führen wir einen neuen Fall ein, in dem ein Ressourcenanbieter ein Token zurückweisen kann, wenn es noch nicht abgelaufen ist. Um Clients darüber zu informieren, dass sie ihren Cache umgehen sollen, obwohl die zwischengespeicherten Token noch nicht abgelaufen sind, führen wir einen Mechanismus namens Anspruchsaufforderung ein, der angibt, dass das Token abgelehnt wurde und ein neues Zugriffstoken von Microsoft Entra ausgestellt werden muss. Für die fortlaufende Zugriffsevaluierung ist ein Client-Update erforderlich, damit der Client die Anspruchsaufforderung verstehen kann. Die neuesten Versionen der folgenden Anwendungen unterstützen die Anspruchsaufforderung:
| Web | Win32 | iOS | Android | Mac | |
|---|---|---|---|---|---|
| Outlook | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Teams | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Office | Nicht unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| OneDrive | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
Lebensdauer von Token
Weil Risiko und Richtlinie in Echtzeit bewertet werden, sind Clients, die Sitzungen mit kontinuierlicher Zugriffsevaluierung aushandeln, nicht mehr auf statische Richtlinien zur Token-Lebensdauer angewiesen. Diese Änderung bedeutet, dass die konfigurierbare Richtlinie für die Gültigkeitsdauer von Token für Clients, die CAE-Sitzungen aushandeln, nicht beachtet wird.
Die Gültigkeitsdauer von Token wird in CAE-Sitzungen auf bis zu 28 Stunden erhöht. Sperrungen werden durch kritische Ereignisse und Richtlinienauswertung gesteuert, nicht einfach durch einen willkürlichen Zeitraum. Diese Änderung erhöht die Stabilität von Anwendungen, ohne den Sicherheitsstatus zu beeinträchtigen.
Wenn Sie keine CAE-fähigen Clients verwenden, bleibt die standardmäßige Gültigkeitsdauer des Zugriffstokens bei einer Stunde. Die standardmäßige Gültigkeitsdauer ändert sich nur, wenn Sie die Gültigkeitsdauer Ihrer Zugriffstoken mit der Previewfunktion Konfigurierbare Tokengültigkeitsdauer (CTL) konfiguriert haben.
Beispiele von Flowdiagrammen
Ablauf bei Benutzersperrereignis
- Ein Client mit CAE-Unterstützung stellt Anmeldeinformationen oder ein Aktualisierungstoken für Microsoft Entra bereit und fordert ein Zugriffstoken für eine Ressource an.
- Ein Zugriffstoken wird zusammen mit anderen Artefakten an den Client zurückgegeben.
- Wenn Administratoren explizit alle Aktualisierungstoken für Benutzer widerrufen, wird ein Widerrufsereignis von Microsoft Entra an den Ressourcenanbieter gesendet.
- Dem Ressourcenanbieter wird ein Zugriffstoken präsentiert. Der Ressourcenanbieter wertet die Gültigkeit des Tokens aus und überprüft, ob für den Benutzer ein Sperrungsereignis vorliegt. Der Ressourcenanbieter verwendet diese Informationen, um den Zugriff auf die Ressource zu gewähren oder zu untersagen.
- In diesem Fall verweigert der Ressourcenanbieter den Zugriff und sendet die Anspruchsaufforderung „401+“ an den Client zurück.
- Der CAE-fähige Client versteht die Anspruchsaufforderung „401+“. Er umgeht die Caches, geht zurück zu Schritt 1 und sendet das Aktualisierungstoken zusammen mit der Anspruchsaufforderung zurück an Microsoft Entra. Microsoft Entra wertet dann alle Bedingungen erneut aus und fordert in diesem Fall die Benutzer auf, sich erneut zu authentifizieren.
Ablauf der Benutzerkonditionsänderung
Im folgenden Beispiel hat ein Administrator für den bedingten Zugriff eine standortbasierte Richtlinie für bedingten Zugriff so konfiguriert, dass der Zugriff nur über bestimmte IP-Adressbereiche zulässig ist:
- Ein Client mit CAE-Unterstützung stellt Anmeldeinformationen oder ein Aktualisierungstoken für Microsoft Entra bereit und fordert ein Zugriffstoken für eine Ressource an.
- Microsoft Entra wertet alle Richtlinien für bedingten Zugriff aus, um zu überprüfen, ob der Benutzer und der Client die Bedingungen erfüllen.
- Ein Zugriffstoken wird zusammen mit anderen Artefakten an den Client zurückgegeben.
- Der Benutzer navigiert zu einer IP-Adresse außerhalb eines zulässigen IP-Adressbereichs.
- Der Client stellt ein Zugriffstoken für den Ressourcenanbieter außerhalb eines zulässigen IP-Adressbereichs bereit.
- Der Ressourcenanbieter wertet die Gültigkeit des Tokens aus und überprüft die über Microsoft Entra synchronisierte Standortrichtlinie.
- In diesem Fall verweigert der Ressourcenanbieter den Zugriff und sendet die Anspruchsaufforderung „401+“ an den Client zurück. Der Client wird herausgefordert, da er nicht aus einem zulässigen IP-Adressbereich stammt.
- Der CAE-fähige Client versteht die Anspruchsaufforderung „401+“. Er umgeht die Caches, geht zurück zu Schritt 1 und sendet das Aktualisierungstoken zusammen mit der Anspruchsaufforderung zurück an Microsoft Entra. Microsoft Entra wertet alle Bedingungen erneut aus und verweigert in diesem Fall den Zugriff.
Ausnahme für IP-Adressvariationen und Deaktivieren der Ausnahme
Wenn Microsoft Entra die Bedingungen im oben beschriebenen Schritt 8 erneut auswertet, wird der Zugriff verweigert, da sich der von Microsoft Entra erkannte neue Standort außerhalb des zulässigen IP-Bereichs befindet. Dies ist nicht immer der Fall. Aufgrund einiger komplexer Netzwerktopologien kann die Authentifizierungsanforderung von einer zulässigen ausgehenden IP-Adresse eintreffen, nachdem die vom Ressourcenanbieter empfangene Zugriffsanforderung von einer nicht zulässigen IP-Adresse eingegangen ist. Unter diesen Bedingungen interpretiert Microsoft Entra die Situation so, dass sich der Client weiterhin an einem zulässigen Standort befindet und ihm Zugriff gewährt werden soll. Daher stellt Microsoft Entra ein Token mit einer Gültigkeit von einer Stunde aus, das die IP-Adressüberprüfungen für der Ressource bis zum Ablauf des Tokens aussetzt. Microsoft Entra erzwingt weiterhin IP-Adressüberprüfungen.
Wenn Sie Datenverkehr über globalen sicheren Zugriff an Microsoft 365-fremde Ressourcen senden, kennen Ressourcenanbieter die Quell-IP-Adresse des Benutzers nicht, da die Wiederherstellung der Quell-IP-Adresse derzeit für diese Ressourcen nicht unterstützt wird. In diesem Fall gilt: Wenn sich der Benutzer an dem vertrauenswürdigen IP-Speicherort befindet (wie von Microsoft Entra festgestellt), stellt Microsoft Entra ein Token mit einer Gültigkeit von einer Stunde aus, das die IP-Adressüberprüfungen für die Ressource bis zum Ablauf des Tokens aussetzt. Die IP-Adressprüfungen für diese Ressourcen werden von Microsoft Entra weiterhin korrekt erzwungen.
Standardmodus im Vergleich zum strikten Modus: Die Gewährung des Zugriffs unter dieser Ausnahme (d. h. ein von Microsoft Entra ID als zulässig erkannter Standort und ein vom Ressourcenanbieter als nicht zulässig erkannter Standort) schützt die Benutzerproduktivität, indem weiterhin Zugriff auf kritische Ressourcen gewährt wird. Dies ist die standardmäßige Standorterzwingung. Auf der anderen Seite können Administrator*innen, die in stabilen Netzwerktopologien arbeiten und diese Ausnahme entfernen möchten, die strikte Standorterzwingung (öffentliche Vorschau) verwenden.
Aktivieren oder Deaktivieren der CAE
Die CAE-Einstellung wurde in bedingten Zugriff verschoben. Neue CAE-Kunden können beim Erstellen von Richtlinien für bedingten Zugriff direkt auf CAE zugreifen und diese umschalten. Einige Bestandskunden müssen jedoch die Migration durchlaufen, bevor sie über bedingten Zugriff auf CAE zugreifen können.
Migration
Kunden, die CAE-Einstellungen unter „Sicherheit“ konfiguriert haben, müssen die Einstellungen zu einer neuen Richtlinie für bedingten Zugriff migrieren.
In der folgenden Tabelle wird die Migrationserfahrung jeder Kundengruppe basierend auf zuvor konfigurierten CAE-Einstellungen beschrieben.
| Vorhandene CAE-Einstellung | Ist die Migration erforderlich? | Automatisch aktiviert für CAE | Erwarteter Migrationsvorgang |
|---|---|---|---|
| Neue Mandanten, für die in der alten Erfahrung nichts konfiguriert wurde. | Nein | Ja | Die alte CAE-Einstellung ist abgeblendet, da diese Kunden sie vor der allgemeinen Verfügbarkeit wahrscheinlich nicht kannten. |
| Mandanten, die ausdrücklich für alle Benutzer mit der alten Erfahrung aktiviert wurden. | Nein | Ja | Die alte CAE-Einstellung ist abgeblendet. Da diese Kunden diese Einstellung ausdrücklich für alle Benutzer*innen aktiviert haben, müssen sie nicht migrieren. |
| Mandanten, die einige Benutzer in ihren Mandanten ausdrücklich mit der alten Erfahrung aktiviert haben. | Ja | Nein | Die alte CAE-Einstellung ist abgeblendet. Wenn Sie auf Migrieren klicken, wird der neue Assistent für Richtlinien für bedingten Zugriff gestartet, der Alle Benutzer einschließt, während aus der CAE kopierte Benutzer und Gruppen ausgenommen sind. Außerdem wird die neue Sitzungssteuerung Anpassen der fortlaufenden Zugriffsevaluierung auf Deaktiviert festgelegt. |
| Mandanten, die die Vorschau ausdrücklich deaktiviert haben. | Ja | Nein | Die alte CAE-Einstellungen ist abgeblendet. Wenn Sie auf Migrieren klicken, wird der neue Assistent für Richtlinien für bedingten Zugriff gestartet, der Alle Benutzer enthält. Außerdem wird die neue Sitzungssteuerung Fortlaufende Zugriffsevaluierung anpassen auf Deaktiviert festgelegt. |
Weitere Informationen zur fortlaufenden Zugriffsauswertung als Sitzungssteuerung finden Sie im Abschnitt Anpassen der fortlaufenden Zugriffsauswertung.
Einschränkungen
Zeitraum bis zur Wirksamkeit einer Aktualisierung von Gruppenmitgliedschaft und Richtlinien
Es kann bis zu einem Tag dauern, bis von Administratoren vorgenommene Änderungen an Richtlinien für bedingten Zugriff und Gruppenmitgliedschaften wirksam werden. Die Verzögerung ist auf die Replikation zwischen Microsoft Entra und Ressourcenanbietern wie Exchange Online und SharePoint Online zurückzuführen. Es wurden einige Optimierungen für Richtlinienaktualisierungen vorgenommen, die die Verzögerung auf zwei Stunden reduzieren. Allerdings sind damit noch nicht alle Szenarien abgedeckt.
Wenn Änderungen an der Richtlinie für bedingten Zugriff oder der Gruppenmitgliedschaft sofort auf bestimmte Benutzer angewendet werden müssen, haben Sie zwei Möglichkeiten.
- Führen Sie den PowerShell-Befehl „revoke-mgusersign“ aus, um alle Aktualisierungs-Tokens eines bestimmten Benutzers zu widerrufen.
- Wählen Sie auf der Benutzerprofilseite die Option „Sitzung widerrufen“ aus, um die Benutzersitzung zu widerrufen, damit die aktualisierten Richtlinien sofort angewendet werden.
IP-Adressvariationen und Netzwerke mit freigegebenen oder unbekannten ausgehenden IP-Adressen
Moderne Netzwerke optimieren die Konnektivität und Netzwerkpfade für Anwendungen oft unterschiedlich. Diese Optimierung führt häufig zu Variationen der Routing- und Quell-IP-Adressen von Verbindungen, wie sie Ihrem Identitätsanbieter und den Ressourcenanbietern angezeigt werden. Diese Variationen in Form von geteilten Pfaden oder bei IP-Adressen sind in verschiedenen Netzwerktopologien zu beobachten. Dazu gehören u. a. die folgenden:
- Lokale und cloudbasierte Proxys.
- Implementierungen von virtuellen privaten Netzwerken (VPNs), z. B. geteiltes Tunneln.
- Bereitstellungen von softwaredefinierten WANs (Wide Area Networks).
- Netzwerktopologien mit Lastenausgleich oder redundantem Netzwerkausgang, z. B. mit SNAT.
- Bereitstellungen in Filialen, die eine direkte Internetverbindung für bestimmte Anwendungen ermöglichen.
- Netzwerke, die IPv6-Clients unterstützen.
- Andere Topologien, die den Anwendungs- oder Ressourcendatenverkehr anders als den Datenverkehr zum Identitätsanbieter verarbeiten.
Neben IP-Variationen können Kunden auch Netzwerklösungen und Dienste einsetzen, für die Folgendes gilt:
- Sie verwenden IP-Adressen, die gemeinsam mit anderen Kunden genutzt werden können. Beispielsweise cloudbasierte Proxydienste, bei denen ausgehende IP-Adressen zwischen Kunden freigegeben werden.
- Sie verwenden leicht variierende oder undefinierbare IP-Adressen. Beispielsweise Topologien, in denen große, dynamische Gruppen von ausgehenden IP-Adressen verwendet werden, wie Szenarien in großen Unternehmen oder geteilter VPN-Datenverkehr und lokaler ausgehender Netzwerkdatenverkehr.
Netzwerke, in denen sich ausgehende IP-Adressen ggf. häufig ändern oder gemeinsam genutzt werden, können sich auf den bedingten Zugriff in Microsoft Entra und die fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE) auswirken. Diese Variabilität kann die Funktionsweise dieser Features und die empfohlenen Konfigurationen beeinflussen. Geteiltes Tunneln kann auch zu unerwarteten Blockierungen führen, wenn eine Umgebung mit bewährten Methoden für VPN mit geteilten Tunneln konfiguriert wird. Das Routing optimierter IP-Adressen über eine vertrauenswürdige IP-Adresse/ein vertrauenswürdiges VPN kann erforderlich sein, um Blockierungen im Zusammenhang mit insufficient_claims oder Fehler bei der Überprüfung der sofortigen IP-Erzwingung zu verhindern.
In der folgenden Tabelle sind die Verhaltensweisen des bedingten Zugriffs und der CAE-Features sowie Empfehlungen für verschiedene Arten von Netzwerkbereitstellungen und Ressourcenanbietern (Resource Providers, RPs) zusammengefasst:
| Netzwerktyp | Beispiel | Für Microsoft Entra sichtbare IP-Adressen | IP-Adressen aus Sicht des RP | Geltende Konfiguration für bedingten Zugriff (vertrauenswürdiger benannter Standort) | CAE-Erzwingung | CAE-Zugriffstoken | Empfehlungen |
|---|---|---|---|---|---|---|---|
| 1. Ausgehende IP-Adressen sind sowohl für Microsoft Entra als auch für den gesamten RP-Datenverkehr dediziert und aufzählbar. | Der gesamte Netzwerkdatenverkehr für Microsoft Entra und RPs wird über 1.1.1.1 und/oder 2.2.2.2.2 ausgegeben. | 1.1.1.1 | 2.2.2.2 | 1.1.1.1 2.2.2.2 |
Kritische Ereignisse IP-Standortänderungen |
Langlebig – bis zu 28 Stunden | Wenn benannte Standorte für bedingten Zugriff definiert sind, stellen Sie sicher, dass sie alle möglichen ausgehenden IP-Adressen enthalten (für Microsoft Entra und alle RPs sichtbar). |
| 2. IP-Adressen für ausgehenden Datenverkehr sind für Microsoft Entra-Datenverkehr dediziert und aufzählbar, aber nicht für RP-Datenverkehr. | Netzwerkdatenverkehr an Microsoft Entra geht über 1.1.1.1 aus. RP-Datenverkehr geht über x.x.x.x.x aus. | 1.1.1.1 | x.x.x.x | 1.1.1.1 | Kritische Ereignisse | Standardlebensdauer von Zugriffstoken – 1 Stunde | Fügen Sie nicht dedizierte oder nicht aufzählbare ausgehende IP-Adressen (x.x.x.x) nicht zu Regeln für bedingten Zugriff für vertrauenswürdige benannte Standorte hinzu, da dies die Sicherheit schwächen kann. |
| 3. IP-Adressen für ausgehenden Datenverkehr sind für Microsoft Entra- und RP-Datenverkehr nicht dediziert/freigegeben oder nicht aufzählbar. | Netzwerkdatenverkehr an Microsoft Entra geht über y.y.y.y aus. RP-Datenverkehr geht über x.x.x.x. aus | y.y.y.y | x.x.x.x | Nicht zutreffend: Es sind keine IP-Richtlinien für bedingten Zugriff/vertrauenswürdige Standorte konfiguriert. | Kritische Ereignisse | Langlebig – bis zu 28 Stunden | Fügen Sie nicht dedizierte oder nicht aufzählbare ausgehende IP-Adressen (x.x.x.x/y.y.y.y) nicht zu Regeln für bedingten Zugriff für vertrauenswürdige benannte Standorte hinzu, da dies die Sicherheit schwächen kann |
Netzwerke und Netzwerkdienste, die von Clients verwendet werden und eine Verbindung mit Identitäts- und Ressourcenanbietern herstellen, entwickeln sich weiter und ändern sich als Reaktion auf moderne Trends. Diese Änderungen können sich auf Konfigurationen für den bedingten Zugriff und CAE auswirken, die von den zugrunde liegenden IP-Adressen abhängen. Berücksichtigen Sie bei der Entscheidung über diese Konfigurationen zukünftige Änderungen an der Technologie und die Wartung der definierten Adressenliste in Ihrem Plan.
Unterstützte Standortrichtlinien
CAE hat nur Erkenntnis von DlP-basiert benannten Orten. CAE hat keine Erkenntnis von anderen Speicherortbedingungen wie für MFA vertrauenswürdige IP-Adressen oder Länder-/Regionen-basierte Speicherorte. Wenn ein Benutzer von einer für MFA vertrauenswürdigen IP-Adresse, einem vertrauenswürdigen Speicherort, der für MFA vertrauenswürdige IP-Adressen enthält, oder einem Länder/Regionen-Speicherort kommt, wird CAE nicht durchgesetzt, nachdem der Benutzer an einen anderen Speicherort wechselt. In diesen Fällen stellt Microsoft Entra ein Zugriffstoken mit einer Gültigkeit von einer Stunde ohne sofortige Prüfung der IP-Erzwingung aus.
Wichtig
Wenn Ihre Standortrichtlinien durch die fortlaufende Zugriffsevaluierung in Echtzeit erzwungen werden sollen, verwenden Sie nur die Standortbedingung für den auf IP-Adressen basierenden bedingten Zugriff, und konfigurieren Sie alle IP-Adressen, einschließlich IPv4- und IPv6-Adressbereichen, die vom Identitätsanbieter und Ressourcenanbieter angezeigt werden können. Verwenden Sie keine länder-/regionsspezifischen Standortbedingungen und auch nicht die Funktion für vertrauenswürdige IP-Adressen, die auf der Seite der Diensteinstellungen für Microsoft Entra ID Multifactor Authentication verfügbar sind.
Einschränkungen für benannte Standorte
Wenn die Summe aller in Standortrichtlinien angegebenen IP-Adressbereiche den Wert 5.000 übersteigt, kann CAE den Benutzerflow zur Standortänderung nicht mehr in Echtzeit erzwingen. In diesem Fall stellt Microsoft Entra ein CAE-Token mit einer Gültigkeit von einer Stunde aus. Neben den Änderungsereignissen für den Clientstandort erzwingt die CAE weiterhin alle übrigen Ereignisse und Richtlinien. Mit dieser Änderung ist Ihr Sicherheitsstatus weiterhin stärker als mit herkömmlichen Token mit einer Gültigkeit von einer Stunde, da andere Ereignisse immer noch nahezu in Echtzeit ausgewertet werden.
Einstellungen für Office und Web Account Manager
| Office-Updatekanal | DisableADALatopWAMOverride | DisableAADWAM |
|---|---|---|
| Halbjährlicher Enterprise-Kanal | Wenn diese Einstellung auf „aktiviert“ oder „1“ festgelegt ist, wird die fortlaufende Zugriffsevaluierung nicht unterstützt. | Wenn diese Einstellung auf „aktiviert“ oder „1“ festgelegt ist, wird die fortlaufende Zugriffsevaluierung nicht unterstützt. |
| Aktueller Kanal oder Monatlicher Enterprise-Kanal |
CAE wird unabhängig von der Einstellung unterstützt | CAE wird unabhängig von der Einstellung unterstützt |
Eine Erläuterung der Office-Updatekanäle finden Sie unter Übersicht über die Updatekanäle von Microsoft 365 Apps. Es wird empfohlen, dass Organisationen den Web Account Manager (WAM) nicht deaktivieren.
Gemeinsame Dokumenterstellung in Office-Apps
Wenn mehrere Benutzer gleichzeitig an einem Dokument zusammenarbeiten, wird ihr Zugriff auf das Dokument möglicherweise nicht sofort basierend auf Richtlinienänderungsereignissen von CAE widerrufen. In diesem Fall verliert der Benutzer den Zugriff vollständig nach:
- Schließen des Dokuments
- Schließen der Office-App
- Nach einer Stunde, wenn eine IP-Richtlinie für bedingten Zugriff festgelegt ist
Um diese Zeit weiter zu verkürzen, kann ein SharePoint-Administrator die maximale Gültigkeitsdauer von Co-Authoring-Sitzungen für Dokumente, die in SharePoint Online und Microsoft OneDrive gespeichert sind, durch Konfigurieren einer Netzwerkadressrichtlinie reduzieren. Nachdem diese Konfiguration geändert wurde, wird die maximale Lebensdauer von Sitzungen für die gemeinsame Dokumenterstellung auf 15 Minuten reduziert und kann mit dem SharePoint Online PowerShell-Befehl Set-SPOTenant –IPAddressWACTokenLifetime weiter angepasst werden.
Aktivieren eines Benutzers nach seiner Deaktivierung
Wenn Sie einen Benutzer direkt nach der Deaktivierung aktivieren, gibt es eine gewisse Wartezeit, bevor das Konto in den nachgelagerten Microsoft-Diensten als aktiviert erkannt wird.
- Bei SharePoint Online und Teams kommt es in der Regel zu einer 15-minütigen Verzögerung.
- Exchange Online hat in der Regel eine Verzögerung von 35-40 Minuten.
Pushbenachrichtigungen
Eine IP-Adressrichtlinie wird nicht ausgewertet, bevor Pushbenachrichtigungen freigegeben werden. Dieses Szenario besteht, weil Pushbenachrichtigungen nach auswärts erfolgen und keine zugehörige IP-Adresse haben, gegen die sie ausgewertet werden können. Wenn diese Push-Benachrichtigung ausgewählt wird, z. B. eine E-Mail in Outlook, werden die CAE-IP-Adressrichtlinien weiterhin erzwungen, bevor die E-Mail angezeigt werden kann. Pushbenachrichtigungen zeigen eine Nachrichtenvorschau an, die nicht durch eine IP-Adressrichtlinie geschützt ist. Alle anderen CAE-Prüfungen werden durchgeführt, bevor die Pushbenachrichtigung gesendet wird. Wenn einem Benutzer oder Gerät der Zugriff entzogen wird, erfolgt die Durchsetzung innerhalb des dokumentierten Zeitraums.
Gastbenutzer
Die CAE unterstützt keine Gastbenutzerkonten. CAE-Sperrereignisse und IP-basierte Richtlinien für bedingten Zugriff werden nicht sofort erzwungen.
CAE und Anmeldehäufigkeit
Die Anmeldehäufigkeit wird mit oder ohne CAE berücksichtigt.