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. Standardmäßig sind diese Zugriffstoken eine Stunde lang gültig. Nach Ablauf dieser Zeit wird der Client zur Aktualisierung zurück an Azure AD geleitet. Die Aktualisierung bietet eine Möglichkeit, Richtlinien für den Benutzerzugriff neu auszuwerten. Möglicherweise soll das Token nicht aktualisiert werden, zum Beispiel aufgrund einer Richtlinie für bedingten Zugriff oder da der Benutzer im Verzeichnis deaktiviert wurde.
Kunden haben Bedenken ausgedrückt hinsichtlich der Verzögerung zwischen der Änderung der Bedingungen für einen Benutzer und der Durchsetzung von Richtlinienänderungen. Azure AD hat mit dem "stumpfen Objekt"-Ansatz verkürzter Token-Lebensdauern experimentiert, aber festgestellt, dass sie die Benutzererfahrung und Zuverlässigkeit beeinträchtigen können, ohne Risiken zu beseitigen.
Eine rechtzeitige Reaktion auf Richtlinienverletzungen oder Sicherheitsprobleme erfordert eine "Konversation" zwischen dem Token-Aussteller (Azure AD) 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 diesen Austausch ist die fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE). Das Ziel für die Bewertung kritischer Ereignisse ist es, nahezu in Echtzeit zu reagieren, aber durch die Dauer der Ereignisweitergabe ist eine Latenz von bis zu 15 Minuten zu beobachten. Die Durchsetzung 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.
Die fortlaufende Zugriffsauswertung ist auf Azure Government GCC High-Mandanten derzeit nicht verfügbar.
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 Azure AD-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
- Mehrstufige Authentifizierung wird für den Benutzer aktiviert.
- Administrator sperrt explizit alle Aktualisierungstoken für einen Benutzer.
- Azure AD Identity Protection hat ein hohes Benutzerrisiko 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
Benutzerrisikoereignisse werden von Teams und SharePoint Online noch nicht unterstützt.
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 der Organisation 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.
Clientfunktionen
Clientseitige Anspruchsaufforderung
Vor der fortlaufenden Zugriffsevaluierung haben die Clients das Zugriffstoken aus ihrem Cache wiedergegeben, 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 Anspruchsüberprüfung ein, um anzuzeigen, dass das Token abgelehnt wurde und ein neues Zugriffstoken von Azure AD ausgestellt werden muss. Für die fortlaufende Zugriffsevaluierung ist ein Client-Update erforderlich, damit der Client die Anspruchsaufforderung verstehen kann. Die aktuelle Version der folgenden Anwendungen unterstützt 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, nicht einfach durch einen willkürlichen Zeitraum gesteuert. 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 1 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 CAE-fähiger Client stellt Anmeldeinformationen oder ein Aktualisierungstoken für Azure AD bereit und fordert ein Zugriffstoken für eine Ressource an.
- Ein Zugriffstoken wird zusammen mit anderen Artefakten an den Client zurückgegeben.
- Ein Administrator sperrt explizit alle Aktualisierungstoken für den Benutzer. Von Azure AD wird ein Sperrereignis 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 Azure AD. Azure AD wertet dann alle Bedingungen erneut aus und fordert in diesem Fall den 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 CAE-fähiger Client stellt Anmeldeinformationen oder ein Aktualisierungstoken für Azure AD bereit und fordert ein Zugriffstoken für eine Ressource an.
- Azure AD 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 Azure AD 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 Azure AD. Azure AD wertet alle Bedingungen erneut aus, und der Zugriff wird in diesem Fall verweigert.
Aktivieren oder Deaktivieren der CAE
Die CAE-Einstellung wurde auf das Blatt „Bedingter 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 zuvor CAE-Einstellungen unter „Sicherheit“ konfiguriert haben, müssen die Einstellungen in eine neue Richtlinie für bedingten Zugriff migrieren. Führen Sie die folgenden Schritte aus, um Ihre CAE-Einstellungen in eine Richtlinie für bedingten Zugriff zu migrieren.
- Melden Sie sich als Administrator für bedingten Zugriff, Sicherheitsadministrator oder globaler Administrator beim Azure-Portal an.
- Navigieren Sie zu Azure Active Directory>Sicherheit>Fortlaufende Zugriffsevaluierung.
- Es wird die Option Migrieren der Richtlinie angezeigt. Diese Aktion ist die einzige Aktion, auf die Sie zu diesem Zeitpunkt zugreifen können.
- Navigieren Sie zu Bedingter Zugriff. Sie sehen dort eine neue Richtlinie namens ZS-Richtlinie aus CAE-Einstellungen, die mit Ihren Einstellungen konfiguriert ist. Administratoren können diese Richtlinie anpassen oder eine eigene Richtlinie erstellen, um sie zu ersetzen.
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 wird ausgeblendet, da diese Kunden die Erfahrung wahrscheinlich vor der allgemeinen Verfügbarkeit nicht gesehen haben. |
| Mandanten, die ausdrücklich für alle Benutzer mit der alten Erfahrung aktiviert wurden. | Nein | Ja | Alte CAE-Einstellungen werden ausgegraut. Da diese Kunden diese Einstellung ausdrücklich für alle Benutzer aktiviert haben, müssen sie nicht migrieren. |
| Mandanten, die einige Benutzer in ihren Mandanten ausdrücklich mit der alten Erfahrung aktiviert haben. | Ja | Nein | Alte CAE-Einstellungen werden ausgegraut. Wenn Sie auf Migrieren klicken, wird der neue Assistent für Richtlinien für bedingten Zugriff gestartet, der Alle Benutzer enthält, während Benutzer und Gruppen, die aus der CAE kopiert wurden, ausgenommen werden. Außerdem wird die neue Sitzungssteuerung Anpassen der fortlaufenden Zugriffsevaluierung auf Deaktiviert festgelegt. |
| Mandanten, die die Vorschau ausdrücklich deaktiviert haben. | Ja | Nein | Alte CAE-Einstellungen werden ausgegraut. Wenn Sie auf Migrieren klicken, wird der neue Assistent für Richtlinien für bedingten Zugriff gestartet, der Alle Benutzer enthält, und die neue Sitzungssteuerung Anpassen der fortlaufenden Zugriffsevaluierung wird 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 Azure AD 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 "Sitzung widerrufen" auf der Benutzerprofilseite imr Azure-Portal aus, um die Sitzung des Benutzers zu widerrufen, um sicherzustellen, dass die aktualisierten Richtlinien sofort angewendet werden.
Variation der IP-Adresse
Im Identitäts- und Ressourcenanbieter werden möglicherweise andere IP-Adressen angezeigt. Dieser Konflikt kann aus folgenden Gründen auftreten:
- Netz-Proxy-Implementierungen in Ihrer Organisation
- Falsche IPv4/IPv6-Konfigurationen zwischen Ihrem Identitätsanbieter und Ihrem Ressourcenanbieter
Beispiele:
- Ihr Identitätsanbieter sieht eine bestimmte IP-Adresse des Clients, während Ihr Ressourcenanbieter nach dem Durchlaufen eines Proxys eine andere IP-Adresse des Clients sieht.
- Die IP-Adresse, die Ihr Identitätsanbieter sieht, gehört zu einem in der Richtlinie erlaubten IP-Bereich, die IP-Adresse des Ressourcenanbieters jedoch nicht.
Um Endlosschleifen aufgrund dieser Szenarien zu vermeiden, gibt Azure AD ein einstündiges CAE-Token aus und wird keine Änderung des Clientorts durchsetzen. In diesem Fall wird die Sicherheit im Vergleich zu traditionellen einstündigen Token verbessert, da wir neben den Ereignissen zur Änderung des Clientorts auch andere-Ereignisse auswerten.
Unterstützte Standortrichtlinien
CAE hat nur Erkenntnis von DlP-basiert benannten Orten. CAE hat keine Erkenntnis von anderen Ortsbedingungen wie MFA vertrauenswürdige IPs oder länderbasierte Orte. Wenn ein Benutzer von einer MFA-vertrauenswürdigen IP, einem vertrauenswürdigen Ort, der MFA-vertrauenswürdige IPs enthält, oder einem länderbasierten Ort kommt, wird CAE nicht durchgesetzt, wenn der Benutzer an einen anderen Ort wechselt. In diesen Fällen wird Azure AD ein einstündiges Zugriffstoken ohne sofortige IP-Durchsetzungsprüfung ausstellen.
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änderspezifischen Standortbedingungen und auch nicht die Funktion für vertrauenswürdige IP-Adressen, die auf der Seite der Diensteinstellungen für Azure AD Multi-Factor Authentication verfügbar ist.
Einschränkungen für benannte Standorte
Wenn die Summe aller IP-Adressbereiche, die in Standortrichtlinien angegeben sind, 5.000 überschreitet, wird der Benutzerflow zur Standortänderung von der CAE nicht in Echtzeit erzwungen. In diesem Fall gibt Azure AD ein einstündiges CAE-Token aus. Abgesehen von Änderungsereignissen für den Clientstandort werden alle übrigen Ereignisse und Richtlinien weiterhin von CAE erzwungen. Mit dieser Änderung behalten Sie weiterhin einen stärkeren Sicherheitsstatus im Vergleich zu herkömmlichen einstündigen Token bei, weil andere Ereignisse in Quasi-Echtzeit ausgewertet werden.
Einstellungen für Office und Web Account Manager
| Office-Updatekanal | DisableADALatopWAMOverride | DisableAADWAM |
|---|---|---|
| Halbjährlicher Enterprise-Kanal | Wenn auf aktiviert oder 1 gesetzt, wird CAE nicht unterstützt. | Wenn auf aktiviert oder 1 gesetzt, wird CAE 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 von CAE widerrufen (basierend auf Richtlinienänderungsereignissen). 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 OneDrive for Business gespeichert sind, durch Konfiguration einer Netzwerkadressrichtlinie in SharePoint Online reduzieren. Wenn diese Konfiguration geändert ist, wird die maximale Gültigkeitsdauer von Koautorensitzungen 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 ein Benutzer auf die Push-Benachrichtigung klickt, z.B. auf eine E-Mail in Outlook, werden die IP-Adressrichtlinien des CAE immer noch durchgesetzt, 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.
Häufig gestellte Fragen
Wie funktioniert die fortlaufende Zugriffsevaluierung (CAE) mit der Anmeldehäufigkeit?
Die Anmeldehäufigkeit wird mit oder ohne CAE berücksichtigt.