MFA non obbligatoria per tutti gli utenti Entra: la lacuna critica di accesso condizionale che i criteri per soli amministratori non coprono

MFA non obbligatoria per tutti gli utenti Entra: che cosa significa davvero

MFA non obbligatoria per tutti gli utenti Entra indica una lacuna di accesso condizionale specifica, frequente e di gravità Critica in Microsoft Entra ID — e non è lo stesso difetto dell'assenza totale di accesso condizionale. Un tenant può superare qualsiasi checklist del tipo «avete l'accesso condizionale?», mostrare un criterio che punta letteralmente a All users (tutti gli utenti), e lasciare comunque ogni account non amministrativo raggiungibile con la sola password. Questo accade quando il controllo di concessione del criterio richiede qualcosa di diverso dall'MFA (la conformità del dispositivo, per esempio), oppure quando l'applicazione dell'MFA è sparsa tra più criteri limitati a ruoli o ad applicazioni, ciascuno solido preso a sé, che però non arrivano mai a sommarsi in una copertura generale.

È la variante più stretta, più comune e più pericolosa di due problemi meglio conosciuti:

• Nessun criterio di accesso condizionale, di alcun tipo, rivolto a tutti gli utenti. È il difetto di copertura di base — si veda Lacune di copertura dei criteri di base di accesso condizionale in Entra ID per i tenant privi di qualsiasi criterio che copra i ruoli amministrativi, tutti gli utenti, tutte le applicazioni cloud o la conformità dei dispositivi. Questo articolo presuppone che un criterio rivolto a tutti gli utenti esista già; la lacuna qui è più stretta e più facile da mancare — il criterio esiste, ma non richiede l'MFA.
• MFA richiesta solo agli amministratori. La maggior parte dei progetti di hardening dell'accesso condizionale parte da qui, e con buone ragioni — si veda Sicurezza delle identità Azure: perché l'MFA da solo non basta. Ma un criterio MFA limitato agli amministratori, per quanto ben costruito, è strutturalmente incapace di proteggere gli account a cui non è mai stato assegnato. Gli utenti standard accedono alle stesse caselle di posta, agli stessi siti SharePoint e alle stesse applicazioni aziendali degli amministratori; non sono un obiettivo di minor valore, sono semplicemente un obiettivo non protetto.

È anche per questo che la lacuna è facile da mancare perfino per team che hanno già svolto un vero lavoro di hardening. Un'organizzazione che ha distribuito l'MFA sugli amministratori ai sensi di MFA_NOT_ENFORCED_ADMINS, o che ha blindato l'autenticazione dei Global Admin ai sensi di PA_GLOBAL_ADMIN_NOT_MFA, ha affrontato per primo il lavoro che sembra più difficile, e presume ragionevolmente che il caso più semplice e più ampio — tutti gli utenti restanti — sia già coperto per estensione. Strutturalmente non lo è: i criteri limitati agli amministratori e quelli rivolti a tutti gli utenti poggiano su condizioni di assegnazione diverse in Entra ID, cosicché completare l'uno lascia la copertura dell'altro esattamente dov'era all'inizio, a zero.

Due modelli distinti, due azioni di Secure Score distinte

Microsoft non modella «richiedere l'MFA» come un controllo unico. Nella galleria dei modelli di accesso condizionale, Require multifactor authentication for admins e Require multifactor authentication for all users figurano come due modelli separati. Entrambi compaiono insieme sotto la categoria «Secure foundation» di Microsoft — l'insieme che Microsoft raccomanda esplicitamente di distribuire come gruppo — ed entrambi ricompaiono, sempre come due voci separate, sotto la categoria «Zero Trust». Nessuna delle due descrizioni di modello sostiene di coprire il terreno dell'altra, in nessuno dei due elenchi.

La stessa separazione esiste nel punteggio. L'Identity Secure Score di Microsoft Entra ID traccia «Require multifactor authentication (MFA) for administrative roles» ed «Ensure all users can complete MFA» come due azioni di miglioramento distinte nel proprio catalogo. Un tenant può ottenere il massimo sulla prima e zero sulla seconda; Secure Score non le tratta come ridondanti, e nemmeno dovrebbe farlo chi rilegge un'esportazione di accesso condizionale.

L'azione relativa a tutti gli utenti è inoltre valutata come percentuale del totale degli utenti protetti, non come esito binario superato/non superato. Nell'esempio numerico di Microsoft, avere 5 utenti protetti su 100 utenti totali rende circa lo 0,53 % di un possibile 10,71 % per quel controllo — il che significa che la maggior parte dei tenant che hanno «iniziato» con l'MFA per tutti gli utenti si porta ancora dietro quasi tutta l'esposizione che il controllo dovrebbe chiudere.

Come una copertura frammentata nasconde la lacuna

Il modello MFA per amministratori e il modello MFA per tutti gli utenti non sono delimitati allo stesso modo, e quella differenza è esattamente il modo in cui una lacuna sopravvive a una revisione superficiale dei criteri:

• Require multifactor authentication for admins si assegna sotto Directory roles (ruoli di directory), e soltanto a un elenco definito di ruoli predefiniti — Global Administrator, Application Administrator, Authentication Administrator, Privileged Role Administrator, Security Administrator, e altri nominati esplicitamente nella documentazione Microsoft. L'avvertenza di Microsoft è diretta: "Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles." Un ruolo personalizzato «IT Support» dotato di permessi elevati, o un ruolo assegnato solo a livello di unità amministrativa, è invisibile a questo criterio anche mentre è abilitato e applicato.
• Require multifactor authentication for all users si assegna sotto Include: All users, con esclusioni limitate agli account di emergenza e agli account di servizio per la sincronizzazione della directory. Non esiste alcuna condizione di ruolo attraverso cui un utente possa sfuggire.

Poiché i due criteri usano modelli di assegnazione diversi, un tenant può accumulare più criteri MFA realmente applicati — uno limitato ai Global Admin, uno limitato a una specifica applicazione finanziaria, uno attivato solo da un accesso a rischio — e non aver mai distribuito l'unico criterio il cui Include vale letteralmente All users, il cui Target resources vale All resources, e il cui controllo di concessione richiede l'MFA. Ogni criterio preso singolarmente è reale; nessuno di essi, nemmeno sommati, equivale alla base che Microsoft raccomanda. Accesso condizionale Azure: bypass dell'MFA e autenticazione legacy tratta lo schema più ampio di esclusioni e disallineamenti di ambito che lasciano sembrare completo un insieme di accesso condizionale pur lasciando esposizione reale in produzione. Accesso privilegiato Azure: troppi amministratori globali tratta il difetto parallelo sul lato privilegiato, dove i ruoli amministrativi permanenti e le carenze di PIM aggravano la stessa debolezza di fondo dall'altro capo.

Rilevamento

Confermare questa lacuna non richiede di indovinare — Microsoft Entra ID registra l'esatta fase di autenticazione raggiunta a ogni accesso, per utente e per applicazione.

Secondo le indicazioni di Microsoft per individuare le lacune di MFA degli amministratori: "Any sign-in where Authentication requirement is Single-factor authentication means there was no multifactor authentication policy that was required for the sign-in." Quelle indicazioni sono scritte specificamente per gli amministratori, ma il campo in sé non è delimitato per ruolo — è una proprietà dell'evento di accesso, quindi lo stesso controllo si applica a qualunque popolazione di utenti, amministratori o no.

authenticationRequirement è esposto sulla risorsa signIn dell'endpoint beta di Microsoft Graph — non è presente sulla risorsa signIn stabile v1.0 — e supporta $filter con gli operatori eq e startsWith:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=authenticationRequirement%20eq%20%27singleFactorAuthentication%27

Il filtro è codificato in percentuale — %20 per gli spazi, %27 per gli apici — così la richiesta funziona sia incollata in un client da riga di comando sia in Graph Explorer. Lasciati non codificati, gli spazi grezzi fanno rifiutare l'URL localmente a strumenti come curl, prima ancora che venga inviata.

Oppure con il modulo beta dell'SDK PowerShell per Microsoft Graph:

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgBetaAuditLogSignIn `
  -Filter "authenticationRequirement eq 'singleFactorAuthentication'" `
  -Top 50 `
  -Property UserPrincipalName, AppDisplayName, CreatedDateTime, AuthenticationRequirement

Remediation

1. Distribuire il modello MFA per tutti gli utenti di Microsoft

Verificate prima se Microsoft non ne abbia già messo uno nel tenant. I criteri Microsoft-managed sono creati e distribuiti da Microsoft direttamente nei tenant idonei, e uno di essi si chiama Multifactor authentication for all users — "covers all users in your organization and requires them to use multifactor authentication whenever they sign in." Arriva inerte: "The policy is automatically created in your tenant in a Report-only state." Microsoft lo abilita poi "no less than 30 days after they're introduced in your tenant if they're left in the Report-only state," avvisando i tenant due settimane prima. Filtrate su Microsoft nella colonna Created by prima di costruire un duplicato.

Altrimenti usate la galleria dei modelli di accesso condizionale, oppure costruite direttamente il criterio equivalente:

• In Assignments → Users, impostate Include: All users.
• In Exclude, aggiungete soltanto gli account di accesso di emergenza «break-glass» documentati della vostra organizzazione e, se usate la sincronizzazione di identità ibrida, il ruolo Directory Synchronization Accounts — non un'ampia esclusione «team IT» che ricrea silenziosamente la lacuna.
• In Target resources, impostate Include: All resources, senza esclusioni di applicazioni.
• In Grant, scegliete Require authentication strength e selezionate la forza predefinita Multifactor authentication strength.

2. Distribuire in modalità solo report, e verificare che ne esca davvero

Esaminate l'impatto previsto tramite Policy impact o la cartella di lavoro Conditional Access Insights and Reporting prima di spostare Enable policy su On — è così che intercettate un account di emergenza, di servizio o ad autenticazione legacy che altrimenti resterebbe bloccato all'improvviso. Un criterio lasciato indefinitamente in modalità solo report, o un elenco di esclusioni cresciuto silenziosamente oltre l'ambito originario, non applica nulla pur continuando a mostrare «On» — verificatelo dopo il rilascio, non solo alla creazione.

3. Validare la copertura con lo strumento What If

Eseguite lo strumento What If su un campione di utenti ordinari, non amministratori — non solo sugli account amministrativi già coperti dall'altro criterio — per confermare che il nuovo criterio si applichi davvero a loro. I criteri abilitati e i criteri in modalità solo report sono entrambi inclusi in un'esecuzione di valutazione, quindi un criterio ancora fermo in solo report comparirà qui. Leggete l'esito come una simulazione e non come una garanzia: Microsoft nota che lo strumento "doesn't test for Conditional Access service dependencies," e che le condizioni lasciate non specificate sono condizioni che non può valutare.

4. Non sostituire con questo l'MFA per gli amministratori, né viceversa

Se nemmeno il criterio MFA limitato agli amministratori è ancora distribuito, trattatelo come una seconda azione, separata. Si vedano Sicurezza delle identità Azure: perché l'MFA da solo non basta e Accesso privilegiato Azure: troppi amministratori globali. Distribuire un criterio non sostituisce l'altro; entrambi sono nell'elenco «Secure foundation» di Microsoft per un motivo.

5. Andare oltre l'MFA di base quando la copertura è stabile

Una volta che la copertura MFA ampia è applicata e stabile, passate dalla forza di base Multifactor authentication strength a metodi resistenti al phishing o senza password per gli utenti che possono sostenerli — si veda Entra ID: il cambiamento nella registrazione MFA senza password.

Come EtcSec rileva questo problema

L'audit Azure/Entra di EtcSec verifica specificamente MFA_NOT_ENFORCED_ALL: una configurazione di accesso condizionale in cui nessun criterio rivolto a tutti gli utenti e a tutte (o praticamente tutte) le applicazioni cloud porta un controllo di concessione che richieda l'MFA o una forza di autenticazione equivalente all'MFA. Viene valutato in modo indipendente da MFA_NOT_ENFORCED_ADMINS, PA_GLOBAL_ADMIN_NOT_MFA e CA_NO_POLICY_ALL_USERS — risolvere uno di quei controlli non risolve questo.