Autenticazione a più fattori e accesso condizionale

Le credenziali rubate sono la causa principale delle violazioni della sicurezza del cloud. Una password da sola può essere sottratta tramite phishing, indovinata con un attacco a forza bruta o divulgata in una violazione di dati di terze parti. L'autenticazione a più fattori (MFA) richiede un secondo fattore di verifica che difficilmente sarà in possesso di un utente malintenzionato, anche dopo che questi ha ottenuto la password, riducendo drasticamente il rischio di accesso non autorizzato all'ambiente Azure.

Entra ID supporta diversi fattori di verifica MFA. L'opzione più sicura e consigliata è l'app Microsoft Authenticator, che offre la corrispondenza dei numeri e le notifiche push. Altre opzioni includono una chiave di sicurezza FIDO2 (token hardware), un token OATH software, un messaggio SMS o una chiamata vocale. SMS e chiamate vocali sono considerati meno sicuri e dovrebbero essere usati solo come metodi alternativi.

In Entra ID, l'MFA può essere applicata tramite tre meccanismi. Security defaults è l'opzione gratuita attivabile con un clic, che applica l'MFA a tutti gli utenti, ma senza possibilità di personalizzazione. Per-user MFA (legacy) abilita l'MFA per account utente specifici. L'approccio moderno consigliato consiste nelle Conditional Access policies (Entra ID P1/P2), che applicano l'MFA solo quando vengono soddisfatte determinate condizioni di rischio, riducendo l'attrito per gli accessi a basso rischio.

Conditional Access (Entra ID P1) è un motore di criteri if-then: se un utente (o un gruppo) tenta di accedere a una risorsa in determinate condizioni, allora consente l'accesso, lo blocca oppure richiede controlli aggiuntivi come l'MFA o un dispositivo conforme. Le condizioni possono includere l'identità dell'utente, la conformità del dispositivo, la posizione IP, l'applicazione a cui si accede e il punteggio di rischio di Entra ID Identity Protection.

Una Conditional Access policy è composta da due parti: Assignments (a chi e a cosa si applica il criterio) e Access Controls (che cosa accade quando il criterio si attiva). Le assegnazioni definiscono gli Users/groups, le Cloud apps a cui si accede e le Conditions (posizione, piattaforma del dispositivo, rischio dell'accesso). I controlli di accesso definiscono se Grant (richiedendo facoltativamente MFA, un dispositivo conforme o un'app approvata) oppure Block completamente l'accesso.

Le named locations di Conditional Access consentono di definire intervalli IP attendibili, ad esempio quelli della rete dell'ufficio aziendale, oppure Paesi. Un criterio comune consiste nel richiedere l'MFA quando un utente accede al di fuori di una posizione denominata attendibile, consentendo invece il pass-through quando accede da un indirizzo IP noto dell'ufficio. In questo modo si riduce l'attrito per i dipendenti in sede, rafforzando al contempo la sicurezza per gli utenti da remoto o in viaggio.

Conditional Access può richiedere che il dispositivo da cui si accede sia compliant (ovvero che soddisfi i criteri di conformità dei dispositivi di Intune) oppure che sia un dispositivo aziendale hybrid Azure AD joined. In questo modo, anche se le credenziali sono valide, gli accessi da dispositivi personali o non gestiti vengono bloccati oppure devono soddisfare controlli aggiuntivi. I controlli basati sui dispositivi sono un pilastro fondamentale del modello di sicurezza Zero Trust.

Entra ID Identity Protection (P2) usa il machine learning per valutare ogni accesso e assegnare un risk score: basso, medio o alto. Tra i fattori di rischio rientrano gli spostamenti impossibili (accessi da due Paesi nel giro di pochi minuti), gli indirizzi IP anonimi, le credenziali compromesse e il rilevamento di attacchi password spray. Le Conditional Access policies possono attivarsi in base al livello di rischio: ad esempio, richiedendo l'MFA per un rischio medio e bloccando automaticamente l'accesso per un rischio alto.

Prima di applicare una Conditional Access policy, è possibile impostarla in modalità Report-Only. In questa modalità, il criterio viene valutato rispetto a tutti gli accessi e registra ciò che sarebbe accaduto (accesso consentito, bloccato o MFA richiesta), ma non applica effettivamente i controlli. Ciò consente di convalidare l'impatto del criterio sugli utenti prima di abilitarlo, evitando blocchi imprevisti dovuti a condizioni configurate in modo errato.

Lo strumento What If nel pannello Conditional Access consente di simulare uno scenario di accesso, specificando un utente, un'applicazione, un indirizzo IP, una piattaforma del dispositivo e un livello di rischio, per visualizzare quali criteri si applicherebbero e quale sarebbe il risultato combinato. È estremamente utile per risolvere i problemi di accesso e verificare che l'insieme dei criteri produca il risultato previsto per determinati utenti e condizioni.

Ogni organizzazione dovrebbe mantenere almeno due break-glass emergency access accounts esclusi da tutte le Conditional Access policies, compresi i requisiti MFA. Questi account devono essere utilizzati solo se l'infrastruttura MFA non funziona o se tutti gli amministratori sono stati bloccati. Le credenziali break-glass devono essere conservate in una cassaforte fisica, usare password casuali lunghe, non avere alcun metodo MFA registrato ed essere sottoposte a controlli rigorosi per rilevare qualsiasi utilizzo.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che: l'MFA richiede un secondo fattore oltre alla password, riducendo drasticamente il rischio di furto delle credenziali, le Conditional Access policies applicano controlli di concessione o blocco in base a condizioni relative a utente, app, posizione e rischio e Identity Protection usa il risk scoring basato sul machine learning per attivare controlli di accesso automatici. Nella prossima lezione esamineremo il Single Sign-On e le identità esterne in Entra ID.