Microsoft Entra ID Protection (già “Identity Protection”) è il servizio che analizza in continuo i segnali di autenticazione per individuare identità e sessioni compromesse, assegnare un livello di rischio e — se lo configuri — reagire in automatico tramite Conditional Access. Come Identity and Access Administrator devi saper distinguere i tipi di rischio, mapparli sulle policy corrette e gestire il ciclo di remediation.

Risk detection: da dove arrivano i segnali

Le risk detection sono i singoli eventi sospetti che il motore rileva. Alcune sono calcolate in tempo reale al momento del sign-in, altre offline (batch, tipicamente entro poche ore). Quelle da conoscere:

  • Leaked credentials: username/password comparsi in un data breach pubblico o nel dark web. È una detection offline e contribuisce allo user risk.
  • Atypical travel / impossible travel: due accessi da località geograficamente incompatibili nel tempo intercorso. È un segnale tipico di sign-in risk.
  • Anonymous IP address: accesso da rete Tor, VPN anonimizzanti o proxy usati per nascondere l’origine.
  • Altre: malicious IP, password spray, Microsoft Entra threat intelligence, unfamiliar sign-in properties, token anomaly.

Le detection premium (calcolo real-time e offline avanzato) richiedono Entra ID P2; con P1/Free vedi solo un rischio aggregato e non puoi automatizzare le policy.

User risk vs sign-in risk

La distinzione è centrale all’esame:

  • Sign-in risk: probabilità che quel singolo tentativo di accesso non provenga dal legittimo proprietario dell’identità (es. impossible travel, anonymous IP). Riguarda la sessione.
  • User risk: probabilità che l’account nel suo complesso sia compromesso (es. leaked credentials). Riguarda l’identità, e persiste finché non viene rimediato.

Entrambi sono classificati su tre livelli: low, medium, high. Nella policy scegli la soglia minima che fa scattare i controlli (es. “high and above” oppure “medium and above”).

Applicare le risk policy via Conditional Access

L’approccio moderno e raccomandato è integrare il rischio nelle Conditional Access policy (non più le legacy policy separate di Identity Protection). Il rischio diventa una condizione; il grant control definisce la reazione.

Sign-in risk policy

Condizione: Sign-in risk = high. Grant control: Require multifactor authentication. L’idea: se la sessione è sospetta, chiedi un secondo fattore. Se l’MFA riesce, la sessione viene ripulita (auto-remediation) e l’accesso procede.

User risk policy

Condizione: User risk = high. Grant control: Require password change (con MFA come prerequisito). Se l’account è probabilmente compromesso, un semplice MFA non basta: obblighi l’utente a resettare la password tramite self-service password reset (SSPR), il che azzera lo user risk.

Regola mnemonica: sign-in risk → MFA, user risk → password change. In entrambi i casi la remediation dell’utente (MFA superata o password cambiata) riporta il rischio a livello remediated.

Remediation e dismissal

Un rischio può essere chiuso in tre modi:

  • Self-remediation automatica: l’utente soddisfa il grant control (MFA o cambio password) e il rischio si azzera senza intervento admin.
  • Remediation manuale dell’admin: da Risky users puoi Reset password, Confirm user compromised (forza rischio high) o Confirm sign-in safe/compromised per addestrare il modello.
  • Dismiss user risk: chiudi il rischio senza alcuna azione correttiva. Usalo solo dopo indagine (falso positivo): non modifica la password né richiede nulla all’utente.

I dati (Risky users, Risky sign-ins, Risk detections) sono esportabili verso Microsoft Sentinel o un SIEM via diagnostic settings per correlazione e automazione (Logic Apps / SOAR).

Trappole tipiche d’esame

  • Scenario: vuoi abilitare le risk-based Conditional Access policy ma la tua tenant ha licenze P1. → Serve Microsoft Entra ID P2: le policy basate su user/sign-in risk (e le detection premium) non sono disponibili con P1/Free.
  • Scenario: ambiente ibrido con Password Hash Sync non attivo (solo federazione o pass-through auth), la detection leaked credentials non compare. → Il rilevamento leaked credentials richiede PHS: senza sincronizzazione degli hash, Entra non può confrontare le credenziali contro i breach.
  • Scenario: sospetti che un account sia compromesso e vuoi la reazione più forte. → User risk = high → Require password change (non solo MFA), così azzeri il rischio sull’identità.
  • Scenario: accesso legittimo da nuova sede segnalato come impossible travel. → Confirm sign-in safe oppure dismiss; usa MFA come grant per l’auto-remediation, non bloccare a priori.
  • Scenario: chiudi un rischio come falso positivo senza voler forzare azioni all’utente. → Dismiss user risk (non “Reset password”): il dismiss non richiede cambio credenziali.