Villkorlig åtkomst: Tokenskydd (förhandsversion)

Tokenskydd (kallas ibland tokenbindning i branschen) försöker minska attacker med tokenstöld genom att se till att en token endast kan användas från den avsedda enheten. När en angripare kan stjäla en token genom att kapa eller spela upp igen kan de personifiera sitt offer tills token upphör att gälla eller återkallas. Tokenstöld tros vara en relativt sällsynt händelse, men skadan från den kan vara betydande.

Tokenskydd skapar en kryptografiskt säker koppling mellan token och den enhet (klienthemlighet) som den utfärdas till. Utan klienthemligheten är den bundna token värdelös. När en användare registrerar en Windows 10- eller senare enhet i Microsoft Entra-ID är deras primära identitet bunden till enheten. Vad detta innebär: En princip kan se till att endast bundna inloggningssessionstoken (eller uppdateringstoken), även kallade primära uppdateringstoken (PRT) används av program när de begär åtkomst till en resurs.

Viktigt!

Tokenskydd är för närvarande i offentlig förhandsversion. Mer information om förhandsversioner finns i Universella licensvillkor för onlinetjänster. Med den här förhandsversionen ger vi dig möjlighet att skapa en princip för villkorlig åtkomst för att kräva tokenskydd för inloggningstoken (uppdateringstoken) för specifika tjänster. Vi stöder tokenskydd för inloggningstoken i villkorlig åtkomst för skrivbordsprogram som har åtkomst till Exchange Online och SharePoint Online på Windows-enheter.

Viktigt!

Följande ändringar har gjorts i Token Protection sedan den första versionen av den offentliga förhandsversionen:

• Utdata för inloggningsloggar: Värdet för strängen som används i "enforcedSessionControls" och "sessionControlsNotSatisfied" ändrades från "Bindning" till "SignInTokenProtection" i slutet av juni 2023. Frågor om inloggningsloggdata bör uppdateras för att återspegla den här ändringen.

Kommentar

Vi kan utbyta inloggningstoken och uppdateringstoken i det här innehållet. Om du vill skydda Microsoft 365-åtkomsttoken och cookies för programsessioner bör du överväga att prova efterlevnad av nätverkskontrollen.

Krav

Den här förhandsversionen stöder följande konfigurationer för åtkomst till resurser med principer för villkorlig åtkomst för Token Protection:

• Windows 10- eller senare enheter som är Microsoft Entra-anslutna, Microsoft Entra-hybridanslutningar eller Microsoft Entra-registrerade.
• OneDrive-synkronisering klientversion 22.217 eller senare
• Teams interna klientversion 1.6.00.1331 eller senare
• Power BI Desktop version 2.117.841.0 (maj 2023) eller senare
• Visual Studio 2022 eller senare när du använder inloggningsalternativet "Windows-autentiseringskoordinator"
• Office Perpetual-klienter stöds inte

Kända begränsningar

• Externa användare (Microsoft Entra B2B) stöds inte och bör inte ingå i principen för villkorsstyrd åtkomst.
• Följande program stöder inte inloggning med hjälp av skyddade tokenflöden och användare blockeras vid åtkomst till Exchange och SharePoint:
  • PowerShell-moduler som har åtkomst till Exchange-, SharePoint- eller Microsoft Graph-omfång som hanteras av Exchange eller SharePoint
  • PowerQuery-tillägg för Excel
  • Tillägg till Visual Studio Code som har åtkomst till Exchange eller SharePoint
  • Den nya förhandsversionsklienten för Teams 2.1 blockeras efter utloggning på grund av en bugg. Den här buggen bör åtgärdas i en framtida tjänstuppdatering.
• Följande Windows-klientenheter stöds inte:
  • Windows Server
  • Surface Hub
  • Windows-baserade Microsoft Teams Rum-system (MTR)

Licensieringskrav

För att använda den här funktionen krävs Microsoft Entra ID P2-licenser. Hitta rätt licens för dina behov i Jämför allmänt tillgängliga funktioner i Microsoft Entra ID.

Kommentar

Token Protection-tillämpning är en del av Microsoft Entra ID Protection och kommer att ingå i P2-licensen vid allmän tillgänglighet.

Distribution

För användare bör distributionen av en princip för villkorsstyrd åtkomst för att framtvinga tokenskydd vara osynlig när kompatibla klientplattformar används på registrerade enheter och kompatibla program.

För att minimera sannolikheten för användarstörningar på grund av att appen eller enheten är inkompatibel rekommenderar vi starkt:

• Börja med en pilotgrupp med användare och expandera med tiden.
• Skapa en princip för villkorsstyrd åtkomst i rapportläge innan du övergår till tillämpning av tokenskydd.
• Samla in loggar för både interaktiv och icke-interaktiv inloggning.
• Analysera loggarna tillräckligt länge för att täcka normal programanvändning.
• Lägg till kända bra användare i en tvingande princip.

Den här processen hjälper till att utvärdera användarnas klient- och appkompatibilitet för tokenskyddsframtvingande.

Skapa en princip för villkorsstyrd åtkomst

Användare som utför specialiserade roller som de som beskrivs i Säkerhetsnivåer för privilegierad åtkomst är möjliga mål för den här funktionen. Vi rekommenderar att du pilottestar med en liten delmängd för att börja.

Stegen som följer hjälper dig att skapa en princip för villkorlig åtkomst för att kräva tokenskydd för Exchange Online och SharePoint Online på Windows-enheter.

1. Logga in på Microsoft Entra admincenter som administratör för villkorsstyrd åtkomst.
2. Bläddra till Skyddsprinciper> för villkorsstyrd åtkomst.>
3. Välj Ny princip.
4. Ge principen ett namn. Vi rekommenderar att organisationer skapar en meningsfull standard för namnen på sina principer.
5. Under Tilldelningar väljer du Användare eller arbetsbelastningsidentiteter.
   1. Under Inkludera väljer du de användare eller grupper som testar den här principen.
   2. Under Exkludera väljer du Användare och grupper och väljer organisationens konton för nödåtkomst eller break-glass.
6. Under Målresurser>Resurser (tidigare molnappar)>Inkludera>Välj resurser

   1. Under Välj väljer du följande program som stöds av förhandsversionen:

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

      Varning

      Principen för villkorsstyrd åtkomst bör endast konfigureras för dessa program. Om du väljer Office 365-programgruppen kan det leda till oavsiktliga fel. Det här är ett undantag från den allmänna regeln att Office 365-programgruppen ska väljas i en princip för villkorsstyrd åtkomst.

   2. Välj Välj.

7. Under förhållanden:
   1. Under Enhetsplattformar:
      1. Ställ in Konfigurera på Ja.
      2. Inkludera>Välj enhetsplattformar>Windows.
      3. Välj Klar.
   2. Under Klientappar:
      1. Ställ in Konfigurera på Ja.

         Varning

         Om du inte konfigurerar villkoret Klientappar eller om webbläsaren är vald kan det leda till att program som använder MSAL.js, till exempel Teams Web, blockeras.

      2. Under Moderna autentiseringsklienter väljer du endast Mobilappar och skrivbordsklienter. Lämna andra objekt avmarkerade.
      3. Välj Klar.
8. Under Åtkomstkontroller>Session väljer du Kräv tokenskydd för inloggningssessioner och väljer Välj.
9. Bekräfta inställningarna och ange Aktivera princip till Endast rapport.
10. Välj Skapa för att skapa för att aktivera principen.

När administratörerna har bekräftat inställningarna med läget endast rapport kan de flytta växlingsknappen Aktivera princip från Endast rapport till På.

Samla in loggar och analysera

Övervakning av tillämpning av villkorlig åtkomst av tokenskydd före och efter tillämpning.

Inloggningsloggar

Använd Inloggningsloggen för Microsoft Entra för att verifiera resultatet av en princip för tvingande tokenskydd i rapportläge eller i aktiverat läge.

1. Logga in på Microsoft Entra admincenter som administratör för villkorsstyrd åtkomst.
2. Bläddra till Loggar för identitetsövervakning>och hälsoinloggning.>
3. Välj en specifik begäran för att avgöra om principen tillämpas eller inte.
4. Gå till fönstret Villkorlig åtkomst eller Endast rapport beroende på dess tillstånd och välj namnet på principen som kräver tokenskydd.
5. Under Sessionskontroller kontrollerar du om principkraven var uppfyllda eller inte.

Log Analytics

Du kan också använda Log Analytics för att fråga inloggningsloggarna (interaktiva och icke-interaktiva) om blockerade begäranden på grund av tokenskyddsfel.

Här är ett exempel på en Log Analytics-fråga som söker i loggarna för icke-interaktiv inloggning under de senaste sju dagarna och som markerar Blockerade och Tillåtna begäranden av programmet. Dessa frågor är bara exempel och kan komma att ändras.

Kommentar

Utdata för inloggningsloggar: Värdet för strängen som används i "enforcedSessionControls" och "sessionControlsNotSatisfied" ändrades från "Bindning" till "SignInTokenProtection" i slutet av juni 2023. Frågor om inloggningsloggdata bör uppdateras för att återspegla den här ändringen. Exemplen omfattar båda värdena för att inkludera historiska data.

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

Resultatet av föregående fråga bör likna följande skärmbild:

I följande frågeexempel tittar vi på den icke-interaktiva inloggningsloggen för de senaste sju dagarna och markerar Blockerad jämfört med Tillåtna begäranden av användare.

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

Nästa steg

• Vad är en primär uppdateringstoken?