Proteggere correttamente Microsoft 365: Conditional Access, eccezioni MFA e account break-glass nella pratica quotidiana

Chi vuole proteggere correttamente Microsoft 365 non può prescindere da Conditional Access (policy di accesso in Entra ID, precedentemente Azure AD) e dalla Multi-Factor Authentication (MFA, cioè autenticazione con almeno due fattori). In molte aziende la MFA e le prime regole di Conditional Access vengono attivate rapidamente – e poi comincia il lavoro vero: le eccezioni devono essere motivate, gli accessi di emergenza organizzati in modo chiaro e i processi operativi progettati affinché la sicurezza non si trasformi in un’ondata di richieste di supporto.

Nella pratica, „M365 absichern“ fallisce raramente per ragioni strettamente tecniche, ma piuttosto per questioni quotidiane: account di servizio per interfacce, protocolli legacy, personale esterno senza rete mobile affidabile, amministratori con diritti troppo estesi, o un incidente in cui proprio la misura di protezione blocca l’accesso dell’IT. Questo contributo chiarisce come Conditional Access, le eccezioni MFA e i Break-Glass-Accounts interagiscono – e come gestire il tutto in modo che rimanga affidabile anche dopo il go-live.

Perché Conditional Access è la leva – e la sola MFA non è sufficiente

La MFA riduce significativamente il rischio di password rubate, ma non costituisce un concetto di accesso completo. Conditional Access (CA) decide in modo contestuale in quali condizioni un accesso è consentito: p.es. solo da dispositivi gestiti, solo da determinati paesi, solo con valutazione basata sul rischio o solo con specifiche app client. Questo è il passo decisivo verso Zero Trust (modello di sicurezza in cui nessun accesso è considerato affidabile per default, ma viene continuamente verificato).

Motivi tipici per cui la sola MFA non è sufficiente in Microsoft 365:

• Token invece della password: Le moderne modalità di autenticazione operano con token (biglietti di accesso a tempo limitato). Un token rubato può aggirare la MFA se CA non impone condizioni aggiuntive (p.es. stato del dispositivo o controllo della sessione).
• Rischio admin: Gli account amministrativi sono particolarmente attraenti per gli attaccanti. Senza regole CA per gli accessi amministrativi (p.es. solo da workstation amministrative o solo con MFA resistente al phishing) rimane la superficie di attacco più ampia.
• „Consentito“ è troppo ampio: Se CA non distingue tra app, classi di dati e modalità di accesso, la sicurezza diventa rapidamente o troppo permissiva o troppo RESTrittiva – entrambe le situazioni generano problemi.

Il nucleo operativo è quindi: CA come strato di policy, la MFA come componente al suo interno, più una gestione chiara delle eccezioni e percorsi di emergenza robusti.

Panoramica architetturale: cosa Conditional Access in Entra ID controlla realmente

Per la direzione IT e per il team operativo è importante non considerare CA come „una singola policy“, ma come una catena di decisione. Entra ID valuta ad ogni autenticazione i segnali e applica le policy. I segnali importanti sono:

• Identità: utenti, gruppi, ruoli (p.es. ruoli privilegiati come Global Administrator).
• Risorsa di destinazione: app cloud (Exchange Online, SharePoint/OneDrive, Teams, ma anche fornitori terzi tramite Enterprise App).
• Tipo di client: browser, client moderni, app mobili, oltre alla „Legacy Authentication“ (protocolli più datati senza token moderni, p.es. vecchie varianti di IMAP/POP/SMTP-Auth).
• Stato del dispositivo: „Compliant“ o „hybrid joined“ (dispositivo gestito, tipicamente tramite Intune o join al dominio con stato del dispositivo).
• Rete/posizione: Named Locations (intervalli IP definiti), paesi/regioni, indicatori di rischio.
• Condizioni di sessione: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (rivalutazione continua in caso di eventi di rischio).

Dal punto di vista operativo, la qualità della vostra configurazione di Conditional Access dipende fortemente dall’affidabilità di questi segnali. Un Named Location è valido solo quanto la vostra igiene degli indirizzi IP. «Compliant» vale solo quanto la vostra gestione dei dispositivi e la definizione di compliance. E la valutazione del rischio è utile solo se lavorate concretamente con gli eventi che da essa derivano.

Proteggere correttamente Microsoft 365 con Conditional Access: un set di policy pratico

Invece di una regola «grande e generale», nella pratica funziona meglio un set composto da poche policy chiaramente delimitate. Questo riduce gli effetti collaterali e facilita l’analisi degli incidenti. Uno schema di base consolidato consiste in:

1) Baseline per tutti gli utenti: imporre MFA, bloccare Legacy

Per gli account utente ordinari la baseline è: MFA obbligatoria e blocco della Legacy Authentication. Legacy qui non significa «vecchio stile», ma tecnicamente problematico: questi protocolli spesso non supportano una moderna sfida MFA e rappresentano quindi un punto d’ingresso classico per attacchi di password spraying.

Importante: non bloccate Legacy «a caso», ma pianificate una fase di transizione con misurazione. Verificate tramite i Sign-in Logs quali client utilizzano ancora Legacy. In azienda spesso dipendono da questo multifunzione, funzionalità di scan-to-mail o client di posta più datati in ambienti speciali.

2) Admin-Policy: decisamente più rigorosa della baseline

I ruoli privilegiati dovrebbero avere una policy dedicata: accesso solo da dispositivi admin definiti (ad es. «compliant» e eventualmente una strategia separata per le admin workstation), MFA con elevata robustezza (resistente al phishing, ad es. FIDO2/Passkey o basato su certificato), e possibilmente restrizioni per paesi/posizioni a rischio. Anche se non tutte le aziende adottano immediatamente una Privileged-Access-Architecture completa (PAM, cioè gestione degli accessi privilegiati), questa distinzione vale subito la pena: un account admin compromesso determina un perimetro di danno molto diverso rispetto a un account utente compromesso.

3) Policy per collaborazione esterna e guest

Gli accessi guest (B2B Collaboration) generano spesso percorsi dati inattesi: i guest scaricano file da SharePoint, lavorano in Teams o accedono a portali di progetto. Definite in modo esplicito se i guest possono entrare solo con MFA, se certe app sono escluse e per quanto tempo le sessioni restano valide. Per il lavoro di progetto una durata delle sessioni più breve è spesso sensata, per ridurre il rischio di «login dimenticati».

4) Policy per percorsi dati sensibili: proteggere il dispositivo o la sessione

Nella pratica esistono diversi livelli di necessità di protezione: un commerciale può magari leggere le e-mail da qualunque dispositivo, ma non scaricare grandi volumi da SharePoint senza un dispositivo gestito. Queste differenze non si rappresentano con un semplice «consenti/nega», ma con combinazioni di CA: «accesso consentito se il dispositivo è compliant» oppure «accesso solo via browser con sessione limitata». È meno drastico del blocco totale, ma comunque efficace.

Eccezioni MFA: dove sono realistiche e come controllarle

Le eccezioni MFA non sono un segno di debolezza, purché siano progettate consapevolmente e controllate operativamente. Senza eccezioni controllate nascono soluzioni in ombra: gli utenti aggirano i processi, gli admin disattivano regole in modo frenetico e a un certo punto la raccolta di policy non è più tracciabile.

Fondamentale è la distinzione: un’eccezione MFA raramente significa «MFA disattivata», ma spesso «MFA diversa» o «accesso solo a condizioni differenti». Categorie tipiche di eccezione:

Caso di eccezione 1: accessi non interattivi e interfacce

Molte soluzioni software integrate ai processi utilizzano servizi M365: invio e-mail, accesso al calendario, archiviazione file su SharePoint, notifiche Teams o accessi alla Graph API. Tali integrazioni non dovrebbero funzionare tramite account utente con MFA disabilitato. È preferibile un accesso tecnico tramite registrazioni di app (applicazione in Entra ID) con autorizzazioni chiare e un ciclo di vita per secret/certificati. Non si tratta di una „eccezione MFA“, ma di una diversa modalità di autenticazione, più auditabile.

Conseguenze operative: i segreti devono essere ruotati, i certificati scadono e le autorizzazioni devono essere ricertificate. Se pianificate integrazioni, definite Ownership (chi rinnova certificati/segreti) e monitoring (es. avvisi prima della scadenza). Altrimenti una autenticazione „sicura“ via app può trasformarsi in un guasto non pianificato.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Qui emergono le classiche discussioni su SMTP-Relay, scan-to-mail o caselle postali per sale. La soluzione sbagliata è quasi sempre „un account utente senza MFA“. Sono migliori percorsi tecnici che non dipendono dall’autenticazione interattiva: relay di posta centrale con RESTrizione IP, approcci basati su certificati o connettori, oppure caselle di sistema separate con privilegi ristretti. Ciò che conta è: il dispositivo non può gestire MFA, quindi il progetto deve garantire la sicurezza sul piano del trasporto e del percorso di rete.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Personale esterno, produzione o turni possono trovarsi in situazioni senza copertura mobile o senza dispositivi mobili privati. Conviene pensare per tempo a metodi MFA alternativi: token hardware, chiavi di sicurezza FIDO2, o Windows Hello for Business (accesso vincolato al dispositivo). „Disabilitare temporaneamente l’MFA“ è operativamente allettante, ma scala male e risulta difficilmente auditabile.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Alcuni sistemi legacy avviano job „come utente“, ad esempio per upload su SharePoint o report. Oggi questo è rischioso perché mescola ruoli e privilegi. Se la sostituzione non è immediata, operate con soluzioni intermedie: service account con privilegi limitati, Named Locations chiare, politiche robuste per password/segreti e logging consistente. E: pianificate la migrazione verso identità di app come pacchetto di lavoro a sé stante, non come „poi si vede“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Le eccezioni in esercizio sono accettabili solo se hanno un ciclo di vita. Praticamente efficace è un approccio leggero, senza burocrazia ma comunque auditabile:

1. Motivazione in una frase: Quale funzione aziendale o operativa dipende da essa (es. „scan-to-mail in sede X“)?
2. Classificazione tecnica: Quale app/protocolli, quali account, quali percorsi dei dati?
3. Controlli compensativi: Cosa limita il rischio (RESTrizione IP, privilegi minimi necessari, monitoraggio)?
4. Data di scadenza: Ogni eccezione ottiene una data di revisione. Senza revisione viene rimossa o rinnovata.
5. Responsabile: Chi è responsabile in caso di problemi o alla scadenza dell’eccezione?

In questo modo le eccezioni non diventano „buone“, ma diventano gestibili. Ed è proprio questa la differenza quotidiana tra una base di sicurezza M365 robusta e un proliferare incontrollato di regole.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Gli account Break-Glass sono account di emergenza per l’accesso al Tenant quando gli accessi amministrativi ordinari non funzionano – ad esempio a causa di una errata configurazione in Conditional Access, del malfunzionamento di un provider MFA o di un incidente di identità. Lo scopo è chiaro, ma l’implementazione presenta insidie tipiche: un account Break-Glass che non viene mai testato non serve in caso di emergenza. Un account Break-Glass troppo facilmente raggiungibile è un obiettivo attraente per gli attaccanti.

Cosa non è il Break-Glass

• Non un account amministrativo quotidiano: Non deve essere utilizzato nell’operatività normale.
• Non un bacino di eccezioni: Non sostituisce una progettazione CA corretta.
• Non «ce l’abbiamo, va bene così»: Senza processo, test e allerta è solo un piano teorico.

Principi fondamentali per Break-Glass in esercizio

Una configurazione praticabile si orienta su tre obiettivi: raggiungibile in caso di emergenza, difficile da attaccare durante l’operatività normale, e chiaramente tracciabile.

• Almeno due account: Redundanza contro blocchi, errori d’uso o credenziali compromesse.
• Fortemente protetto: Password lunghe e casuali; nessun inoltro di e-mail; nessun utilizzo per app/integrazioni.
• Escluso mirato dalle CA – ma in modo ristretto: Tipicamente si crea un’eccezione per alcune policy CA, in modo da non rimanere esclusi in caso di emergenza dalle proprie regole. Parallelamente dovrebbero scattare altri meccanismi di sicurezza: allarmi in caso di utilizzo, assegnazione di ruoli RESTrittiva, conservazione separata delle credenziali.
• Registrazione e allerta: Ogni autenticazione deve generare un segnale immediato (SIEM/SOC o almeno un allarme via e-mail/Teams a una casella per incidenti). L’utilizzo del Break-Glass è per definizione un evento di sicurezza.

Un punto centrale: decidete consapevolmente se gestire il Break-Glass con o senza MFA. Molte organizzazioni lo mantengono senza MFA per RESTare operativi in caso di guasto MFA. In tal caso però i controlli compensativi devono essere particolarmente accurati (conservazione, accesso alla password, allerta, rotazione periodica). In alternativa si può dotare il Break-Glass di MFA basato su hardware (p. es. FIDO2), indipendente dalla rete mobile. Ciò che conta non è l’ideologia «giusta», ma un percorso di emergenza che funzioni realmente nel vostro contesto.

Realtà del rollout: come evitare lockout e picchi di supporto

Molti rollout CA/MFA falliscono non per ragioni tecniche, ma organizzative: troppo veloci, troppo estesi, senza telemetria e senza un processo di supporto chiaro. Un rollout stabile lavora a ondate e con punti di misurazione.

Passo 1: Creare visibilità (prima di bloccare)

Usate i Sign-in Logs e le analisi per scoprire: quali app vengono utilizzate? Quali client sono „legacy“? Quali sedi/gamma di IP sono reali? Quali utenti hanno particolari problemi di autenticazione? Senza questi dati ogni policy è un volo cieco.

Passo 2: Gruppi pilota con casi speciali reali

I piloti non dovrebbero essere solo „IT e qualche volontario“. Includete intenzionalmente i casi limite: operatori sul campo, siti di produzione, collaboratori di progetto con accesso guest, e almeno un reparto con tipici strumenti di terze parti. L’obiettivo non è l’armonia, ma individuare pRESTo gli ostacoli reali.

Passo 3: Definire playbook per l’helpdesk

Quando l’MFA viene imposto, aumentano i ticket: cambio dispositivo, telefoni smarriti, nuovi collaboratori, account bloccato dopo troppi tentativi. Definite cosa può risolvere il supporto di primo livello (es. reset MFA dopo verifica dell’identità) e quando va effettuata l’escalation. Senza playbook tutto viene scalato – e gli admin diventano il collo di bottiglia.

Fase 4: Lavori tecnici residui come backlog separato

CA rende visibili i debiti tecnici nascosti: client di posta obsoleti, scanner non documentati, script con password nel Task Scheduler, o integrazioni che ancora usano Basic Auth. Pianificate questi lavori come pacchetti di lavoro visibili. Altrimenti RESTano come «eccezione permanente».

Typische Fehlerbilder aus dem Betrieb – und wie man sie schneller einordnet

Nella pratica quotidiana contano ipotesi rapide. Alcuni schemi ricorrono frequentemente:

„Plötzlich geht Outlook nicht mehr“

Cause comuni: client legacy, profilo vecchio, o un blocco CA per mancato stato del dispositivo. Verificate: tipo di client nel Sign-in Log, CA-Policy applicata, e se il dispositivo è registrato come compliant. La correzione operativa raramente è «disattivare la policy», ma piuttosto «modernizzare il client» o «mettere in ordine la gestione dei dispositivi».

„Service XY kann keine E-Mails mehr senden“

Spesso c’è dietro una modifica dell’autenticazione SMTP, una Relay-Policy cambiata o una nuova regola CA che involontariamente colpisce anche account tecnici. Qui aiuta una decisione architetturale chiara: invio tramite Relay/Connector invece del login utente, con RESTrizione IP e logging (tracciabilità nell’incident).

„Admin kommt nicht mehr in den Tenant“

Questo è il momento per cui è previsto il Break-Glass. Se anche l’accesso Break-Glass non funziona, di solito manca un percorso di emergenza testato o l’eccezione è stata costruita in modo errato. Perciò: esercitare regolarmente l’uso (con documentazione, chi testa quando e come si presenta l’allarme).

„Zu viele Ausnahmen – niemand blickt durch“

È un problema di governance. Consolidate le policy, definite un rituale di review (es. 30 minuti al mese), e rimuovete le eccezioni che non hanno più un Owner/uno scopo. Tecnicamente non è glamour, ma è la differenza tra sicurezza controllabile e privilegi speciali cresciuti storicamente.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

CA e MFA generano molti eventi. Se raccogliete tutto, affogate; se non analizzate nulla, noterete i problemi troppo tardi. Praticamente sensate sono tre livelli:

• Allertamento su eventi critici: Break-Glass-Login, accesso admin da paesi insoliti, eventi di blocco su app critiche.
• Review regolari: principali motivi di blocco, top user con problemi MFA, tentativi di autenticazione legacy, nuove app/Enterprise Apps.
• Traccia di audit per le eccezioni: chi ha autorizzato quale eccezione, con quale data di scadenza, e quando è stata revisionata?

Se avete già processi centrali di logging e incident (SIEM, Ticketing, Change-Management), ancorate lì le modifiche CA. Conditional Access non è una «piccola impostazione», ma uno strato di accesso critico per la produzione.

Aufwand und Verantwortlichkeiten: Wer muss was liefern?

I progetti CA-/MFA sono sottovalutati perché sembrano mera configurazione. In realtà sono progetti di interfaccia tra identità, endpoint, rete e processi di business. Un modello di responsabilità chiaro riduce gli attriti:

• Identity-Team / Entra Admins: design delle policy, modello di ruoli, Break-Glass, registrazioni delle app.

La decisione manageriale più importante spesso non è “MFA sì/no”, bensì: abbiamo tempo e risorse per i lavori di follow-up (ridurre il legacy, modernizzare le integrazioni, stabilizzare la gestione dei dispositivi)? Senza questo lavoro il miglioramento della sicurezza resta al di sotto delle aspettative – oppure il funzionamento diventa inutilmente gravoso.

Conclusione: la sicurezza vince quando emergenza ed eccezione fanno parte del sistema

Proteggere correttamente Microsoft 365 significa operare l’Accesso condizionale come livello centrale di controllo – non come una configurazione una tantum. MFA è obbligatoria, ma la reale qualità operativa nasce da eccezioni ben gestite (con data di scadenza, owner e controlli compensativi) e da account Break-Glass, che siano testati, monitorati e inseriti nell’organizzazione. Chi considera insieme questi tre elementi riduce i rischi sugli account, ottiene capacità di audit senza overhead e impedisce che le regole di sicurezza, in caso di incidente, diventino un ostacolo.

Discutere un progetto o un’iniziativa di modernizzazione con Net-Base.