Lacune di Copertura Accesso Condizionale in Entra ID

Le lacune di copertura policy di base accesso condizionale Entra ID che i tenant si portano dietro sono la forma più elementare di fallimento dell'Accesso Condizionale che esista: non una policy mal configurata, non un'esclusione troppo ampia, ma nessuna policy in assoluto che copra i ruoli admin, tutti gli utenti, tutte le app cloud o la conformità dei dispositivi. Un tenant può avere una dozzina di policy di Accesso Condizionale nell'admin center — blocchi dell'autenticazione legacy, regole di accesso basate sul rischio, eccezioni specifiche per applicazione — e comunque avere zero copertura su una qualsiasi di queste quattro basi. Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione copre la deriva di ambito, le esclusioni e l'autenticazione legacy all'interno di policy già esistenti. Questo articolo riguarda la domanda che precede tutto questo: esiste anche solo una policy di base?

Lacune di Copertura Policy di Base Accesso Condizionale Entra ID: I Quattro Punti Ciechi

Le linee guida di Microsoft per il deployment dell'Accesso Condizionale sono esplicite: un tenant dovrebbe poter indicare un piccolo insieme di policy di base che si applicano ampiamente, non un cumulo di eccezioni ristrette. Come afferma Microsoft nella sua guida di pianificazione del deployment, le organizzazioni dovrebbero creare una policy che ha come target tutti gli utenti, tutte le risorse senza esclusioni di applicazioni, e che richiede l'autenticazione a più fattori — perché ciò "garantisce di non dover aggiornare le policy di Accesso Condizionale ogni volta che viene integrata una nuova applicazione". Un tenant a cui manca una qualsiasi delle quattro lacune seguenti non ha raggiunto quella base, indipendentemente da quante altre policy abbia configurato.

Nessuna policy per i ruoli admin (CA_NO_POLICY_ADMINS)

La policy comune di Accesso Condizionale di Microsoft per gli amministratori raccomanda di richiedere MFA resistente al phishing su almeno quattordici ruoli altamente privilegiati come minimo: Amministratore Globale, Amministratore di Ruolo Privilegiato, Amministratore della Sicurezza, Amministratore dell'Accesso Condizionale, Amministratore Utenti, e altri con impatto sull'intero tenant. Senza una policy che ha come target specificamente questi ruoli di directory — anziché affidarsi a una policy MFA generica per tutti gli utenti che potrebbe essere esclusa o sottodimensionata per gli accessi admin — una credenziale amministrativa compromessa non incontra alcun controllo di accesso aggiuntivo.

Nessuna policy per tutti gli utenti (CA_NO_POLICY_ALL_USERS)

Una policy che ha come target gruppi o applicazioni specifiche non è la stessa cosa di una policy che ha come target Tutti gli utenti. La documentazione Microsoft sull'assegnazione utenti in Accesso Condizionale specifica che Tutti gli utenti in un'assegnazione di Accesso Condizionale include sia gli ospiti B2B sia i membri, ed è esattamente questo il punto: una copertura utenti parziale, costruita un gruppo alla volta, tende a lasciare fuori qualunque tipo di account a cui nessuno ha pensato di aggiungere. Un tenant con MFA solida sul proprio team marketing e nulla su collaboratori esterni o personale appena assunto presenta questa lacuna, anche se l'elenco delle policy sembra completo.

Nessuna copertura di tutte le app cloud (CA_NO_ALL_APPS_COVERAGE)

Le linee guida di deployment dell'Accesso Condizionale di Microsoft affermano chiaramente che "dal punto di vista della sicurezza, è meglio creare una policy che includa Tutte le risorse (in precedenza 'tutte le app cloud')" proprio perché un ambito applicazione per applicazione significa che ogni nuova applicazione SaaS integrata parte non protetta finché qualcuno non si ricorda di aggiungerla a una policy. Un tenant che ha scritto una policy di Accesso Condizionale solo per Exchange Online e il portale Azure ha lasciato tutte le altre risorse — incluse le applicazioni OAuth di terze parti e Microsoft Graph — fuori da qualsiasi valutazione dell'Accesso Condizionale, poiché gli accessi verso risorse non targettizzate non sono governati da nulla.

Nessun requisito di conformità dei dispositivi (CA_NO_DEVICE_COMPLIANCE)

Microsoft documenta una policy di Accesso Condizionale che richiede che i dispositivi che accedono alle risorse siano contrassegnati come conformi alle policy di conformità Intune dell'organizzazione, oppure uniti in modalità ibrida a Microsoft Entra. Senza di essa, gli accessi che soddisfano la MFA da dispositivi non gestiti, non aggiornati o personali raggiungono le stesse risorse degli accessi da un laptop aziendale irrobustito e verificato conforme — la MFA prova chi sta accedendo, non che il dispositivo usato sia sicuro per potergli affidare la sessione.

⚠️

⚠️ Avvertenza: Queste quattro lacune sono indipendenti l'una dall'altra. Un tenant può richiedere la MFA per tutti gli utenti e comunque non avere alcuna policy specifica per gli admin, oppure coprire ogni app cloud per la MFA senza richiedere da nessuna parte la conformità dei dispositivi. Ognuna va verificata separatamente — soddisfarne una non implica che le altre siano coperte.

Perché "Abbiamo l'Accesso Condizionale" Non Significa Che Esista la Copertura di Base

Due elementi danno regolarmente ai tenant una falsa sicurezza che queste quattro lacune di base siano colmate quando non lo sono.

Security Defaults non è un sostituto, e scompare nel momento in cui viene creata qualsiasi policy personalizzata. Microsoft attiva automaticamente Security Defaults per i nuovi tenant per fornire una base minima di MFA, ma Security Defaults e le policy di Accesso Condizionale sono mutuamente esclusivi — non possono essere attivi contemporaneamente. La trappola: un admin che crea un'unica policy di Accesso Condizionale ristretta (ad esempio, bloccare l'autenticazione legacy per un solo reparto) disattiva silenziosamente Security Defaults sull'intero tenant nello stesso momento, anche se quell'unica policy non copre affatto i ruoli admin, tutti gli utenti, tutte le app o la conformità dei dispositivi. Il tenant finisce con meno protezione di base di prima, mentre l'admin center continua a mostrare "Accesso Condizionale: configurato". Azure Tenant Hardening: Security Defaults copre questa e altre trappole delle impostazioni predefinite nei nuovi tenant.

Le policy gestite da Microsoft coprono un ambito più ristretto di quanto "base" lasci intendere, e partono in modalità solo report. Da fine 2023, Microsoft distribuisce automaticamente un insieme di policy di Accesso Condizionale gestite da Microsoft ai tenant idonei, inclusi i requisiti MFA per gli admin e per tutti gli utenti. Si tratta di un miglioramento genuino, ma per questo articolo contano due limiti: primo, la policy gestita focalizzata sugli admin ha come target specificamente gli accessi ai portali di amministrazione Microsoft (portale Azure, admin center Microsoft 365, admin center Entra, e simili), non gli accessi con ruolo admin verso applicazioni line-of-business arbitrarie; secondo, Microsoft crea queste policy in modalità solo report per impostazione predefinita, che valuta ma non applica. Un tenant che si affida alla policy gestita senza mai verificare se è uscita dalla modalità solo report ha la stessa esposizione pratica di non avere alcuna policy — una modalità di fallimento distinta ma adiacente alla deriva in modalità solo report trattata in Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione.

Rilevamento

Rilevare le lacune di copertura di base significa enumerare ciò che esiste realmente nell'insieme di policy di Accesso Condizionale del tenant — non ciò che il tenant intendeva configurare.

Segnale	Dove verificare	Cosa indica
Ambito `conditions.users` della policy su tutte le policy	Microsoft Graph `GET /identity/conditionalAccess/policies`, o `Get-MgIdentityConditionalAccessPolicy` (`Policy.Read.All`)	Se una policy attiva include `All` (tutti) gli utenti/ruoli anziché solo gruppi specifici — la verifica diretta per `CA_NO_POLICY_ALL_USERS` e `CA_NO_POLICY_ADMINS`
`conditions.users.includeRoles` della policy popolato con gli ID dei ruoli di directory admin	Stessa query Graph, filtrata sullo stato attivo	Conferma che esiste una policy che ha come target specificamente i ruoli di directory privilegiati, e non semplicemente una regola MFA generica per tutti gli utenti che potrebbe essere esclusa per gli admin
Valore `conditions.applications.includeApplications` della policy	Stessa query Graph	`All` significa che esiste copertura Tutte le risorse/Tutte le app cloud; qualsiasi altro valore significa che la policy è limitata ad applicazioni specifiche e ogni applicazione non elencata resta non protetta
`grantControls` della policy contenente `compliantDevice` o `domainJoinedDevice`	Stessa query Graph	Conferma se una policy applicata richiede realmente la conformità dei dispositivi o l'unione ibrida, rispetto alla sola MFA
Valore `state` della policy (`enabled` rispetto a `enabledForReportingButNotEnforced`)	Stessa query Graph, o la scheda Solo report nell'admin center	Distingue una policy applicata da una policy gestita da Microsoft o personalizzata ancora in modalità solo report — una policy in modalità solo report non colma la lacuna
Workbook di analisi delle lacune di Accesso Condizionale	Admin center Entra → Monitoraggio e integrità → Workbook → sezione Accesso Condizionale (richiede Report Reader e un'area di lavoro Log Analytics)	Progettato appositamente per mostrare utenti, applicazioni e posizioni denominate senza alcuna policy di Accesso Condizionale applicata, usando prove reali di accesso anziché il testo delle policy
Campo `conditionalAccessStatus` nelle voci dei log di accesso	Log di accesso dell'admin center Entra, o `GET /auditLogs/signIns`	`notApplied` su un accesso da un ruolo admin, un utente standard o un dispositivo non gestito è la conferma in condizioni reali che la lacuna di base corrispondente è reale, non teorica

💡

💡 Suggerimento: Revisione delle policy prima della revisione degli accessi. Un workbook di analisi delle lacune o una query sui log di accesso mostra prove solo per le identità e le applicazioni che si sono effettivamente connesse durante la finestra di osservazione. Enumerare prima l'insieme delle policy tramite Graph indica in modo definitivo se le quattro policy di base esistono, indipendentemente dal fatto che qualcuno abbia o meno innescato la lacuna quel giorno.

Rimedio: colmare le lacune di copertura

Distribuisci per primo una policy MFA dedicata ai ruoli admin. Punta all'insieme documentato di ruoli altamente privilegiati (Amministratore Globale, Amministratore di Ruolo Privilegiato, Amministratore della Sicurezza, Amministratore dell'Accesso Condizionale, e il resto dell'elenco dei ruoli admin della policy comune Microsoft — vedi Accesso Privilegiato Azure: Troppi Admin Globali per il contesto completo su questi ruoli), richiedi la MFA o una forza di autenticazione superiore, ed escludi solo gli account break-glass — vedi Account di Accesso di Emergenza Break Glass Entra ID prima di creare quell'esclusione.
Distribuisci una policy di base per tutti gli utenti, con target Tutti gli utenti e Tutte le risorse. Evita l'ambito applicazione per applicazione o gruppo per gruppo per lo strato di base; aggiungi sopra policy più ristrette e più forti per applicazioni specifiche ad alto valore anziché cercare di enumerare ogni applicazione che necessita della base.
Aggiungi un requisito di conformità dei dispositivi o di unione ibrida per, come minimo, lo stesso insieme di ruoli admin e risorse sensibili coperto sopra, usando le policy di conformità Intune come fonte di applicazione.
Verifica se esistono policy gestite da Microsoft e se sono ancora in modalità solo report. In tal caso, portale in modalità applicata dopo una finestra di revisione convalidata, oppure sostituiscile con policy di proprietà del tenant che coprano l'ambito più ampio descritto in questo articolo, anziché i soli portali di amministrazione Microsoft.
Se Security Defaults è stato disattivato silenziosamente da una policy ristretta precedente, non limitarti a riattivarlo — sostituiscilo con le policy di base esplicite sopra indicate; Security Defaults e l'Accesso Condizionale personalizzato restano mutuamente esclusivi, e riattivarlo rimuoverebbe la policy più ristretta che aveva motivato la domanda in primo luogo.
Convalida con lo strumento What If e il workbook di analisi delle lacune per un account admin rappresentativo, un utente standard rappresentativo e un dispositivo non gestito rappresentativo prima di considerare la lacuna colmata — la configurazione della policy e la sua applicazione confermata non sono la stessa prova.

Come EtcSec Rileva Questo

I controlli Azure/Entra di EtcSec corrispondono direttamente alle quattro lacune di questo articolo: CA_NO_POLICY_ADMINS e CA_NO_POLICY_ALL_USERS segnalano l'assenza di qualsiasi policy attiva che ha come target rispettivamente i ruoli admin o tutti gli utenti, CA_NO_ALL_APPS_COVERAGE segnala l'assenza di una policy che copra tutte le app cloud/risorse, e CA_NO_DEVICE_COMPLIANCE segnala l'assenza di qualsiasi controllo di concessione per la conformità dei dispositivi. AZ_SECURITY_DEFAULTS_NO_CA rileva la trappola specifica descritta sopra: Security Defaults disattivato senza una base di Accesso Condizionale compensativa al suo posto.

ℹ️

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

Lacune di Copertura Policy di Base Accesso Condizionale Entra ID: Nessuna Policy per Admin, Tutti gli Utenti o Tutte le App