Lacune accesso condizionale Entra ID

Lacune accesso condizionale Entra ID: questo e il modo piu diretto per descrivere la differenza tra policies che sembrano ampie nell'admin center e controlli che valutano davvero i users, guests, apps, protocols e workload identities che contano in produzione. Un tenant puo apparire ben coperto da Conditional Access e lasciare comunque una reale esposizione attraverso esclusioni, protocolli legacy, percorsi guest o service principals che non sono mai stati nel scope corretto.

Questo articolo tratta Conditional Access come un problema di evidenza, non di screenshot. L'obiettivo e spiegare cosa costituisce una lacuna reale, quali segnali Microsoft la dimostrano, come correggerla senza creare lockout operativo e come validare che lo stato piu sicuro sia davvero applicato dopo il cambiamento. Per una review piu ampia del tenant, inizia da Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica.

Lacune accesso condizionale Entra ID: quali sono quelle reali?

Una lacuna di Conditional Access e qualsiasi scostamento tra la policy che pensi di imporre e i sign-ins che Microsoft Entra valuta realmente. Microsoft descrive Conditional Access come un motore di policy che combina segnali, applica assignments e conditions, e poi concede, blocca o restringe ulteriormente l'accesso. Il meccanismo e potente, ma non si dimostra da solo. Una policy riduce il rischio solo se punta alle identita e alle resources corrette, valuta il giusto protocol path e lascia prove nei sign-in logs e negli audit logs.

In pratica, una lacuna appare di solito in uno dei seguenti casi:

manca del tutto una policy per uno scope sensibile
una policy esiste, ma esclude i users o i roles che contano di piu
una policy protegge i users ma non le workload identities
una policy punta alle resources o ai client paths sbagliati
una policy usa un grant troppo debole per la resource protetta
una policy resta in report-only e non arriva mai all'enforcement

Microsoft ricorda inoltre che Conditional Access viene valutato dopo il primo fattore di autenticazione. Per questo il post non deve descrivere Conditional Access come un controllo magico "prima dell'autenticazione". E uno strato decisionale attorno a un sign-in, e la qualita di quella decisione dipende da scope, telemetry e design della policy.

Perche Conditional Access Puo Lasciare Comunque una Reale Esposizione

Molti team pensano a Conditional Access in modo binario: attivo o non attivo. L'esposizione reale e piu disordinata. Microsoft Entra valuta tutte le policies applicabili a un sign-in e l'utente deve soddisfare tutti i requisiti applicabili prima che l'accesso venga concesso. Il vero problema e che molti sign-ins che avrebbero dovuto essere governati non diventano mai davvero "applicable" nella pratica.

Il primo esempio e il drift di scope. I team di sicurezza spesso credono che una policy ampia copra tutti perche usa All users. Microsoft documenta che All users include anche i B2B guests, il che e utile, ma questo non significa che ogni percorso di identita sia coperto. Le workload identities sono una classe di assignment distinta, e le user-scoped policies non governano automaticamente i service principals. Se il tenant dipende da app registrations, automazione o integrazioni backend, questo va rivisto con lo stesso rigore riservato agli utenti umani.

Il secondo esempio e la differenza tra un grant ampio e un grant forte. Require multifactor authentication e Require authentication strength non sono lo stesso controllo. Se l'aspettativa di business e autenticazione phishing-resistant per ruoli admin o applicazioni sensibili, un semplice requisito MFA puo essere piu debole dell'intento reale. Per questo Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta, MFA Fatigue: rilevamento e prevenzione in Microsoft Entra ID e una review di Conditional Access spesso devono stare insieme.

L'ultimo problema ricorrente e il drift di validazione. Le policies accumulano esclusioni, bozze in report-only, template sovrapposti ed eccezioni di emergenza. Il portale continua a mostrare molte policies, ma i sign-ins che contano davvero possono ancora passare senza challenge o essere valutati su percorsi piu deboli del previsto.

Lacune di Scope: Users, Guests, Roles, Resources e Workload Identities

Users, directory roles ed exclusions

Il primo passo della review e mappare chi viene realmente colpito dalle policies. Conditional Access puo includere o escludere tutti i users, users e groups selezionati, directory roles, guests ed external users, oltre alle workload identities. Un tenant con una buona copertura user puo comunque lasciare ruoli privilegiati o exclusions privilegiate mal governate. Questo e ancora piu importante quando l'accesso privilegiato e gia troppo esteso, come in Accesso Privilegiato Azure: Troppi Admin Globali.

Le emergency access accounts sono l'esempio piu chiaro di exclusion intenzionale. Microsoft raccomanda di escluderle dalle policies di Conditional Access per evitare il lockout del tenant, ma questa raccomandazione non giustifica exclusions di comodo. Ogni exclusion deve avere una ragione stretta, un owner e monitoraggio attivo. Se la stessa break-glass viene usata per l'amministrazione normale, la lacuna e operativa, non teorica.

Guests ed external users

L'accesso guest ed esterno merita una review propria, non una rapida assunzione che All users abbia gia risolto tutto. Microsoft Entra consente di colpire tipi specifici di guests ed external users, e il comportamento esterno dipende anche dai cross-tenant trust settings. Per esempio, quando si usano le authentication strengths per external users, Microsoft documenta che il resource tenant valuta anche la fiducia MFA del home tenant. Questo significa che la copertura guest non e solo una questione di esistenza della policy. E una questione di scope e trust. Per questo Account Guest Azure: governance, MFA e rischio di accesso esterno va spesso rivisto nello stesso momento.

Resources, apps e user actions

Un'altra lacuna di scope compare quando il tenant protegge il set sbagliato di resources. Le policies possono essere assegnate a tutte le resources o a resources selezionate. Se il tenant protegge i Microsoft admin portals ma non le applicazioni di business o SaaS che i users raggiungono davvero per prime, la storia del controllo resta incompleta. Lo stesso problema compare quando il team si ferma a uno screenshot di una cloud app invece di verificare il vero resource path che un attaccante riutilizzerebbe dopo il furto di credenziali o sessione. Gli attacchi che abusano di sessioni valide o di percorsi OAuth si concatenano spesso con queste lacune; per questo Device Code Phishing: come OAuth Device Flow compromette gli account Entra ID e chiaramente collegato.

Workload identities

I service principals e le workload identities sono il punto cieco piu comune in tenant altrimenti maturi. Microsoft documenta che le chiamate eseguite da service principals non vengono bloccate da policies di Conditional Access scopeate sui users, e che bisogna usare Conditional Access per workload identities quando tali identita devono essere trattate tramite policy. In pratica, questo significa che un tenant puo mostrare una buona copertura MFA user lasciando al tempo stesso identita di automazione e applicazione fuori dal modello Conditional Access.

Questo non significa che ogni workload identity debba ricevere la stessa policy. Significa che il tenant deve dimostrare di sapere quali workload identities esistono, quali sono fuori per design e quali dipendono ancora da schemi piu deboli che dovrebbero migrare verso managed identities quando possibile.

Lacune di Controllo: MFA, Authentication Strengths, Legacy Authentication e Risk Policies

La copertura MFA non equivale a un design forte di autenticazione

Un tenant puo avere molte policies che richiedono MFA e lasciare comunque accessi di alto valore su metodi piu deboli del previsto. Microsoft documenta le authentication strengths come un controllo di Conditional Access che limita quali combinazioni di metodi possono essere usate per accedere a una resource. Questa distinzione conta ogni volta che l'obiettivo della policy e piu forte di "qualsiasi MFA va bene". Per ruoli admin o applicazioni sensibili, la differenza tra un grant MFA ampio e un requisito phishing-resistant o passwordless deve essere esplicita.

Legacy authentication resta una lacuna reale quando e ancora raggiungibile

Legacy authentication va trattata con precisione perche viene spesso descritta in modo troppo generico. Microsoft spiega che i protocolli legacy non supportano MFA e non trasmettono lo stato del dispositivo. Microsoft raccomanda inoltre di bloccare le requests di autenticazione che usano questi protocolli e osserva che tali percorsi restano molto usati nelle campagne di password spraying e credential stuffing.

La formulazione difendibile e questa: legacy authentication e una lacuna quando quei protocolli restano raggiungibili per identita o resources che il tenant ritiene protette da requisiti moderni di Conditional Access. Alcuni tenant chiudono questa lacuna con una policy di blocco dedicata. Altri si appoggiano a grant piu ampi che si applicano a tutti i client apps. Una buona review non consiste nel memorizzare un template. Consiste nel dimostrare, con sign-in logs, che i client legacy sono bloccati o assenti. Se il tenant sta gia rivedendo la debolezza del primo fattore, questo lavoro va collegato a Password Spraying: rilevamento e prevenzione per Active Directory ed Entra ID.

Le risk policies non sono implicite in una buona maturita di Conditional Access

Un tenant senza policies di sign-in risk o user risk non e automaticamente mal configurato, perche queste policies dipendono dalle capacita di Microsoft Entra ID Protection e dal corretto livello di licenza. Ma se la narrativa di sicurezza sostiene che l'accesso sia adattato al rischio, il tenant deve dimostrare che questi controlli esistono e vengono applicati. Microsoft documenta le sign-in risk policies separatamente e rende chiara la dipendenza da P2. Se il tenant non licenzia o non usa questa capacita, va detto in modo esplicito invece di suggerire un controllo inesistente. Si veda anche Azure Identity Protection: Criteri di Rischio.

Rilevamento

Il rilevamento delle lacune di accesso condizionale Entra ID e un esercizio di correlazione, non un alert basato su un singolo campo.

I sign-in logs di Microsoft Entra sono la fonte primaria di prova. Per sign-ins interattivi e non interattivi, rivedi almeno queste dimensioni:

Segnale	Perche conta
`conditionalAccessStatus`	Mostra se Conditional Access ha avuto successo, e fallito o non e stato applicato. `notApplied` non e automaticamente un bug, ma diventa una lacuna se il sign-in avrebbe dovuto essere nel giusto scope.
`appliedConditionalAccessPolicies`	Mostra quali policies hanno realmente valutato il sign-in. E piu utile che presumere quale policy avrebbe dovuto applicarsi.
`clientAppUsed`	Identifica percorsi legacy come IMAP, POP, SMTP, Exchange ActiveSync e altri clients che normalmente dovrebbero essere bloccati o assenti.
`riskLevelDuringSignIn` e campi di rischio correlati	Utili quando il tenant afferma di applicare enforcement basato sul rischio e deve dimostrarlo.
contesto di resource e app	Aiuta a capire se il sign-in ha raggiunto l'insieme di resources che la policy intendeva proteggere.
sign-ins interattivi vs non interattivi	Necessario perche i percorsi legacy e i percorsi guidati da servizi vengono spesso persi quando il team guarda solo agli interattivi.

La sfumatura importante e questa: un sign-in riuscito con conditionalAccessStatus = notApplied non basta da solo. La domanda reale e se quel sign-in avrebbe dovuto essere governato secondo il design dello stesso tenant.

Rivedere gli audit logs per il policy drift

Gli audit logs sono la seconda fonte di prova. Vanno usati per rivedere creazione di policies, aggiornamenti, cambi di enablement, passaggi a report-only, modifiche delle exclusions ed eliminazioni. Se un tenant cambia ripetutamente lo scope di Conditional Access senza conservare prove del perche, la lacuna reale e tanto di governance drift quanto di design della policy.

Rivedere lo stato della policy, non solo il testo

La modalita report-only e lo strumento What If sono utili, ma rispondono a domande diverse. report-only aiuta a stimare l'impatto senza enforcement. What If aiuta a simulare quali policies si applicherebbero a un sign-in di user o di service principal. Nessuno dei due sostituisce la prova di produzione. Una review matura usa entrambi e poi conferma il risultato nei dati reali di sign-in.

Remediation

La remediation deve chiudere prima le lacune di scope e di controllo con l'impatto maggiore.

Stabilire una baseline ampia per users e resources. Il tenant deve poter indicare quali policies di base proteggono l'accesso normale dei users alle resources che contano davvero, non solo a un admin portal o a un'applicazione preferita.
Rivedere le exclusions prima di aggiungere nuove policies. Se exclusions nascondono gia amministratori, guests o gruppi di alto valore, nuove policies possono creare l'illusione di progresso lasciando invariata l'esposizione reale.
Bloccare o eliminare i percorsi di legacy authentication. Quando Conditional Access e disponibile, scope di policy e validazione vanno usati per bloccare legacy authentication. Quando esistono ancora dipendenze di servizio o applicazione, queste vanno documentate esplicitamente e trattate come eccezioni da rimuovere, non come assunzioni permanenti di design.
Separare la copertura user dalla copertura workload identity. Se il tenant dipende da service principals, automazione o identita applicative, serve un percorso di review distinto per le workload identities. Non bisogna assumere che le user-scoped policies abbiano gia fatto questo lavoro.
Usare authentication strengths quando l'obiettivo di accesso e piu forte di un MFA generico. Applicazioni sensibili, accessi esterni e ruoli privilegiati richiedono spesso qualcosa in piu di un grant MFA ampio.
Aggiungere risk policies solo quando il tenant e davvero in grado di operarle. Se la valutazione del rischio supportata da P2 fa parte della narrativa di sicurezza, l'evidenza deve dimostrarlo. Se non e licenziata o distribuita, l'articolo deve trattarla come una limitazione consapevole, non come maturita nascosta.

Validazione Dopo Cambiamenti di Policy

E qui che il lavoro su Conditional Access fallisce piu spesso.

Per prima cosa, usa What If per verificare l'applicazione attesa delle policies per users rappresentativi, ruoli admin, guests e service principals. In secondo luogo, usa report-only quando e appropriato per capire il blast radius prima dell'enforcement. In terzo luogo, conferma il risultato reale nei sign-in logs dopo che la policy e stata attivata.

Questa validazione deve rispondere a domande concrete:

i users previsti colpiscono davvero le policies previste?
gli account esclusi restano esclusi in modo intenzionale e monitorato?
i sign-ins guest seguono il percorso di policy atteso?
le workload identities restano fuori dai controlli scopeati sui users?
i tentativi tramite clients legacy ora falliscono o scompaiono?
se sono state introdotte authentication strengths, i sign-ins interessati mostrano nella pratica la forza attesa?

Un tenant che non sa rispondere a queste domande con evidenze di sign-in e audit non ha completato la propria remediation.

Evidenze da Conservare Tra una Review e l'Altra

Conditional Access deriva in silenzio, quindi il pacchetto di evidenze conta.

Conservare	Perche conta
export di policy o screenshot con assignments, exclusions e grant controls	Prova cio che il tenant intendeva imporre in quel momento.
campioni di sign-in logs per identita rappresentative dentro e fuori scope	Prova cio che Microsoft Entra ha realmente valutato.
audit logs sulle modifiche di policy	Conserva chi ha cambiato scope, modalita, exclusions o logica di grant.
registro delle eccezioni per emergency accounts, guests o dipendenze legacy	Distingue eccezioni deliberate da lacune accidentali.
inventario delle workload identities	Prova che le identita non umane sono state riviste separatamente e non date per coperte.

Questo pacchetto permette alla review successiva di misurare il drift invece di ripartire da screenshot sparsi. Se il tenant ha anche bisogno di un quadro piu ampio per compliance, Requisiti NIS2 per la sicurezza delle identita: cosa devono dimostrare i team AD ed Entra e l'articolo complementare corretto, non un sostituto di questa review tecnica.

Come EtcSec Aiuta a Misurare le Lacune di Accesso Condizionale

Qui EtcSec deve essere posizionato in modo stretto: non come un rilevatore magico di sign-ins, ma come un modo per misurare di nuovo nel tempo condizioni strutturali di lacuna in Conditional Access.

Per questo articolo, i findings davvero pertinenti sono quelli che corrispondono gia a veri problemi di policy design:

CA_NO_MFA_REQUIREMENT
CA_NO_LEGACY_AUTH_BLOCK
CA_NO_RISK_BASED_SIGNIN
LEGACY_AUTH_ALLOWED

Questo mapping e utile perche supporta review ricorrenti. Il tenant puo riauditare dopo i cambiamenti di policy e verificare se le stesse lacune strutturali esistono ancora, invece di trattare Conditional Access come una configurazione iniziale una tantum.

Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione

Lacune accesso condizionale Entra ID: quali sono quelle reali?

Perche Conditional Access Puo Lasciare Comunque una Reale Esposizione