Le Conditional Access policy sono il motore decisionale di Microsoft Entra ID: valutano ogni tentativo di autenticazione e decidono se concederlo, bloccarlo o rafforzarlo. Il modello mentale è una frase logica: “if — then”. Se un certo insieme di segnali è vero, allora applica determinati controlli. Capire come si scompone una policy è la chiave sia per progettare sia per superare i quesiti d’esame.

Assignments: il “chi”, “cosa” e “quando”

Gli assignments definiscono a chi e in quali circostanze la policy si applica. Sono la parte che filtra il traffico.

  • Users: utenti, gruppi, ruoli directory o guest (B2B). Include sempre la possibilità di exclude, fondamentale per gli account di emergenza.
  • Target resources (ex Cloud apps): applicazioni cloud (es. Office 365, Azure Management), user actions come Register security information, o authentication context per proteggere risorse specifiche.
  • Conditions: i segnali contestuali. I principali sono:
    • Sign-in risk e user risk: livelli (low/medium/high) forniti da Entra ID Protection.
    • Device platforms: iOS, Android, Windows, macOS, Linux.
    • Locations: basate su named locations (vedi sotto).
    • Client apps: browser, app moderne, o i più rischiosi legacy authentication client (protocolli come POP, IMAP, SMTP che non supportano MFA).
    • Filter for devices: query sugli attributi del dispositivo (es. device.trustType o extension attributes).

Access controls: grant e session

Se gli assignment “matchano”, entrano in gioco gli access controls.

Grant control

Determina se concedere l’accesso e a quali condizioni. Opzioni tipiche: Require multifactor authentication, Require device to be marked as compliant (compliance via Intune), Require Hybrid Entra joined device, Require approved client app, Require app protection policy, Terms of use.

Il punto architetturale critico è la scelta finale:

  • Require all the selected controls → i controlli sono in AND (tutti obbligatori).
  • Require one of the selected controls → in OR (ne basta uno).

Session control

Non decide se entrare, ma come si comporta la sessione:

  • Sign-in frequency: forza la riautenticazione periodica (es. ogni 4 ore per app sensibili).
  • Persistent browser session: controlla il “resta connesso”.
  • App enforced restrictions: delega a SharePoint/Exchange limiti come blocco del download su dispositivi non gestiti.
  • Conditional Access App Control: instrada la sessione tramite Defender for Cloud Apps per monitoraggio/blocco in tempo reale.

Named locations e report-only mode

Le named locations sono definizioni riutilizzabili basate su intervalli IP (CIDR, per reti aziendali) oppure country/region (per geofencing). Possono essere marcate come trusted, il che influenza anche altri segnali di rischio. Sono la base per policy come “blocca l’accesso da paesi non previsti” o “non richiedere MFA dalla rete corporate”.

La report-only mode è lo strumento di collaudo: la policy viene valutata e loggata (visibile nei Sign-in logs e nel Conditional Access Insights workbook) senza applicare i controlli. Permette di misurare l’impatto reale — quanti utenti sarebbero bloccati, quante MFA in più — prima di passare a On. È la best practice obbligata prima di ogni rollout.

Come interagiscono più policy

Ogni policy è valutata in modo indipendente, ma il risultato è cumulativo: tutte le policy applicabili devono essere soddisfatte contemporaneamente (AND). Se una richiede MFA e un’altra richiede compliant device, l’utente dovrà soddisfare entrambe. Un Block ha sempre la precedenza su qualsiasi Grant.

Trappole tipiche d’esame

  • Scenario: crei una policy che richiede MFA per All users → includi sempre un break-glass / emergency access account nell’esclusione. Un errore di configurazione o un’interruzione MFA rischia altrimenti di bloccare fuori l’intero tenant, admin compresi.
  • Scenario: due policy separate, una richiede MFA, l’altra compliant device → l’utente deve soddisfarle entrambe (AND), non “una qualsiasi”. Le policy non sono alternative.
  • Scenario: vuoi impedire l’accesso a un servizio da un paese specifico ma solo dalla rete non aziendale → usa named locations (country per il geofencing, IP ranges trusted per la corporate), non filtri utente.
  • Scenario: devi introdurre una policy restrittiva senza rischiare disservizi → attiva prima in report-only e analizza i Sign-in logs, poi passa a On. Non partire mai direttamente in enforcement su All users.
  • Scenario: gli utenti bypassano l’MFA usando client email datati → la condizione client apps = legacy authentication con grant Block è la risposta; l’MFA da sola non copre i protocolli legacy.
  • Scenario: serve la riautenticazione periodica su un’app finanziaria → è un session control (sign-in frequency), non un grant control.