Entra ID Risk Protection: Credenziali Trapelate, Utenti a Rischio Non Risolti

Entra ID Risk Protection: Credenziali Trapelate, Utenti a Rischio Non Risolti

Entra ID Risk Protection non ha alcuna difficoltà a individuare account compromessi. Il problema è ciò che accade dopo. In un gran numero di tenant si ripete lo stesso schema — Entra ID Risk Protection segnala credenziali trapelate e utenti a rischio che restano non risolti per settimane o mesi — perché il rilevamento scatta, finisce in un report e vi rimane. Questo articolo parla proprio di questo gap: non dell'ingegneria del rilevamento, di cui Microsoft si occupa già, ma del flusso di risposta che quasi nessuno mette in pratica.

Ogni utente a rischio in Entra ID ha uno stato di rischio associato. Microsoft Graph documenta i valori possibili come none, confirmedSafe, remediated, dismissed, atRisk e confirmedCompromised (oltre al valore sentinella unknownFutureValue). Solo tre di questi chiudono un account segnalato togliendolo dalla coda — remediated, dismissed e confirmedSafe, che corrispondono alle azioni manuali esposte da Microsoft: ignora, conferma sicuro, conferma compromissione. Sia atRisk che confirmedCompromised lasciano l'utente nel report degli utenti a rischio. atRisk significa che l'account è ancora segnalato e non è stata intrapresa alcuna azione. confirmedCompromised è quello che trae in inganno: un amministratore ha esaminato l'account, ha confermato che era compromesso, e lo stato da solo non significa comunque che qualcuno lo abbia messo in sicurezza.

Confermare la compromissione è un'azione di etichettatura, non di contenimento. Lo stesso vale per l'ignora (dismissal).

Anche l'arretrato non scade da solo. I rilevamenti e gli utenti a rischio basso "persistono nel prodotto per sei mesi, dopodiché vengono automaticamente rimossi" — ma i livelli di rischio medio e alto persistono finché non vengono risolti o ignorati. Un rilevamento di credenziali trapelate ad alto rischio sollevato due anni fa è ancora oggi nel report degli utenti a rischio, a meno che una persona o un criterio non lo abbia chiuso.

Come Funziona il Rilevamento delle Credenziali Trapelate

Le credenziali trapelate sono uno dei pochi rilevamenti di rischio che non presenta alcuna ambiguità.

Microsoft descrive la pipeline che sta dietro: un servizio di scansione delle credenziali su larga scala che monitora continuamente forum del dark web, repository di dump di violazioni, siti di paste, dati di sequestro delle forze dell'ordine e altre fonti, attraverso il Microsoft Threat Intelligence Center (MSTIC), la Microsoft Digital Crimes Unit (DCU) e partner del settore. Quando vengono scoperte delle credenziali, il servizio verifica il materiale delle credenziali effettive rispetto agli hash delle password correnti e valide del tenant, e un rilevamento viene emesso solo quando viene trovata una corrispondenza confermata. Nelle parole stesse di Microsoft, il rilevamento "è sempre ad alto rischio perché rappresenta un'esposizione di credenziali verificata, non un segnale euristico."

Ne derivano due conseguenze operative.

Primo, non è un punteggio di probabilità. Un viaggio atipico potrebbe essere semplicemente un utente in vacanza. Un rilevamento di credenziali trapelate significa che una password attualmente funzionante nel vostro tenant è nelle mani di qualcun altro. Merita un incidente, non una coda di triage.

Secondo, lo si scopre in ritardo. Le credenziali trapelate vengono calcolate offline, e Microsoft documenta che "i rilevamenti attivati in tempo reale impiegano dai 5 ai 10 minuti per mostrare i dettagli nei report. I rilevamenti offline impiegano fino a 48 ore per comparire nei report." La finestra tra l'esposizione e la prima possibilità di agire si misura in giorni, ed è esattamente per questo che la risposta deve essere rapida non appena il segnale arriva.

La sincronizzazione hash delle password conta qui più di quanto la maggior parte dei team si renda conto. Un reset password basato su cloud tramite Microsoft Entra risolve il rischio utente per questo rilevamento sia per le password cloud che per quelle on-premises — ma solo "purché la sincronizzazione hash delle password (PHS) sia abilitata per le password on-premises."

Perché l'Arretrato degli Utenti a Rischio Non Si Svuota Mai

I tenant con gli arretrati peggiori raramente sono quelli che hanno ignorato il prodotto. Sono quelli in cui si sommano diverse piccole lacune.

Gli avvisi non raggiungono nessuno. L'email "Utenti a rischio rilevati" ha per impostazione predefinita una soglia di rischio utente Alto. Per impostazione predefinita, gli utenti a cui sono attivamente assegnati i ruoli Global Administrator, Security Administrator o Security Reader vengono aggiunti all'elenco dei destinatari, e devono avere configurato un indirizzo Email o Email alternativa. Due avvertenze documentate rompono silenziosamente questo meccanismo: un utente che sale a uno di questi ruoli tramite Privileged Identity Management "riceve email solo se è elevato al momento in cui l'email viene inviata," e "l'invio di email agli utenti con ruoli assegnati tramite gruppo non è supportato." Un tenant che concede Security Reader tramite un gruppo ed eleva gli amministratori su richiesta tramite PIM può ricevere esattamente zero notifiche mentre la sua dashboard si riempie.

Le soglie dei criteri sono impostate al di sopra della maggior parte della coda. La configurazione consigliata da Microsoft è un criterio di rischio utente su Alto e un criterio di rischio di accesso su Medio e Alto. È una guida solida, ma significa che ogni rilevamento di rischio utente medio e ogni rilevamento a basso rischio vengono lasciati a una persona, e i rischi medi persistono finché qualcuno non li chiude.

L'auto-risoluzione non è realmente disponibile. Microsoft avverte che "gli utenti devono registrarsi per l'autenticazione a più fattori di Microsoft Entra prima di trovarsi in una situazione che richiede la risoluzione. Per gli utenti ibridi sincronizzati da on-premises, deve essere abilitato il writeback della password. Gli utenti non registrati vengono bloccati e richiedono l'intervento dell'amministratore." Anche gli utenti ibridi hanno bisogno di PHS oltre all'impostazione opzionale Consenti la modifica della password on-premises per reimpostare il rischio utente, prima che una modifica della password on-premises possa azzerare il loro rischio. Dove questi prerequisiti mancano, il criterio non svuota la coda — trasforma gli utenti a rischio in utenti bloccati e scarica il lavoro sull'help desk.

Alcuni rilevamenti hanno smesso di risolversi automaticamente. Microsoft non risolve più automaticamente le sessioni che portano rivendicazioni MFA quando scatta un rilevamento legato al furto di token o il rilevamento IP di un attore di minaccia verificato. I rilevamenti interessati sono Microsoft Entra threat intelligence, Token anomalo, Attacker in the Middle, IP di attore di minaccia verificato e Anomalia dell'emittente del token. Quando uno di questi colpisce un utente, azzerare il rischio richiede una modifica sicura della password e una nuova autenticazione con MFA. Se il vostro modello mentale è ancora "l'MFA risolve tutto," questi casi si accumulano.

Gli utenti eliminati restano bloccati per sempre. "Se un utente è stato eliminato dalla directory e presentava un rischio, quell'utente compare ancora nel report dei rischi anche se l'account è stato eliminato. Gli amministratori non possono ignorare il rischio per gli utenti eliminati dalla directory." Rimuoverli richiede l'apertura di un caso di supporto Microsoft. Ogni utente a rischio disattivato gonfia permanentemente il conteggio, il che porta il team a smettere di fidarsi del numero.

L'automazione legacy ha una data di scadenza. Le indicazioni di Microsoft sono esplicite: "i criteri di rischio legacy configurati in Microsoft Entra ID Protection saranno ritirati il 1° ottobre 2026." I tenant la cui unica risposta automatizzata è un criterio di rischio ID Protection legacy — anziché un criterio di accesso condizionale — lo perderanno, e un arretrato che veniva svuotato automaticamente ricomincerà a crescere.

Rilevamento: Misurate il Vostro Arretrato di Risoluzione

I report del portale vi dicono chi è a rischio. Non vi dicono per quanto tempo le persone restano a rischio, che è il numero che conta davvero. Per questo servono i dati di rischio in Log Analytics.

Configurate le impostazioni diagnostiche in Entra ID > Monitoraggio e integrità > Impostazioni diagnostiche ed esportate le categorie RiskyUsers e UserRiskEvents (Microsoft espone anche RiskyServicePrincipals, ServicePrincipalRiskEvents, RiskyAgents e AgentRiskEvents). Confluiscono nelle tabelle AADRiskyUsers e AADUserRiskEvents.

Cosa monitorare

Rilevamenti di credenziali trapelate ancora aperti

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskEventType == "leakedCredentials"
| where RiskState == "atRisk"
| project DetectedDateTime, UserPrincipalName, RiskLevel, RiskState, RiskDetail, DetectionTimingType
| order by DetectedDateTime asc

Ogni riga è un account la cui password risulta esposta e che nessuno ha ancora toccato. Ordinato dal più vecchio, l'inizio di questo elenco rappresenta la vostra esposizione peggiore.

Da quanto tempo esiste l'arretrato a rischio

AADRiskyUsers
| summarize arg_max(TimeGenerated, RiskState, RiskLevel, RiskDetail, RiskLastUpdatedDateTime)
    by UserPrincipalName
| where RiskState == "atRisk"
| where RiskLevel in ("high", "medium")
| extend DaysAtRisk = datetime_diff('day', now(), RiskLastUpdatedDateTime)
| project UserPrincipalName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime, DaysAtRisk
| order by DaysAtRisk desc

AADRiskyUsers riceve un record ogni volta che lo stato di rischio di un utente cambia, quindi arg_max riduce il flusso all'ultimo stato noto per ogni utente prima di calcolare l'età.

Verificare l'uso del pulsante ignora

AADRiskyUsers
| where TimeGenerated > ago(90d)
| where RiskState == "dismissed" and RiskDetail == "adminDismissedAllRiskForUser"
| project TimeGenerated, UserPrincipalName, RiskLevel, RiskDetail
| order by TimeGenerated desc

Ignorare è un esito legittimo dopo un'indagine. È anche il modo più rapido per far apparire sana una dashboard. Confrontate questo elenco con il vostro sistema di ticketing: un'azione di ignora senza un corrispondente record di indagine è una decisione che nessuno potrà giustificare in seguito.

Tempo di chiusura, per tipo di rilevamento

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskLevel == "high"
| where RiskState in ("remediated", "dismissed", "confirmedCompromised")
| extend HoursToClose = datetime_diff('hour', LastUpdatedDateTime, DetectedDateTime)
| summarize Detections = count(),
            MedianHours = percentile(HoursToClose, 50),
            P90Hours = percentile(HoursToClose, 90)
    by RiskEventType
| order by Detections desc

Questa è la metrica da presentare al management. "Abbiamo 40 utenti a rischio" fa alzare le spalle; "il nostro tempo mediano per chiudere una credenziale trapelata confermata è di 26 giorni" no.

Interrogare gli stessi dati da Microsoft Graph

L'API riskyUsers richiede una licenza Microsoft Entra ID P2 (o Microsoft Entra Suite). La lettura richiede l'autorizzazione IdentityRiskyUser.Read.All, e per l'accesso delegato l'utente autenticato deve avere il ruolo Global Reader, Security Operator, Security Reader o Security Administrator.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskState eq 'atRisk' and riskLevel eq 'high'

L'endpoint supporta $filter e $select, con una dimensione massima della pagina di 500 oggetti tramite $top. La stessa query tramite il Graph PowerShell SDK:

Import-Module Microsoft.Graph.Identity.SignIns

Get-MgRiskyUser -Filter "riskState eq 'atRisk' and riskLevel eq 'high'" -All |
    Select-Object UserPrincipalName, RiskLevel, RiskState, RiskDetail, RiskLastUpdatedDateTime

Eseguitela su base pianificata e impostate un avviso sul conteggio, non sui singoli eventi. Un arretrato che cresce settimana dopo settimana è il vero elemento da segnalare.

Risoluzione: Svuotare la Coda e Mantenerla Svuotata

1. Sapere cosa fa davvero ciascuna azione

Prima di automatizzare qualsiasi cosa, assicuratevi che il team concordi sul significato di ciascun pulsante. Microsoft documenta lo stato e il dettaglio risultanti per ogni percorso:

La nomenclatura è genuinamente confusa e Microsoft lo segnala: il dettaglio del rischio "L'utente ha eseguito un reset sicuro della password" è un'etichetta riportata dal sistema che indica che l'utente ha completato una modifica sicura della password (MFA seguita da una modifica della password), non un flusso di reset password self-service.

Da notare anche la suddivisione dei ruoli — Security Operator è il ruolo con i privilegi minimi necessari per ignorare il rischio utente, mentre User Administrator è richiesto per reimpostare le password. Reimpostare una password dall'interno di ID Protection richiede entrambi.

2. Lavorare una volta sola, manualmente, l'arretrato delle credenziali trapelate

I passaggi di indagine di Microsoft per questo rilevamento sono specifici e rappresentano il runbook corretto per svuotare la coda esistente:

1. Valutare l'ampiezza dell'esposizione — esaminare la cronologia del rischio dell'utente e i log di accesso alla ricerca di rischi di accesso correlati (posizioni non familiari, indirizzi IP anonimi, viaggi atipici).
2. Verificare se la password è già stata modificata dopo il rilevamento del leak; in tal caso, il rischio potrebbe già essersi auto-risolto.
3. Bloccare l'accesso se un attaccante è attivo — bloccare l'utente, reimpostare la password e revocare tutti i refresh token laddove i log mostrino un accesso non autorizzato.
4. Verificare l'eventuale movimento laterale — escalation dei privilegi, nuove registrazioni di app, modifiche alle regole della cassetta postale, accesso a risorse sensibili.
5. Verificare gli account collegati — se l'utente riutilizza le password, trattate la credenziale come compromessa anche al di fuori del vostro tenant.

3. Fare in modo che "conferma compromissione" attivi il contenimento

Confermare la compromissione imposta il livello di rischio su alto e alimenta i modelli di Microsoft, ma Microsoft elenca le azioni di contenimento separatamente: richiedere una modifica della password, bloccare l'utente se l'attaccante può reimpostare la password o eseguire l'MFA, revocare i refresh token, disabilitare eventuali dispositivi ritenuti compromessi e revocare tutti i token di accesso se si utilizza la valutazione continua dell'accesso.

Automatizzate l'etichettatura in modo che il tempo umano vada al contenimento:

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/confirmCompromised
Content-Type: application/json

{
  "userIds": [
    "29f270bb-4d23-4f68-8a57-dc73dc0d4caf",
    "20f91ec9-d140-4d90-9cd9-f618587a1471"
  ]
}

Questa azione richiede IdentityRiskyUser.ReadWrite.All, con Security Administrator come ruolo supportato a privilegi minimi, e restituisce 204 No Content in caso di successo.

4. Automatizzare lo stato stazionario con l'accesso condizionale

Lo svuotamento manuale non è scalabile. Due criteri di accesso condizionale basati sul rischio mantengono la coda vicina allo zero, e Microsoft è esplicita sul fatto che devono essere separati — "non combinate le condizioni di rischio di accesso e rischio utente nello stesso criterio di accesso condizionale."

• Criterio di rischio utente: selezionate Richiedi risoluzione del rischio quando il rischio utente è Alto. Selezionandolo si applica automaticamente Richiedi robustezza dell'autenticazione come controllo di concessione e Frequenza di accesso – Ogni volta come controllo di sessione.
• Criterio di rischio di accesso: richiedete l'autenticazione a più fattori quando il rischio di accesso è Medio o Alto, con la frequenza di accesso impostata su ogni volta.

Escludete gli account di accesso di emergenza e le entità servizio, iniziate in modalità solo report e confermate l'impatto prima di passare ad Attivo. Il percorso di configurazione completo è disponibile in Azure Identity Protection: Criteri di Rischio — e la modalità solo report è una fase di implementazione, non una destinazione, una trappola trattata in Accesso condizionale solo report, esclusioni obsolete: cosa significa davvero «applicato». Definite prima correttamente l'elenco delle esclusioni, seguendo le indicazioni in Account di Accesso di Emergenza Break Glass Entra ID: Assenti, Non Monitorati, Non Esclusi, e verificate l'insieme dei criteri nel suo complesso rispetto a Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione.

5. Correggere i prerequisiti che bloccano l'auto-risoluzione

• Verificate che gli utenti siano registrati per l'MFA prima che il criterio diventi attivo; gli utenti non registrati vengono bloccati anziché risolti. La copertura della registrazione è solo metà della storia — vedere Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta.
• Per le identità ibride, abilitate la sincronizzazione hash delle password e attivate Consenti la modifica della password on-premises per reimpostare il rischio utente in Protezione > Identity Protection > Impostazioni. Microsoft precisa che questa opzione è solo opt-in e raccomanda di mettere in sicurezza il processo di modifica della password on-premises — ad esempio richiedendo l'MFA prima di una modifica on-premises.

6. Instradare le notifiche verso qualcuno che le legge

Verificate che i destinatari dell'avviso Utenti a rischio rilevati dispongano di un indirizzo Email o Email alternativa valido, non dipendano da ruoli assegnati tramite gruppo, e tengano conto della tempistica dell'elevazione PIM. Valutate di abbassare la soglia di avviso al di sotto del valore predefinito Alto se il vostro team ha la capacità di gestirlo, e attivate il digest settimanale per la visibilità sui trend.

7. Migrare dai criteri di rischio legacy

Se l'applicazione del rischio risiede ancora nei criteri ID Protection legacy anziché nell'accesso condizionale, migrate prima del 1° ottobre 2026: create i criteri di accesso condizionale equivalenti in modalità solo report, validateli, attivateli, quindi disabilitate i vecchi criteri in ID Protection > Dashboard.

Come EtcSec Rileva Questo Problema

EtcSec verifica il percorso di risposta, non solo il livello di rilevamento.

I controlli Risk Protection segnalano RISK_LEAKED_CREDENTIALS (Credenziali Trapelate Non Bloccate) quando gli account con credenziali compromesse confermate sono ancora attivi e non bloccati, e RISK_USERS_NOT_REMEDIATED (Utenti a Rischio Non Risolti) quando gli account segnalati come a rischio non sono mai stati risolti o ignorati. Entrambi sono classificati come Critici, perché entrambi descrivono un account che un attaccante può utilizzare attualmente.

Accanto a questi, RISK_HIGH_RISK_USERS_ACTIVE mette in evidenza gli utenti ad alto rischio i cui account restano abilitati, RISK_SIGNINS_NOT_INVESTIGATED individua gli accessi a rischio senza alcun follow-up, e RISK_NO_AUTOMATED_RESPONSE identifica i tenant in cui il rischio è visibile ma non esiste alcun contenimento automatizzato.

Per la revisione più ampia del tenant in cui si inseriscono questi controlli, vedere Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica. Per i rilevamenti lato accesso che alimentano il rischio utente, vedere Entra ID AiTM Token Replay: Rilevamento Viaggi Impossibili e Fatica MFA e Password Spraying: rilevamento e prevenzione per Active Directory ed Entra ID.

Riferimenti Principali

• What are risk detections? — Microsoft Entra ID Protection
• Risk detection types and levels
• Remediate risks and unblock users
• Investigate risk with Microsoft Entra ID Protection
• Risk policies — Microsoft Entra ID Protection
• Configure Microsoft Entra ID Protection notifications
• Export and use Microsoft Entra ID Protection data
• What is Microsoft Entra ID Protection?
• riskyUser resource type — Microsoft Graph v1.0
• riskyUser: confirmCompromised — Microsoft Graph v1.0
• List riskyUsers — Microsoft Graph v1.0
• Azure Monitor Logs reference — AADRiskyUsers
• Azure Monitor Logs reference — AADUserRiskEvents