Perché i Breakglass non sono “solo un altro breakglass”

Quando si parla di sicurezza in Microsoft Entra ID, il concetto di “breakglass” evoca sempre una certa tensione.

Un breakglass account è un account “di emergenza” pensato per essere usato solo quando tutto il resto fallisce. Si tratta di un utente con privilegi molto alti (tipicamente Global Administrator) che rimane fuori da qualsiasi automatismo di sicurezza — niente MFA complesso, niente Conditional Access rigide, niente dipendenze esterne — proprio per garantire accesso quando tutto è critico.

In molti ambienti IT si tende ancora a considerare il breakglass come un semplice account “di emergenza”, quasi una via di fuga da utilizzare quando qualcosa non funziona. La realtà, però, è decisamente più complessa e strategica: i breakglass non servono quando tutto va bene, servono quando tutto è andato male allo stesso tempo. E in scenari del genere, improvvisare non è mai una buona idea.

Che cos’è un Breakglass account

Secondo Microsoft, gli account di accesso di emergenza sono necessari per mitigare il rischio di rimanere bloccati fuori dal tenant nel caso in cui:

• il provider di identità federata non è disponibile;
• gli amministratori non possono completare l’autenticazione MFA;
• tutti gli altri account con privilegi sono stati bloccati o disabilitati.

In pratica, non stai solo creando un account con privilegi, ma un meccanismo di resilienza che deve funzionare anche quando le policy di sicurezza attive — come Conditional Access o MFA — falliscono o impediscono l’accesso.

Peccato che la teoria lasci molto spazio a interpretazioni e, soprattutto, ad errori di valutazione. È per questo che il dibattito all’interno della community continua da anni: quanti breakglass servono davvero? Ha senso dotarli di MFA? E, se sì, quale tipo? È opportuno metterli in un gruppo? Oppure sarebbe meglio evitarlo? E poi, un service principal può davvero diventare un’alternativa?

Tutte domande apparentemente semplici, che però non hanno una risposta unica. Perché non esiste un ambiente identico a un altro. Ogni tenant ha i propri rischi, le proprie dipendenze, i propri punti di fragilità. E quando si entra nel mondo degli MSP la questione diventa ancora più interessante: non si tratta solo di sapere come rientrare nel tenant, ma di costruire un sistema che permetta anche al resto del team di farlo in qualunque momento, anche quando la persona “esperta” non è disponibile.

Un approccio che funziona quando tutto va storto

Il breakglass account deve essere progettato considerando il peggior scenario possibile, non quello ideale. Per questo motivo la Best Practices è quella di non affidarsi ad un singolo account, ma di prevederne almeno due, distinti sia per le modalità di autenticazione, sia per la loro configurazione. Un account basato su TOTP permette un recupero rapido, mentre un secondo account protetto da una chiave FIDO2 offre un livello di sicurezza superiore e una resilienza maggiore in scenari estremi.

Un aspetto spesso sottovalutato riguarda il dominio usato per i breakglass. È fondamentale non utilizzare il dominio aziendale principale, perché in caso di problemi DNS, quei breakglass diventerebbero immediatamente inutilizzabili. Il dominio onmicrosoft.com rappresenta una garanzia di indipendenza e sopravvivenza anche in caso di guasti critici.

Altro elemento chiave è la protezione organizzativa. Gli account di emergenza devono essere inseriti in un’area protetta e isolata, come una “Restricted Management Administrative Unit”, questo per impedire modifiche accidentali o malevole, oppure evitare che un gruppo inserito erroneamente in qualche Conditional Access Policy che ne pregiudichi il funzionamento.

Il vero tallone d’Achille: monitoraggio

Un breakglass account non è un account come gli altri. Ogni accesso e ogni modifica dovrebbe generare un’allerta immediata:

• notifiche in tempo reale;
• integrazione con SIEM (come Microsoft Sentinel);
• analisi automatica di anomalie di accesso.

Se l’utilizzo di un account di emergenza non viene rilevato tempestivamente, quell’account rischia di trasformarsi da strumento di resilienza a un potenziale vettore di compromissione.

Service Principal: da rischio a risorsa

Un altro tema riguarda i Service principal. A differenza degli utenti reali, i service principal (in pratica l’equivalente degli utenti di servizio su Entra ID) bypassano completamente la Conditional Access. Non richiedono MFA, non hanno dispositivi associati, non dipendono da DNS o attributi utente e non prevedono un login interattivo. Questo li rende potenzialmente pericolosi, perché potrebbero agire al di fuori del perimetro di sicurezza pensato per gli amministratori. Ma, allo stesso tempo, rappresentano una risorsa preziosa in uno scenario di recupero.

È per questo che alcuni professionisti considerano un service principal ben configurato come una sorta di “piano C”. Non sostituisce i breakglass “umani”, ma li affianca, offrendo un livello ulteriore di ridondanza basato su un meccanismo diverso e quindi più resiliente. Microsoft stessa si sta muovendo in questa direzione attraverso la Conditional Access dedicata alle workload identities, una funzionalità che colma una delle lacune più evidenti del modello di sicurezza tradizionale.

Inforcer e la gestione multi-tenant

Soluzioni di gestione multi-tenant come ad esempio Inforcer, una soluzione pensata per gli MSP che devono gestire centinaia di tenant contemporaneament, non rappresentano un classico breakglass, ma possono essere una backdoor controllata che permette di rientrare in un tenant quando le Conditional Access bloccano gli amministratori umani. Si basa su un insieme di meccanismi Microsoft molto precisi:

• GDAP (Granular Delegated Admin Privileges) → permette all’MSP di ottenere permessi limitati e temporizzati sui tenant dei clienti.
• Certificati → l’accesso avviene tramite identità applicative, non account umani (quindi niente password, niente MFA).
• Autorizzazioni minimali → vengono richiesti solo i permessi strettamente necessari per gestire il tenant.
• Region Lock → vincola l’uso dell’identità ai datacenter/regione corretta, riducendo il rischio di abuso.
• Workload Identities → identità applicative create per eseguire operazioni automatizzate, con log e audit.

Questi elementi messi insieme creano una sorta di Backdoor sicura che permette all’MSP di continuare a gestire il tenant anche in situazioni complicate, senza dover ricorrere a soluzioni rischiose come utenti nascosti o esclusioni forzate dalla sicurezza.

Conclusioni

La sicurezza è un processo dinamico, che richiede monitoraggio continuo, revisione, disciplina e ridondanza. I breakglass non sono un oggetto da configurare una volta e dimenticare, ma un elemento critico da verificare, testare e governare. Non basta avere un piano A. Bisogna avere un piano B. E, quando serve, anche un piano C. Perché il momento in cui serviranno davvero sarà anche il più caotico, il più urgente e il più stressante. Una preparazione accurata può essere la differenza tra risolvere un’emergenza o amplificarla.