La regola: segnali, assegnazioni e controlli

Una Conditional Access policy è, nella sua forma più semplice, un enunciato if-then: se qualcuno vuole accedere a una risorsa, allora deve soddisfare un controllo. La si costruisce nel Microsoft Entra admin center sotto Entra ID > Conditional Access > Policies e ha tre blocchi. Gli Assignments dicono a chi si applica e su quali Target resources. Le Conditions sono i segnali valutati: informazioni su indirizzo IP e posizione, il dispositivo, l’applicazione, e il rischio calcolato in tempo reale che arriva da Microsoft Entra ID Protection e da Microsoft Defender for Cloud Apps. Gli Access controls sono la decisione: Block access, la più restrittiva, oppure Grant access con uno o più requisiti fra cui Require multifactor authentication, Require authentication strength, Require device to be marked as compliant, Require a Microsoft Entra hybrid joined device, Require an approved client app, Require an app protection policy, Require a password change e Require terms of use.

Due dettagli che vale la pena fissare. Il primo: le policy vengono valutate dopo che la prima autenticazione è già stata completata, quindi Conditional Access non è la difesa di prima linea contro chi bussa alla porta, ma il filtro che decide se rilasciare il token. Il secondo: prima di accendere una policy la si porta in Report-only, uno stato in cui il motore valuta senza applicare nulla. Gli esiti compaiono nei tab Conditional Access e Report-only del dettaglio di un sign-in, con valori come Report-only: Success, Report-only: Failure, Report-only: User action required e Report-only: Not applied. Solo dopo si sposta il toggle Enable policy da Report-only a On. Conditional Access richiede Microsoft Entra ID P1.

MFA, authentication strength e i due rischi

Un’authentication strength è un controllo che specifica quali combinazioni di metodi l’utente può usare per accedere a una risorsa. Ne esistono tre predefinite: Multifactor authentication strength, Passwordless MFA strength e Phishing-resistant MFA strength. Attenzione a non confonderla con la Authentication methods policy, che decide quali metodi sono abilitati e per chi nel tenant: la strength restringe ulteriormente, scenario per scenario. E non si possono usare Require multifactor authentication e Require authentication strength nella stessa policy, perché la strength predefinita Multifactor authentication è l’equivalente del primo controllo.

ID Protection alimenta Conditional Access con due grandezze diverse, e qui nasce la confusione più comune. Il sign-in risk misura la probabilità che quel singolo accesso sia compromesso; lo user risk misura la probabilità che l’identità in sé lo sia, come nel caso di Leaked credentials. Le detection sono calcolate in tempo reale oppure offline, e confluiscono in tre report: Risk detections, Risky sign-ins e Risky users. ID Protection richiede Microsoft Entra ID P2.

Di conseguenza cambiano i controlli. Microsoft raccomanda, per la sign-in risk policy, di richiedere Require authentication strength con la strength predefinita Multifactor authentication quando il livello è High e Medium, aggiungendo il session control Sign-in frequency - Every time. Per la user risk policy si sceglie Require risk remediation al livello High: selezionandolo, Require authentication strength e Sign-in frequency - Every time vengono applicati automaticamente. Le due condizioni non vanno mai combinate nella stessa policy: si creano policy separate. E in entrambi i casi si escludono gli account emergency access o break-glass, per non restare chiusi fuori dal proprio tenant. Se la remediation automatica non basta, l’amministratore agisce a mano dai report con Dismiss, Confirm safe o Confirm compromised.

Lo stesso motore, ma sulle identità degli agenti

Conditional Access copre anche gli agenti, però i controlli disponibili non sono gli stessi che valgono per una persona, e questa è la distinzione che l’esame verifica più volentieri su questo dominio. Sotto Assignments > Users, agents (Preview) or workload identities si sceglie Agents, e poi All agent identities, All agent users (Preview), Select agent identities o Select agent users (Preview).

Quando la policy punta a una agent identity, l’unica condition disponibile è Agent risk (Preview) e l’unico access control è Block access, semplicemente perché non esiste una remediation interattiva: nessuno può rispondere a un prompt MFA al posto dell’agente. Quando invece punta a un agent’s user account, cioè l’account utente collegato all’agente, si aprono condition come Agent execution environments (Preview), Device platforms, Filter for devices e Network, e diventa possibile un Grant access con Require device to be marked as compliant. Da ricordare: una policy rivolta a All users non include gli account utente degli agenti, e una policy che punta alle agent identity non si applica ai loro account utente. Nei flussi on-behalf-of, infine, il soggetto del token è la persona, quindi si targettizzano utenti e gruppi, non l’identità dell’agente. Lato ID Protection esiste il report Risky Agents, con azioni Confirm compromise, Confirm safe, Dismiss risk e Disable, e il tab Agent detections dentro Risk detections; nei flussi on-behalf-of il rischio viene attribuito all’utente, non all’agente.

Capire cosa è successo davvero

La diagnosi parte da Entra ID > Monitoring & health > Sign-in logs, accessibili con almeno il ruolo Reports Reader. I log sono di quattro tipi (Interactive user sign-ins, Non-interactive user sign-ins, Service principal sign-ins, Managed identity sign-ins), affiancati dagli agent activity logs. Trovato l’evento, il tab Conditional Access mostra quali policy si sono applicate e con quale esito fra Success, Failure e Not applied; i tab Basic Info, Location, Device Info e Authentication Details spiegano quali segnali sono stati raccolti. Fra i codici ricorrenti, 53000 è DeviceNotCompliant e 53003 è BlockedByConditionalAccess.

Se il log non basta, si lancia il Sign-in diagnostic da Basic info > Troubleshoot Event, oppure da Diagnose & solve problems cercando per User, Application, correlationId o requestId; lo strumento produce un Authentication summary e dei Diagnostic results con raccomandazioni. Per ragionare in anticipo su una policy c’è invece il What If tool. Ultima distinzione da non sbagliare: i flagged sign-in non sono i risky sign-in. I primi sono errori che l’utente stesso segnala attivando Enable flagging dal messaggio di errore, valido venti minuti sullo stesso browser, e che l’amministratore ritrova con il filtro Flagged for review. I secondi sono una funzionalità di ID Protection. AB-650 è ancora in beta, quindi Microsoft non pubblica durata né numero di domande, ma la soglia di superamento resta 700.