Conditional Access è il motore di policy di Microsoft Entra ID che valuta ogni tentativo di accesso e decide se consentirlo, bloccarlo o condizionarlo. Nell’esame MS-102 le domande sono quasi sempre scenari: un requisito di business scritto in italiano tecnico che devi tradurre nella combinazione corretta di assignments (chi/cosa/condizioni) e access controls (grant o session).
Anatomia di una policy
Ogni policy ha tre blocchi:
| Blocco | Contiene | Esempi |
|---|---|---|
| Users | utenti, gruppi, ruoli directory, guest, workload identities | includi All users, escludi Break-glass |
| Target resources | cloud app, azioni utente, contesto di autenticazione | Office 365, Azure Management, “Register security information” |
| Conditions | rischio utente/accesso, piattaforma, location, client app, filtro dispositivo | Network location, Device platform |
| Grant | blocca oppure concedi con requisiti | MFA, dispositivo compliant, Hybrid Entra joined, app client approvata, app protection policy, terms of use |
| Session | modifica l’esperienza dopo il grant | Conditional Access App Control, sign-in frequency, persistent browser, token protection |
Tradurre requisiti in configurazione
“MFA quando l’accesso arriva da rete non attendibile.” Definisci le sedi aziendali come named location marcata trusted (range IPv4/IPv6 pubblici o country location), poi crea una policy con Users = All users, Target = All cloud apps, Condition → Network: Any network or location con esclusione delle location attendibili, Grant = Require multifactor authentication. Nota il pattern: si esclude la rete buona, non si include quella cattiva.
“Bloccare l’accesso dai paesi in cui non operiamo.” Crea una country named location che include i paesi consentiti, poi una policy con Network = Any location, exclude la named location dei paesi consentiti, Grant = Block access. È il modello allow-list: più robusto della deny-list, perché copre anche i paesi che compaiono in futuro. Ricorda che il GPS/IP dei paesi si basa sull’IP pubblico, quindi una VPN aziendale in un altro continente falsa il risultato.
“Le app che contengono dati finanziari solo da dispositivi gestiti.” Target resources = le app specifiche, Grant = Require device to be marked as compliant (compliance valutata da Microsoft Intune) oppure Require Microsoft Entra hybrid joined device, con l’opzione Require one of the selected controls. Se selezioni Require all, un device solo Entra joined e compliant ma non ibrido viene bloccato.
“Da browser non gestito si può leggere ma non scaricare.” Questo è session control, non grant: Session → Use Conditional Access App Control → Block downloads (o Use custom policy in Microsoft Defender for Cloud Apps). Il traffico viene proxato da Defender for Cloud Apps in reverse proxy, permettendo controlli granulari su download, copia, stampa. Abbinalo a una condition su Client apps: Browser e a un device filter che escluda i dispositivi compliant.
Ordine di valutazione
Non esiste priorità numerica: tutte le policy applicabili vengono valutate insieme e i loro requisiti si sommano (AND logico fra policy, OR o AND fra i controlli dentro la stessa policy a seconda dell’opzione scelta). Regola d’oro: un blocco esplicito vince sempre su qualunque grant. Ne consegue che aggiungere una policy non può mai allentare una restrizione esistente: può solo restringere.
Testare prima di rompere
- Report-only mode: la policy viene valutata e loggata nei sign-in logs (tab Report-only) ma non applicata. È lo stato di default per le nuove policy e va tenuto attivo giorni, non minuti.
- What If tool: simula un utente, un’app, un IP, una piattaforma e mostra quali policy si applicherebbero. Ottimo per capire perché un utente viene bloccato.
- Sign-in logs → Conditional Access tab: mostra per ogni tentativo le policy Success/Failure/Not applied.
- Le security defaults e Conditional Access sono mutuamente esclusive: per usare CA devi disattivare le security defaults.
Trappole tipiche d’esame
- Scenario: hai creato una policy “Require MFA for all users, all apps” e ora nessun amministratore può entrare per correggerla → la risposta giusta è che mancava l’esclusione degli account break-glass (almeno due account cloud-only,
.onmicrosoft.com, esclusi da tutte le policy e monitorati con alert). Serve il supporto Microsoft per uscirne. - Scenario: dopo l’attivazione di una policy la sincronizzazione directory o uno script si interrompe → hai colpito l’account di sincronizzazione (
Directory Synchronization Accounts) o un service principal: escludi l’account di sync e usa policy dedicate alle workload identities con condizione su IP consentiti. - Scenario: “l’utente deve poter usare la web app ma senza scaricare file” → session control (Conditional Access App Control con Defender for Cloud Apps), non grant control. Il grant decide se entri, la session decide cosa puoi fare una volta dentro.
- Scenario: “verificare l’impatto senza rischi prima del rollout” → report-only mode (e What If per il singolo caso), non “abilitare per un gruppo pilota e vedere che succede”.
- Scenario: assegnare la policy a un gruppo dinamico che include ruoli amministrativi → preferisci l’assegnazione diretta ai ruoli di directory in CA, perché i gruppi dinamici si aggiornano con latenza e possono lasciare scoperti admin appena nominati.