Bedingter Zugriff: Tokenschutz (Vorschau)

Der Tokenschutz (in der Branche manchmal als Tokenbindung bezeichnet) versucht, Angriffe über Tokendiebstahl zu reduzieren, indem sichergestellt wird, dass ein Token nur vom Zielgerät verwendet werden kann. Wenn ein Angreifer ein Token durch Hijacking oder Replay stehlen kann, kann er die Identität seines Opfers annehmen, bis das Token abläuft oder widerrufen wird. Tokendiebstahl kommt zwar relativ selten vor, der Schaden kann allerdings erheblich sein.

Der Tokenschutz schafft eine kryptografisch sichere Bindung zwischen dem Token und dem Gerät (geheimer Clientschlüssel), für das es ausgestellt wird. Ohne den geheimen Clientschlüssel ist das gebundene Token nutzlos. Wenn ein Benutzer ein Windows 10-Gerät oder neueres Gerät in Microsoft Entra ID registriert, ist seine primäre Identität an das Gerät gebunden. Dies bedeutet, dass eine Richtlinie sicherstellen kann, dass nur gebundene Anmeldesitzungstoken (oder Aktualisierungstoken), die auch als primäre Aktualisierungstoken (PRTs) bezeichnet werden, von Anwendungen verwendet werden, wenn der Zugriff auf eine Ressource angefordert wird.

Diese Vorschau unterstützt die folgenden Konfigurationen für den Zugriff auf Ressourcen mit Tokenschutzrichtlinien für bedingten Zugriff:

• Windows 10 oder neuere Geräte, die Microsoft Entra-eingebunden, Microsoft Entra-hybrideingebunden oder Microsoft Entra-registriert sind.
• OneDrive-Synchronisierung-Clientversion 22.217 oder höher
• Native Teams-Clientversion 1.6.00.1331 oder höher
• Power BI Desktop Version 2.117.841.0 (Mai 2023) oder höher
• Visual Studio 2022 oder höher bei Verwendung der Anmeldeoption „Windows-Authentifizierungsbroker“
• Unbefristete Office-Clients werden nicht unterstützt.

• Externe Benutzer (Microsoft Entra B2B) werden nicht unterstützt und sollten nicht in Ihre Richtlinie für bedingten Zugriff einbezogen werden.
• Die folgenden Anwendungen unterstützen die Anmeldung mit geschützten Tokenflows nicht, und Benutzer werden beim Zugriff auf Exchange und SharePoint blockiert:
  • PowerShell-Module, die auf Exchange-, SharePoint- oder Microsoft Graph-Bereiche zugreifen, die von Exchange oder SharePoint bereitgestellt werden
  • PowerQuery-Erweiterung für Excel
  • Erweiterungen für Visual Studio Code, die auf Exchange oder SharePoint zugreifen
  • Der neue Teams 2.1-Vorschauclient wird nach der Abmeldung aufgrund eines Fehlers blockiert. Dieser Fehler sollte in einem zukünftigen Dienstupdate behoben werden.
• Die folgenden Windows-Clientgeräte werden nicht unterstützt:
  • Windows Server
  • Surface Hub
  • Windows-basierte Microsoft Teams-Räume (MTR)-Systeme

Für die Verwendung dieses Features werden Microsoft Entra ID P2-Lizenzen benötigt. Informationen zur Ermittlung der richtigen Lizenz für Ihre Anforderungen finden Sie im Vergleich der allgemein verfügbaren Features von Microsoft Entra ID.

Für Benutzer sollte die Bereitstellung einer Richtlinie für bedingten Zugriff zum Erzwingen des Tokenschutzes unsichtbar sein, wenn kompatible Clientplattformen auf registrierten Geräten und kompatiblen Anwendungen verwendet werden.

Um die Wahrscheinlichkeit einer Benutzerunterbrechung aufgrund der Inkompatibilität von Apps oder Geräten zu minimieren, wird dringend empfohlen:

• mit einer Pilotgruppe von Benutzern zu beginnen und diese im Laufe der Zeit zu erweitern.
• eine Richtlinie für bedingten Zugriff im Nur-Melde-Modus zu erstellen, bevor zur Erzwingung des Tokenschutzes übergegangen wird.
• sowohl interaktive als auch nicht interaktive Anmeldeprotokolle zu erfassen.
• diese Protokolle so lange zu analysieren, bis die normale Anwendungsnutzung abgedeckt ist.
• einer Erzwingungsrichtlinie bekannte Benutzer hinzuzufügen.

Dieser Prozess hilft ihnen, die Client- und App-Kompatibilität Ihrer Benutzer für die Erzwingung des Tokenschutzes zu bewerten.

Diese Funktionalität kann z. B. für Benutzer verwendet werden, die spezielle Rollen ausführen, wie sie unter Sicherheitsstufen für privilegierten Zugriff beschrieben sind. Es wird empfohlen, mit einer kleinen Pilotgruppe zu beginnen.

Die folgenden Schritte helfen beim Erstellen einer Richtlinie für bedingten Zugriff, um Tokenschutz für Exchange Online und SharePoint Online auf Windows-Geräten anzufordern.

1. Melden Sie sich beim Microsoft Entra Admin Center mindestens als Administrator für bedingten Zugriff an.
2. Navigieren Sie zu Schutz>Bedingter Zugriff>Richtlinien.
3. Wählen Sie Neue Richtlinie.
4. Benennen Sie Ihre Richtlinie. Es wird empfohlen, dass Unternehmen einen aussagekräftigen Standard für die Namen ihrer Richtlinien erstellen.
5. Wählen Sie unter Zuweisungen die Option Benutzer- oder Workloadidentitäten aus.
   1. Wählen Sie unter Einschließen die Benutzer oder Gruppen aus, die diese Richtlinie testen.
   2. Wählen Sie unter Ausschließen die Option Benutzer und Gruppen und dann die Konten für den Notfallzugriff Ihres Unternehmens aus.
6. Unter Zielressourcen>Ressourcen (ehemals Cloud-Apps)>Einschließen>Gewählte Ressourcen

   1. Wählen Sie unter Auswählen die folgenden von der Vorschau unterstützten Anwendungen aus:

      1. Microsoft Office 365 Exchange Online
      2. Office 365 SharePoint Online

      Warnung

      Ihre Richtlinie für bedingten Zugriff sollte nur für diese Anwendungen konfiguriert werden. Die Auswahl der Office 365-App-Gruppe kann zu unbeabsichtigten Fehlern führen. Dies ist eine Ausnahme von der allgemeinen Regel, dass die Office 365-App-Gruppe in einer Richtlinie für bedingten Zugriff ausgewählt werden soll.

   2. Klicken Sie auf Auswählen.

7. Unter Bedingungen:
   1. Unter Geräteplattformen:
      1. Legen Sie Konfigurieren auf Ja fest.
      2. Einschließen>Geräteplattformen auswählen>Windows.
      3. Wählen Sie Fertig aus.
   2. Unter Client-Apps:
      1. Legen Sie Konfigurieren auf Ja fest.

         Warnung

         Wenn Sie die Client-Apps-Bedingung nicht konfigurieren oder Browser ausgewählt lassen, werden Anwendungen, die MSAL.js verwenden (z. B. Teams Web), möglicherweise blockiert.

      2. Wählen Sie unter „Clients mit moderner Authentifizierung” nur die Option Mobile Apps und Desktopclients aus. Lassen Sie alle anderen Optionen deaktiviert.
      3. Wählen Sie Fertigaus.
8. Wählen Sie unter Zugriffssteuerung>Sitzung die Option Tokenschutz für Anmeldesitzungen erforderlich aus, und klicken Sie auf Auswählen.
9. Bestätigen Sie die Einstellungen, und legen Sie Richtlinie aktivieren auf Nur Bericht fest.
10. Wählen Sie Erstellen aus, um die Richtlinie zu erstellen und zu aktivieren.

Wenn ein Administrator die Einstellungen mit dem reinen Berichtsmodus bestätigt hat, kann er den Schalter Richtlinie aktivieren von Nur Bericht auf Ein festlegen.

Überwachung der Tokenschutzerzwingung für bedingten Zugriff vor und nach der Erzwingung.

Verwenden Sie das Microsoft Entra-Anmeldeprotokoll, um das Ergebnis einer Richtlinie zur Erzwingung des Tokenschutzes im Nur-Melde-Modus oder im aktivierten Modus zu überprüfen.

1. Melden Sie sich beim Microsoft Entra Admin Center mindestens als Administrator für bedingten Zugriff an.
2. Browsen Sie zu Identität>Überwachung und Integrität>Anmeldeprotokolle.
3. Wählen Sie eine bestimmte Anforderung aus, um festzustellen, ob die Richtlinie angewendet wird oder nicht.
4. Wechseln Sie je nach Status zum Bereich Bedingter Zugriff oder Nur melden, und wählen Sie den Namen Ihrer Richtlinie aus, die Tokenschutz erfordert.
5. Überprüfen Sie unter Sitzungssteuerelemente, ob die Richtlinienanforderungen erfüllt wurden oder nicht.

Sie können auch Log Analytics verwenden, um die Anmeldeprotokolle (interaktiv und nicht interaktiv) für blockierte Anforderungen aufgrund eines Fehlers bei der Tokenschutzerzwingung abzufragen.

Im Folgenden finden Sie eine Log Analytics-Beispielabfrage, die die nicht interaktiven Anmeldeprotokolle der letzten sieben Tage durchsucht, wobei blockierte und zulässige Anforderungen nach Anwendung hervorgehoben werden. Diese Abfragen sind nur Beispiele und können sich ändern.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrinicpalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

Das Ergebnis der vorherigen Abfrage sollte dem folgenden Screenshot ähneln:

Im folgenden Abfragebeispiel wird das nicht interaktive Anmeldeprotokoll der letzten sieben Tage untersucht, wobei blockierte und zulässige Anforderungen nach Benutzer hervorgehoben werden.

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

• Was ist ein primäres Aktualisierungstoken (Primary Refresh Token, PRT)?