M365Con 2027 – conferenza online gratuita · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Perché l'MFA non viene richiesta quando dovrebbe in Microsoft 365

By ·

L'autenticazione a più fattori (MFA) dovrebbe essere la tua rete di sicurezza in Microsoft 365 e Azure, bloccando gli aggressori anche quando rubano una password. Ma cosa succede quando quella rete semplicemente non c'è, proprio quando dovrebbe esserci? …

Automatically translated with AI from the original post. Read the English original

Cover: Detect Microsoft 365 Attack Chains with Entra and Sentinel

L'autenticazione a più fattori (MFA) dovrebbe essere la tua rete di sicurezza in Microsoft 365 e Azure, bloccando gli aggressori anche quando rubano una password. Ma cosa succede quando quella rete semplicemente non c'è, anche quando dovrebbe esserci? "Dovrebbe" significa quei momenti critici: accessi a rischio, accessi con account amministrativi o accessi da luoghi insoliti rispetto al normale. Se l'MFA non scatta in questi casi, sei esposto, e basta.

Queste falle spesso si insinuano per una combinazione di problemi tecnici, criteri di configurazione confusi e persino aggiramenti da parte degli utenti finali. A volte dipendono da app che usano l'autenticazione legacy, da criteri di accesso condizionale deboli o da una copertura incompleta degli utenti. Qualunque sia la causa, la mancanza dell'MFA proprio dove conta di più apre la porta agli aggressori e crea seri grattacapi di sicurezza.

Capire questi cedimenti nell'applicazione dell'MFA, e correggerli, è fondamentale per mantenere i dati protetti. Se vuoi vedere come gli aggressori sfruttano queste crepe con il furto di token e i giochetti con OAuth, questa analisi di una violazione di Microsoft 365 mostra con precisione cosa c'è in gioco.

Dove l'MFA non scatta e perché

L'MFA è forte solo quanto i criteri e la tecnologia che ci stanno dietro. La cosa frustrante è che, anche quando sei sicuro di aver configurato tutto correttamente, ci sono molti scenari in cui l'MFA non si attiva silenziosamente, anche per utenti critici o durante accessi a rischio.

Una causa frequente sono i criteri di accesso condizionale configurati male. Magari un utente VIP viene escluso "per comodità", oppure account di test restano attivi con autorizzazioni ampie e senza MFA richiesta. Esclusioni di questo tipo possono sembrare innocue in fase di configurazione, ma possono aprire falle proprio nelle tue difese. Se i criteri non vengono verificati regolarmente, potresti ritrovarti con lacune invisibili che nessuna dashboard segnala.

Le app legacy sono un altro problema subdolo. Strumenti come Exchange ActiveSync o alcuni client di posta desktop usano spesso un'autenticazione obsoleta, aggirando di default l'MFA moderna. Queste app non browser si basano sull'autenticazione di base, che non è compatibile con la tua nuova configurazione MFA, e questo può far sì che gli accessi avvengano completamente al di fuori del tuo controllo.

Non dimenticare poi i comportamenti degli utenti. Alcuni generano "password per le app" per collegare app meno recenti, aggirando completamente l'MFA. Altri concedono involontariamente autorizzazioni OAuth ad app di terze parti tramite richieste di consenso rischiose, offrendo agli aggressori una porta di servizio che non viene mai sottoposta a MFA. È qui che la governance fa la differenza, perché gli utenti possono aggirare l'MFA senza nemmeno rendersi conto del rischio.

Nelle organizzazioni con ambienti ibridi o multi-cloud, queste falle si moltiplicano. Se non verifichi sistematicamente chi e cosa ha l'MFA applicata, rischi di non vedere esposizioni critiche. Esaminare le dashboard di identità su più piattaforme è l'unico modo per mappare la copertura reale. Capire dove l'MFA non scatta è la base per rafforzare i controlli e proteggere ogni accesso, indipendentemente da come o dove avviene.

Implementare metodi MFA resistenti al phishing per un'autenticazione sicura

L'MFA standard è valida, finché gli aggressori non riescono a ingannare gli utenti con push fatigue, richieste di phishing o furto di token. Per questo passare a un'MFA resistente al phishing fa davvero la differenza se vuoi chiudere la porta agli attacchi moderni.

La corrispondenza dei numeri nelle app di autenticazione è un miglioramento solido. Invece di approvare un push generico, l'utente deve inserire un codice, rendendo quasi impossibile per un aggressore ingannare qualcuno con il prompt bombing. Microsoft e altri la promuovono con decisione e la attivano per impostazione predefinita nelle nuove configurazioni MFA. Affronta direttamente quei subdoli trucchi di prompt bombing usati in violazioni recenti di grande rilievo.

Le chiavi di sicurezza fisiche come YubiKey e i token FIDO2 vanno ancora oltre. Queste chiavi non possono essere oggetto di phishing e non si basano su segreti condivisi. In ambienti altamente sensibili, o per amministratori e dirigenti, questa è quasi una "modalità di blocco": un'autenticazione hardware che neutralizza sul nascere la maggior parte delle tecniche d'attacco reali.

Non serve nemmeno sacrificare l'usabilità. Con le moderne opzioni di accesso senza password e la forte integrazione con piattaforme come Microsoft 365 e Defender, puoi inserire l'MFA resistente al phishing direttamente nei flussi di lavoro esistenti. Per esempi concreti di integrazione dell'accesso condizionale con la protezione avanzata dalle minacce e un'esperienza semplice per gli utenti, dai un'occhiata a questa guida alle impostazioni di sicurezza di M365 a prova di attacco. Passare all'MFA resistente al phishing non è solo un «nice to have»: sta rapidamente diventando la nuova base minima per proteggersi da attaccanti sofisticati.

Implementare l'MFA senza costi per le piccole aziende con Microsoft Entra ID

Se gestisci una piccola azienda, non ti servono un budget enorme o licenze costose per ottenere un MFA efficace. Microsoft Entra ID (ex Azure AD) offre le impostazioni di sicurezza predefinite, che ogni azienda può attivare con pochi clic.

Attiva le impostazioni di sicurezza predefinite nell'interfaccia di amministrazione di Entra. In questo modo l'MFA viene applicato immediatamente a tutti gli utenti, senza dover creare criteri complessi né acquistare licenze aggiuntive. La parte migliore? Queste impostazioni preconfigurate funzionano subito e offrono una protezione di base contro la compromissione degli account, bloccando per impostazione predefinita i protocolli di autenticazione legacy.

Il rollout va pianificato con cura. Avvisa in anticipo gli utenti, così nessuno si trova spiazzato dalle nuove richieste. Supporta chi ha meno familiarità con gli strumenti MFA o con le app di autenticazione. Se possibile, testa prima la configurazione con un gruppo pilota, per assicurarti che non ci siano sorprese con le app di lavoro critiche o con gli account di servizio.

La chiave è non limitarsi a «impostare e dimenticarsi». Verifica regolarmente chi rientra nelle impostazioni di sicurezza predefinite e controlla eventuali account che potrebbero sfuggire. Se in futuro avrai bisogno di controlli più granulari, valuta di introdurre l'accesso condizionale per fasi, ma parti in modo semplice e sicuro. Per un piano di rollout sicuro e idee per chiudere le lacune invisibili, questa guida pratica sull'accesso condizionale illustra le insidie e le strategie che ti conviene conoscere.

MFA per le aziende: best practice per l'applicazione dei criteri e la mitigazione dei rischi

  1. Applica l'MFA a tutti, senza eccezioni per comodità. Assicurati che tutti gli account utente (non solo quelli degli amministratori) siano coperti dai criteri MFA, inclusi quelli del personale temporaneo, dei fornitori e dei dirigenti. Le esclusioni devono essere rare, sempre a tempo determinato e giustificate da solide esigenze aziendali.
  2. Proteggi gli account di servizio e quelli non umani con soluzioni moderne. I tradizionali account di servizio possono rappresentare grandi lacune nell'MFA. Modernizzali usando strumenti come Entra Workload Identities per l'autenticazione gestita, con la gestione del ciclo di vita e la verificabilità. Approfondisci questo approccio in questa analisi sul rischio legato alle identità non umane.
  3. Accompagna gli utenti con formazione e supporto adeguati. Aiuta gli utenti a configurare app di autenticazione o token fisici e spiega perché l'MFA è importante. Offri supporto helpdesk durante il rollout, soprattutto a chi non ha familiarità con le nuove richieste MFA, come la corrispondenza dei numeri.
  4. Monitora i tentativi di aggirare l'MFA e gli accessi anomali. Configura avvisi e log per rilevare quando l'MFA manca in scenari ad alto rischio previsti o quando i protocolli legacy riescono a passare. Automatizza la risposta agli incidenti dove possibile, ad esempio reimpostando le password o richiedendo uno step-up dell'MFA sugli accessi rischiosi.
  5. Verifica regolarmente la copertura MFA e la conformità dei criteri. Non dare per scontato che la copertura sia «a posto». Usa dashboard di identità e report sia in Microsoft 365 sia nelle altre piattaforme se operi in ambienti multi-cloud. Traduci i risultati in report chiari, così IT e management possono vedere dove permangono i rischi. Una governance efficace va oltre pulsanti e impostazioni; per approfondire, leggi questi insegnamenti tratti dai fallimenti della governance di M365.

Seguendo questa checklist riduci notevolmente il rischio che gli attaccanti riescano ad aggirare l'MFA, indipendentemente dalla sofisticazione della tecnica. Coerenza, criteri chiari e revisioni periodiche mantengono alta la protezione e le falle chiuse.

Conditional Access Microsoft Multifactor authentication (MFA) Microsoft 365 Exchange Online

Related articles

RSS