Przewodnik wdrażania ochrony tokenów — aplikacje internetowe (wersja zapoznawcza)

W tym przewodniku opisano kroki wymagane do wdrożenia i wymuszenia ochrony tokenów dla tokenów sesji logowania używanych przez aplikacje internetowe (oparte na przeglądarce), które uzyskują dostęp do Azure Resource Manager (ARM).

Aby zapoznać się z przeglądem Ochrony Tokenów i obsługiwanych platform, zapoznaj się z Ochrona Tokenów w Microsoft Entra w Dostępie Warunkowym. Przed rozpoczęciem korzystania z tego przewodnika wdrażania zapoznaj się z dokumentacją przeglądu.

Wymagania wstępne

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

Obsługiwane aplikacje, zasoby i przeglądarki

Aplikacje

• Azure Portal
• Centrum administracyjne Microsoft Intune
• centrum administracyjne Microsoft Entra
• Microsoft Engage Center
• Microsoft Angażowanie centrum

Obsługiwane są tylko poprzednie aplikacje internetowe. Dostęp użytkowników do innych aplikacji internetowych, które uzyskują dostęp do usługi ARM, jest blokowany , gdy zasady są wymuszane. Najważniejsze aplikacje internetowe, które uzyskują dostęp do usługi ARM, ale nie są obsługiwane , ale nie są ograniczone do następujących elementów:

• Centrum zabezpieczeń i zgodności usługi Microsoft 365
• Microsoft AppSource
• Azure Data Factory
• aplikacja Azure AI Studio
• Azure Synapse Studio
• Microsoft Power BI
• Portal deweloperów Microsoft
• Azure OpenAI Studio
• centrum administracyjne platformy Power Platform

Obsługiwane zasoby

• Azure Resource Manager (ARM) skonfigurowana w dostępie warunkowym jako zasób interfejsu API Windows Azure Service Management.

Obsługiwane platformy i przeglądarki

¹ Niektóre typy rejestracji urządzeń nie są obsługiwane. Zobacz listę nieobsługiwanych typów rejestracji urządzeń.

Włączanie ochrony tokenów dla usługi ARM w systemach Windows i macOS

Aby zminimalizować prawdopodobieństwo zakłóceń użytkownika z powodu niezgodności aplikacji, przeglądarki lub urządzenia, postępuj zgodnie z następującymi zaleceniami:

• Zacznij od grupy pilotażowej użytkowników i rozszerz się wraz z upływem czasu.
• Przed wymuszeniem należy utworzyć zasady dostępu warunkowego dla ochrony tokenów w trybie tylko do raportu .
• Przechwyć dzienniki logowania obu typów: interakcyjnego i nieinterakcyjnego.
• Przeanalizuj te dzienniki wystarczająco długo, tak aby obejmować normalne użycie aplikacji. Instrukcje dotyczące analizowania i zrozumienia wpływu na użytkownika zostały opisane w poniższych sekcjach.
• Dodaj znanych, niezawodnych użytkowników do grupy użytkowników i wymuś zasady.

Ten proces pomaga ocenić gotowość użytkowników do wymuszania ochrony tokenów.

Krok 1. Konfigurowanie urządzeń użytkowników końcowych

Wykonaj poniższe czynności na każdym urządzeniu ręcznie lub za pomocą zasad grupy lub usługi Intune.

Windows

1. Upewnij się, że urządzenie jest uruchomione Windows 11 kompilacji 26100.8246/26200.8246 lub nowszej.

2. Włącz tę wersję zapoznawcza, ustawiając następującą wartość rejestru:

   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\BrowserCore]
   "EnablePlatformAuth"=dword:00000001
   

3. Zainstaluj rozszerzenie przeglądarki Microsoft Single Sign-On:

   • Google Chrome: Zainstaluj Microsoft logowanie jednokrotne ze sklepu Chrome Web Store, wybierz pozycję Dodaj do rozszerzenia Chrome>Add i upewnij się, że jest on wyświetlany na pasku narzędzi.
   • Microsoft Edge: przejdź do edge://extensionspozycji , włącz opcję Zezwalaj na rozszerzenia z innych sklepów, zainstaluj rozszerzenie Microsoft logowania jednokrotnego i upewnij się, że jest ono włączone.

macOS

1. Zainstaluj Portal firmy firmy Microsoft lub wdróż ją za pośrednictwem rozwiązania MDM. Portal firmy służy jako broker uwierzytelniania na potrzeby logowania Microsoft Entra.
2. Włącz rejestrację z obsługą sprzętu przy użyciu jednej z następujących opcji:
   • Opcja A: Włącz wtyczkę logowania jednokrotnego Microsoft Enterprise.
   • Opcja B: Konfigurowanie logowania jednokrotnego platformy dla systemu macOS. Jednokrotne logowanie dla platformy domyślnie korzysta z magazynu opartego na sprzęcie i nie wymaga dodatkowej konfiguracji przełączników. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Konfiguracja platformy SSO dla urządzeń z systemem macOS w Microsoft Intune.
3. Zainstaluj rozszerzenie przeglądarki logowania jednokrotnego Microsoft w programie Microsoft Edge lub Google Chrome, zgodnie z opisem w poprzedniej sekcji Windows.

Czego można oczekiwać po kroku 1

Gdy urządzenie spełnia wymagania wstępne i konfigurację propagacji, żądania uwierzytelniania z obsługiwanych aplikacji i przeglądarek przestają kończone w całości w przeglądarce i są obsługiwane przez brokera uwierzytelniania platformy. To zachowanie umożliwia tym aplikacjom używanie tokenów sesji logowania powiązanego z urządzeniem, takich jak podstawowe tokeny odświeżania (PRT) i spełnianie zasad dostępu warunkowego ochrony tokenu.

Zaplanuj następujące kwestie:

• Poczekaj co najmniej 24 godziny na zastosowanie zmiany. Przejście do uwierzytelniania opartego na brokerze nie jest natychmiastowe po zastosowaniu wartości rejestru, rozszerzenia ani profilu logowania jednokrotnego platformy. Nie przenoś się do kroku 2, dopóki to okno nie przejdzie lub dane tylko do raportu nie pokazują dokładnie gotowości.
• Przejście jest automatyczne w większości przypadków. Użytkownicy zazwyczaj nie podejmują żadnych działań; istniejące sesje przeglądarki nadal działają, gdy zmiany są propagowane.
• Niektórzy użytkownicy widzą krótkie okno dialogowe logowania. Podczas korzystania z wersji zapoznawczej użytkownicy, którzy uzyskują dostęp do portalu Azure, mogą na krótko zobaczyć komunikat "Trwa logowanie... " komunikat informujący o otwarciu nowego okna. Nie zostanie wyświetlone żadne nowe okno i nie jest wymagane żadne działanie użytkownika, a logowanie zostanie ukończone samodzielnie. Opcjonalnie przekaż to zachowanie grupie pilotażowej z wyprzedzeniem, aby nie było zgłaszane jako awaria.

Krok 2. Tworzenie zasad dostępu warunkowego w trybie tylko do raportu

Po odczekaniu 24 godzin po zakończeniu kroku 1 możesz nadal ustawiać zasady w trybie tylko dla raportu, aby przejrzeć gotowość wymuszania.

1. Zaloguj się do centrum administracyjne Microsoft Entra co najmniej administrator dostępu warunkowego.
2. Przejdź do pozycji Entra ID>Zasady dostępu >warunkowego, a następnie wybierz pozycję Nowe zasady i nadaj jej nazwę.
3. W obszarze PrzypisaniaUżytkownicy dołącz użytkowników pilotażowych> lub testowych. Nie dołączaj kont awaryjnych ani kont szklenia w organizacji.
4. W obszarze Zasoby docelowe>(dawniej aplikacje w chmurze)>Uwzględnij>pozycję Wybierz zasoby, wybierz pozycję Windows Azure Interfejs API zarządzania usługami.
5. W obszarze Warunki>Platformy urządzeń ustaw wartość Konfiguruj na Tak i uwzględnij Windows, macOS lub oba te ustawienia.
6. W obszarze Warunki>Aplikacje klienckie ustaw pozycję Konfiguruj na Wartość Tak i dołącz przeglądarkę. Pamiętaj, aby nie wybierać aplikacji mobilnych i klientów klasycznych dla tej wersji zapoznawczej.
7. W obszarze Kontrola> dostępuSesja wybierz pozycję Wymagaj ochrony tokenu dla sesji logowania, a następnie wybierz pozycję Wybierz.
8. Ustaw Włącz politykę jako Tylko raportowanie i wybierz Utwórz.

Krok 3. Przegląd gotowości do wymuszania przy użyciu dzienników i metryk

Po wdrożeniu i uruchomieniu polityki zapisującej tylko raporty należy przejrzeć wpływ polityki, przeanalizować dzienniki logowania oraz zbadać z Log Analytics, aby ocenić gotowość do egzekwowania.

Dzienniki logowania

Aby wyświetlić zdarzenia logowania związane z ochroną tokenów w centrum administracyjnym:

1. Zaloguj się do centrum administracyjnego Microsoft Entra jako co najmniej Administrator Dostępu Warunkowego.
2. Przejdź do Entra ID>Monitorowanie i kondycja>Dzienniki logowań.
3. Dodaj kolumnę Token Protection — kod stanu sesji logowania do widoku, aby szybko zobaczyć powiązane zdarzenia logowania. Ponadto przefiltruj zasób Azure Resource Manager i ustaw pozycję Aplikacja kliencka na Przeglądarkę, aby odizolować żądania logowania związane z tą wersją zapoznawcza.
4. Wybierz zdarzenie logowania, które badasz.
5. Przejrzyj karty Dostęp warunkowy i Tylko raport w zależności od stanu zasad i wybierz zasady ochrony tokenu.
6. W obszarze Kontrolki sesji sprawdź, czy zostały spełnione wymagania dotyczące zasad.
7. Wybierz kartę Informacje podstawowe i sprawdź pole Ochrona tokenu — sesja logowania , aby uzyskać więcej informacji.

Dzienniki logowania zawierają właściwość wskazującą tokenProtectionStatusDetails , czy żądanie używa tokenu powiązanego z urządzeniem:

"tokenProtectionStatusDetails": {
  "signInSessionStatus": "bound | unbound",
  "signInSessionStatusCode": <code>
}

Kody stanu sesji logowania

Aby zrozumieć, dlaczego żądanie jest wyświetlane jako niezwiązane lub do określenia, do których użytkowników można zastosować zasady, zapoznaj się z następującymi kodami stanu.

Identyfikowanie użytkowników samozwańczych (tylko system macOS)

W systemie macOS kody 1003 i 1004 są samozwańcze w ramach jednorazowego uaktualnienia rejestracji urządzenia.

Aby zidentyfikować żądania zgodne lub uaktualnialne za pomocą akcji użytkownika, przefiltruj następujące elementy:

• signInSessionStatus == bound, lub
• signInSessionStatus == unbound z signInSessionStatusCode lub 10031004.

Przykładowe zapytanie Microsoft Graph dotyczące logowania nieinterakcyjnego:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=(
  signInEventTypes/any(t: t eq 'nonInteractiveUser')
  and resourceDisplayName eq 'Azure Resource Manager'
  and (tokenProtectionStatusDetails/signInSessionStatusCode eq 1003
    or tokenProtectionStatusDetails/signInSessionStatusCode eq 1004
    or tokenProtectionStatusDetails/signInSessionStatus eq 'bound'))

Gdy ochrona tokenów jest wymuszana dla tych użytkowników, zostanie wyświetlony monit o ponowne zalogowanie się i będzie mógł uzyskać dostęp do zasobów po zakończeniu uwierzytelniania.

Analiza dzienników

Można również użyć Log Analytics do wykonywania zapytań dotyczących interaktywnych i nieinterakcyjnych dzienników logowania dla żądań zablokowanych z powodu niepowodzenia wymuszania ochrony tokenu. Te zapytania są tylko przykładami i mogą ulec zmianie. Filtrują one zasoby Azure Resource Manager i dodają metryki gotowości, dzięki czemu można odróżnić bloki twarde od samodzielnych.

Żądania według aplikacji

Poniższe przykładowe zapytanie wyszukuje dzienniki logowania nieinterakcyjnego z ostatnich siedmiu dni, wyróżniając zablokowane i dozwolone żądania do usługi ARM według aplikacji oraz flagi blokujące, że użytkownicy mogą samodzielnie korygować. Zamień się, SigninLogs aby przejrzeć logowania w przeglądarce interakcyjnej.

// Select the log to query (SigninLogs or AADNonInteractiveUserSignInLogs)
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, Status, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | 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 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Users = dcount(UserPrincipalName),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true),
    BlockedUsers = dcountif(UserPrincipalName, Result == "Block"),
    BlockedUsersSelfRemediable = dcountif(UserPrincipalName, IsSelfRemediable == true)
    by AppDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project AppDisplayName, Requests, Users, Allow, Block,
    BlockSelfRemediable, BlockedUsers, BlockedUsersSelfRemediable,
    PctAllowed, PctEnforceable
| sort by Requests desc

Żądania według użytkownika

Poniższe zapytanie analizuje dzienniki logowania nieinterakcyjnego z ostatnich siedmiu dni, z wyróżnionymi zablokowanymi i dozwolonymi żądaniami do usługi ARM przez użytkownika, z tymi samymi metrykami samodzielnego korygowania i wymuszania.

// Per-user query for the Azure portal -> ARM web app scenario
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | 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 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true)
    by UserPrincipalName, AppDisplayName, ResourceDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project UserPrincipalName, AppDisplayName, ResourceDisplayName,
    Requests, Allow, Block, BlockSelfRemediable,
    PctAllowed, PctEnforceable
| sort by UserPrincipalName asc

Krok 4. Wymuszanie zasad

Po przejrzeniu danych dziennika logowania i potwierdzeniu, że docelowi użytkownicy i urządzenia są gotowi, przenieś przełącznik Włącz politykę z obszaru Tylko raport do pozycji Włącz.

Treści powiązane

• Ochrona tokenów w usłudze Dostęp warunkowy usługi Microsoft Entra
• Przewodnik wdrażania ochrony tokenów — Windows
• Przewodnik wdrażania ochrony tokenów — platformy firmy Apple
• Co to jest podstawowy token odświeżania?