Udostępnij za pośrednictwem

Dostęp warunkowy firmy Microsoft Entra: ochrona tokenu (wersja zapoznawcza)

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, poprzez przechwycenie lub odtworzenie, może podszywać się pod swoją ofiarę do momentu wygaśnięcia lub unieważnienia tokenu. Uważa się, że kradzież tokenu jest stosunkowo rzadkim zdarzeniem, ale uszkodzenie z niego może być znaczące.

Ochrona tokenu tworzy kryptograficznie bezpieczne powiązanie między tokenem a urządzeniem (tajemnicą klienta), do którego jest on wydawany. Bez tajnego klucza klienta powiązany token 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 przez aplikacje tylko powiązane tokeny sesji logowania (lub tokeny 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 komputerowych, 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 wymuszanych kontrolach sesji oraz niespełnionych kontrolach sesji 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.
  • Urządzenia dołączone do firmy Microsoft Entra przy użyciu niektórych metod nie są już obsługiwane. Aby uzyskać pełną listę, zobacz sekcję znanych ograniczeń .
  • Zmiana kodu błędu: Kod błędu w Zasadzie ochrony tokenu i dostępu warunkowego zmienia się z 53003 na 530084, aby lepiej identyfikować błędy związane z ochroną tokenu.
  • Ochrona tokenów obsługuje teraz aplikację systemu Windows, rozszerzając ochronę na systemy Windows 365 i Azure Virtual Desktop.

Zrzut ekranu przedstawiający zasady dostępu warunkowego wymagające ochrony tokenu jako kontrolkę sesji.

Wymagania

Korzystanie z tej funkcji wymaga licencji microsoft Entra ID P2. Aby znaleźć odpowiednią licencję dla swoich wymagań, zobacz plany i cennik firmy Microsoft Entra.

Uwaga

Egzekwowanie ochrony tokenów jest częścią usługi Microsoft Entra ID Protection i wymaga licencji Microsoft Entra ID P2 przy ogólnej dostępności.

Następujące urządzenia i aplikacje obsługują dostęp do zasobów, na których są stosowane zasady dostępu warunkowego ochrony tokenów:

Obsługiwane urządzenia:

  • Urządzenia z systemem Windows 10 lub nowszym, które są przyłączone do Microsoft Entra, przyłączone hybrydowo do Microsoft Entra lub zarejestrowane w Microsoft Entra. Zobacz sekcję Znane ograniczenia dotyczące nieobsługiwanych typów urządzeń.
  • System Windows Server 2019 lub nowszy, z przyłączoną hybrydowo usługą Microsoft Entra.

Obsługiwane aplikacje:

  • Klient synchronizacji usługi OneDrive w wersji 22.217 lub nowszej
  • Natywny klient 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
  • Moduł programu Exchange PowerShell w wersji 3.7.0 lub nowszej
  • Program Microsoft Graph PowerShell w wersji 2.0.0 lub nowszej z opcją EnableLoginByWAM
  • Program Visual Studio 2022 lub nowszy podczas korzystania z opcji logowania "Broker uwierzytelniania systemu Windows"
  • Aplikacja systemu Windows w wersji 2.0.379.0 lub nowszej

Znane ograniczenia

  • Klienci bezterminowi pakietu Office nie są obsługiwani.
  • 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 programu SharePoint
    • Rozszerzenie PowerQuery dla programu Excel
    • Rozszerzenia programu Visual Studio Code, które uzyskują dostęp do programu Exchange lub SharePoint
  • Następujące urządzenia klienckie z systemem Windows nie są obsługiwane:
    • Surface Hub
    • Systemy Microsoft Teams Rooms (MTR) oparte na systemie Windows
  • Użytkownicy zewnętrzni, którzy spełniają wymagania dotyczące rejestracji urządzeń ochrony tokenów w swojej dzierżawie macierzystej, są objęci wsparciem. Jednak użytkownicy, którzy nie spełniają tych wymagań, zobaczą niejasny komunikat o błędzie bez wskazania głównej przyczyny.
  • Urządzenia zarejestrowane w usłudze Microsoft Entra ID przy użyciu następujących metod nie są obsługiwane:
  • Nowe urządzenia zarejestrowane w usłudze Microsoft Entra w wersjach systemu Windows przed 24H2 mogą zostać zablokowane, jeśli użytkownicy nie wykonują nowego logowania podczas rejestracji. W przypadku zablokowania użytkownicy muszą ponownie zarejestrować urządzenie.

Aby zidentyfikować urządzenia, których to dotyczy z powodu nieobsługiwanych typów rejestracji wymienionych wcześniej, sprawdź atrybut tokenProtectionStatusDetails w dziennikach logowania. Żądania tokenów, które są blokowane z powodu nieobsługiwanego typu rejestracji urządzenia, można zidentyfikować przy użyciu wartości signInSessionStatusCode 1003.

Aby zapobiec jakimkolwiek przerwom w nowym wdrażaniu, można zmodyfikować zasady ochrony tokenu w dostępie warunkowym, dodając warunek filtru urządzenia, który wyklucza urządzenia wpisujące się w wcześniej opisaną kategorię wdrażania. Aby na przykład wykluczyć:

  • Komputery w chmurze, które są połączone z Microsoft Entra, można korzystać z systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
  • Usługi Azure Virtual Desktop, które są połączone z Microsoft Entra, można używać systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
  • W przypadku grup maszyn hostowanych przez Power Automate, które są przyłączone do Microsoft Entra, można użyć systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
  • Urządzenia Windows Autopilot wdrażane w trybie samodzielnego wdrażania mogą korzystać z właściwości enrollmentProfileName. Jeśli na przykład utworzyłeś profil rejestracji w Intune dla urządzeń w trybie samodzielnego wdrażania Autopilot jako „Profil samodzielnego wdrażania Autopilot”, możesz użyć polecenia `enrollmentProfileName -eq "Profil samodzielnego wdrażania Autopilot".
  • Maszyny wirtualne z systemem Windows na platformie Azure, które są przyłączone do Microsoft Entra, można użyć profileType -eq "SecureVM" and trustType -eq "AzureAD".

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 egzekwowania ochrony tokenów.
  • Zanotuj zarówno dzienniki logowania interaktywnego, jak i nieinteraktywnego.
  • Przeanalizuj te dzienniki wystarczająco długo, aby zapewnić zcoverowanie normalnego użycia aplikacji.
  • Dodaj użytkowników określonych jako zaufani do polityki egzekwowania.

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łą grupą.

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 administrator dostępu warunkowego.
  2. Przejdź do Entra ID>Warunkowy dostęp>Zasady.
  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 robocze.
    1. W obszarze Uwzględnij wybierz użytkowników lub grupy, które testują te zasady.
    2. W obszarze Wyklucz wybierz Użytkownicy i grupy i wybierz konta awaryjne w organizacji.
  6. W obszarze Zasoby docelowe>(dawniej aplikacje w chmurze)>Uwzględnij>pozycję Wybierz zasoby

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

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online
      3. Jeśli aplikacja systemu Windows została wdrożona w środowisku, uwzględnij następujące elementy:
        1. Azure Virtual Desktop
        2. Windows 365
        3. Logowanie do chmury systemu Windows

      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. Ta zmiana jest wyjątkiem od reguły ogólnej, że grupa aplikacji usługi Office 365 powinna zostać wybrana w zasadach dostępu warunkowego.

    2. Wybierz Wybierz.

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

      1. Ustaw pozycję Konfiguruj na Wartość Tak.

        Ostrzeżenie

        Nie skonfigurowano 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 Nowoczesne uwierzytelnianie klientów wybierz pozycję Aplikacje mobilne i klienci komputerowi. Pozostaw inne elementy niezaznaczone.

      3. Wybierz pozycję Gotowe.

  8. W obszarze Kontrola> dostępuSesja wybierz pozycję Wymagaj ochrony tokenu dla sesji logowania i wybierz pozycję Wybierz.
  9. Potwierdź ustawienia i ustaw Włącz politykę na Tylko raportowanie.
  10. Wybierz Utwórz, aby włączyć swoje zasady.

Gdy administratorzy ocenią ustawienia zasad przy użyciu trybu wpływu zasad lub trybu tylko raportowania, mogą przestawić przełącznik Włącz zasady z Tylko raport na Włączone.

Wskazówka

Ponieważ zasady dostępu warunkowego wymagające ochrony tokenów są obecnie dostępne tylko dla urządzeń z systemem Windows, należy zabezpieczyć środowisko przed potencjalnym obejściem zasad, gdy osoba atakująca może wydawać się pochodzić z innej platformy.

Ponadto należy skonfigurować następujące zasady:

Przechwytywanie dzienników i analizowanie

Monitoruj wymuszanie ochrony tokenu w dostępie warunkowym przed i po jego wymuszeniu, korzystając z funkcji takich jak Wpływ zasad (wersja zapoznawcza), dzienniki logowania lub Log Analytics.

Dzienniki logowania

Użyj dziennika logowania Microsoft Entra, aby zweryfikować wynik zasady egzekwowania ochrony tokenu w trybie tylko do raportowania lub w trybie włączonym.

Zrzut ekranu przedstawiający przykład niespełnienia wymagań polityki.

  1. Zaloguj się do centrum administracyjnego firmy Microsoft Entra jako co najmniej administrator dostępu warunkowego.
  2. Przejdź do Entra ID Monitorowanie & zdrowie Dzienniki logowania.
  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.
  6. Aby uzyskać więcej informacji na temat stanu powiązania żądania, wybierz okienko Informacje podstawowe i zobacz pole Ochrona tokenu — sesja logowania. Możliwe wartości to:
    1. Związane: żądanie korzystało z ograniczonych protokołów. Niektóre logowania mogą zawierać wiele żądań, a wszystkie żądania muszą być powiązane, aby spełnić zasady ochrony tokenów. Nawet jeśli pojedyncze żądanie wydaje się być powiązane, nie zapewnia zgodności z zasadami, jeśli inne żądania są niezwiązane. Aby wyświetlić wszystkie żądania dotyczące logowania, można filtrować wszystkie żądania dla określonego użytkownika lub wyszukać według identyfikatora logowania.
    2. Niezawiązane: żądanie nie używało powiązanych protokołów. Możliwe statusCodes, gdy żądanie jest niezwiązane:
      1. 1002: Żądanie jest niepowiązane z powodu braku informacji o stanie urządzenia Microsoft Entra ID.
      2. 1003: Żądanie jest niezwiązane, ponieważ stan urządzenia Microsoft Entra ID nie spełnia wymagań zasad dostępu warunkowego na potrzeby ochrony tokenów. Ten błąd może być spowodowany nieobsługiwanym typem rejestracji urządzenia lub urządzenie nie zostało zarejestrowane przy użyciu nowych poświadczeń logowania.
      3. 1005: Żądanie jest odrzucone z innych nieokreślonych powodów.
      4. 1006: Żądanie jest niezwiązane, ponieważ wersja systemu operacyjnego nie jest obsługiwana.
      5. 1008: Żądanie jest niezwiązane, ponieważ klient nie jest zintegrowany z brokerem platformy, takim jak Menedżer kont systemu Windows (WAM).

Zrzut ekranu przedstawiający przykładowe logowanie z wyróżnionym atrybutem Ochrona tokenu — sesja logowania.

Analiza Logów

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 "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" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| 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, 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:

Zrzut ekranu przedstawiający przykładowe wyniki zapytania usługi Log Analytics, które szuka zasad ochrony tokenów

Poniższy przykład zapytania analizuje dziennik logowania nieinterakcyjnego z ostatnich siedmiu dni, wyróżniając Zablokowane versus Dozwolone żądania przez 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" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| 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

W poniższym zapytaniu przedstawiono dziennik logowania bez interakcji z ostatnich siedmiu dni, wyróżniając użytkowników korzystających z urządzeń, gdzie stan urządzenia Microsoft Entra ID nie spełnia wymagań polityki ochrony tokenu.

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName

Środowisko użytkownika końcowego

Użytkownik, który zarejestrował lub zapisał swoje urządzenie, nie doświadcza żadnych różnic w doświadczeniu logowania w aplikacji z obsługą ochrony tokenów, gdy wymóg ochrony tokenu jest włączony.

Użytkownik, który nie zarejestrował ani nie zapisał swojego urządzenia, lub korzysta z nieobsługiwanej aplikacji, kiedy włączono wymaganie ochrony tokenu, zobaczy poniższy zrzut ekranu po uwierzytelnieniu.

Zrzut ekranu przedstawiający komunikat o błędzie ochrony tokenu, gdy urządzenie nie jest zarejestrowane ani zapisane.

Użytkownik, który nie korzysta z obsługiwanej aplikacji, gdy jest włączone wymaganie ochrony tokenu, zobaczy poniższy zrzut ekranu po uwierzytelnieniu.

Zrzut ekranu przedstawiający komunikat o błędzie, gdy zasady ochrony tokenu blokują dostęp.

Powiązana zawartość

Co to jest podstawowy token odświeżania?