Il contesto: identità come nuovo perimetro

Nel modello Zero Trust l’identità è il piano di controllo primario: non esiste più una rete “interna” fidata, quindi ogni richiesta di accesso va verificata esplicitamente, concessa con privilegio minimo e valutata assumendo la compromissione (assume breach). La Microsoft Cybersecurity Reference Architecture (MCRA) posiziona Microsoft Entra ID e il suo motore di Conditional Access (CA) come punto di applicazione delle policy (policy enforcement point), che combina i segnali provenienti da identità, dispositivi, applicazioni e telemetria di rischio.

Come architetto AZ-305, il tuo compito non è “attivare l’MFA”, ma progettare un set coerente di policy che bilanci sicurezza e produttività, mappato ai pilastri del Well-Architected Framework — in particolare Security (verifica esplicita) e Operational Excellence (deploy controllato e osservabile).

I segnali di decisione

Una policy CA è una regola if-then: dato un insieme di assignment (chi/cosa) e condition (segnali), applica un grant o session control. I segnali chiave da comporre nel design:

  • Utente/gruppo/ruolo: target dell’accesso; i ruoli privilegiati (Global Admin, ecc.) richiedono controlli più stringenti.
  • Dispositivo: stato compliant (via Intune) o Hybrid Entra joined come requisito di grant.
  • Rischio utente e rischio di sign-in: forniti da Entra ID Protection; permettono policy adattive (es. high risk → blocca o forza reset password + MFA).
  • Posizione/rete: named locations, IP fidati, paesi — utile ma mai come unico fattore forte (spoofing/VPN).
  • Applicazione client: distinzione tra browser, client moderni e legacy authentication (da bloccare esplicitamente, perché aggira l’MFA).

Baseline raccomandata: MFA e passwordless

La baseline di sicurezza deve richiedere MFA per tutti gli utenti, con esclusione unicamente degli account di emergenza. Come metodo, raccomanda il passwordless phishing-resistant: passkey (FIDO2), Windows Hello for Business o certificate-based authentication per gli scenari ad alto valore. Rispetto all’MFA SMS/telefonata (vulnerabile a SIM-swap e phishing), il passwordless riduce contemporaneamente attrito (nessuna password da digitare) e rischio — un raro caso in cui i due obiettivi convergono. Per l’enforcement usa le Authentication Strengths, che consentono di pretendere uno specifico livello (es. “phishing-resistant”) per i ruoli amministrativi.

Il trade-off: rigore vs attrito

Il cuore del design è calibrare il controllo sul valore della risorsa e sul rischio del contesto:

  • Accesso a dati altamente sensibili o azioni admin → grant forte (dispositivo compliant + auth phishing-resistant), sessione breve (Sign-in Frequency) e blocco della persistenza (Persistent browser session off).
  • App di produttività standard da dispositivo gestito → MFA con esperienza fluida; evita il prompt continuo per non spingere gli utenti verso workaround insicuri.

Un rigore uniforme e massimo è un anti-pattern: genera fatica da MFA, ticket e shadow IT. Il design corretto è adattivo e basato sul rischio, non binario.

Deploy sicuro: report-only e break-glass

Due elementi sono non negoziabili nel design AZ-305:

  • Report-only mode: attiva ogni nuova policy in modalità report-only prima dell’enforcement, così da misurarne l’impatto sui sign-in reali (tramite log e What If tool) ed evitare lockout massivi. È l’applicazione del pilastro Operational Excellence al rollout delle policy.
  • Break-glass account (account di emergenza): almeno due account cloud-only, con credenziali robuste conservate offline, esclusi dalle policy CA e monitorati con alert dedicati in Microsoft Sentinel. Servono a recuperare l’accesso se una policy o il provider MFA si guasta.

Trappole tipiche d’esame

  • Requisito: nessun rischio di lockout amministrativo totale → progetta break-glass account esclusi da tutte le CA policy, con sign-in monitorati in Sentinel. La loro assenza è l’errore classico da evitare.
  • Requisito: bloccare l’aggiramento dell’MFA → non basta abilitare l’MFA: aggiungi una policy che blocca la legacy authentication, altrimenti protocolli come POP/IMAP la eludono.
  • Scenario: policy in conflitto (una richiede dispositivo compliant, una lo blocca) → ricorda che le CA sono additive e il blocco vince sempre; consolida e testa con il What If tool prima dell’enforcement.
  • Requisito: esentare un reparto senza aprire un buco → evita esclusioni troppo ampie (interi tenant, “All trusted locations”). Escludi il gruppo minimo indispensabile e prevedi controlli compensativi.
  • Requisito: minimizzare l’impatto sugli utenti di una nuova policy → distribuiscila in report-only mode con rollout a fasi (pilot group), non l’enforcement immediato su “All users”.