Un tenant può bloccarsi da solo, senza bisogno di alcun attaccante. Se ogni assegnazione di Global Administrator e di Privileged Role Administrator è di tipo eligible, l'attivazione richiede un'approvazione e non è stato selezionato alcun approvatore, nessuno può approvare nulla. Gli amministratori attivi sono gli approvatori predefiniti, e non ce ne sono. Due account break-glass solo cloud, configurati e sottoposti a prove in anticipo, sono la via d'uscita.
Quando serviranno
La guida Microsoft sull'accesso di emergenza elenca i casi. La federazione non funziona perché l'host del Suo identity provider è andato in avaria. Tutti gli amministratori hanno registrato per l'MFA solo chiamate vocali e SMS, e la rete mobile è fuori servizio. L'ultima persona con accesso Global Administrator lascia l'azienda e il suo account viene disabilitato o eliminato on-premises, cosa che Entra ID non impedisce.
Creare gli account
Crei almeno due account. Li renda solo cloud sul dominio *.onmicrosoft.com, non federati e non sincronizzati da on-premises. Assegni a ciascuno il ruolo Global Administrator.
In Privileged Identity Management (PIM), renda tale assegnazione active permanent, non eligible. Gli amministratori di uso quotidiano dovrebbero usare l'accesso just-in-time, ma questi account non possono dipendere da un passaggio di attivazione, perché proprio quel passaggio potrebbe essere indisponibile. PIM richiede Microsoft Entra ID P2 oppure Entra ID Governance.
Le fonti non trattano i tenant privi di PIM, quindi questa parte è un nostro ragionamento. L'impostazione active-versus-eligible risiede in PIM e in quel caso non si applica. Gli account devono comunque avere un'assegnazione Global Administrator diretta e permanente, per lo stesso motivo: nulla deve dover essere attivato.
Per l'autenticazione, scelga un metodo passwordless che soddisfi il requisito MFA:
- Passkey (FIDO2), che Microsoft raccomanda.
- Autenticazione basata su certificato, se gestite già una PKI.
Usi un metodo diverso da quello degli amministratori di uso quotidiano. Se questi usano l'app Microsoft Authenticator, assegni agli account di emergenza una chiave di sicurezza FIDO2. Non leghi gli account condivisi a una persona né a un dispositivo fornito dal dipendente, come uno smartphone. Microsoft consente anche account di emergenza individuali per ciascun amministratore, il che garantisce la tracciabilità delle responsabilità e permette di usarli da sedi remote. Scelga un modello in modo consapevole.
Conservi le chiavi in casseforti ignifughe, in luoghi sicuri e separati, accessibili alle persone autorizzate a usarle. Utilizzi una workstation sicura dedicata, come una Privileged Access Workstation, ogni volta che qualcuno accede con questi account.
Escluderli da Conditional Access
Una policy applicata che richieda MFA, un dispositivo conforme o un altro controllo può rendere l'account inutilizzabile proprio durante l'emergenza. A proteggere l'account è la credenziale resistente al phishing, quindi lo escluda da qualsiasi policy che blocchi o limiti l'accesso. Conditional Access richiede Entra ID P1.
Crei un gruppo di sicurezza dedicato, per esempio EmergencyAccess, vi inserisca entrambi gli account ed escluda il gruppo da tali policy. Le policy in modalità report-only non bloccano l'accesso e non richiedono esclusioni.
Un gruppo da solo non basta, perché le nuove policy sono scritte da persone che potrebbero non ricordare l'esistenza di questi account. Apra ogni policy abilitata e verifichi che il gruppo compaia nella sezione Exclude. Ricontrolli le policy report-only prima che qualcuno le attivi. Aggiunga alla checklist di revisione di ogni nuova policy la domanda "EmergencyAccess è escluso?" e provi un accesso dopo ogni modifica significativa.
Un alert a ogni accesso
Questi account dovrebbero accedere solo per le prove e per le emergenze reali, quindi qualsiasi accesso merita un alert. L'esempio di Microsoft usa Azure Monitor e richiede che i log di accesso di Entra siano prima inviati a un workspace Log Analytics.
- Nell'Entra admin center, con almeno il ruolo User Administrator, vada in Entra ID > Users, apra ciascun account di emergenza e copi il suo Object ID.
- Nel portale Azure, con almeno il ruolo Monitoring Contributor, apra Monitor > Alerts e selezioni + Create > Alert rule.
- Nella scheda Scope, selezioni il Suo workspace Log Analytics.
- Nella scheda Condition, scelga Custom log search come nome del segnale e Aggregated logs come tipo di query.
- Inserisca una query con entrambi gli Object ID:
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription- In Measurement, selezioni la misura, il tipo di aggregazione e la granularità di aggregazione. In Split by dimensions, selezioni la colonna Resource ID.
- In Alert logic, imposti il tipo di soglia su Static, l'operatore su Greater than e il valore soglia su 0. Imposti la frequenza di valutazione in base alla rapidità con cui desidera essere avvisato.
- Indirizzi l'alert a email e SMS di più amministratori, non di uno solo.
Microsoft mostra anche una query basata su UserPrincipalName. Noi usiamo l'Object ID per abitudine, perché una query scritta intorno a un nome dipende dal fatto che quel nome resti invariato. Per ogni account aggiuntivo, aggiunga un'ulteriore clausola or UserId == "ObjectGuid".
Se nel Suo team nessuno controlla gli alert fuori orario, un servizio di monitoraggio gestito può farsi carico di questa parte.
Testarli e rivedere ogni utilizzo
Convalidi gli account almeno ogni 90 giorni. Una prova dovrebbe comprendere l'elenco degli utenti autorizzati, un accesso reale con la chiave di sicurezza e un'attività amministrativa. Dovrebbe confermare che gli account accedono ancora con la Sua attuale configurazione di Conditional Access e che ogni chiave o certificato è presente, non è scaduto e non è stato rimosso da una pulizia automatica.
Ogni prova dovrebbe far scattare il Suo alert. Ripeta il test dopo qualsiasi modifica al workspace o alle impostazioni di diagnostica che lo alimentano. Tenga un breve registro:
| Data | Eseguito da | Account e chiave | Chiave o certificato valido | Alert ricevuto dopo | Anomalie riscontrate |
|---|---|---|---|---|---|
| Account 1, chiave A | |||||
| Account 2, chiave B |
Dopo ogni utilizzo reale, svolga un post-mortem. Stabilisca se l'utilizzo era autorizzato e se le azioni compiute erano appropriate. Le organizzazioni regolamentate possono presentare questa documentazione, insieme ai log e al registro delle prove, come evidenza che l'accesso di emergenza è governato. Se desidera una verifica esterna, il nostro team di consulenza può rivedere la configurazione.
Da dove iniziare
- Elenchi i Suoi Global Administrator nell'Entra admin center e confronti il numero con l'indicazione di Microsoft, che raccomanda meno di cinque. Verifichi se qualche account sia già destinato alle emergenze.
- Crei due account solo cloud
.onmicrosoft.comcon un'assegnazione Global Administrator attiva e permanente e registri per ciascuno una chiave FIDO2 diversa. - Crei il gruppo
EmergencyAccesse lo escluda da ogni policy di Conditional Access che blocchi o limiti l'accesso. - Invii i log di accesso a Log Analytics e costruisca la regola di alert con soglia maggiore di 0 su entrambi gli Object ID.
- Riponga le chiavi in luoghi ignifughi separati, indichi per nome gli utenti autorizzati e verifichi che nessuna credenziale scada o rientri nell'ambito di una pulizia automatica.
- Acceda con ciascun account, confermi che l'alert scatti, compili la prima riga del registro delle prove e fissi in calendario la prova successiva entro 90 giorni.
