Guida alla distribuzione di Token Protection - App Web (anteprima)

Questa guida illustra i passaggi necessari per distribuire e applicare La protezione dei token per i token di sessione di accesso usati dalle applicazioni Web (basate su browser) che accedono a Azure Resource Manager (ARM).

Per una panoramica della protezione dei token e delle piattaforme supportate, vedere Token Protection in Microsoft Entra Accesso condizionale. Esaminare la documentazione di panoramica prima di usare questa guida alla distribuzione.

Prerequisiti

L'uso di questa funzionalità richiede licenze Microsoft Entra ID P1. Per trovare la licenza appropriata per le tue esigenze, vedere Confronta le funzionalità disponibili a livello generale di Microsoft Entra ID.

Applicazioni, risorse e browser supportati

Applications

• Azure portal
• Interfaccia di amministrazione di Microsoft Intune
• Interfaccia di amministrazione di Microsoft Entra
• Microsoft Engage Center
• Microsoft Engage Hub

Sono supportate solo le applicazioni Web precedenti. L'accesso degli utenti ad altre applicazioni Web che accedono ad ARM viene bloccato quando vengono applicati i criteri. Le principali applicazioni Web che accedono ad ARM ma non sono supportate includono, ma non sono limitate a:

• Centro protezione e conformità di Microsoft 365
• Microsoft AppSource
• Azure Data Factory
• app Azure AI Studio
• Azure Synapse Studio
• Microsoft Power BI
• portale per sviluppatori Microsoft
• Azure OpenAI Studio
• Interfaccia di amministrazione di Power Platform

Risorse supportate

• Azure Resource Manager (ARM), configurato in Accesso condizionale come risorsa API di gestione dei servizi Windows Azure.

Piattaforme e browser supportati

¹ Alcuni tipi di registrazione del dispositivo non sono supportati. Vedere l'elenco dei tipi di registrazione dei dispositivi non supportati.

Abilitare la protezione dei token per ARM in Windows e macOS

Per ridurre al minimo la probabilità di interruzione dell'utente a causa di incompatibilità tra app, browser o dispositivo, seguire queste raccomandazioni:

• Iniziare con un gruppo pilota di utenti ed espandersi nel tempo.
• Creare un criterio di accesso condizionale per La protezione token in modalità solo report prima di applicarlo.
• Acquisire registri di accesso interattivi e non interattivi.
• Analizzare questi log abbastanza a lungo per coprire l'uso normale dell'applicazione. Le istruzioni per l'analisi e la comprensione dell'impatto dell'utente sono descritte nelle sezioni seguenti.
• Aggiungere utenti noti e affidabili a un gruppo di utenti e applicare i criteri.

Questo processo consente di valutare l'idoneità degli utenti per l'applicazione della protezione dei token.

Passaggio 1: Configurare i dispositivi degli utenti finali

Completare le operazioni seguenti in ogni dispositivo manualmente o tramite Criteri di gruppo o Intune.

Windows

1. Assicurarsi che il dispositivo venga eseguito Windows 11 build 26100.8246 / 26200.8246 o versione successiva.

2. Abilitare questa anteprima impostando il valore del Registro di sistema seguente:

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

3. Installare l'estensione del browser single Sign-On Microsoft:

   • Google Chrome: Installare Microsoft Single Sign-On da Chrome Web Store, selezionare Aggiungi a Chrome>Aggiungi estensione e verificare che venga visualizzato sulla barra degli strumenti.
   • Microsoft Edge: passare a edge://extensions, attivare Consenti estensioni da altri archivi, installare l'estensione single sign-on Microsoft e verificare che sia abilitata.

macOS

1. Installare Microsoft Portale aziendale o distribuirlo tramite la soluzione MDM. Portale aziendale funge da gestore di autenticazione per gli accessi Microsoft Entra.
2. Abilitare la registrazione supportata dall'hardware usando una delle opzioni seguenti:
   • Opzione A: Abilitare il plug-in SSO di Microsoft Enterprise.
   • Opzione B: Configurare l'accesso Single Sign-On di Platform per macOS. L'SSO della piattaforma utilizza l'archiviazione supportata dall'hardware per impostazione predefinita e non richiede alcuna configurazione aggiuntiva dei flag. Per istruzioni sulla configurazione, vedere Configurare l'accesso Single Sign-On della piattaforma per i dispositivi macOS in Microsoft Intune.
3. Installare l'estensione del browser Single Sign-On Microsoft in Microsoft Edge o Google Chrome, come descritto nella sezione Windows precedente.

Cosa aspettarsi dopo il passaggio 1

Una volta che il dispositivo soddisfa i prerequisiti e la configurazione si propaga, le richieste di autenticazione provenienti da applicazioni e browser supportati interrompono completamente il completamento all'interno del browser e vengono invece gestite dal broker di autenticazione della piattaforma. Questo comportamento consente alle applicazioni di usare token di sessione di accesso associati a dispositivo, ad esempio token di aggiornamento primario (PRT) e soddisfare i criteri di accesso condizionale di Protezione token.

Pianificare quanto segue:

• Attendere almeno 24 ore per rendere effettiva la modifica. Il passaggio all'autenticazione basata su broker non è immediato dopo l'applicazione del valore del Registro di sistema, dell'estensione o del profilo SSO della piattaforma. Non passare al passaggio 2 fino al passaggio 2 o i dati solo del report non mostrano accuratamente l'idoneità.
• La transizione è automatica nella maggior parte dei casi. Gli utenti in genere non esegino alcuna azione; le sessioni del browser esistenti continuano a funzionare durante la propagazione della modifica.
• Alcuni utenti visualizzano una breve finestra di dialogo di accesso. Durante l'anteprima, gli utenti che accedono al portale di Azure potrebbero visualizzare brevemente un messaggio "Accesso in corso... " messaggio che informa che viene aperta una nuova finestra. Non viene visualizzata alcuna nuova finestra e non è necessaria alcuna azione dell'utente e l'accesso viene completato autonomamente. Facoltativamente, comunicare questo comportamento al gruppo pilota in anticipo in modo che non venga segnalato come errore.

Passaggio 2: Creare i criteri di accesso condizionale in modalità solo report

Dopo aver atteso 24 ore dopo aver completato il passaggio 1, è possibile continuare a impostare un criterio in modalità di sola report per verificare l'idoneità per l'applicazione.

1. Accedere al Interfaccia di amministrazione di Microsoft Entra almeno come amministratore dell'accesso condizionale.
2. Passare a Entra ID>Criteri di accesso> condizionale, quindi selezionare Nuovo criterio e assegnare un nome.
3. In Assegnazioni>Utenti includere gli utenti pilota o di test. Non includere l'accesso di emergenza o gli account break-glass dell'organizzazione.
4. In Risorse> di destinazione(in precedenza app cloud)>Includi>risorse selezionare Selezionare le risorse selezionare Windows Azure API di gestione dei servizi.
5. In Condizioni>Piattaforme del dispositivo impostare Configura su Sì e includere Windows, macOS o entrambi.
6. In Condizioni>App client impostare Configura su Sì e includere Browser. Assicurarsi di non selezionare App per dispositivi mobili e client desktop per questa anteprima.
7. In Controlli di> accessoSessione selezionare Richiedi protezione token per le sessioni di accesso e quindi selezionare Seleziona.
8. Impostare Abilita criteri su Solo Report e selezionare Crea.

Passaggio 3: Esaminare l'idoneità per l'imposizione con log e metriche

Dopo che la politica in modalità solo report è attiva, è necessario esaminare l'impatto della Policy, analizzare i log di sign-in ed effettuare un'indagine con Log Analytics per valutare la prontezza all'applicazione.

Log di registrazione

Per visualizzare gli eventi di accesso correlati a Token Protection nell'interfaccia di amministrazione:

1. Accedi al Centro Amministrativo Microsoft Entra come almeno un Amministratore di Accesso Condizionale .
2. Passare a Entra ID>Monitoraggio e integrità>Registri degli accessi.
3. Aggiungere la colonna Token Protection - Codice di stato della sessione di accesso alla visualizzazione per visualizzare rapidamente gli eventi di accesso correlati. Filtrare anche la risorsa Azure Resource Manager e impostare App client su Browser per isolare le richieste di accesso correlate a questa anteprima.
4. Seleziona l'evento di accesso che stai esaminando.
5. Esaminare le schede Accesso condizionale e Solo report , a seconda dello stato dei criteri e selezionare i criteri di protezione dei token.
6. In Controlli sessione verificare se i requisiti dei criteri sono stati soddisfatti.
7. Selezionare la scheda Informazioni di base e selezionare il campo Token Protection - Sessione di accesso per altre informazioni.

I log di accesso includono una tokenProtectionStatusDetails proprietà che indica se una richiesta usa un token associato al dispositivo:

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

Codici di stato della sessione di accesso

Per comprendere il motivo per cui una richiesta viene visualizzata come non associato o per identificare gli utenti a cui è possibile applicare i criteri, fare riferimento ai codici di stato seguenti.

Identificare gli utenti automediabili (solo macOS)

In macOS, i codici 1003 e 1004 sono automediabili tramite un aggiornamento della registrazione di un dispositivo monouso.

Per identificare le richieste conformi o aggiornabili con l'azione dell'utente, filtrare per:

• signInSessionStatus == bound o
• signInSessionStatus == unbound con signInSessionStatusCode o 10031004.

Query di esempio Microsoft Graph per gli accessi non interattivi:

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'))

Quando viene applicata la protezione dei token per questi utenti, viene richiesto di accedere di nuovo e di accedere alle risorse al termine dell'autenticazione.

Log Analytics

È anche possibile usare Log Analytics per eseguire query sui log di accesso interattivi e non interattivi per le richieste bloccate a causa di un errore di imposizione di Token Protection. Queste query sono solo esempi e sono soggette a modifiche. Filtrano la risorsa Azure Resource Manager e aggiungono metriche di idoneità in modo da distinguere i blocchi rigidi da quelli automediabili.

Richieste per ogni applicazione

La query di esempio seguente cerca i log di accesso non interattivi per gli ultimi sette giorni, evidenziando le richieste bloccate rispetto alle richieste consentite ad ARM per applicazione e contrassegnando blocchi che gli utenti possono correggere automaticamente. Scambiarsi SigninLogs per esaminare invece gli accessi interattivi del browser.

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

Richieste da parte dell'utente

La query seguente esamina i log di accesso non interattivi per gli ultimi sette giorni, evidenziando le richieste bloccate rispetto alle richieste consentite ad ARM da parte dell'utente, con le stesse metriche automediabili e applicabili.

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

Passaggio 4: Applicare i criteri

Dopo aver esaminato i dati di log di accesso e aver verificato che gli utenti e i dispositivi di destinazione siano pronti, spostare l'interruttore Abilita criterio da Solo reportistica a Attivato.

Contenuti correlati

• Protezione dei token in Accesso condizionale di Microsoft Entra
• Guida alla distribuzione di Token Protection - Windows
• Guida alla distribuzione di Token Protection - Piattaforme Apple
• Che cos'è un token di aggiornamento primario?