Controlli di sessione di accesso condizionale, frequenza di accesso, posizioni denominate: cosa revoca davvero un token attivo

Controlli di sessione di accesso condizionale, frequenza di accesso, posizioni denominate: cosa controlla davvero ciascuno

Se hai cercato controlli di sessione di accesso condizionale frequenza di accesso posizioni denominate, quasi certamente stai inseguendo una sola domanda: inasprire un controllo di sessione espelle davvero chi ha già una sessione attiva? La risposta breve è no. Un controllo di sessione descrive ciò che accade la prossima volta che Microsoft Entra ID valuta la sessione — non va a recuperare un token di accesso già emesso per revocarlo retroattivamente.

La documentazione di riferimento sui controlli di sessione di Microsoft ne elenca otto: restrizioni applicate dall'app, controllo delle applicazioni di accesso condizionale, frequenza di accesso, sessione del browser persistente, personalizzazione della valutazione continua dell'accesso, disattivazione delle impostazioni predefinite di resilienza, richiesta di protezione del token per le sessioni di accesso, e utilizzo del profilo di sicurezza Global Secure Access. Due di questi — la frequenza di accesso e la sessione del browser persistente — si comportano nel tempo in modi documentati in una pagina separata, i criteri di durata della sessione adattivi, dove Microsoft afferma anche che «l'accesso condizionale è una funzionalità di Microsoft Entra ID P1 o P2 che richiede una licenza premium».

Se controlli queste impostazioni tramite Microsoft Graph anziché il portale, la visione è ancora più ristretta. La risorsa v1.0 conditionalAccessSessionControls espone esattamente cinque proprietà — applicationEnforcedRestrictions, cloudAppSecurity, disableResilienceDefaults, persistentBrowser, signInFrequency — quindi uno script che enumera i controlli di sessione v1.0 non vedrà affatto la protezione del token né l'interruttore CAE.

L'impostazione predefinita è più permissiva di quanto la maggior parte degli amministratori presuma. Microsoft afferma chiaramente: «La configurazione predefinita di Microsoft Entra ID per la frequenza di accesso dell'utente è una finestra mobile di 90 giorni». La motivazione è esplicita — «non chiedere agli utenti di fornire le proprie credenziali se il livello di sicurezza delle loro sessioni non è cambiato».

Come funziona: quando un criterio viene effettivamente valutato

Questa è la frase che governa tutto il resto. Dalla documentazione sui segnali di rete di Microsoft:

I criteri di accesso condizionale vengono valutati quando: un utente accede inizialmente a un'app Web, un'applicazione mobile o desktop. Un'applicazione mobile o desktop che usa l'autenticazione moderna utilizza un token di aggiornamento per acquisire un nuovo token di accesso. Per impostazione predefinita, questo controllo si verifica una volta all'ora.

E, per i browser: «per le applicazioni Web, i criteri si applicano all'accesso iniziale e restano validi per l'intera durata della sessione nell'applicazione Web». Microsoft aggiunge la conseguenza pratica: «Per impostazione predefinita, Microsoft Entra ID emette i token ogni ora. Dopo che gli utenti lasciano la rete aziendale, entro un'ora il criterio viene applicato per le applicazioni che usano l'autenticazione moderna».

Un criterio di posizione è quindi un controllo al momento del rinnovo, non un innesco in tempo reale — a meno che non entri in gioco la valutazione continua dell'accesso.

Frequenza di accesso, inclusa l'opzione «Ogni volta»

La frequenza di accesso «specifica per quanto tempo un utente può accedere a una risorsa prima che gli venga chiesto di accedere di nuovo». Scegliere Ogni volta non significa in modo continuo. Microsoft: «Quando selezioni Ogni volta, il criterio richiede una riautenticazione completa quando la sessione viene valutata. Questo requisito significa che se l'utente chiude e riapre il browser durante la durata della sessione, potrebbe non essergli richiesta la riautenticazione». Il controllo «tiene conto anche di cinque minuti di sfasamento dell'orologio quando è selezionato ogni volta, in modo da non richiedere l'accesso agli utenti più di una volta ogni cinque minuti».

L'applicazione viene anche differita per tutto ciò che non è interattivo: «Se l'app client (nei dettagli dell'attività) è un browser, il sistema differisce l'applicazione della frequenza di accesso di eventi e criteri sui servizi in background fino alla successiva interazione dell'utente. Sui client riservati, il sistema differisce l'applicazione della frequenza di accesso sugli accessi non interattivi fino al successivo accesso interattivo».

Sui dispositivi aggiunti esiste un secondo orologio: «sbloccare il dispositivo o accedere in modo interattivo aggiorna il Primary Refresh Token (PRT) ogni quattro ore». L'esempio pratico di Microsoft mostra un criterio SIF di un'ora che richiede l'accesso all'utente alle 05:45 — cinque ore e 45 minuti dopo l'accesso iniziale delle 00:00 — perché il PRT è stato aggiornato alle 04:45.

La valutazione continua dell'accesso è ciò che revoca davvero

La valutazione continua dell'accesso (CAE) è ciò che trasforma un criterio in una revoca quasi in tempo reale, e lo fa per un elenco chiuso di eventi critici: un account utente viene eliminato o disabilitato; una password viene modificata o reimpostata; l'MFA viene abilitato per l'utente; un amministratore revoca esplicitamente tutti i token di aggiornamento; viene rilevato un rischio utente elevato da ID Protection. La latenza dichiarata da Microsoft: «l'obiettivo per la valutazione degli eventi critici è una risposta quasi in tempo reale, ma è possibile osservare una latenza fino a 15 minuti a causa del tempo di propagazione dell'evento; tuttavia, l'applicazione del criterio sulle posizioni IP è istantanea».

Il compromesso sono token più lunghi: «la durata del token aumenta fino a una durata prolungata, fino a 28 ore, nelle sessioni CAE». Senza client compatibili con CAE, «la durata predefinita del token di accesso rimane di 1 ora». E, aspetto cruciale per questo articolo: «la frequenza di accesso viene rispettata con o senza CAE».

Il divario: dove un token attivo sopravvive al tuo criterio

1. Le posizioni denominate basate sul paese sono invisibili per CAE

Questa è la riga di maggior valore in tutta la documentazione CAE:

CAE ha visibilità solo sulle posizioni denominate basate su IP. CAE non ha visibilità su altre condizioni di posizione come gli IP attendibili MFA o le posizioni basate su paese/regione. Quando un utente proviene da un IP attendibile MFA, da una posizione attendibile che include IP attendibili MFA, o da una posizione paese/regione, CAE non verrà applicato dopo che l'utente si sposta in una posizione diversa. In questi casi, Microsoft Entra emette un token di accesso di un'ora senza controllo istantaneo di applicazione IP.

Un criterio «blocca l'accesso al di fuori di questi paesi» riporta quindi il tenant al modello orario precedente a CAE. L'indicazione di Microsoft è inequivocabile: «Non usare le condizioni di posizione paese/regione né la funzionalità IP attendibili disponibile nella pagina delle impostazioni del servizio di autenticazione a più fattori di Microsoft Entra».

2. Troppi intervalli IP disattivano silenziosamente l'applicazione della posizione in tempo reale

«Quando la somma di tutti gli intervalli IP specificati nei criteri di posizione supera 5.000, CAE non può applicare in tempo reale il flusso di cambio posizione dell'utente. In questo caso, Microsoft Entra emette un token CAE di un'ora». La soglia è a livello di tenant — la somma su tutti i criteri di posizione, non un limite per criterio — quindi viene superata per accumulo e non per una singola modifica. Si degrada solo l'applicazione della posizione: «CAE continua ad applicare tutti gli altri eventi e criteri, ad eccezione degli eventi di cambio posizione del client». Anche i limiti strutturali sono finiti: non più di 195 posizioni denominate, non più di 2.000 intervalli IP per posizione denominata, e solo maschere CIDR maggiori di /8.

3. I percorsi di uscita divisi attivano l'eccezione di variazione IP

Quando l'IP visto da Entra e l'IP visto dal resource provider differiscono — proxy, VPN split-tunnel, SD-WAN, SNAT, IPv6 — «Microsoft Entra interpreta che il client si trova ancora in una posizione consentita e che debba essere concesso l'accesso. Pertanto, Microsoft Entra emette un token di un'ora che sospende i controlli dell'indirizzo IP presso la risorsa fino alla scadenza del token». Questa è la modalità standard, attiva per impostazione predefinita. L'alternativa più rigorosa di Microsoft, che la sua pagina CAE etichetta ancora come Public Preview, è l'applicazione rigorosa della posizione: «interrompere immediatamente l'accesso se l'indirizzo IP rilevato dal resource provider non è consentito dal criterio di accesso condizionale».

4. I cookie del browser persistente sopravvivono al criterio

L'avviso di Microsoft sulla persistenza è diretto: «Nei browser persistenti, i cookie rimangono memorizzati sul dispositivo dell'utente anche dopo la chiusura del browser. Questi cookie potrebbero accedere agli artefatti di Microsoft Entra, che rimangono utilizzabili fino alla scadenza del token, indipendentemente dai criteri di accesso condizionale applicati all'ambiente della risorsa». Un proxy adversary-in-the-middle che raccoglie quel cookie eredita esattamente questa proprietà — vedi replay dei token AiTM e rilevamento di viaggi impossibili in Entra ID e phishing con device code per capire come avviene il furto in primo luogo.

5. La condizione della piattaforma del dispositivo è un input non verificato

«L'accesso condizionale identifica la piattaforma del dispositivo usando le informazioni fornite dal dispositivo, come le stringhe user agent. Poiché le stringhe user agent possono essere modificate, questa informazione non è verificata». Una condizione di piattaforma è un meccanismo di ambito, non un controllo di autenticazione. La raccomandazione di Microsoft è di usarla «insieme ai criteri di conformità dei dispositivi di Microsoft Intune o come parte di un'istruzione di blocco».

6. Le modifiche ai criteri non si applicano retroattivamente

«Le modifiche apportate dagli amministratori ai criteri di accesso condizionale e all'appartenenza ai gruppi possono richiedere fino a un giorno per diventare effettive… Viene eseguita una certa ottimizzazione per gli aggiornamenti dei criteri, che riduce il ritardo a due ore». Inasprire un criterio dopo un incidente non espelle le sessioni già esistenti. Vale la pena citare altri due punti ciechi: «CAE non supporta gli account utente guest», e «Teams è composto da più servizi; i servizi di chiamate e chat non rispettano i criteri di accesso condizionale basati su IP».

Rilevamento

Inizia dalla configurazione, poi passa alla telemetria.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All'

# Policies with no session controls at all, and those relying on country locations
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State,
        @{n='SessionControls';e={ $_.SessionControls | ConvertTo-Json -Depth 4 -Compress }},
        @{n='Locations';e={ $_.Conditions.Locations | ConvertTo-Json -Depth 3 -Compress }}

# Named locations: which are IP-based (CAE-visible) and which are trusted
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object Id, DisplayName, AdditionalProperties

Entrambi i cmdlet richiedono solo Policy.Read.All; Microsoft cita Global Reader, Security Reader, Security Administrator e Conditional Access Administrator tra i ruoli con privilegi minimi per queste letture. Le chiamate REST equivalenti sono GET /identity/conditionalAccess/policies e GET /identity/conditionalAccess/namedLocations.

Nella risposta di Graph, una posizione basata su IP è di tipo #microsoft.graph.ipNamedLocation con isTrusted e ipRanges[].cidrAddress; una posizione paese è di tipo #microsoft.graph.countryNamedLocation con countriesAndRegions e includeUnknownCountriesAndRegions. Solo il primo tipo viene applicato dal vivo da CAE. Un controllo del browser persistente appare come persistentBrowser con un mode pari a always o never, e la frequenza di accesso come signInFrequency con un frequencyInterval pari a timeBased o everyTime.

La tabella SigninLogs di Azure Monitor contiene tutte queste informazioni. Una query di partenza per il problema del percorso diviso:

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(IPAddressFromResourceProvider)
| where IPAddressFromResourceProvider != IPAddress
| summarize Sessions = count(),
            Users = dcount(UserPrincipalName)
        by AppDisplayName, IPAddress, IPAddressFromResourceProvider, ConditionalAccessStatus
| order by Sessions desc

La documentazione di riferimento sulla tabella SigninLogs di Microsoft descrive IPAddressFromResourceProvider come «l'indirizzo IP usato da un utente per raggiungere un resource provider, utilizzato per determinare la conformità dell'accesso condizionale per alcuni criteri… Questo valore è spesso nullo» — nullo è il caso sano, il che significa che entrambe le visualizzazioni concordano. Il suo equivalente nel portale è la colonna Indirizzo IP (visto dalla risorsa) nei log di accesso, e Microsoft fornisce un modello di cartella di lavoro pubblico, Continuous Access Evaluation Insights, per far emergere le stesse discrepanze.

Correzione

1. Converti le posizioni critiche per l'applicazione in posizioni denominate basate su IP. Microsoft: «Se vuoi che i tuoi criteri di posizione vengano applicati in tempo reale dalla valutazione continua dell'accesso, usa solo la condizione di posizione di accesso condizionale basata su IP e configura tutti gli indirizzi IP, inclusi sia IPv4 sia IPv6, visibili dal tuo provider di identità e dal tuo resource provider». Mantieni le posizioni per paese solo per il blocco generico, e ricorda che una posizione contrassegnata come attendibile «non può essere eliminata senza prima rimuovere la designazione attendibile».

2. Enumera ogni IP di uscita — entrambe le visualizzazioni. Includi gli indirizzi visti da Entra all'autenticazione e gli indirizzi visti da Exchange Online, SharePoint Online, Teams e Microsoft Graph. Non gonfiare l'elenco: «Non aggiungere IP di uscita non dedicati o non enumerabili alle regole di accesso condizionale delle posizioni denominate attendibili, poiché può indebolire la sicurezza». Mantieni il totale a livello di tenant sotto i 5.000 intervalli.

3. Correggi correttamente il punto cieco del proxy. Con un proxy cloud o una VPN, «l'indirizzo IP che Microsoft Entra ID usa durante la valutazione di un criterio è l'indirizzo IP del proxy. L'intestazione X-Forwarded-For (XFF)… non viene usata perché non c'è alcuna convalida che provenga da una fonte attendibile». Microsoft consiglia il ripristino dell'IP di origine di Global Secure Access, oppure un controllo basato sul dispositivo anziché un elenco di IP.

4. Solo a quel punto valuta l'applicazione rigorosa della posizione. Convalida prima con la cartella di lavoro CAE e il filtro Indirizzo IP (visto dalla risorsa). L'avvertenza di Microsoft: «Se il traffico verso Microsoft Entra ID o una risorsa supportata da CAE passa attraverso un IP di uscita condiviso o non definibile, non abilitare l'applicazione rigorosa della posizione nei tuoi criteri di accesso condizionale». Distribuisci gruppo per gruppo.

5. Imposta il browser persistente su never — e definisci correttamente l'ambito. Graph documenta il vincolo direttamente sulla proprietà: «Tutte le app devono essere selezionate affinché questo controllo di sessione funzioni correttamente». Un criterio del browser persistente con ambito limitato a un sottoinsieme di app non fa ciò che il suo nome implica.

6. Non affidarti solo alla condizione di piattaforma. Abbina Device platforms alla conformità di Intune o alla condizione Filter for devices. Nota che la condizione precedente Device state è deprecata, e che «lo stato del dispositivo e i filtri per i dispositivi non possono essere usati insieme in un criterio di accesso condizionale».

7. Risolvi due conflitti noti prima di abilitare la frequenza di accesso. Disabilita prima «Ricorda MFA sui dispositivi attendibili» — «usare queste due impostazioni insieme potrebbe richiedere l'accesso agli utenti in modo inaspettato» — e non mescolare i controlli di sessione con la funzionalità legacy di durata del token configurabile, che «Microsoft ha ritirato… per le durate dei token di aggiornamento e di sessione il 30 gennaio 2021».

8. Revoca esplicitamente durante un incidente. Poiché le modifiche ai criteri impiegano fino a un giorno (due ore con l'ottimizzazione) per raggiungere i resource provider, usa l'azione diretta:

Import-Module Microsoft.Graph.Users.Actions

# A UPN can also be used as -UserId.
Revoke-MgUserSignInSession -UserId $userId

Revoke-MgUserSignInSession «invalida tutti i token di aggiornamento rilasciati alle applicazioni per un utente (e i cookie di sessione nel browser dell'utente), reimpostando la proprietà utente signInSessionsValidFromDateTime sulla data e ora correnti». Richiede almeno User.RevokeSessions.All. L'equivalente nel portale è Revoke Session nella pagina del profilo utente. Conferma che i tuoi account break-glass siano esclusi da qualsiasi criterio di posizione prima di inasprirlo.

9. Aggiungi la protezione del token dove il client la supporta. La protezione del token «tenta di ridurre gli attacchi che sfruttano il furto di token garantendo che un token sia utilizzabile solo dal dispositivo previsto», e la colonna TokenProtectionStatusDetails in SigninLogs indica se un token di accesso era vincolato al proprio dispositivo.

Come lo rileva EtcSec

Un audit Azure di EtcSec legge i tuoi criteri di accesso condizionale e le posizioni denominate tramite Microsoft Graph e segnala le lacune di configurazione dietro ciascuno degli scenari precedenti: CA_NO_SESSION_CONTROLS quando nessun criterio abilitato imposta una frequenza di accesso né una modalità del browser persistente, CA_PERSISTENT_BROWSER_ENABLED quando ai cookie del browser è consentito persistere, CA_NO_NAMED_LOCATIONS e CA_NO_TRUSTED_LOCATIONS quando il tenant non ha alcun vocabolario di posizione che CAE possa applicare, CA_NO_LOCATION_BLOCK quando nessun criterio blocca in base alla posizione, e CA_NO_PLATFORM_FILTER quando nessun criterio delimita l'ambito in base alla piattaforma del dispositivo. Questi si combinano naturalmente con la revisione più ampia in lacune dell'accesso condizionale di Entra ID, lacune di copertura dei criteri di base, e la guida completa all'audit di sicurezza di Entra ID.