Identita Azure: Perche MFA non basta

Cos'è la sicurezza delle identità Azure?

La sicurezza delle identità Azure è l'insieme di controlli che protegge gli account di Microsoft Entra ID, i ruoli privilegiati, i metodi di autenticazione, l'accesso alle applicazioni e le sessioni amministrative in Microsoft 365, Azure e nelle applicazioni SaaS connesse. È la porta d'ingresso al tenant. Se il livello identità è debole, un attaccante potrebbe non aver bisogno di un exploit lato server: una password rubata, un flusso di autenticazione vulnerabile al phishing, un'eccezione mal configurata o una sessione privilegiata possono bastare.

L'MFA è parte della soluzione, ma da sola non costituisce una strategia completa di sicurezza delle identità Azure. Un tenant ha bisogno anche di una copertura Conditional Access, di metodi di autenticazione forte per i ruoli privilegiati, di una risposta basata sul rischio, di controlli sugli account di accesso di emergenza, di una governance delle applicazioni e della verifica che le policy si applichino realmente agli accessi reali.

I due errori di base che si ripresentano più spesso sono semplici:

account privilegiati senza autenticazione forte applicata
Security Defaults disattivate senza una copertura Conditional Access equivalente

Questi errori creano uno scarto tra ciò che gli amministratori credono sia protetto e ciò che Microsoft Entra ID applica realmente.

Security Defaults e Conditional Access a confronto

Security Defaults sono le protezioni di base integrate di Microsoft, pensate per le organizzazioni che hanno bisogno di un punto di partenza semplice. La documentazione Microsoft descrive Security Defaults come adatte alle organizzazioni che vogliono migliorare la sicurezza ma non sanno da dove iniziare, e a quelle che utilizzano il livello gratuito di Microsoft Entra ID.

Security Defaults richiedono a tutti gli utenti di registrarsi per l'autenticazione a più fattori, impongono agli amministratori di eseguire l'MFA a ogni accesso, chiedono l'MFA agli altri utenti quando Microsoft lo ritiene necessario, bloccano i protocolli di autenticazione legacy, bloccano il device code flow e richiedono l'MFA per le attività privilegiate come l'accesso al portale Azure, al Microsoft Entra admin center, ad Azure PowerShell e ad Azure CLI. Sono volutamente semplici e non personalizzabili: l'interruttore è acceso o spento, senza possibilità di ambito o eccezioni.

Conditional Access è il motore di policy più flessibile. Le organizzazioni con licenze Microsoft Entra ID P1 o P2 e requisiti più complessi hanno di solito bisogno di Conditional Access per il targeting delle applicazioni, lo stato del dispositivo, le posizioni, le condizioni di rischio, i livelli di robustezza dell'autenticazione, i controlli di sessione e le eccezioni con ambito definito.

Lo stato pericoloso è il vuoto di transizione: Security Defaults è disattivata, ma Conditional Access non offre ancora una protezione equivalente o superiore. Le indicazioni Microsoft per l'abbandono di Security Defaults raccomandano di attivare immediatamente policy Conditional Access per proteggere l'organizzazione dopo la disattivazione. Microsoft distribuisce ora policy Conditional Access gestite da Microsoft per coprire questo passaggio: Blocca l'autenticazione legacy, Richiedi l'autenticazione a più fattori per la gestione di Azure, Richiedi l'autenticazione a più fattori per gli amministratori e Richiedi l'autenticazione a più fattori per tutti gli utenti. Attenzione al loro stato predefinito: Microsoft le crea in modalità Solo report, che valuta e registra ma non applica nulla, e le attiva non prima di 30 giorni se vengono lasciate in questo stato. Fino a quel momento, un elenco di policy che sembra coprire il rischio non sta applicando nulla — la stessa trappola descritta in Modalità solo report di Conditional Access ed esclusioni obsolete.

Perché l'MFA da sola non basta

L'MFA migliora la resistenza alla compromissione basata sulla sola password, ma non tutti i metodi MFA offrono lo stesso livello di protezione. Un tenant può restare esposto se:

gli amministratori sono esclusi dalle policy Conditional Access del tenant per motivi di troubleshooting di emergenza
Conditional Access si applica solo ad applicazioni selezionate mentre i portali di amministrazione restano raggiungibili
gli utenti privilegiati utilizzano metodi vulnerabili al phishing quando sarebbero disponibili metodi più robusti
esistono account break-glass ma non vengono monitorati a ogni accesso
l'autenticazione legacy o client più datati restano disponibili per alcuni flussi di lavoro
la registrazione e il recupero dei metodi di autenticazione sono controllati debolmente
le sessioni e i refresh token restano validi dopo un evento a rischio

Una di queste lacune è stata nel frattempo colmata a livello di piattaforma, e questo cambia il modo in cui va letto il problema delle esclusioni. Microsoft ora impone l'MFA sugli accessi Azure indipendentemente dalla configurazione del tenant: dall'ottobre 2024 per il portale Azure, il Microsoft Entra admin center e il Microsoft Intune admin center, dal febbraio 2025 per il Microsoft 365 admin center, e dal 1° ottobre 2025 per Azure CLI, Azure PowerShell, l'app mobile Azure, gli strumenti IaC e gli endpoint REST di Azure Resource Manager per le operazioni di creazione, modifica ed eliminazione. Questa applicazione ha priorità sulle intenzioni del tenant: Microsoft dichiara che le eccezioni e le esclusioni di Conditional Access non le si applicano più, e che copre ogni account utente, inclusi gli account break-glass. Non si estende a Microsoft Graph, che resta governato dalle proprie policy, e al momento Microsoft non la applica in Azure per US Government o altri cloud sovrani. L'MFA a livello di piattaforma alza il livello minimo su un elenco ristretto di superfici amministrative. Non fornisce al tenant una copertura Conditional Access, la robustezza dei metodi né le condizioni relative a dispositivo e rischio.

I livelli di robustezza dell'autenticazione di Microsoft Entra esistono perché la robustezza del metodo conta. Un livello di robustezza dell'autenticazione in Conditional Access può richiedere combinazioni specifiche di metodi, incluse opzioni resistenti al phishing come le chiavi di sicurezza passkey/FIDO2 o l'autenticazione basata su certificati, dove distribuita e supportata.

La catena d'attacco

Passo 1 - Individuare il percorso di identità debole

Un attaccante cerca account che possano autenticarsi senza controlli robusti: account amministrativi senza MFA, account esclusi da Conditional Access, account inattivi, account di emergenza non monitorati o applicazioni con permessi eccessivi.

Passo 2 - Ottenere una credenziale o una sessione valida

L'accesso iniziale può derivare dal riutilizzo di password, dal phishing di credenziali, dal furto di token, dall'abuso dell'help desk o da un dispositivo compromesso. La tecnica esatta varia, ma la domanda sul controllo dell'identità resta la stessa: il tenant richiede un metodo di autenticazione più robusto, un dispositivo conforme, un accesso a basso rischio o un percorso amministrativo approvato prima di concedere l'accesso?

Passo 3 - Raggiungere una superficie amministrativa

Se l'account riesce a raggiungere il portale Azure, il Microsoft Entra admin center, i portali di amministrazione di Microsoft 365, Microsoft Graph o PowerShell senza i controlli previsti, il tenant presenta una lacuna nella policy effettiva.

Passo 4 - Mantenere l'accesso

Una volta all'interno, l'attaccante può tentare di aggiungere un metodo di autenticazione, creare un nuovo utente, assegnare un ruolo, registrare un'applicazione, aggiungere una credenziale a un service principal o indebolire una policy Conditional Access. Queste azioni vanno trattate come eventi di audit ad alto segnale per le identità privilegiate.

Rilevamento

Segnali di accesso e policy

Esaminate i log di accesso di Microsoft Entra e i risultati di Conditional Access alla ricerca di:

accessi privilegiati riusciti in cui l'MFA non è stata richiesta ma avrebbe dovuto esserlo
accessi in cui il metodo di autenticazione non soddisfa il livello di robustezza previsto
accessi amministrativi da dispositivi non gestiti o da posizioni inattese
accessi a rischio medio o alto completati con successo
ripetuti fallimenti seguiti da un successo per un account amministrativo
accessi da parte di account di emergenza
utilizzo di client o protocolli legacy laddove dovrebbero essere bloccati

Segnali dei log di controllo (audit log)

Monitorate le modifiche al tenant che possono indebolire i controlli sulle identità:

Area di modifica	Perché è importante
Aggiornamento di una policy Conditional Access	Può rimuovere i requisiti relativi a MFA, dispositivo, rischio o applicazione
Aggiornamento di un'esclusione Conditional Access	Può creare un percorso di bypass silenzioso
Modifica di un metodo di autenticazione	Può favorire il recupero dell'account o la persistenza
Assegnazione di un ruolo	Può trasformare un singolo account nel controllo del tenant
Modifica delle credenziali di un'applicazione	Può creare una persistenza duratura basata sull'app
Modifica di Security Defaults	Può rimuovere la protezione di base se non viene sostituita

Avvertenze sul rilevamento

Non generate allerte basandovi solo sull'esistenza dell'MFA. Generate allerte sugli esiti effettivi. La domanda non è "il tenant ha una policy MFA?" La domanda è "questo accesso a questa risorsa da parte di questa identità ha soddisfatto il controllo richiesto?" Contano il risultato di Conditional Access, i dettagli dell'autenticazione, il livello di rischio, il ruolo dell'utente, l'applicazione, il dispositivo e la posizione.

Remediation

La base sicura è costituita da Security Defaults per i tenant semplici oppure da un design Conditional Access completo per i tenant più complessi. Lasciare assenti entrambe è l'errore evitabile.

1. Riattivare Security Defaults o sostituirle immediatamente

Se il tenant non dispone di un design Conditional Access maturo, attivate Security Defaults. Se l'organizzazione utilizza Conditional Access, documentate la base sostitutiva prima di disattivare Security Defaults e testatela su scenari di accesso reali.

Come minimo, il design sostitutivo deve coprire gli utenti privilegiati, la gestione di Azure, le superfici amministrative di Microsoft 365, gli accessi a rischio e l'esposizione all'autenticazione legacy.

2. Richiedere un'autenticazione forte per i ruoli privilegiati

Per gli utenti privilegiati normali, richiedete l'MFA e valutate metodi più robusti per i ruoli più sensibili. Utilizzate i livelli di robustezza dell'autenticazione di Conditional Access per richiedere metodi resistenti al phishing dove l'ambiente li supporta.

Le popolazioni di ruoli ad alto valore più comuni includono:

Global Administrator
Privileged Role Administrator
Conditional Access Administrator
Security Administrator
Application Administrator
Cloud Application Administrator
Exchange Administrator e SharePoint Administrator nei tenant fortemente basati su Microsoft 365

3. Gestire separatamente gli account di accesso di emergenza

Gli account di emergenza sono necessari per la resilienza. Microsoft raccomanda due o più account di accesso di emergenza esclusivamente cloud sul dominio *.onmicrosoft.com, né federati né sincronizzati dall'on-premises. Questi account non dovrebbero essere utilizzati come identità amministrative quotidiane, e il loro design di controllo dovrebbe evitare dipendenze che potrebbero fallire proprio durante l'emergenza che sono destinati a risolvere.

L'autenticazione resistente al phishing su questi account non è più opzionale. L'applicazione obbligatoria dell'MFA vale anche per gli account break-glass, quindi un account di emergenza protetto solo da password è ormai un blocco d'accesso in attesa di verificarsi. Le indicazioni attuali di Microsoft sono di registrare uno dei due metodi senza password che soddisfano il requisito MFA obbligatorio — una passkey (FIDO2), raccomandata da Microsoft, oppure l'autenticazione basata su certificati dove esiste già una PKI — mantenendo questo metodo diverso da quello usato dai normali account amministrativi. Escludete questi account dalle policy Conditional Access che bloccano o limitano l'accesso (le policy in sola modalità report non richiedono esclusioni), conservate le credenziali in posizioni sicure separate, mantenete l'assegnazione di Global Administrator permanentemente attiva anziché idonea (eligible) in PIM, generate un'allerta a ogni accesso e convalidate gli account almeno ogni 90 giorni. Se un account di emergenza effettua l'accesso, il team di sicurezza deve saperlo.

4. Rimuovere le eccezioni non necessarie

Esaminate ogni utente, gruppo, posizione, applicazione e condizione relativa al dispositivo esclusi in Conditional Access. Le eccezioni create durante il troubleshooting diventano spesso permanenti. Ogni eccezione dovrebbe avere un responsabile, una motivazione, una data di scadenza o una cadenza di revisione, e un monitoraggio compensativo.

5. Abbinare la sicurezza delle identità alla risposta basata sul rischio

Security Defaults e l'MFA non sostituiscono una risposta basata sul rischio nei tenant più grandi. Utilizzate i segnali di rischio di Microsoft Entra ID Protection tramite le condizioni di rischio di Conditional Access per richiedere un'autenticazione rafforzata (step-up), una nuova autenticazione, la remediation del rischio o il blocco quando viene rilevato un rischio. La raccomandazione attuale di Microsoft è di richiedere la remediation del rischio in caso di rischio utente elevato, e MFA più una frequenza di accesso Ogni volta in caso di rischio di accesso medio o elevato. Costruite queste regole come policy Conditional Access anziché nel riquadro di ID Protection: le policy di rischio legacy configurate all'interno di Microsoft Entra ID Protection andranno in pensione il 1° ottobre 2026, quindi i tenant che le utilizzano ancora devono ricreare gli equivalenti in Conditional Access e disattivare quelle vecchie.

Convalida dopo le modifiche alle policy

Convalidate il percorso di policy effettivo invece di fidarvi degli screenshot di configurazione:

testate l'accesso di un utente privilegiato al portale Azure e confermate che il controllo previsto sia effettivamente richiesto
testate l'accesso di un utente privilegiato a Microsoft Graph o PowerShell, dove pertinente
confermate che lo stesso account non sia escluso tramite un altro gruppo, posizione, applicazione o condizione relativa al dispositivo
esaminate i log di accesso per confermare il risultato di Conditional Access e i dettagli del metodo di autenticazione
convalidate l'allerta sugli account di emergenza esaminando il percorso dell'allerta, senza dare per scontato che esista
esaminate gli accessi a rischio e confermate che le policy basate sul rischio si applicherebbero
confermate che l'autenticazione legacy sia bloccata laddove Security Defaults o Conditional Access dovrebbero bloccarla
verificate se i requisiti di robustezza dell'autenticazione siano soddisfatti solo dai metodi previsti

Un controllo che esiste ma non si applica agli accessi che gli attaccanti possono utilizzare non è un controllo di sicurezza delle identità.

Come EtcSec rileva questo problema

EtcSec verifica i controlli sulle identità Azure a ogni scansione del tenant. Tutti e tre i controlli seguenti sono a livello di tenant: stabiliscono se il controllo esiste, il che è la precondizione per la domanda relativa al singolo accesso di cui tratta questo articolo.

MFA_NOT_ENFORCED_ADMINS segnala un tenant in cui nessuna policy Conditional Access attiva si rivolge ai ruoli di directory con un controllo di concessione basato su MFA.

AZ_SECURITY_DEFAULTS_DISABLED segnala un tenant il cui interruttore Security Defaults è disattivato. Se una base Conditional Access equivalente l'abbia sostituita è la verifica separata descritta in questo articolo.

CA_NO_MFA_REQUIREMENT segnala un tenant in cui nessuna policy Conditional Access attiva richiede l'MFA nei propri controlli di concessione.

La domanda rilevante non è se un tenant abbia policy sulla carta. È se gli accessi privilegiati affrontino realmente i controlli previsti e se le sessioni a rischio attivino una risposta.

Controlli correlati

Questo controllo va esaminato insieme a Azure Identity Protection: bloccare le credenziali trapelate, Accesso privilegiato Azure: troppi Global Admin, Azure Tenant Hardening: correggere le impostazioni predefinite insicure, Account guest Azure: la superficie di attacco dimenticata del tenant e App registration Azure: applicazioni del tenant con privilegi eccessivi. Una postura MFA debole peggiora molto quando lo stesso tenant presenta anche privilegi amministrativi permanenti, un accesso guest esteso, applicazioni rischiose o una risposta basata sul rischio insufficiente.

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