Accesso condizionale solo report, esclusioni obsolete

Accesso condizionale solo report, esclusioni obsolete: cosa significa davvero «applicato»

La modalità solo report (report-only) dell'Accesso condizionale e le esclusioni obsolete sono le due ragioni più comuni per cui un criterio di Accesso condizionale risulta «Attivato» nell'interfaccia di amministrazione di Microsoft Entra pur non bloccando assolutamente nulla. Entrambe le situazioni passano facilmente inosservate durante una revisione rapida del portale, perché il criterio esiste ancora, le sue condizioni sono ancora configurate correttamente e compare ancora nell'elenco dei criteri:

Il criterio — o una modifica apportata ad esso — si trova in modalità solo report, che valuta gli accessi e ne registra l'esito, ma non concede, blocca o mette mai alla prova l'accesso.
Il criterio è applicato, ma il suo elenco di esclusioni è cresciuto oltre il motivo ristretto e documentato per cui era stato creato, così gli accessi più rilevanti gli sfuggono senza essere toccati.

Nessuna delle due situazioni è un bug. Entrambe sono funzionalità Microsoft Entra supportate e intenzionali. Il divario è operativo: nessuno ha ricontrollato se l'eccezione fosse ancora necessaria. Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione copre l'ambito e il panorama dei controlli più ampio — criteri assenti, identità dei carichi di lavoro, autenticazione legacy. Questo articolo resta volutamente circoscritto: cosa succede dopo che un criterio esiste, quando il suo stato di applicazione o il suo elenco di esclusioni si allontana silenziosamente da ciò che il tenant crede di avere protetto.

Modalità solo report: il non-controllo silenzioso

La modalità solo report è uno stato per singolo criterio nell'Accesso condizionale. Microsoft la documenta come un modo per consentire agli amministratori di «testare la maggior parte dei criteri di Accesso condizionale prima di attivarli» — durante l'accesso, il sistema valuta il criterio ma non applica i controlli di concessione o di sessione, e agli utenti non viene mai richiesta la MFA, la conformità del dispositivo, né vengono bloccati da un criterio in modalità solo report.

⚠️

⚠️ Attenzione: la modalità solo report non è una versione indebolita di «Attivato». Equivale funzionalmente a «Disattivato» ai fini dell'applicazione — il criterio produce prove nei log, non un controllo di accesso.

Perché la modalità solo report deriva da uno stato di test a uno permanente

Il meccanismo che rende questo pericoloso in pratica non è la distribuzione iniziale — la maggior parte dei team mette deliberatamente in scena i nuovi criteri in modalità solo report per una finestra di revisione. Il rischio nasce nella deriva successiva: un criterio applicato può essere silenziosamente riportato in modalità solo report da chiunque disponga dei diritti di Amministratore di accesso condizionale. La documentazione Microsoft è esplicita nell'affermare che la modalità solo report non applica mai i controlli di concessione o di sessione, indipendentemente dallo stato precedente del criterio: «durante l'accesso, il sistema valuta i criteri in modalità solo report ma non li applica». Quel singolo interruttore, cambiato durante una sessione di risoluzione dei problemi o un'eccezione di accesso di emergenza e mai ripristinato, rimuove silenziosamente un controllo che ogni dashboard e ogni elenco di criteri continua comunque a mostrare come configurato.

La raccomandazione di Microsoft è di convalidare le modifiche a un criterio già applicato clonandolo in una copia in modalità solo report, anziché commutare l'interruttore del criterio originale — confrontando i risultati della copia con quelli del criterio attivo, per poi eliminare la copia una volta soddisfatti. Quando questo schema non viene seguito, è il criterio originale stesso a finire per restare in modalità solo report, a volte indefinitamente.

Esclusioni obsolete ed eccessive: come si erode la copertura nel tempo

Le esclusioni esistono per ragioni operative reali: un ufficio remoto che non può ancora soddisfare un requisito di posizione, un dispositivo legacy in attesa di sostituzione, un account di accesso di emergenza (break-glass). La stessa guida Microsoft sulla gestione degli utenti esclusi è esplicita sul fatto che si parte in piccolo e si diventa un problema:

«Spesso, quando si configura per la prima volta un'esclusione, esiste un breve elenco di utenti che aggirano il criterio. Nel tempo, altri utenti vengono aggiunti all'esclusione e l'elenco cresce. A un certo punto, è necessario rivedere l'elenco e confermare che ciascuno di questi utenti sia ancora idoneo per l'esclusione.»

Tre modi in cui gli elenchi di esclusione peggiorano più di quanto sembri

Le esclusioni di singoli utenti o di gruppi locali legacy non offrono alcuna visibilità continua. Gli utenti spesso non sanno di essere esclusi, e se l'esclusione utilizza un gruppo sincronizzato dall'ambiente locale o un gruppo dinamico, gli amministratori hanno una visibilità limitata su chi ne fa parte e perché.
L'appartenenza self-service può trasformare un'esclusione in un modo per aggirare il criterio. Se il gruppo di esclusione consente l'adesione self-service (uno schema legittimo per lo scenario del «dipendente in viaggio»), qualsiasi utente che scopra il gruppo può aggiungersi da solo.
L'idoneità non viene mai ricontrollata. Un utente escluso a causa di un dispositivo legacy ormai sostituito, o un'esclusione per un fornitore che è sopravvissuta alla fine del contratto, resta escluso a tempo indeterminato perché nulla impone una nuova revisione.

Il controllo compensativo: gruppi assegnati più verifiche di accesso ricorrenti

Il controllo compensativo raccomandato da Microsoft consiste nel far corrispondere ogni esclusione a un gruppo di sicurezza Microsoft Entra dedicato, con appartenenza Assegnata (non un elenco di singoli utenti, né un gruppo sincronizzato legacy), e nell'allegare una verifica di accesso ricorrente a quel gruppo. Lo schema documentato per un'esclusione basata sulla posizione è una verifica che viene eseguita ogni settimana, non termina mai, richiede l'autoattestazione di ogni membro e rimuove automaticamente chi non risponde. Per un'esclusione legata all'autenticazione legacy, lo schema raccomandato è una verifica ricorrente con i proprietari delle unità di business come revisori e applicazione automatica dei risultati. Entrambi gli schemi richiedono una licenza Microsoft Entra ID P2, Microsoft Entra ID Governance o Enterprise Mobility + Security E5 — le verifiche di accesso non sono disponibili nei livelli inferiori.

💡

💡 Suggerimento: se un gruppo di esclusione non ha alcuna verifica di accesso collegata, trattate questo come il riscontro stesso — non «questa esclusione è ancora ragionevole», ma «nulla in questo tenant porrà mai più questa domanda».

Le esclusioni presentano anche un punto cieco di ambito che la maggior parte dei revisori non controlla: le esclusioni di risorse sui criteri «Tutte le risorse». Microsoft sta distribuendo una modifica all'applicazione, a partire dal 15 giugno 2026, che colma esattamente questa lacuna. In precedenza, quando un criterio «Tutte le risorse» aveva un'esclusione di risorsa, gli accessi che richiedevano solo un insieme ristretto di «ambiti di base» (openid, profile, email, offline_access, User.Read e alcuni ambiti di directory simili) venivano silenziosamente esentati da qualsiasi applicazione — anche se l'amministratore che aveva creato il criterio credeva che «Tutte le risorse» significasse davvero tutto. Client pubblici come Azure CLI o VS Code, e app web riservate che richiedono solo quegli ambiti, passavano senza essere messi alla prova. Gli aggressori che abusano di flussi OAuth richiedendo ambiti minimi, in modo simile a quanto avviene nel device code phishing, sono esattamente il tipo di accesso che questa lacuna avrebbe lasciato passare senza revisione. Questo è un caso in cui la telemetria stessa di Microsoft ha confermato che le esclusioni a livello di risorsa producevano lacune di copertura più ampie e non volute di quanto i tenant credessero — la stessa modalità di fallimento di cui tratta questo articolo, solo a livello di ambito anziché a livello di utente.

Rilevamento

Il rilevamento qui è un esercizio di correlazione tra le prove di accesso e la cronologia delle modifiche ai criteri, non un singolo avviso.

Segnale	Dove trovarlo	Cosa indica
Esito per criterio nella scheda Solo report di una voce del log di accesso	Interfaccia di amministrazione Entra → dettagli del log di accesso	Se quello specifico accesso sarebbe passato, fallito o avrebbe richiesto un'azione se il criterio fosse stato applicato
`appliedConditionalAccessPolicies[].result` tramite Microsoft Graph	`GET /auditLogs/signIns` (i valori solo report richiedono l'intestazione `Prefer: include-unknown-enum-members`)	Versione programmatica della scheda precedente — valori di enumerazione: `success`, `failure`, `notApplied`, `notEnabled`, `reportOnlySuccess`, `reportOnlyFailure`, `reportOnlyNotApplied`, `reportOnlyInterrupted`
`enforcedGrantControls` / `enforcedSessionControls` sullo stesso oggetto	Microsoft Graph `appliedConditionalAccessPolicy`	Conferma quali controlli si sono effettivamente applicati per un dato accesso rispetto a quelli che il criterio è configurato per richiedere
Cartella di lavoro Conditional Access Insights and Reporting	Interfaccia di amministrazione Entra, richiede Entra ID P1 + un'area di lavoro Log Analytics che riceve i log di accesso	Confronto aggregato solo report rispetto ad applicato su un intervallo di tempo, un insieme di app e un insieme di utenti — il modo più rapido per individuare un criterio rimasto in modalità solo report ben oltre una finestra di test
Vista Impatto criterio (anteprima)	Interfaccia di amministrazione Entra, ruolo Lettore di sicurezza o superiore	Istantanea a 24h/7g/1 mese dell'impatto potenziale ed esistente di un criterio, senza creare una query della cartella di lavoro
Log di controllo: modifiche di stato «Enable policy»	Interfaccia di amministrazione Entra → Log di controllo, filtrati sugli aggiornamenti dei criteri di Accesso condizionale	L'evento specifico su cui allertare: qualsiasi transizione da Attivato a Solo report su un criterio precedentemente applicato
Appartenenza al gruppo di esclusione + risultati/log di controllo delle verifiche di accesso	ID Governance → Verifiche di accesso → Risultati / Log di controllo	Chi è stato rimosso, approvato automaticamente o non ha mai risposto — la prova concreta che esisteva un'esclusione obsoleta
`membershipType` del gruppo di esclusione	Endpoint `groups` di Microsoft Graph o interfaccia di amministrazione Entra	Segnala i gruppi di esclusione sincronizzati dall'ambiente locale o dinamici anziché Assegnati — lo schema che Microsoft indica come causa di riduzione della visibilità

🚨 Pericolo: un criterio senza alcun evento reportOnlyFailure o Failure non è necessariamente ben calibrato. Può altrettanto significare che le sue esclusioni sono così ampie che quasi nulla viene realmente valutato rispetto ad esso.

Remediation

Chiudere la deriva della modalità solo report

Estraete lo stato Attivato corrente di ogni criterio e la data della sua ultima modifica. Qualsiasi criterio in modalità solo report privo di una data di fine della finestra di revisione documentata è la lacuna — non solo «si tratta di un nuovo test», ma «qualcuno è responsabile di farlo passare ad applicato».
Allertate specificamente sugli eventi del log di controllo Attivato → Solo report. Questa transizione è rara, deliberata e pericolosa quando avviene su un criterio precedentemente applicato — non dovrebbe mai verificarsi silenziosamente.

Chiudere la deriva delle esclusioni

Sostituite le esclusioni di singoli utenti e di gruppi sincronizzati legacy con gruppi di sicurezza Microsoft Entra dedicati, con appartenenza Assegnata. Questo è il prerequisito del passaggio successivo; le verifiche di accesso hanno come target i gruppi, non elenchi di utenti ad hoc.
Allegate una verifica di accesso ricorrente a ogni gruppo di esclusione, seguendo gli schemi documentati da Microsoft: autoattestazione con rimozione automatica per le esclusioni di viaggio/posizione, revisione del proprietario con applicazione automatica per le esclusioni di autenticazione legacy o di dispositivo. Ciò richiede una licenza Entra ID P2 o Entra ID Governance.
Rivedete ogni criterio «Tutte le risorse» che presenti un'esclusione di risorsa alla luce della distribuzione dell'applicazione degli ambiti di base prevista per il 15 giugno 2026. Decidete deliberatamente — attivate in anticipo la nuova applicazione tramite le impostazioni degli ambiti di base, oppure usate «Personalizza comportamento» per le applicazioni specifiche che necessitano davvero dell'esenzione legacy — invece di lasciare che sia la distribuzione predefinita di Microsoft a decidere silenziosamente.
Rivalidate con prove, non con intenzioni. Dopo qualsiasi passaggio da solo report ad applicato o pulizia di un gruppo di esclusione, confermate il risultato nei log di accesso per account rappresentativi, sia esclusi che inclusi, non solo nella schermata di configurazione del criterio.

Come EtcSec rileva questo problema

I controlli Azure/Entra di EtcSec corrispondono direttamente alle due modalità di fallimento descritte in questo articolo: CA_POLICY_REPORT_ONLY segnala i criteri di Accesso condizionale ancora in modalità solo report, CA_EXCESSIVE_EXCLUSIONS e CA_GROUP_EXCLUSION_LARGE segnalano i criteri il cui ambito di esclusione è cresciuto in modo sproporzionato rispetto al suo scopo, e CA_USER_EXCLUSIONS_STALE segnala le esclusioni a livello utente che non mostrano prove di una revisione recente. Poiché entrambe le modalità di fallimento riguardano una deriva e non un errore di configurazione una tantum, il valore sta nel rieseguire periodicamente l'audit — un tenant che ha superato questo controllo sei mesi fa può fallirlo silenziosamente oggi senza che sia stato eliminato un solo criterio o modificata una sola schermata di impostazioni.

ℹ️

ℹ️ Nota: EtcSec verifica automaticamente questa vulnerabilità a ogni audit AD/Azure. Esegui un audit gratuito per verificare il tuo ambiente.

Accesso condizionale solo report, esclusioni obsolete: cosa significa davvero «applicato»