Conditional Access come control plane della Zero Trust

In un’architettura Zero Trust l’identità è il perimetro primario e Microsoft Entra ID ne è il piano di controllo. Il Conditional Access (CA) è il motore che, ad ogni richiesta di accesso, valuta i segnali disponibili e decide se concedere, bloccare o condizionare la sessione. Come architetto, il tuo compito non è scrivere singole policy, ma progettare un sistema di policy coerente che traduca i principi Zero Trust — “verify explicitly”, “least privilege”, “assume breach” — in controlli applicabili e privi di gap.

I segnali e la logica decisionale

Ogni policy CA è una funzione assignment → condition → control. Gli assignment definiscono chi e cosa (utenti/gruppi, ruoli, app cloud o azioni utente). Le condition valutano i segnali:

  • Rischio utente e rischio di sign-in (da Entra ID Protection): distingui il rischio dell’identità compromessa nel tempo (user risk) dall’anomalia della singola autenticazione (sign-in risk).
  • Device state: compliant (via Microsoft Intune) o Hybrid Entra Joined, per esigere endpoint gestiti.
  • Location / named locations: reti attendibili, geografie, IP corporate.
  • Client app e piattaforma: browser, app mobile, o legacy authentication.

I grant control impongono requisiti (MFA, device compliant, app protection policy, terms of use). I session control modulano l’esperienza dopo l’accesso: Sign-in Frequency, Persistent Browser, e soprattutto il token protection e le Conditional Access App Control con Microsoft Defender for Cloud Apps per il monitoraggio in-session e il blocco di download su device non gestiti.

Il trade-off sicurezza vs frizione

Il cuore del design d’esame è bilanciare postura di sicurezza e frizione utente (pilastro Security del Azure Well-Architected Framework, in tensione con Operational Excellence e produttività). Un approccio maturo è risk-based e adattivo:

  • Per la maggioranza degli accessi a bassa sensibilità, MFA una tantum + device compliant è sufficiente; non forzare re-autenticazioni continue che spingono gli utenti verso workaround.
  • Alza dinamicamente il controllo solo quando i segnali lo giustificano: sign-in risk = High → blocca o richiedi MFA + password change; user risk = High → remediation forzata.
  • Per app ad alta sensibilità (dati finanziari, admin portal) applica requisiti più stringenti — device gestito obbligatorio, phishing-resistant MFA (FIDO2/passkey, Windows Hello), sign-in frequency ridotta.

La raccomandazione architetturale è privilegiare passwordless e phishing-resistant per abbattere la frizione e alzare la sicurezza contemporaneamente, evitando la falsa dicotomia.

Struttura organizzata: persona × sensibilità

Policy nate in modo ad-hoc generano conflitti e gap. Progetta una matrice per persona (global admin, internal user, guest/external, workload identity, developer) × sensibilità dell’applicazione. Ricorda che in CA il blocco vince sempre sul grant: valuta con cura l’ordine logico e usa i report-only mode per validare l’impatto prima dell’enforcement. Adotta una convenzione di naming (es. CAxxx-Persona-App-Control) e gestisci le policy come codice tramite Microsoft Graph per versioning e revisione (pilastro Operational Excellence).

Colmare i gap di copertura

I due gap classici, entrambi molto testati:

  1. Legacy authentication (POP, IMAP, SMTP, MAPI over HTTP): non supporta MFA ed è il vettore preferito degli attacchi password-spray. Va bloccata esplicitamente con una policy dedicata. Nota che Microsoft ha ormai deprecato Basic Auth su Exchange Online, ma resta un requisito d’esame verificarlo con CA.
  2. Break-glass / emergency access account: 2 account cloud-only, con password lunga custodita offline, esclusi da tutte le policy CA per evitare lockout totale se il tenant o l’IdP MFA falliscono. Vanno però monitorati con alert dedicati in Microsoft Sentinel.

Trappole tipiche d’esame

  • Requisito: proteggere da password spray e attacchi che aggirano MFA → soluzione: una policy CA che blocca la legacy authentication per tutti gli utenti. MFA da solo non basta se i protocolli legacy restano abilitati.
  • Requisito: garantire che un lockout MFA non blocchi l’amministrazione del tenant → soluzione: configurare 2 break-glass account cloud-only esclusi da CA, con alert Sentinel sul loro utilizzo. Mai escludere interi gruppi di admin “per comodità”.
  • Requisito: consentire l’accesso solo da endpoint aziendali sicuri con minima frizione → soluzione: grant control “Require device to be marked as compliant” (Intune) + passwordless, non semplicemente “Require MFA”.
  • Requisito: reagire automaticamente a credenziali compromesse → soluzione: policy risk-based con Entra ID Protection: user risk High → require secure password change, sign-in risk High → require MFA. Non una MFA statica indiscriminata.
  • Requisito: impedire il download di dati su dispositivi non gestiti (BYOD) senza bloccarne l’accesso → soluzione: session control con Conditional Access App Control (Defender for Cloud Apps) o app protection policy, non un blocco totale che aumenterebbe la frizione.