Identita Azure: Perche MFA non basta

Cos'e la sicurezza delle identita Azure?

La sicurezza delle identita in Microsoft Entra ID non si riduce a una domanda binaria del tipo "MFA si o no". Per un team tecnico, la domanda corretta e piu precisa: quali identita possono ancora autenticarsi con metodi troppo deboli, quali eccezioni sopravvivono, quali flussi non sono coperti da Conditional Access e quali trust esterni vengono accettati senza abbastanza controllo.

Microsoft documenta chiaramente che i Security Defaults sono una baseline per organizzazioni che vogliono partire rapidamente, ma non sono la risposta giusta per tenant con licenze P1/P2 o requisiti complessi. Microsoft documenta anche che per gli amministratori e raccomandata la phishing-resistant MFA, non una MFA qualsiasi. Questo cambia il modo in cui va letto il rischio: un tenant puo dichiarare di usare MFA e rimanere comunque esposto se continua ad affidarsi a metodi troppo facili da aggirare, a policy legacy o a eccezioni mai riviste.

Perche l'MFA da sola non basta

Non tutte le MFA hanno lo stesso valore difensivo

Microsoft Entra offre tre famiglie rilevanti in termini di forza: MFA standard, passwordless MFA e phishing-resistant MFA. Per gli account amministrativi Microsoft raccomanda esplicitamente la phishing-resistant MFA. Questo significa che l'obiettivo non dovrebbe essere solo "registrare un secondo fattore", ma verificare quale metodo e realmente permesso e richiesto per i ruoli piu sensibili.

Se un tenant consente ancora combinazioni troppo deboli, un aggressore puo puntare su phishing interattivo, session hijacking o abuso di eccezioni operative. Non tutte queste strade sono bloccate allo stesso modo da notifiche push, codici OTP o metodi legacy.

Security Defaults sono una baseline, non un programma di hardening completo

I Security Defaults impongono MFA per gli amministratori, richiedono la registrazione MFA, bloccano l'autenticazione legacy e proteggono attivita privilegiate su Azure Resource Manager. Microsoft pero specifica anche due limiti operativi importanti:

se hai Microsoft Entra ID P1 o P2 e requisiti complessi, Conditional Access e in genere l'approccio corretto
la protezione privilegiata dei Security Defaults per Azure Resource Manager non copre Microsoft Entra ID o Microsoft Graph

Questa distinzione e importante per i team che amministrano ruoli directory, app registration, consent, sync e workload identities: una baseline valida non sostituisce una strategia di policy mirata.

Le policy dei metodi di autenticazione contano quanto l'obbligo MFA

Microsoft raccomanda di gestire i metodi tramite Authentication methods policy. Le vecchie policy MFA/SSPR restano il modo legacy di gestire alcuni metodi e Microsoft ha annunciato la loro deprecazione operativa. Se un tenant non ha completato la migrazione, puo trovarsi con metodi registrabili o usabili in modi inattesi perche piu policy restano contemporaneamente rilevanti.

Per un audit tecnico questo vuol dire che non basta chiedere "chi ha MFA?". Bisogna verificare:

quali metodi sono abilitati nella Authentication methods policy
se restano policy legacy ancora attive
se gli amministratori possono registrare e usare metodi davvero coerenti con una baseline ad alta affidabilita

I service principal e le workload identity non si proteggono come gli utenti

Microsoft documenta che le Conditional Access policy assegnate agli utenti non bloccano le chiamate dei service principal. Se un tenant usa service principal o account di sync con privilegi ampi, limitarsi alla MFA per gli utenti amministrativi non e sufficiente. Va chiarito quali automazioni usano ancora segreti statici, quali identita applicative sono privilegiate e dove e possibile sostituirle con managed identities o policy specifiche per workload identities.

Gli utenti esterni aggiungono un altro piano di rischio

Per guest ed external users, Microsoft documenta che le authentication strengths lavorano insieme alle impostazioni di cross-tenant access e alla fiducia MFA in ingresso. Se la fiducia MFA tra tenant e configurata male, oppure se si accettano utenti esterni senza chiarire dove e come soddisfano la MFA, il controllo puo risultare piu debole di quanto sembri dalla sola schermata di Conditional Access.

Audit tecnico minimo da eseguire

Un audit serio deve partire da verifiche ripetibili, non da impressioni.

1. Verificare se il tenant sta usando Security Defaults o Conditional Access

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled

Se IsEnabled = True, il tenant usa la baseline Microsoft. Se False, devi verificare che esista una copertura equivalente o migliore tramite Conditional Access.

2. Verificare i metodi realmente gestiti nella Authentication methods policy

Get-MgPolicyAuthenticationMethodPolicy |
  Select-Object -ExpandProperty AuthenticationMethodConfigurations |
  Select-Object Id, State

L'obiettivo qui non e solo contare i metodi abilitati, ma capire se i metodi forti sono disponibili e se i metodi piu deboli o legacy restano una scorciatoia accettata.

3. Verificare i ruoli amministrativi e le eccezioni

Get-MgDirectoryRole | Select-Object DisplayName, Id

Poi va verificato quali utenti sono assegnati ai ruoli piu sensibili e quali account di emergenza sono esclusi dalle policy. Microsoft raccomanda esplicitamente di escludere i break-glass accounts dalle policy MFA troppo rigide per evitare lockout, ma questo non significa lasciarli fuori controllo: significa documentarli, proteggerli e testarli separatamente.

4. Verificare guest e trust esterni

Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
Get-MgPolicyCrossTenantAccessPolicyDefault

Questa verifica serve a capire chi puo invitare guest, se la collaborazione B2B e aperta per default e se MFA o device claims da tenant esterni vengono fidati in modo coerente con la tua strategia.

Catena di attacco reale

Una catena di abuso tipica contro Entra ID non richiede una singola falla spettacolare. Piu spesso nasce da una combinazione di controlli mediocri:

un amministratore usa ancora un metodo MFA non phishing-resistant o non ha una policy dedicata
il tenant ha Security Defaults disabilitati senza una copertura Conditional Access equivalente
le Authentication methods policy non sono state ripulite e i metodi legacy restano registrabili
esistono account break-glass, guest o service principal con privilegi ampi e review insufficiente
un aggressore ottiene un accesso iniziale e poi punta a ruoli directory, app registration o consensi applicativi

Il punto non e dire che "MFA non serve". Il punto e dire che MFA senza hardening del contesto identitario non chiude i percorsi di abuso piu interessanti.

Detection

Per questo tema la detection utile e una miscela di postura e attivita:

cambiamenti ai Security Defaults
modifiche alle Authentication methods policy
nuove esclusioni o cambi di stato nelle Conditional Access policy per ruoli amministrativi
nuovi assegnamenti di ruoli directory ad alto privilegio
service principal privilegiati che continuano a usare segreti statici
guest access accettato senza una strategia chiara di MFA trust o di challenge nel resource tenant

A livello operativo conviene rivedere regolarmente:

sign-in logs degli amministratori
audit logs di Entra per cambi policy e assegnazioni di ruolo
inventory di metodi di autenticazione registrati dagli admin
elenco dei break-glass accounts e relativa prova di test
elenco dei service principal che sostituiscono ancora managed identities

Remediation

1. Decidere una baseline esplicita

Se il tenant e piccolo o privo di P1/P2, i Security Defaults possono essere la baseline iniziale. Se il tenant ha requisiti complessi o licenze adeguate, passa a Conditional Access e documenta per iscritto quali policy sostituiscono i controlli di baseline.

2. Richiedere phishing-resistant MFA agli amministratori

Microsoft raccomanda di usare authentication strengths e di imporre la phishing-resistant MFA almeno per i ruoli amministrativi piu sensibili. Questo e il passaggio che separa un tenant "con MFA" da un tenant che riduce davvero il rischio di compromissione privilegiata.

3. Migrare tutto nella Authentication methods policy

La gestione dei metodi dovrebbe stare nella Authentication methods policy, non restare distribuita tra impostazioni legacy MFA e SSPR. Questa migrazione va trattata come parte dell'hardening, non come un dettaglio amministrativo.

4. Trattare break-glass e sync accounts come eccezioni controllate

Gli account di emergenza devono essere pochi, documentati, protetti e testati. Gli account di sync e altri principal di infrastruttura vanno separati dall'uso umano e non devono diventare scorciatoie amministrative.

5. Governare guest e trust cross-tenant

Per guest ed external users:

riduci chi puo invitarli
chiarisci se il tenant si fida della MFA del tenant esterno o richiede un challenge locale
applica authentication strength dove supportato
usa il grant control MFA dove authentication strength non e applicabile

6. Ridurre i privilegi delle workload identity

Dove possibile, sostituisci segreti statici con managed identities. Dove non e possibile, riduci scope e lifetime dei segreti e tieni un inventario separato delle workload identity privilegiate.

Validazione

Una remediation credibile deve dimostrare almeno questo:

gli admin role critici richiedono davvero phishing-resistant MFA o un controllo equivalente deliberato
non esistono piu metodi legacy gestiti solo tramite vecchie policy MFA/SSPR
i break-glass account sono pochi, documentati e testati
guest e trust esterni sono coerenti con la politica di accesso definita
i service principal privilegiati sono stati ridotti o sostituiti da managed identities dove possibile

Se una di queste condizioni manca, il tenant puo anche dichiarare "MFA attiva", ma la postura identitaria resta incompleta.

Fonti primarie

Come EtcSec rileva questo

EtcSec guarda questo rischio da piu angoli:

MFA_NOT_ENFORCED_ADMINS
AZ_SECURITY_DEFAULTS_DISABLED
CA_NO_MFA_REQUIREMENT
esposizioni adiacenti su guest, ruoli privilegiati, app registration e workload identity

La domanda che conta non e se MFA compare in un diagramma. La domanda che conta e se le identita che amministrano il tenant sono davvero difficili da riutilizzare, aggirare o estendere.

Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta