Implementieren der Sitzungsverwaltung und kontinuierlichen Zugriffsauswertung

  • 3 Minuten

In komplexen Bereitstellungen müssen Organisationen Authentifizierungssitzungen manchmal einschränken. Einige mögliche Szenarien:

  • Ressourcenzugriff von einem nicht verwalteten oder freigegebenen Gerät
  • Zugriff auf vertrauliche Informationen über ein externes Netzwerk
  • Benutzer mit hoher Priorität oder Führungskräfte.
  • Unternehmenskritische Geschäftsanwendungen

Mit Steuerungen für den bedingten Zugriff können Sie Richtlinien erstellen, die auf spezifische Anwendungsfälle in Ihrer Organisation ausgerichtet sind, ohne alle Benutzenden zu beeinflussen.

Bevor wir auf die Details zur Konfiguration der Richtlinie eingehen, betrachten wir die Standardkonfiguration.

Anmeldehäufigkeit von Benutzenden

Die Anmeldehäufigkeit bezeichnet den Zeitraum, bevor jemand beim Zugriff auf eine Ressource aufgefordert wird, sich erneut anzumelden.

Die Standardkonfiguration von Microsoft Entra ID sieht für die Anmeldehäufigkeit von Benutzenden ein rollierendes Zeitfenster von 90 Tagen vor. Benutzer häufig zur Eingabe von Anmeldeinformationen aufzufordern, kann einerseits sinnvoll sein, andererseits aber auch das Gegenteil bewirken: Benutzer, die es gewohnt sind, ihre Anmeldeinformationen ohne Überlegung einzugeben, können diese auch versehentlich bei einer schädlichen Anmeldeaufforderung eingeben.

Es klingt vielleicht beunruhigend, keine erneute Anmeldung von einem Benutzer zu fordern, tatsächlich wird die Sitzung bei einer Verletzung der IT-Richtlinien jedoch gesperrt. Zu den Beispielen zählen eine Kennwortänderung, ein nicht konformes Gerät oder eine Kontodeaktivierung. Sie können Benutzersitzungen auch explizit mit PowerShell widerrufen. Die Standardkonfiguration der Microsoft Entra-ID bezieht sich auf "Bitten Sie Benutzer nicht, ihre Anmeldeinformationen anzugeben, wenn sich der Sicherheitsstatus ihrer Sitzungen nicht geändert hat.".

Die Einstellung für die Anmeldehäufigkeit funktioniert bei Apps mit standardkonformer Implementierung des OAUTH2- oder OIDC-Protokolls. Die meisten Apps für Windows, Mac und Mobile, einschließlich der folgenden Webanwendungen, entsprechen der Einstellung.

  • Startseiten für Word, Excel und PowerPoint Online
  • OneNote Online
  • Office.com
  • Microsoft 365 Admin-Portal
  • Exchange Online
  • SharePoint und OneDrive
  • Teams-Webclient
  • Dynamics CRM Online
  • Azure-Portal

Die Einstellung für die Anmeldehäufigkeit funktioniert auch mit SAML-Anwendungen, solange diese nicht ihre eigenen Cookies löschen und in regelmäßigen Abständen an Microsoft Entra ID zur Authentifizierung umgeleitet werden.

Anmeldehäufigkeit von Benutzern und mehrstufige Authentifizierung

Die Anmeldehäufigkeit wurde bisher nur für die einstufige Authentifizierung auf Geräten angewendet, die in Microsoft Entra eingebunden, hybrid in Microsoft Entra Hybrid eingebunden und bei Microsoft Entra registriert waren. Es gab keine einfache Möglichkeit für unsere Kunden, die mehrstufige Authentifizierung (MFA) auf diesen Geräten erneut zu erzwingen. Aufgrund des Kundenfeedbacks wird die Anmeldehäufigkeit jetzt auch auf die Multi-Faktor-Authentifizierung angewendet.

Diagramm: Anmeldungsprozess der Multi-Faktor-Authentifizierung mit Anmeldehäufigkeit

Anmeldehäufigkeit von Benutzenden und Geräteidentitäten

Wenn Sie über in Microsoft Entra eingebundene, hybrid in Microsoft Entra eingebundene oder in Microsoft Entra registrierte Geräte verfügen, erfüllen auch das Entsperren von Geräten oder interaktive Anmeldungen von Besuchern die Richtlinie für die Anmeldehäufigkeit. In den folgenden beiden Beispielen ist die Anmeldehäufigkeit von Benutzern auf eine Stunde festgelegt:

Beispiel 1:

  • Um 00:00 Uhr meldet sich jemand bei einem in Microsoft Entra eingebundenen Windows 10-Gerät an und beginnt mit der Bearbeitung eines in SharePoint Online gespeicherten Dokuments.
  • Die benutzende Person arbeitet auf dem Gerät eine Stunde an diesem Dokument.
  • Um 01:00 Uhr wird sie basierend auf der von der administrierenden Person in der Richtlinie für bedingten Zugriff konfigurierten Anmeldehäufigkeitsanforderung zur erneuten Anmeldung aufgefordert.

Beispiel 2:

  • Um 00:00 Uhr meldet sich jemand bei einem in Microsoft Entra eingebundenen Windows 10-Gerät an und beginnt mit der Bearbeitung eines in SharePoint Online gespeicherten Dokuments.
  • Um 00:30 Uhr steht der Benutzer auf und macht eine Pause, wobei er sein Gerät sperrt.
  • Um 00:45 Uhr kehrt die Person aus ihrer Pause zurück und entsperrt das Gerät.
  • Um 01:45 Uhr wird sie basierend auf der von der administrierenden Person in der Richtlinie für bedingten Zugriff konfigurierten Anmeldehäufigkeitsanforderung zur erneuten Anmeldung aufgefordert, weil die letzte Anmeldung um 00:45 Uhr erfolgte.

Persistenz von Browsersitzungen

Bei einer persistenten Browsersitzung können Benutzende angemeldet bleiben, nachdem sie ihr Browserfenster geschlossen und erneut geöffnet haben. Die Microsoft Entra-ID-Standardeinstellung für die Persistenz von Browsersitzungen ermöglicht Benutzern auf persönlichen Geräten die Auswahl, ob die Sitzung beibehalten werden soll, indem ein "Angemeldet bleiben" angezeigt wird? die Aufforderung „Angemeldet bleiben?“ nach erfolgreicher Authentifizierung.

Überprüfung

Verwenden Sie das Was-wäre-wenn-Tool, um eine Anmeldung des Benutzers bei der Zielanwendung und weitere Bedingungen zu simulieren, die davon abhängig sind, wie Sie die Richtlinie konfiguriert haben. Die Steuerungen für die Verwaltung von Authentifizierungssitzungen werden in den Ergebnissen des Tools angezeigt.

Screenshot der Ergebnisse des „What If“-Tools für den bedingten Zugriff.

Richtlinienbereitstellung

Um die erwartete Funktionsweise der Richtlinie sicherzustellen, empfiehlt es sich, sie zu testen, bevor Sie sie in der Produktionsumgebung verwenden. Idealerweise sollten Sie in einem Testmandanten überprüfen, ob die neue Richtlinie wie erwartet funktioniert.

Kontinuierliche Zugriffsauswertung (Continuous Access Evaluation, CAE)

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 Microsoft Entra ID 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.

Es gibt jedoch eine Verzögerung zwischen der Änderung von Bedingungen für einen Benutzer und der Erzwingung von Richtlinienänderungen. Die rechtzeitige Reaktion auf Richtlinienverstöße oder Sicherheitsprobleme erfordert einen echten Austausch zwischen dem Tokenaussteller und der vertrauenden Seite (kompatible App). 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 die Vertrauenspartei dazu veranlassen, die Token für einen bestimmten Benutzer nicht mehr zu akzeptieren, falls das Konto kompromittiert oder deaktiviert wurde oder aus anderen Bedenken. Der Mechanismus für diesen Austausch ist die fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE).

Vorteile

Die fortlaufende Zugriffsbewertung bietet mehrere wichtige Vorteile.

  • 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.

Ablauf des Auswertungs- und Sperrprozesses

Schematische Darstellung des Prozessflusses, wenn ein Zugriffstoken widerrufen wird und ein Client sich für den Zugriff erneut verifizieren muss.

  1. Ein Client, der die Kontinuierliche Zugriffsevaluierung (Continuous Access Evaluation, CAE) unterstützt, stellt Anmeldeinformationen oder ein Aktualisierungstoken für Microsoft Entra ID bereit und fordert ein Zugriffstoken für eine bestimmte Ressource an.
  2. Ein Zugriffstoken wird zusammen mit anderen Artefakten an den Client zurückgegeben.
  3. Ein Administrator sperrt explizit alle Aktualisierungstoken für den Benutzer. Von Microsoft Entra ID wird ein Sperrungsereignis an den Ressourcenanbieter gesendet.
  4. 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.
  5. Im Falle des Diagramms verweigert der Ressourcenanbieter den Zugriff und sendet die Anspruchsaufforderung „401+“ an den Client zurück.
  6. 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 ID. Microsoft Entra ID wertet dann alle Bedingungen erneut aus und fordert in diesem Fall den Benutzer auf, sich erneut zu authentifizieren.