Valutazione continua dell'accesso

La scadenza e l'aggiornamento dei token sono un meccanismo standard del settore. Quando un'applicazione client come Outlook si connette a un servizio come Exchange Online, le richieste API vengono autorizzate usando i token di accesso OAuth 2.0. Per impostazione predefinita, i token di accesso sono validi per un'ora, quando scadono il client viene reindirizzato ad Azure AD per aggiornarli. Tale periodo di aggiornamento offre la possibilità di rivalutare i criteri per l'accesso degli utenti. Ad esempio, è possibile scegliere di non aggiornare il token a causa di un criterio di accesso condizionale o perché l'utente è stato disabilitato nella directory.

I clienti hanno espresso preoccupazioni sul ritardo tra quando le condizioni cambiano per un utente e quando vengono applicate le modifiche dei criteri. Azure AD ha sperimentato l'approccio "blunt object" di durata ridotta dei token, ma ha scoperto che possono degradare le esperienze utente e l'affidabilità senza eliminare i rischi.

Una risposta tempestiva alle violazioni dei criteri o ai problemi di sicurezza richiede realmente una "conversazione" tra l'emittente del token (Azure AD) e la relying party (app abilitate). Questa conversazione bidirezionale offre due importanti funzionalità. La relying party può vedere quando le proprietà cambiano, ad esempio il percorso di rete, e comunicarlo all'autorità di certificazione del token. Inoltre offre all’autorità di certificazione del token un modo per indicare alla relying party di interrompere il rispetto dei token per un determinato utente a causa di una compromissione o disabilitazione dell'account o di altri problemi. Il meccanismo per questa conversazione è la valutazione dell'accesso continuo (continuous access evaluation, CAE). L'obiettivo per la valutazione degli eventi critici è che la risposta sia quasi in tempo reale, ma la latenza di fino a 15 minuti può essere osservata a causa del tempo di propagazione degli eventi; Tuttavia, l'applicazione dei criteri di posizione IP è immediata.

L'implementazione iniziale della valutazione continua dell'accesso è incentrata su Exchange, Teams e SharePoint Online.

Per preparare le applicazioni per l'uso di CAE, vedere Come usare le API abilitate per la valutazione dell'accesso continuo nelle applicazioni.

La valutazione dell'accesso continuo non è attualmente disponibile nei tenant GCC High Azure per enti pubblici.

Vantaggi principali

  • Cessazione dell’utente o modifica/reimpostazione della password: la revoca della sessione utente verrà applicata quasi in tempo reale.
  • Modifica del percorso di rete: i criteri dei percorsi di accesso condizionale verranno applicati quasi in tempo reale.
  • L'esportazione di token in un computer esterno a una rete attendibile può essere impedita con i criteri dei percorsi di accesso condizionale.

Scenari

Esistono due scenari che costituiscono la valutazione continua dell'accesso, la valutazione critica degli eventi e la valutazione dei criteri di accesso condizionale.

Valutazione degli eventi critici

La valutazione dell'accesso continuo viene implementata abilitando i servizi, ad esempio Exchange Online, SharePoint Online e Teams, per sottoscrivere eventi critici di Azure AD. Tali eventi possono quindi essere valutati e applicati quasi in tempo reale. La valutazione degli eventi critici non si basa sui criteri di accesso condizionale, quindi è disponibile in qualsiasi tenant. Gli eventi seguenti vengono attualmente valutati:

  • L'account utente viene eliminato o disabilitato
  • La password per un utente viene modificata o reimpostata
  • L'autenticazione a più fattori è abilitata per l'utente
  • L'amministratore revoca in modo esplicito tutti i token di aggiornamento per un utente
  • Rischio utente elevato rilevato da Azure AD Identity Protection

Questo processo consente agli utenti di perdere l'accesso ai file di SharePoint Online dell'organizzazione, alla posta elettronica, al calendario o alle attività e a Teams da Microsoft 365 app client entro pochi minuti dopo un evento critico.

Nota

SharePoint Online non supporta gli eventi di rischio utente.

Valutazione dei criteri di accesso condizionale

Exchange Online, SharePoint Online, Teams e MS Graph possono sincronizzare i criteri di accesso condizionale chiave per la valutazione all'interno del servizio stesso.

Questo processo consente agli utenti di perdere l'accesso ai file dell'organizzazione, alla posta elettronica, al calendario o alle attività da Microsoft 365 app client o SharePoint Online immediatamente dopo le modifiche alla posizione di rete.

Nota

Non tutte le combinazioni di app client e provider di risorse sono supportate. Vedere le tabelle seguenti. La prima colonna di questa tabella fa riferimento alle applicazioni Web avviate tramite Web browser (ad esempio PowerPoint avviato nel Web browser) mentre le restanti quattro colonne fanno riferimento alle applicazioni native in esecuzione in ogni piattaforma descritta. Inoltre, i riferimenti a "Office" includono Word, Excel e PowerPoint.

Outlook Web Outlook Win32 Outlook iOS Outlook Android Outlook Mac
SharePoint Online Supportato Supportato Supportato Supportato Supportato
Exchange Online Supportato Supportato Supportato Supportato Supportato
App Web di Office App Win32 di Office Office per iOS Office per Android Office per Mac
SharePoint Online Non supportato * Supportato Supportato Supportato Supportato
Exchange Online Non supportato Supportato Supportato Supportato Supportato
Web OneDrive OneDrive Win32 OneDrive iOS OneDrive Android OneDrive Mac
SharePoint Online Supportato Non supportato Supportato Supportato Non supportato
Web Teams Teams Win32 Teams iOS Teams Android Teams Mac
Servizio Teams Parzialmente supportato Parzialmente supportato Parzialmente supportato Parzialmente supportato Parzialmente supportato
SharePoint Online Parzialmente supportato Parzialmente supportato Parzialmente supportato Parzialmente supportato Parzialmente supportato
Exchange Online Parzialmente supportato Parzialmente supportato Parzialmente supportato Parzialmente supportato Parzialmente supportato

* La durata dei token per le app Web di Office viene ridotta a 1 ora quando viene impostato un criterio di accesso condizionale.

Funzionalità client

Richiesta di attestazione lato client

Prima della valutazione dell'accesso continuo, i client riprodurrebbero il token di accesso dalla cache purché non fosse scaduto. Con l'autorità di certificazione viene presentato un nuovo caso in cui un provider di risorse può rifiutare un token quando non è scaduto. Per informare i client di ignorare la cache anche se i token memorizzati nella cache non sono scaduti, viene presentato un meccanismo denominato richiesta di richiesta per indicare che il token è stato rifiutato e che è necessario rilasciare un nuovo token di accesso da Azure AD. L'autorità di certificazione richiede un aggiornamento client per comprendere la richiesta di attestazione. La versione più recente delle applicazioni seguenti supporta la richiesta di attestazione:

Web Win32 iOS Android Mac
Outlook Supportato Supportato Supportato Supportato Supportato
Teams Supportato Supportato Supportato Supportato Supportato
Office Non supportato Supportato Supportato Supportato Supportato
OneDrive Supportato Supportato Supportato Supportato Supportato

Durata dei token

Poiché i criteri e i rischi vengono valutati in tempo reale, i client che negoziano sessioni di valutazione dell'accesso continuo non si basano più sui criteri di durata del token di accesso statico. Questa modifica significa che i criteri di durata del token configurabili non sono onorati per i client che negoziano sessioni con riconoscimento CAE.

La durata del token è aumentata fino a 28 ore nelle sessioni CAE. La revoca è basata su eventi critici e valutazione dei criteri, non solo da un periodo di tempo arbitrario. Questa modifica aumenta la stabilità delle applicazioni senza influire sul comportamento di sicurezza.

Se non si usano client compatibili con CAE, la durata predefinita del token di accesso rimarrà 1 ora. L'impostazione predefinita cambia solo se è stata configurata la durata del token di accesso con la funzionalità di anteprima del token configurabile (CTL).

Diagrammi di flusso di esempio

Flusso di eventi di revoca utente

Flusso di eventi di revoca utente

  1. Un client con funzionalità CAE presenta le credenziali o un token di aggiornamento ad Azure AD che richiede un token di accesso per una risorsa.
  2. Un token di accesso viene restituito insieme ad altri artefatti al client.
  3. Un amministratore revoca in modo esplicito tutti i token di aggiornamento per l'utente. Un evento di revoca verrà inviato al provider di risorse da Azure AD.
  4. Viene presentato un token di accesso al provider di risorse. Il provider di risorse valuta la validità del token e verifica se è presente un evento di revoca per l'utente. Il provider di risorse usa queste informazioni per decidere di concedere o meno l'accesso alla risorsa.
  5. In questo caso, il provider di risorse nega l'accesso e invia una richiesta di attestazione 401+ al client.
  6. Il client abilitato per CAE riconosce il test di attestazione 401+. Ignora le cache e torna al passaggio 1, inviando il token di aggiornamento insieme al test di attestazione ad Azure AD. Azure AD rivaluta quindi tutte le condizioni e chiede all'utente di ripetere l'autenticazione in questo caso.

Flusso di modifica della condizione utente

Nell'esempio seguente un amministratore di accesso condizionale ha configurato un criterio di accesso condizionale basato sulla posizione per consentire l'accesso solo da intervalli IP specifici:

Flusso di eventi condizione utente

  1. Un client con funzionalità CAE presenta le credenziali o un token di aggiornamento ad Azure AD che richiede un token di accesso per una risorsa.
  2. Azure AD valuta tutti i criteri di accesso condizionale per verificare se l'utente e il client soddisfano le condizioni.
  3. Un token di accesso viene restituito insieme ad altri artefatti al client.
  4. L'utente esce da un intervallo IP consentito.
  5. Il client presenta un token di accesso al provider di risorse dall'esterno di un intervallo IP consentito.
  6. Il provider di risorse valuta la validità del token e controlla i criteri di posizione sincronizzati da Azure AD.
  7. In questo caso, il provider di risorse nega l'accesso e invia una richiesta di attestazione 401+ al client. Il client viene contestato perché non proviene da un intervallo IP consentito.
  8. Il client abilitato per CAE riconosce il test di attestazione 401+. Ignora le cache e torna al passaggio 1, inviando il token di aggiornamento insieme al test di attestazione ad Azure AD. Azure AD rivaluta tutte le condizioni e nega l'accesso in questo caso.

Abilitare o disabilitare l'autorità di certificazione

L'impostazione di Valutazione continua dell'accesso è stata spostata nel pannello Accesso condizionale. I nuovi clienti di Valutazione continua dell'accesso possono accedere e attivare o disattivare Valutazione continua dell'accesso direttamente durante la creazione dei criteri di accesso condizionale. Tuttavia, alcuni clienti esistenti dovranno eseguire la migrazione prima di poter accedere alla funzionalità Valutazione continua dell'accesso tramite l'accesso condizionale.

Migrazione

I clienti che hanno configurato le impostazioni CAE in Sicurezza prima di dover eseguire la migrazione delle impostazioni a un nuovo criterio di accesso condizionale. Seguire questa procedura per eseguire la migrazione delle impostazioni CAE a un criterio di accesso condizionale.

Visualizzazione portale che mostra l'opzione per eseguire la migrazione della valutazione dell'accesso continuo a criteri di accesso condizionale.

  1. Accedere alla portale di Azure come amministratore di accesso condizionale, amministratore della sicurezza o amministratore globale.
  2. Passare allavalutazione dell'accesso continuo allasicurezza> di Azure Active Directory>.
  3. Verrà quindi visualizzata l'opzione Migrazione dei criteri. Questa azione è l'unica a cui si avrà accesso a questo punto.
  4. Passare all'accesso condizionale e si troverà un nuovo criterio denominato Criteri di accesso condizionale creati dalle impostazioni CAE con le impostazioni configurate. Gli amministratori possono scegliere di personalizzare questo criterio o crearne uno personalizzato per sostituirlo.

La tabella seguente descrive l'esperienza di migrazione di ogni gruppo di clienti in base alle impostazioni CAE configurate in precedenza.

Impostazione CAE esistente È necessaria la migrazione Abilitata automaticamente per CAE Esperienza di migrazione prevista
Nuovi tenant che non hanno configurato nulla nell'esperienza precedente. No L'impostazione CAE precedente verrà nascosta perché è probabile che questi clienti non visualizzino l'esperienza prima della disponibilità generale.
Tenant abilitati in modo esplicito per tutti gli utenti con l'esperienza precedente. No L'impostazione CAE precedente verrà disattivata. Poiché questi clienti hanno abilitato in modo esplicito questa impostazione per tutti gli utenti, non devono eseguire la migrazione.
Tenant che hanno abilitato in modo esplicito alcuni utenti nei tenant con l'esperienza precedente. No Le impostazioni cae precedenti verranno disattivate. Facendo clic su Esegui migrazione viene avviata la creazione guidata dei nuovi criteri di accesso condizionale, che include Tutti gli utenti, escludendo gli utenti e i gruppi copiati da CAE. Imposta anche il nuovo controllo Personalizzazione della valutazione dell'accesso continuo Su Disabilitato.
Tenant che hanno disabilitato in modo esplicito l'anteprima. No Le impostazioni cae precedenti verranno disattivate. Facendo clic su Esegui migrazione viene avviata la creazione guidata dei nuovi criteri di accesso condizionale, che include Tutti gli utenti e imposta il nuovo controllo Personalizza sessione di valutazione dell'accesso continuo su Disabilitato.

Altre informazioni sulla valutazione dell'accesso continuo come controllo sessione sono disponibili nella sezione Personalizzare la valutazione dell'accesso continuo.

Limitazioni

Tempo effettivo per l'appartenenza ai gruppi e l'aggiornamento dei criteri

Le modifiche apportate ai criteri di accesso condizionale e all'appartenenza ai gruppi apportati dagli amministratori potrebbero richiedere fino a un giorno per essere effettive. Il ritardo è dovuto alla replica tra Azure AD e provider di risorse, ad esempio Exchange Online e SharePoint Online. Alcune ottimizzazioni sono state eseguite per gli aggiornamenti dei criteri, riducendo il ritardo a due ore. Tuttavia, non copre ancora tutti gli scenari.

Quando i criteri di accesso condizionale o le modifiche all'appartenenza ai gruppi devono essere applicati immediatamente a determinati utenti, sono disponibili due opzioni.

  • Eseguire il comando revoke-mgusersign di PowerShell per revocare tutti i token di aggiornamento di un utente specificato.
  • Selezionare "Revoca sessione" nella pagina del profilo utente nel portale di Azure per revocare la sessione dell'utente per assicurarsi che i criteri aggiornati vengano applicati immediatamente.

Variazione dell'indirizzo IP e reti con indirizzi IP condivisi o ip in uscita sconosciuti

Le reti moderne spesso ottimizzano la connettività e i percorsi di rete per le applicazioni in modo diverso. Questa ottimizzazione causa spesso variazioni degli indirizzi IP di routing e di origine delle connessioni, come illustrato dal provider di identità e dai provider di risorse. È possibile osservare questa variazione di percorso diviso o indirizzo IP in più topologie di rete, tra cui, ad esempio:

  • Proxy locali e basati sul cloud.
  • Implementazioni di rete privata virtuale (VPN), ad esempio split tunneling.
  • Distribuzioni sd-WAN (Software Defined Wide Area Network).
  • Topologie di rete in uscita con carico bilanciato o ridondante, ad esempio quelle che usano SNAT.
  • Distribuzioni di succursali che consentono la connettività Internet diretta per applicazioni specifiche.
  • Reti che supportano i client IPv6.
  • Altre topologie, che gestiscono il traffico di applicazioni o risorse in modo diverso dal traffico al provider di identità.

Oltre alle varianti IP, i clienti possono anche usare soluzioni e servizi di rete che:

  • Usare gli indirizzi IP che possono essere condivisi con altri clienti. Ad esempio, i servizi proxy basati sul cloud in cui gli indirizzi IP in uscita vengono condivisi tra i clienti.
  • Usare facilmente indirizzi IP variabili o indefinibili. Ad esempio, le topologie in cui sono presenti set dinamici di grandi dimensioni di indirizzi IP in uscita usati, ad esempio scenari aziendali di grandi dimensioni o traffico di rete in uscita locale e VPN diviso.

Le reti in cui gli indirizzi IP in uscita possono cambiare frequentemente o sono condivisi possono influire sull'accesso condizionale di Azure AD e continua la valutazione dell'accesso (CAE). Questa variabilità può influire sul funzionamento di queste funzionalità e sulle relative configurazioni consigliate.

La tabella seguente riepiloga i comportamenti delle funzionalità di accesso condizionale e cae e i consigli per diversi tipi di distribuzioni di rete:

Tipo di rete Esempio Indirizzi IP visualizzati da Azure AD Indirizzi IP visualizzati da RP Configurazione CA applicabile (percorso denominato attendibile) Applicazione dell'autorità di certificazione Token di accesso CAE Consigli
1. Gli indirizzi IP in uscita sono dedicati ed enumerabili sia per il traffico di Azure AD che per tutto il traffico di indirizzi IP Tutto il traffico di rete verso Azure AD e gli indirizzi IP in uscita da 1.1.1.1 e/o 2.2.2.2.2 1.1.1.1 2.2.2.2 1.1.1.1
2.2.2.2
Eventi critici
Modifiche alla posizione IP
Durata prolungata: fino a 28 ore Se sono definite posizioni denominate ca, assicurarsi che contengano tutti gli indirizzi IP in uscita possibili (visti da Azure AD e da tutti gli indirizzi IP)
2. Gli indirizzi IP in uscita sono dedicati ed enumerabili per Azure AD, ma non per il traffico degli indirizzi IP Traffico di rete verso Azure AD in uscita fino alla versione 1.1.1.1. Traffico RP in uscita attraverso x.x.x.x.x 1.1.1.1 x.x.x.x.x 1.1.1.1 Eventi critici Durata del token di accesso predefinita - 1 ora Non aggiungere indirizzi IP in uscita non dedicati o non enumerabili (x.x.x.x.x) in regole CA con percorso denominato attendibile perché possono indebolire la sicurezza
3. Gli indirizzi IP in uscita non sono dedicati/condivisi o non enumerabili sia per il traffico di Azure AD che per i provider di servizi di ricerca Traffico di rete verso Azure AD in uscita attraverso y.y.y.y. Traffico RP in uscita attraverso x.x.x.x.x y.y.y.y x.x.x.x.x N/D -nessun criterio CA IP/Percorsi attendibili configurati Eventi critici Durata prolungata: fino a 28 ore Non aggiungere indirizzi IP in uscita non dedicati o non enumerabili (x.x.x.x/y.y.y.y.y) in regole CA con percorso denominato attendibile perché possono indebolire la sicurezza

Le reti e i servizi di rete usati dai client che si connettono ai provider di identità e risorse continuano a evolversi e cambiare in risposta alle tendenze moderne. Queste modifiche possono influire sulle configurazioni dell'accesso condizionale e dell'autorità di certificazione che si basano sugli indirizzi IP sottostanti. Quando si decide su queste configurazioni, tenere conto delle modifiche future apportate alla tecnologia e alla manutenzione dell'elenco di indirizzi definito nel piano.

Criteri di posizione supportati

CaE ha solo informazioni dettagliate sulle posizioni denominate basate su IP. CaE non ha informazioni dettagliate su altre condizioni di posizione, ad esempio indirizzi IP attendibili MFA o località basate sul paese. Quando un utente proviene da un indirizzo IP attendibile MFA, una posizione attendibile che include indirizzi IP attendibili MFA o un paese, CAE non verrà applicato dopo che l'utente si sposta in una posizione diversa. In questi casi, Azure AD emetterà un token di accesso di un'ora senza un controllo immediato dell'applicazione IP.

Importante

Se si desidera che i criteri di posizione vengano applicati in tempo reale dalla valutazione dell'accesso continuo, usare solo la condizione di posizione dell'accesso condizionale basato su IP e configurare tutti gli indirizzi IP, inclusi IPv4 e IPv6, che possono essere visualizzati dal provider di identità e dal provider di risorse. Non usare le condizioni di località paese o la funzionalità ips attendibile disponibile nella pagina delle impostazioni del servizio di Azure AD Multi-Factor Authentication.

Limitazioni relative alla posizione denominata

Quando la somma di tutti gli intervalli IP specificati nei criteri di posizione supera i 5.000, il flusso della posizione di modifica utente non verrà applicato da CAE in tempo reale. In questo caso, Azure AD emetterà un token CAE di un'ora. CaE continuerà ad applicare tutti gli altri eventi e criteri oltre a eventi di modifica della posizione client. Con questa modifica, si mantiene comunque un comportamento di sicurezza più elevato rispetto ai token tradizionali di un'ora, poiché altri eventi verranno valutati quasi in tempo reale.

Impostazioni di Office e Web Account Manager

Canale di aggiornamento di Office DisableADALatopWAMOverride DisableAADWAM
Canale Enterprise semestrale Se impostato su abilitato o 1, CAE non sarà supportato. Se impostato su abilitato o 1, CAE non sarà supportato.
Canale corrente
oppure
Canale Enterprise mensile
CaE è supportato indipendentemente dall'impostazione CaE è supportato indipendentemente dall'impostazione

Per una spiegazione dei canali di aggiornamento di Office, vedere Panoramica dei canali di aggiornamento per Microsoft 365 Apps. È consigliabile che le organizzazioni non disabilitino Web Account Manager (WAM).

Creazione condivisa nelle app di Office

Quando più utenti collaborano contemporaneamente a un documento, l'accesso al documento potrebbe non essere immediatamente revocato da CAE in base agli eventi di modifica dei criteri. In questo caso, l'utente perde completamente l'accesso dopo:

  • Chiusura del documento
  • Chiusura dell'app office
  • Dopo 1 ora in cui viene impostato un criterio IP di accesso condizionale

Per ridurre ulteriormente questo tempo, un amministratore di SharePoint può ridurre la durata massima delle sessioni di creazione condivisa per i documenti archiviati in SharePoint Online e OneDrive for Business, configurando i criteri dei percorsi di rete in SharePoint Online. Una volta modificata questa configurazione, la durata massima delle sessioni di creazione condivisa verrà ridotta a 15 minuti e può essere modificata ulteriormente usando il comando PowerShell di SharePoint Online "Set-SPOTenant –IPAddressWACTokenLifetime".

Abilitare dopo che un utente è disabilitato

Se si abilita un utente subito dopo la disabilitazione, si verifica una certa latenza prima che l'account venga riconosciuto come abilitato nei servizi di Microsoft downstream.

  • SharePoint Online e Teams hanno in genere un ritardo di 15 minuti.
  • Exchange Online in genere ha un ritardo di 35-40 minuti.

Notifiche push

I criteri degli indirizzi IP non vengono valutati prima del rilascio delle notifiche push. Questo scenario esiste perché le notifiche push sono in uscita e non hanno un indirizzo IP associato per la valutazione. Se un utente fa clic su tale notifica push, ad esempio un messaggio di posta elettronica in Outlook, i criteri di indirizzo IP caE vengono ancora applicati prima che il messaggio di posta elettronica possa essere visualizzato. Le notifiche push visualizzano un'anteprima dei messaggi, che non è protetta da un criterio di indirizzo IP. Tutti gli altri controlli CAE vengono eseguiti prima dell'invio della notifica push. Se un utente o un dispositivo ha accesso rimosso, l'imposizione viene eseguita entro il periodo documentato.

Domande frequenti

Come funziona CAE con frequenza di accesso?

La frequenza di accesso verrà rispettata con o senza CAE.

Passaggi successivi