Share via

Dostęp warunkowy: ochrona tokenów (wersja zapoznawcza)

  • Artykuł

Ochrona tokenów (czasami nazywana powiązaniem tokenu w branży) próbuje zmniejszyć liczbę ataków przy użyciu kradzieży tokenu, zapewniając, że token można używać tylko z zamierzonego urządzenia. Gdy osoba atakująca może ukraść token, przechwytując lub powtarzając, może personifikować swoją ofiarę do momentu wygaśnięcia lub odwołania tokenu. Uważa się, że kradzież tokenu jest stosunkowo rzadkim zdarzeniem, ale uszkodzenie z niego może być znaczące.

Ochrona tokenu tworzy kryptograficznie bezpieczny krawat między tokenem a urządzeniem (kluczem tajnym klienta), do których jest wystawiony. Bez wpisu tajnego klienta token powiązany jest bezużyteczny. Gdy użytkownik zarejestruje urządzenie z systemem Windows 10 lub nowszym w usłudze Microsoft Entra ID, jego podstawowa tożsamość jest powiązana z urządzeniem. Co to oznacza: zasady mogą zagwarantować, że podczas żądania dostępu do zasobu są używane tylko tokeny sesji logowania (lub odświeżania), znane jako podstawowe tokeny odświeżania (PRT).

Ważne

Ochrona tokenów jest obecnie dostępna w publicznej wersji zapoznawczej. Aby uzyskać więcej informacji na temat wersji zapoznawczych, zobacz Uniwersalne postanowienia licencyjne dotyczące usług online. W tej wersji zapoznawczej udostępniamy możliwość tworzenia zasad dostępu warunkowego w celu wymagania ochrony tokenów dla tokenów logowania (tokenów odświeżania) dla określonych usług. Obsługujemy ochronę tokenów dla tokenów logowania w dostępie warunkowym dla aplikacji klasycznych, które uzyskują dostęp do usług Exchange Online i SharePoint Online na urządzeniach z systemem Windows.

Ważne

Od czasu początkowej publicznej wersji zapoznawczej wprowadzono następujące zmiany w ochronie tokenów:

  • Dane wyjściowe dzienników logowania: wartość ciągu używanego w poleceniach "enforcedSessionControls" i "sessionControlsNotSatisfied" została zmieniona z "Binding" na "SignInTokenProtection" pod koniec czerwca 2023 r. Aby odzwierciedlić tę zmianę, należy zaktualizować zapytania dotyczące danych dziennika logowania.

Uwaga

Możemy wymieniać tokeny logowania i odświeżać tokeny w tej zawartości. Ta wersja zapoznawcza nie obsługuje obecnie tokenów dostępu ani plików cookie internetowych.

Screenshot showing a Conditional Access policy requiring token protection as the session control

Wymagania

Ta wersja zapoznawcza obsługuje następujące konfiguracje dostępu do zasobów z zastosowanymi zasadami dostępu warunkowego ochrony tokenów:

  • Urządzenia z systemem Windows 10 lub nowszym, które są przyłączone do firmy Microsoft, przyłączone hybrydo do firmy Microsoft Entra lub zarejestrowane w usłudze Microsoft Entra.
  • synchronizacja usługi OneDrive klienta w wersji 22.217 lub nowszej
  • Klient natywny usługi Teams w wersji 1.6.00.1331 lub nowszej
  • Power BI Desktop w wersji 2.117.841.0 (maj 2023 r.) lub nowszej
  • Program Visual Studio 2022 lub nowszy w przypadku korzystania z opcji logowania "Broker uwierzytelniania systemu Windows"
  • Klienci bezterminowi pakietu Office nie są obsługiwani

Znane ograniczenia

  • Użytkownicy zewnętrzni (Microsoft Entra B2B) nie są obsługiwani i nie powinni być uwzględniani w zasadach dostępu warunkowego.
  • Następujące aplikacje nie obsługują logowania przy użyciu przepływów tokenów chronionych, a użytkownicy są blokowani podczas uzyskiwania dostępu do programów Exchange i SharePoint:
    • Moduły programu PowerShell, które uzyskują dostęp do zakresów programu Exchange, SharePoint lub Microsoft Graph obsługiwanych przez program Exchange lub SharePoint
    • Rozszerzenie PowerQuery dla programu Excel
    • Rozszerzenia programu Visual Studio Code, które uzyskują dostęp do programu Exchange lub SharePoint
    • Nowy klient usługi Teams 2.1 w wersji zapoznawczej zostanie zablokowany po wylogowaniu się z powodu błędu. Ta usterka powinna zostać usunięta w przyszłej aktualizacji usługi.
  • Następujące urządzenia klienckie z systemem Windows nie są obsługiwane:
    • Windows Server
    • Surface Hub
    • Systemy Microsoft Teams Rooms (MTR) oparte na systemie Windows

Wymagania dotyczące licencji

Korzystanie z tej funkcji wymaga licencji microsoft Entra ID P2. Aby znaleźć licencję odpowiednią do wymagań, zobacz porównanie ogólnodostępnych funkcji usługi Microsoft Entra ID.

Uwaga

Wymuszanie ochrony tokenu jest częścią Ochrona tożsamości Microsoft Entra i będzie częścią licencji P2 w ogólnej dostępności.

Wdrożenie

W przypadku użytkowników wdrożenie zasad dostępu warunkowego w celu wymuszania ochrony tokenów powinno być niewidoczne w przypadku korzystania z zgodnych platform klienckich na zarejestrowanych urządzeniach i zgodnych aplikacjach.

Aby zminimalizować prawdopodobieństwo zakłóceń użytkownika z powodu niezgodności aplikacji lub urządzenia, zdecydowanie zalecamy:

  • Rozpocznij od grupy pilotażowej użytkowników i rozwiń ją wraz z upływem czasu.
  • Utwórz zasady dostępu warunkowego w trybie tylko do raportu przed przejściem do wymuszania ochrony tokenu.
  • Przechwyć dzienniki logowania interakcyjnego i nieinterakcyjnego.
  • Przeanalizuj te dzienniki pod kątem wystarczająco długiego, aby pokryć normalne użycie aplikacji.
  • Dodaj znanych dobrych użytkowników do zasad wymuszania.

Ten proces pomaga ocenić zgodność klientów i aplikacji użytkowników pod kątem wymuszania ochrony tokenów.

Tworzenie zasady dostępu warunkowego

Użytkownicy, którzy wykonują wyspecjalizowane role, takie jak opisane w sekcji Poziomy zabezpieczeń dostępu uprzywilejowanego, są możliwymi elementami docelowymi dla tej funkcji. Zalecamy rozpoczęcie pilotowania z małym podzbiorem.

Screenshot of a configured Conditional Access policy and its components.

Kroki, które należy wykonać, pomagają utworzyć zasady dostępu warunkowego, aby wymagać ochrony tokenów dla usług Exchange Online i SharePoint Online na urządzeniach z systemem Windows.

  1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra jako co najmniej Administracja istrator dostępu warunkowego.
  2. Przejdź do strony Ochrona>dostępu warunkowego.
  3. Wybierz pozycję Nowe zasady.
  4. Nadaj zasadzie nazwę. Zalecamy, aby organizacje tworzyły znaczący standard dla nazw swoich zasad.
  5. W obszarze Przypisania wybierz pozycję Użytkownicy lub tożsamości obciążeń.
    1. W obszarze Uwzględnij wybierz użytkowników lub grupy, które testują te zasady.
    2. W obszarze Wyklucz wybierz pozycję Użytkownicy i grupy , a następnie wybierz konta awaryjne lub konta ze szkła awaryjnego w organizacji.
  6. W obszarze Docelowe zasoby>w chmurze aplikacje>obejmują>wybieranie aplikacji

    1. W obszarze Wybierz wybierz następujące aplikacje obsługiwane przez wersję zapoznawcza:

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

      Ostrzeżenie

      Zasady dostępu warunkowego powinny być skonfigurowane tylko dla tych aplikacji. Wybranie grupy aplikacji usługi Office 365 może spowodować niezamierzone błędy. Jest to wyjątek od reguły ogólnej, że grupa aplikacji usługi Office 365 powinna zostać wybrana w zasadach dostępu warunkowego.

    2. Naciśnij przycisk Wybierz.

  7. W warunkach:
    1. W obszarze Platformy urządzeń:
      1. Ustaw pozycję Konfiguruj na Wartość Tak.
      2. Uwzględnij>pozycję Wybierz platformy urządzeń z systemem>Windows.
      3. Wybierz pozycję Gotowe.
    2. W obszarze Aplikacje klienckie:
      1. Ustaw pozycję Konfiguruj na Wartość Tak.

        Ostrzeżenie

        Brak konfigurowania warunku Aplikacje klienckie lub pozostawienie wybranej przeglądarki może spowodować zablokowanie aplikacji korzystających z MSAL.js, takich jak witryna sieci Web usługi Teams.

      2. W obszarze Klienci nowoczesnego uwierzytelniania wybierz pozycję Aplikacje mobilne i klienci klasyczni. Pozostaw inne elementy niezaznaczone.
      3. Wybierz pozycję Gotowe.
  8. W obszarze Kontrola>dostępu Sesja wybierz pozycję Wymagaj ochrony tokenu dla sesji logowania i wybierz pozycję Wybierz.
  9. Potwierdź ustawienia i ustaw opcję Włącz zasadyna tylko raport.
  10. Wybierz pozycję Utwórz , aby utworzyć, aby włączyć zasady.

Po potwierdzeniu przez administratorów ustawień w trybie tylko do raportu mogą przenieść przełącznik Włącz zasady z obszaru Tylko raport do pozycji Włączone.

Przechwytywanie dzienników i analizowanie

Monitorowanie wymuszania dostępu warunkowego ochrony tokenu przed wymuszaniem i po nim.

Dzienniki logowania

Użyj dziennika logowania firmy Microsoft Entra, aby zweryfikować wynik zasad wymuszania ochrony tokenu w trybie tylko raportu lub w trybie włączonym.

  1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra jako co najmniej Administracja istrator dostępu warunkowego.
  2. Przejdź do dzienników logowania do monitorowania tożsamości>i kondycji.>
  3. Wybierz określone żądanie, aby określić, czy zasady są stosowane, czy nie.
  4. Przejdź do okienka Dostęp warunkowy lub Tylko raport w zależności od jego stanu i wybierz nazwę zasad wymagających ochrony tokenu.
  5. W obszarze Kontrolki sesji sprawdź, czy wymagania dotyczące zasad zostały spełnione, czy nie.

Screenshot showing an example of a policy not being satisfied.

Log Analytics

Usługa Log Analytics umożliwia również wykonywanie zapytań dotyczących dzienników logowania (interakcyjnych i nieinterakcyjnych) dla zablokowanych żądań z powodu niepowodzenia wymuszania ochrony tokenu.

Oto przykładowe zapytanie usługi Log Analytics wyszukujące dzienniki logowania nieinterakcyjnego z ostatnich siedmiu dni z wyróżnionymi zablokowanymi i dozwolonymi żądaniami według aplikacji. Te zapytania są tylko przykładami i mogą ulec zmianie.

Uwaga

Dane wyjściowe dzienników logowania: wartość ciągu używanego w poleceniach "enforcedSessionControls" i "sessionControlsNotSatisfied" została zmieniona z "Binding" na "SignInTokenProtection" pod koniec czerwca 2023 r. Aby odzwierciedlić tę zmianę, należy zaktualizować zapytania dotyczące danych dziennika logowania. Przykłady obejmują obie wartości, aby uwzględnić dane historyczne.

//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

Wynik poprzedniego zapytania powinien być podobny do poniższego zrzutu ekranu:

Screenshot showing example results of a Log Analytics query looking for token protection policies

Poniższy przykład zapytania analizuje dziennik logowania nieinterakcyjnego z ostatnich siedmiu dni, z wyróżnioną pozycją Zablokowane i Dozwolone żądania według użytkownika.

//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

Następne kroki