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 wymuszonych kontrolach sesji i 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.
Wymagania
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
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ę znanych ograniczeń dla 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"
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 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
- 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 macierzystej dzierżawie, są obsługiwani. 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:
- Microsoft Entra dodała hosty sesji do usługi Azure Virtual Desktop.
- Urządzenia z systemem Windows wdrożone za pomocą rejestracji zbiorczej .
- Chmurowe komputery wdrożone przez Windows 365, dołączone do Microsoft Entra.
- Usługi Power Automate hostowane grupy maszyn, które są dołączone do usługi Microsoft Entra.
- Urządzenia Windows Autopilot wdrożone przy użyciu trybu samodzielnego wdrażania się .
- Maszyny wirtualne z systemem Windows wdrożone na platformie Azure przy użyciu rozszerzenia maszyny wirtualnej, które są włączone na potrzeby uwierzytelniania Microsoft Entra ID.
- Urządzenia zarejestrowane w usłudze Microsoft Entra ID w wersjach systemu Windows przed 24H2 mogą być blokowane, jeśli użytkownicy nie wykonują nowego logowania podczas rejestracji. Wersja systemu Windows 24H2 rozwiązuje ten problem, wymagając nowego logowania.
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". - Maszyny wirtualne z systemem Windows na platformie Azure, które są przyłączone do Microsoft Entra, można użyć
systemLabels -eq "AzureResource" 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 wyłącznie raportowania przed przejściem do wymuszania ochrony tokenu.
- 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.
- Zaloguj się do centrum administracyjnego Microsoft Entra jako co najmniej Administrator dostępu warunkowego.
- Przejdź do Ochrona>Dostęp Warunkowy>Zasady.
- Wybierz pozycję Nowe zasady.
- Nadaj zasadzie nazwę. Zalecamy, aby organizacje tworzyły znaczący standard dla nazw swoich zasad.
- W obszarze Przypisania wybierz pozycję Użytkownicy lub tożsamości obciążeń roboczych.
- W obszarze Uwzględnij wybierz użytkowników lub grupy, które testują te zasady.
- W obszarze Wyklucz wybierz pozycję Użytkownicy i grupy, a następnie wybierz konta awaryjne lub konta awaryjne ('break-glass') w organizacji.
- W obszarze Zasoby docelowe>(dawniej aplikacje w chmurze)> Uwzględnij>Wybierz zasoby
W obszarze Wybierz wybierz następujące aplikacje obsługiwane przez wersję zapoznawcza:
- Office 365 Exchange Online
- 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. Ta zmiana jest wyjątkiem od reguły ogólnej, że w zasadach dostępu warunkowego należy wybrać grupę aplikacji usługi Office 365.
Naciśnij przycisk Wybierz.
- W warunkach:
- W obszarze Platformy urządzeń:
- Ustaw pozycję Konfiguruj na Wartość Tak.
- Uwzględnij>Wybierz platformy urządzeń>Windows.
- Wybierz pozycję Gotowe.
- W obszarze Aplikacje klienckie:
Ustaw pozycję Konfiguruj na Wartość Tak.
Ostrzeżenie
Brak skonfigurowania warunku Aplikacje klienckie lub pozostawienie opcji Browser zaznaczonej może spowodować zablokowanie aplikacji korzystających z MSAL.js, takich jak Teams Web.
W ustawieniach nowoczesnego uwierzytelniania wybierz opcję Aplikacje mobilne i klienci komputerowi. Pozostaw inne elementy niezaznaczone.
Wybierz pozycję Gotowe.
- W obszarze Platformy urządzeń:
- W obszarze Kontrole dostępu>Sesja, wybierz opcję Wymagaj ochrony tokenu dla sesji logowania i kliknij Wybierz.
- Potwierdź swoje ustawienia i ustaw opcję Włącz politykę na Tylko raportowanie.
- Wybierz pozycję Utwórz, aby włączyć swoją zasadę.
Po potwierdzeniu przez administratorów ustawień w trybie raportowania, mogą przenieść przełącznik Włączanie polityki z trybu Tylko raport do pozycji 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 tokenów przez Dostęp Warunkowy przed i po wdrożeniu, 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.
- Zaloguj się do centrum administracyjnego Microsoft Entra jako co najmniej Administrator dostępu warunkowego.
- Przejdź do Tożsamość>Monitorowanie i kondycja>Dzienniki logowania.
- Wybierz określone żądanie, aby określić, czy zasady są stosowane, czy nie.
- Przejdź do okienka Dostęp warunkowy lub Tylko raportowanie, w zależności od stanu, i wybierz nazwę zasad wymagających ochrony tokenu.
- W obszarze Kontrolki sesji sprawdź, czy wymagania dotyczące zasad zostały spełnione.
- Aby uzyskać więcej informacji na temat stanu powiązania żądania, wybierz okienko Podstawowe Informacje i zobacz pole Ochrona tokenów -Sesja logowania. Możliwe wartości to:
- 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.
- Niezawiązane: żądanie nie używało powiązanych protokołów. Możliwe
statusCodes, gdy żądanie jest niezwiązane:- 1002: Żądanie jest niezwiązane z powodu braku stanu urządzenia Microsoft Entra ID.
- 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.
- 1005: Żądanie jest niezwiązane z innych nieokreślonych powodów.
- 1006: Żądanie jest niezwiązane, ponieważ wersja systemu operacyjnego nie jest obsługiwana.
- 1008: Żądanie jest niezwiązane, ponieważ klient nie jest zintegrowany z brokerem platformy, takim jak Menedżer kont systemu Windows (WAM).
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 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:
Poniższy przykład zapytania analizuje dziennik logowania nieinterakcyjnego z ostatnich siedmiu dni, podkreślając różnicę między Zablokowane a 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
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