Cos'e Azure Identity Protection?
Azure Identity Protection, ora Microsoft Entra ID Protection, e lo strato di rilevamento e risposta al rischio per le identita Microsoft Entra. Valuta segnali che possono indicare una compromissione dell'account e li espone come rischio utente, rischio di accesso, utenti a rischio e rilevazioni di rischio.
Il punto operativo importante e che il solo rilevamento non contiene un attacco. Un tenant puo mostrare utenti a rischio e accessi a rischio nel portale pur continuando a consentire all'aggressore di proseguire se nessun criterio richiede rimedio, autenticazione a piu fattori, ri-autenticazione, cambio password o blocco. Questo articolo si concentra proprio su questa lacuna: il rischio e visibile, ma la risposta del tenant e assente, incompleta o troppo limitata.
Le indicazioni attuali di Microsoft collocano i controlli basati sul rischio nell'Accesso Condizionale. I criteri di rischio legacy di Identity Protection esistono ancora in alcuni tenant, ma la documentazione Microsoft indica che i criteri legacy di rischio utente e rischio di accesso devono essere migrati verso l'Accesso Condizionale e che il loro ritiro e previsto per il 1 ottobre 2026.
Come Funziona Azure Identity Protection
Identity Protection utilizza due concetti di rischio strettamente collegati:
Il rischio di accesso e la probabilita che una specifica richiesta di autenticazione non provenga dal legittimo proprietario dell'identita. Viene valutato durante l'accesso e puo essere usato come condizione nell'Accesso Condizionale.
Il rischio utente e la probabilita che l'account utente stesso sia compromesso. Puo persistere oltre un singolo accesso e puo richiedere cambio password, revoca della sessione, indagine da parte di un amministratore o archiviazione.
Microsoft documenta rilevazioni di rischio come credenziali divulgate, indirizzo IP anonimo, viaggio atipico, proprieta di accesso insolite, indirizzo IP dannoso, regole sospette di manipolazione della posta in arrivo, spray di password, token anomalo e altri segnali. Alcune rilevazioni sono in tempo reale, mentre altre vengono calcolate offline e possono comparire in seguito. Questa tempistica ha rilevanza operativa: un evento di rischio puo emergere dopo che l'autenticazione originale e gia stata completata.
Perche i Criteri di Rischio Falliscono in Pratica
Identity Protection rende meno di quanto dovrebbe quando i team trattano la dashboard come se fosse il controllo. Le modalita di fallimento comuni includono:
- nessun criterio di Accesso Condizionale utilizza le condizioni di rischio di accesso o rischio utente
- i criteri restano in modalita solo report dopo i test
- i criteri di rischio coprono gli utenti pilota ma non gli utenti privilegiati ne la popolazione generale
- gli account di emergenza sono esclusi senza un monitoraggio compensativo
- gli utenti ibridi non possono completare l'auto-rimedio perche il password writeback non e disponibile dove necessario
- le notifiche sugli utenti a rischio arrivano a una casella di posta che nessuno controlla
- gli analisti possono archiviare il rischio senza uno standard di evidenza documentato
- i service principal vengono confusi con una copertura di Accesso Condizionale destinata agli utenti
L'ultimo punto e importante. I criteri di rischio utente e rischio di accesso sono destinati agli accessi degli utenti. Il rischio delle identita di workload e dei service principal richiede un modello di controllo diverso e non deve essere dato per scontato come coperto dai criteri di rischio utente pensati per le persone.
La Catena di Attacco Senza Risposta al Rischio
Scenario 1 - Credenziali Divulgate
Le credenziali di un utente compaiono in dati di breach o vengono altrimenti valutate come rischiose. Identity Protection alza il rischio utente, ma nessun criterio di rischio utente richiede il rimedio. L'account resta utilizzabile finche un altro controllo non blocca l'aggressore.
Scenario 2 - Un Accesso a Rischio che Va Comunque a Buon Fine
Un accesso presenta un rischio medio o alto a causa di segnali come infrastruttura anonima, proprieta di accesso insolite o viaggio atipico. Se non si applica alcun criterio di rischio di accesso, la sessione puo comunque completarsi. Esiste una voce di log, ma l'aggressore ha gia ottenuto l'accesso.
Scenario 3 - Spray di Password Contro Account Cloud
Una campagna di spray di password genera un ampio rumore di autenticazione e puo produrre rilevazioni rischiose. Se gli accessi riusciti non vengono forzati attraverso un'autenticazione rafforzata (step-up) o bloccati secondo il criterio, l'aggressore mantiene le sessioni riuscite.
Scenario 4 - Rischio Archiviato Senza Indagine
Un utente a rischio viene archiviato perche l'avviso risulta scomodo o rumoroso. Se il processo di archiviazione non richiede prove, il tenant puo normalizzare una compromissione reale ed eliminare il segnale di cui i difensori avevano bisogno.
Rilevamento
Segnali di Rischio da Monitorare
| Segnale | Cosa Indica | Uso Operativo |
|---|---|---|
| Credenziali divulgate | Sono state trovate credenziali associate all'account in materiale compromesso noto | Trattare come prova di compromissione dell'account fino alla revisione |
| Indirizzo IP anonimo | L'accesso proviene da infrastruttura di anonimizzazione | Correlare con dispositivo, posizione e cronologia utente |
| Viaggio atipico | La geografia dell'accesso e incoerente con l'attivita recente | Rivedere gli schemi di viaggio impossibili o sospetti |
| Proprieta di accesso insolite | L'accesso differisce dal comportamento normale dell'utente | Utile se combinato con il contesto di dispositivo e posizione |
| Indirizzo IP dannoso | L'infrastruttura di origine e associata ad attivita dannosa | Urgenza maggiore per gli utenti privilegiati |
| Spray di password | Viene rilevato un comportamento esteso di indovinamento password | Correlare con blocchi, fallimenti e accessi riusciti |
| Token anomalo | Il comportamento del token appare sospetto | Rivedere l'attivita di sessione e revocare quando opportuno |
Eventi e Report da Rivedere
Il rilevamento dovrebbe includere:
- il report degli utenti a rischio
- il report delle rilevazioni di rischio
- i log di accesso con livello e dettaglio del rischio
- i risultati di Accesso Condizionale per gli accessi a rischio
- i log di controllo per l'archiviazione del rischio, il ripristino della password, le modifiche ai criteri e le azioni amministrative
- il contesto del ruolo privilegiato per le identita interessate
Un accesso ad alto rischio per un amministratore globale non ha la stessa priorita operativa di un evento a basso rischio per un account di test inattivo. L'avviso dovrebbe includere ruolo, dispositivo, posizione, app, risultato del criterio ed esito della sessione.
Rimedio
Identity Protection diventa utile quando il rischio attiva una risposta. Una dashboard senza Accesso Condizionale applicato e solo visibilita.
1. Configurare Criteri di Rischio Separati
Le indicazioni Microsoft sconsigliano di combinare le condizioni di rischio utente e rischio di accesso nello stesso criterio di Accesso Condizionale. Create criteri separati in modo che ogni condizione di rischio abbia un percorso di risposta chiaro.
Per il rischio di accesso, Microsoft consiglia di richiedere l'autenticazione a piu fattori per rischio medio e alto. Per il rischio utente, Microsoft consiglia di richiedere il rimedio del rischio quando il rischio utente e alto. Le organizzazioni possono scegliere soglie piu rigide, ma devono bilanciare sicurezza, falsi positivi e interruzione dell'utente.
2. Usare la Modalita Solo Report, Poi Applicare
La modalita solo report e utile per il rollout. Non e uno stato finale. Verificate quali utenti, app e scenari sarebbero interessati, correggete le rotture previste, quindi passate il criterio su Attivo. Mantenete una registrazione datata del rollout in modo che i criteri in modalita solo report non diventino residui permanenti.
3. Far Funzionare l'Auto-Rimedio
L'auto-rimedio dipende da prerequisiti. Gli utenti devono essere registrati per l'autenticazione a piu fattori di Microsoft Entra prima di poter soddisfare il rimedio basato su MFA. Gli utenti ibridi possono richiedere il password writeback per gli scenari di cambio password sicuro. Se questi prerequisiti mancano, gli utenti possono essere bloccati e richiedere l'intervento dell'amministratore.
4. Definire il Flusso di Lavoro dell'Analista
Un criterio di rischio non sostituisce l'indagine. Definite chi puo:
- confermare la compromissione di un utente
- archiviare il rischio utente
- ripristinare le password
- revocare le sessioni
- sbloccare gli utenti
- approvare le esclusioni
- aggiornare le soglie di rischio dell'Accesso Condizionale
Ogni azione dovrebbe avere uno standard di evidenza. Archiviare il rischio perche l'utente dichiara di aver viaggiato non equivale a validare dispositivo, IP, metodo di autenticazione e attivita di sessione.
5. Rivedere le Esclusioni e gli Account di Servizio
Gli account di accesso di emergenza possono richiedere un trattamento speciale, ma le esclusioni dovrebbero essere poche e fortemente monitorate. Gli account di servizio e le identita di workload non dovrebbero essere esclusi silenziosamente dalla conversazione sul rischio; possono richiedere Accesso Condizionale per identita di workload, identita gestite, rotazione delle credenziali o un monitoraggio diverso.
Sequenza di Rollout Sicura
Un rollout sicuro non inizia bloccando l'intero tenant senza prove. Iniziate con criteri in modalita solo report per la popolazione prevista, rivedete l'impatto del criterio, correggete i prerequisiti di registrazione e password writeback, quindi applicate il criterio per fasi. Le identita privilegiate dovrebbero avere priorita perche un accesso a rischio riuscito per un amministratore ha un raggio d'impatto molto piu ampio dello stesso evento su un account a basso privilegio.
Mantenete il rollout misurabile. Tracciate quanti accessi a rischio sarebbero stati bloccati o sfidati, quanti utenti hanno potuto auto-rimediarsi, quali account sono esclusi e quali incidenti hanno richiesto l'azione dell'amministratore. Questi numeri aiutano a distinguere un programma di protezione funzionante da un criterio che esiste ma non puo essere applicato in sicurezza.
Validazione Dopo l'Attivazione della Risposta al Rischio
Validate il controllo sia dal portale sia dalla prospettiva dell'aggressore:
- confermate che i criteri di rischio di accesso e rischio utente siano attivati, non solo configurati
- confermate che gli utenti target includano identita privilegiate e utenti normali nell'ambito
- confermate che gli utenti esclusi siano documentati e monitorati
- rivedete gli accessi a rischio recenti e verificate che il risultato del criterio previsto sia stato applicato
- confermate che gli accessi ad alto rischio riusciti siano rari, spiegabili e indagati
- confermate che gli amministratori possano confermare la compromissione, archiviare il rischio, revocare le sessioni e ripristinare le credenziali usando flussi di lavoro documentati
- testate l'instradamento degli avvisi in modo che le notifiche sugli utenti a rischio raggiungano il team di risposta
- rivedete se le identita di workload richiedono Accesso Condizionale o monitoraggio separati
Se il tenant rileva il rischio ma consente agli utenti a rischio di continuare senza rimedio, il controllo e incompleto.
Come EtcSec Rileva Questo
EtcSec verifica se le rilevazioni di rischio sono collegate a un percorso di risposta applicato.
La categoria Risk Protection evidenzia l'assenza del criterio di rischio di accesso, l'assenza del criterio di rischio utente e una risposta debole del tenant in cui l'attivita rischiosa e visibile ma l'applicazione e assente o incompleta.
Questa e la lacuna operativa al centro di questo articolo: rilevazioni di rischio senza contenimento.
Controlli Correlati
Identity Protection funziona meglio se abbinata a Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta, Lacune Accesso Condizionale Azure: Bypass MFA, Accesso Privilegiato Azure: Troppi Admin Globali, Account Guest Azure: governance, MFA e rischio di accesso esterno, e App Azure con Privilegi Eccessivi nel Tenant. Altrimenti il tenant potrebbe rilevare il rischio ma lasciare comunque facilmente sfruttabili i percorsi adiacenti di privilegio e applicazione.
Riferimenti Principali
Esplora le pagine di identity security collegate a questo tema