Account di Accesso di Emergenza Break Glass Entra ID: Assenti, Non Monitorati, Non Esclusi

Cos'è un account di accesso di emergenza Break Glass Entra ID

Un account di accesso di emergenza break-glass Entra ID è un account Global Administrator tenuto di riserva per l'unico scenario che tutti gli altri percorsi di amministrazione sono progettati per evitare: il blocco totale. Le linee guida ufficiali di Microsoft elencano le situazioni per cui esistono questi account — un'interruzione della federazione che lascia bloccato ogni admin sincronizzato, un guasto del dispositivo o del servizio MFA che blocca l'attivazione di un ruolo, l'uscita dell'ultimo Global Administrator attivo, un disastro naturale che mette fuori uso le reti telefoniche, o uno stallo di approvazione nel Privileged Identity Management (PIM) in cui ogni assegnazione idonea di Global Administrator o Privileged Role Administrator necessita di un approvatore e nessuno è attivo. Per una visione più ampia di come le assegnazioni PIM e il numero di Global Admin permanenti guidino il rischio del tenant, vedi Accesso Privilegiato Azure: Troppi Admin Globali.

Nessuno di questi casi è esotico. Sono i casi limite specifici che "basta usare l'MFA" e "basta usare il PIM" non coprono, perché l'MFA e il PIM sono esattamente ciò che può fallire.

Il gap di governance trattato in questo articolo non è il concetto — la maggior parte dei team di sicurezza ha già sentito parlare degli account break-glass. È che il catalogo di audit di Microsoft rileva tre modi distinti e comuni in cui il controllo fallisce in tenant reali:

1. Non esiste alcun account di accesso di emergenza (PA_NO_EMERGENCY_ACCOUNTS) — il caso base, e secondo il catalogo di EtcSec la severità critica di default: zero copertura break-glass significa zero percorso di recupero se il percorso di amministrazione primario fallisce.
2. L'account esiste ma non è escluso dal Conditional Access (PA_EMERGENCY_NO_EXCLUSION / CA_NO_BREAK_GLASS_EXCLUSION) — cosicché proprio la policy pensata per proteggere il tenant è ciò che blocca l'account di recupero durante l'emergenza per cui è stato creato.
3. L'account esiste ed è escluso, ma nessuno lo monitora (PA_EMERGENCY_NO_MONITORING) — cosicché un evento di accesso che dovrebbe far scattare tutti gli allarmi (un account Global Admin fuori dai normali controlli CA che si è appena autenticato) non genera alcun avviso.

Un quarto gap correlato appare nella stessa famiglia del catalogo: credenziali obsolete (PA_EMERGENCY_CREDENTIAL_STALE) — un account di emergenza il cui metodo di autenticazione o dispositivo non è stato validato da così tanto tempo che nessuno sa davvero se funziona ancora.

Come si verifica il gap in pratica

Gli account break-glass vengono solitamente creati una sola volta, durante la configurazione iniziale del tenant o un'iniziativa di compliance, e poi lasciati inutilizzati — il che è precisamente il problema, perché "lasciati inutilizzati" vale in entrambi i sensi.

Completamente assente

I tenant più piccoli, i tenant migrati da un provider di identità più vecchio, o i tenant che hanno considerato "tutti i nostri admin hanno l'MFA" come copertura sufficiente, spesso non hanno alcun account di accesso di emergenza dedicato. Microsoft raccomanda di creare due o più account solo cloud sul dominio predefinito *.onmicrosoft.com del tenant — non federati, non sincronizzati da on-premises — proprio affinché un'interruzione locale o di federazione non elimini anche il percorso di recupero insieme a tutto il resto.

Non escluso dal Conditional Access

Questa è la modalità di fallimento che trasforma un controllo in una trappola. Una policy CA che richiede un dispositivo conforme, un metodo MFA specifico, o blocca in base alla posizione, si applicherà tranquillamente all'account di emergenza come a qualsiasi altro Global Administrator — il che significa che proprio la policy che dovrebbe proteggere il tenant diventa il motivo per cui l'account di emergenza non riesce ad accedere durante l'interruzione o il blocco per cui esiste. Microsoft è esplicita su questo punto: escludi gli account break-glass da qualsiasi policy CA che blocchi o limiti l'accesso; le policy in modalità solo report non bloccano l'accesso e non necessitano dell'esclusione. Questo è un caso specifico di uno schema più ampio — vedi Lacune accesso condizionale Entra ID su come gli errori nell'ambito di esclusione emergano nelle policy in generale.

Non monitorato

Anche con un account creato ed escluso correttamente, la maggior parte dei tenant non ha alcun avviso sul suo utilizzo. Un account break-glass è progettato per non accedere quasi mai. Questa proprietà rende il monitoraggio economico e ad alto segnale: qualsiasi autenticazione da quell'account è o un'esercitazione di validazione programmata o un incidente attivo (un'emergenza legittima, oppure un attaccante che ha trovato e compromesso l'unico account esplicitamente escluso dall'applicazione della policy). Senza un avviso permanente, questo segnale resta invisibile finché qualcuno non controlla per caso i log di accesso — cosa che, per la maggior parte dei tenant, è rara o non accade mai. Questo punto cieco si affianca ai gap di segnale di rischio più ampi trattati in Azure Identity Protection: Criteri di Rischio.

Rilevamento

Verifica lo stato della copertura degli account di accesso di emergenza break-glass con questi controlli, mappati alle voci del catalogo:

Costruire la query di avviso per l'accesso

Per il controllo di monitoraggio in particolare, l'approccio documentato da Microsoft è una regola di avviso su log personalizzato di Log Analytics sulla tabella SigninLogs, indicizzata sull'Object ID dell'account (disponibile in Entra ID → Users → [account] → Object ID):

// Alert query — any sign-in from an emergency access account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Imposta il valore di soglia dell'avviso su 0 (maggiore di), la severità su 0 – Critica, e collega un gruppo di azioni che invii e-mail e SMS al tuo team di sicurezza — perché, secondo le linee guida di Microsoft, qualsiasi accesso da questo account dovrebbe scatenare una revisione, che si tratti di un'esercitazione programmata o di un incidente reale.

Raccogli anche le voci del log di audit dell'account (non solo il log di accesso) — modifiche alle assegnazioni di ruolo, registrazioni di credenziali e modifiche di appartenenza a policy CA che riguardano l'account sono tutti eventi che meritano un avviso indipendentemente dall'attività di accesso. Se stai costruendo questo tipo di controllo come parte di una revisione più ampia del tenant piuttosto che come azione isolata, Come auditare la sicurezza di Microsoft Entra ID illustra l'intero ambito di revisione in cui questo si inserisce.

Correzione

1. Crea almeno due account di accesso di emergenza. Solo cloud, dominio *.onmicrosoft.com, non federati né sincronizzati. Le linee guida di Microsoft raccomandano due o più account affinché una singola credenziale compromessa o non disponibile non elimini del tutto la capacità di recupero.
2. Usa un'autenticazione senza password resistente al phishing. La passkey (FIDO2) è il metodo raccomandato da Microsoft; l'autenticazione basata su certificati è l'alternativa se la tua organizzazione gestisce già una PKI. Non riutilizzare il metodo MFA usato dai tuoi account admin normali — se la notifica push di Microsoft Authenticator è standard per gli admin, metti invece l'account di emergenza su una chiave hardware FIDO2, così che un'unica interruzione o classe di compromissione non elimini entrambi i percorsi contemporaneamente.
3. Assegna il ruolo Global Administrator come permanente, attivo — non idoneo — in PIM. Un account di emergenza bloccato dietro un passaggio di attivazione PIM vanifica lo scopo se il PIM stesso fa parte dell'interruzione.
4. Escludi gli account da ogni policy Conditional Access che blocchi o limiti l'accesso. Crea un gruppo di sicurezza dedicato (nome di esempio di Microsoft: EmergencyAccess) ed escludi quel gruppo dalle policy applicate — le policy solo-report non necessitano dell'esclusione poiché non possono bloccare l'accesso. Riverifica l'elenco di esclusione ogni volta che viene rilasciata una nuova policy CA.
5. Configura il monitoraggio degli accessi prima di averne bisogno. Costruisci la regola di avviso Log Analytics sopra descritta, indirizzala a un gruppo di azioni reale (e-mail + SMS, non una casella che nessuno controlla), e imposta la severità su Critica.
6. Conserva le credenziali in una posizione sicura e ad accesso controllato — uno storage fisicamente separato e ignifugo per i token hardware o i certificati CBA, accessibile a più di una persona autorizzata, non legato al dispositivo di un singolo dipendente.
7. Valida ogni 90 giorni, e dopo ogni cambiamento nel team di amministrazione. Conferma che l'account accede ancora con successo sotto la configurazione CA attuale, conferma che l'avviso scatta ancora, e conferma che l'elenco degli utenti autorizzati è aggiornato. Le linee guida di Microsoft sono esplicite sul fatto che questa validazione debba avvenire almeno ogni 90 giorni e dopo ogni cambio di personale — un account di accesso di emergenza che nessuno ha testato in condizioni reali di guasto non è un controllo funzionante, è una supposizione.
8. Esegui un post-mortem a ogni attivazione, esercitazione o reale, per confermare che l'utilizzo fosse autorizzato e che le azioni intraprese corrispondessero all'incidente.

La copertura break-glass è un elemento di una base più ampia di hardening del tenant — vedi Azure Tenant Hardening: Security Defaults per le altre lacune di configurazione predefinita che vale la pena chiudere insieme a questa.

Come EtcSec rileva questo

L'audit Entra ID di EtcSec verifica tutte le tre modalità di fallimento trattate qui: PA_NO_EMERGENCY_ACCOUNTS segnala i tenant con zero account di accesso di emergenza qualificati, PA_EMERGENCY_NO_EXCLUSION (accoppiato con CA_NO_BREAK_GLASS_EXCLUSION) segnala gli account ancora nell'ambito di una policy Conditional Access applicata, PA_EMERGENCY_NO_MONITORING segnala gli account senza una corrispondente configurazione di avviso di accesso, e PA_EMERGENCY_CREDENTIAL_STALE segnala gli account le cui credenziali non sono state validate entro la finestra raccomandata.