Conditional Access in Entra ID: da dove iniziare senza bloccare nessuno

Conditional Access è la feature più potente di Entra ID per la sicurezza degli accessi. È anche quella che, configurata male, può bloccare gli utenti nel momento peggiore — lunedì mattina, riunione importante, nessun amministratore raggiungibile. Questa guida parte dall'inizio: cosa è, come funziona il motore di valutazione, e le tre policy che ogni tenant M365 dovrebbe avere prima di qualsiasi altra cosa.

Cosa è Conditional Access — e cosa non è

Conditional Access non è un firewall. Non è una lista di indirizzi IP autorizzati. È il motore di policy di Zero Trust integrato in Entra ID: valuta ogni tentativo di accesso in tempo reale sulla base di segnali — chi è l'utente, da dove si connette, con quale dispositivo, a quale applicazione — e decide se consentire l'accesso, richiedere un secondo fattore o bloccarlo completamente.

La distinzione con il vecchio MFA per-utente è fondamentale. Il MFA per-utente è una casella di spunta su un account: o l'utente ha MFA abilitato o non ce l'ha. Conditional Access è una regola: questo utente, che accede da questo contesto, deve soddisfare queste condizioni. La stessa persona può ricevere un trattamento diverso a seconda che si connetta dall'ufficio con un dispositivo managed o da un hotel con un browser su Mac personale.

Come il motore valuta ogni accesso

Quando un utente tenta di accedere a una risorsa protetta da Entra ID, il motore di Conditional Access raccoglie i segnali disponibili e li confronta con tutte le policy attive. Il risultato è sempre uno di tre: accesso consentito, accesso consentito con condizioni (es. MFA), accesso bloccato.

I segnali principali che le policy possono leggere sono:

• Identità: utente specifico, gruppo, ruolo amministrativo, utenti guest
• Applicazione: tutte le app cloud, Exchange Online, SharePoint, Teams, app custom
• Condizioni: piattaforma del dispositivo (Windows/iOS/Android), posizione geografica (Named Location), rischio utente e rischio di accesso (Entra ID Protection)
• Client: browser, app native, client Exchange ActiveSync, client legacy

Il motore valuta tutte le policy in parallelo e applica la policy più restrittiva che corrisponde ai segnali. Se nessuna policy corrisponde, l'accesso è consentito per default — questo è un punto critico che vedremo nella sezione sugli errori.

Le tre policy baseline che ogni tenant deve avere

Non esiste un set di policy universalmente valido. Ma dopo anni di audit, ci sono tre policy che riteniamo non negoziabili come punto di partenza.

1. MFA per tutti gli utenti su tutte le applicazioni

La policy più semplice e la più importante. Richiede MFA a chiunque acceda a qualsiasi applicazione Microsoft 365, senza eccezioni di posizione o dispositivo. È il pavimento minimo: se non avete questa policy, tutto il resto è opzionale.

Nome: CA001 - Richiedi MFA per tutti gli utenti
Utenti: Tutti gli utenti (escludere break-glass account)
Applicazioni cloud: Tutte le applicazioni cloud
Condizioni: (nessuna)
Controlli accesso: Richiedi autenticazione a più fattori
Stato: Abilitata

2. Blocco autenticazione legacy

I protocolli di autenticazione legacy (IMAP, POP3, SMTP AUTH, Exchange ActiveSync di vecchia generazione) non supportano MFA. Un attaccante che trova credenziali valide può usarli per aggirare completamente le policy di Conditional Access che richiedono MFA. Questa policy li blocca.

Nome: CA002 - Blocca autenticazione legacy
Utenti: Tutti gli utenti
Applicazioni cloud: Tutte le applicazioni cloud
Condizioni - App client: Seleziona client di autenticazione Exchange (legacy)
             + altri client
Controlli accesso: Blocca accesso
Stato: Abilitata

3. MFA sempre per gli amministratori

Gli account con ruoli privilegiati sono il target principale degli attacchi. Questa policy richiede MFA agli amministratori in modo indipendente dalla prima policy — anche se un domani decidete di escludere certi utenti dalla policy 1, gli admin restano sempre protetti.

Nome: CA003 - MFA obbligatorio per amministratori
Utenti: Tutti i ruoli amministrativi (Global, Security,
        Exchange, SharePoint, User, Helpdesk admin)
Applicazioni cloud: Tutte le applicazioni cloud
Condizioni: (nessuna)
Controlli accesso: Richiedi autenticazione a più fattori
Stato: Abilitata

Come fare il rollout senza bloccare gli utenti

La ragione per cui molti rimandano l'attivazione di Conditional Access è la paura di bloccare gli utenti nel momento sbagliato. È una preoccupazione legittima — ma ha una soluzione tecnica: la modalità Report-only.

Report-only è uno stato intermedio della policy: la policy viene valutata su ogni accesso e il risultato viene registrato nei log, ma non viene applicato. È possibile simulare l'impatto di una policy su tutto il tenant prima di attivarla.

Il processo che seguiamo:

• Fase 1 — Report-only (1-2 settimane): attivare la policy in Report-only, monitorare i log in Entra ID (Sign-in logs → filtro Conditional Access), identificare gli accessi che verrebbero bloccati o che richiederebbero MFA
• Fase 2 — Pilota (3-5 giorni): attivare la policy per un gruppo pilota (team IT, manager, utenti non critici), raccogliere feedback, identificare configurazioni MFA mancanti
• Fase 3 — Rollout completo: espandere a tutti gli utenti, comunicare in anticipo il cambio, avere un break-glass account disponibile

Gli errori più comuni che troviamo durante gli audit

Dopo dieci anni di audit di tenant Microsoft 365, la lista degli errori ricorrenti su Conditional Access è sempre la stessa.

Policy in stato Report-only da mesi

La policy è stata creata in Report-only per testare l'impatto, ma nessuno l'ha mai attivata. Il tenant crede di avere Conditional Access configurato; in realtà non c'è nessuna protezione. Controlliamo sempre lo stato di ogni policy prima di dichiarare il tenant "conforme".

Esclusioni eccessive dal MFA

Per risolvere un problema con un utente specifico, qualcuno ha aggiunto quell'utente alla lista di esclusione della policy MFA. Poi un altro. E un altro ancora. Nel tempo l'esclusione diventa la norma e il MFA protegge solo una frazione degli utenti.

Nessuna policy per i client legacy

Le policy MFA sono attive, ma i protocolli legacy non sono bloccati. Risultato: un attaccante con credenziali valide può autenticarsi via IMAP senza mai vedere il prompt MFA. È l'equivalente di mettere un lucchetto nuovo sulla porta e lasciare la finestra aperta.

Break-glass account non documentato

Il break-glass account esiste ma la password non è documentata, non è aggiornata, o è salvata solo nel password manager del responsabile IT che nel frattempo ha lasciato l'azienda.

Named Locations, device compliance e il passo successivo

Le tre policy baseline sono il punto di partenza, non il punto di arrivo. Una volta consolidate, i passi successivi sono:

• Named Locations: definire le posizioni geografiche attendibili (ufficio, VPN aziendale) e applicare controlli diversi agli accessi da location non attendibili — ad esempio richiedere un secondo fattore aggiuntivo o bloccare completamente certi Paesi
• Device compliance: richiedere che il dispositivo sia managed (Intune-enrolled e compliant) per accedere a dati sensibili — SharePoint, Exchange, Teams
• Rischio di accesso: se avete Entra ID P2, usare il rischio di accesso calcolato da Entra ID Protection per bloccare automaticamente gli accessi anomali (posizione impossibile, IP anonimo, credential spray rilevato)
• Continuous Access Evaluation: configurare CAE per revocare i token in tempo reale quando le condizioni di accesso cambiano, senza aspettare la scadenza naturale del token

Nessuno di questi passi è complesso tecnicamente. Il difficile è capire in quale ordine procedere nel contesto specifico del vostro tenant — quanti dispositivi non managed ci sono, quanti utenti accedono da mobile, quali applicazioni gestiscono dati sensibili.