Entra ID: Accesso Condizionale e Policy di Base

L’accesso condizionale di Entra ID (ex Azure Active Directory) è la spina dorsale della sicurezza basata sull’identità nel cloud. Permette di applicare controlli di accesso granulari basati su condizioni specifiche, come la posizione dell’utente, lo stato del dispositivo, l’applicazione a cui si tenta di accedere e il livello di rischio rilevato. Non è una funzionalità aggiuntiva, ma un elemento fondamentale per proteggere le risorse e garantire la conformità. Leggi anche: Amministratore Sistema GDPR: Obbligo, Ruolo e Obblighi

Queste policy sono cruciali per mitigare attacchi come il credential stuffing, il phishing e gli attacchi di replay, che sfruttano credenziali deboli o rubate. Implementare un set di policy di base è il primo passo per ogni organizzazione che utilizzi Entra ID, indipendentemente dalle dimensioni o dal settore. Ti consente di rafforzare la sicurezza senza compromettere l’usabilità per gli utenti legittimi, applicando controlli solo quando e dove necessario.

Entra ID: Accesso Condizionale in 60 secondi

Per configurare e gestire rapidamente le policy di accesso condizionale in Entra ID, questi sono i comandi essenziali da PowerShell, usando il modulo Microsoft.Graph:

# Installazione del modulo Microsoft.Graph (se non già presente)
Install-Module -Name Microsoft.Graph -Scope CurrentUser

# Connessione a Microsoft Graph con i permessi necessari per leggere le policy
Connect-MgGraph -Scopes Policy.Read.All

# Elenco delle policy di accesso condizionale esistenti e il loro stato
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State

# Visualizzare i log di accesso con fallimenti di accesso condizionale (ultimi 20)
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 20

# Disconnessione dalla sessione Graph
Disconnect-MgGraph

Versioni di riferimento: Microsoft Entra ID (la versione stabile corrente, consultata a novembre 2026) · documentazione consultata a novembre 2026

Cos’è l’accesso condizionale e che licenza serve

L’accesso condizionale è il motore di policy di Entra ID che consente di implementare regole “if-then”. Ad esempio: se un utente tenta di accedere da una posizione sconosciuta, allora richiedi l’autenticazione a più fattori (MFA). Questo permette di spostare il focus dalla semplice verifica della password a una valutazione del rischio in tempo reale per ogni tentativo di accesso. Le policy vengono applicate prima che l’utente acceda alla risorsa, aggiungendo un livello di protezione proattivo. Leggi anche: Microsegmentazione Rete: VLAN e Firewall in Produzione

Per utilizzare l’accesso condizionale, è necessaria una licenza Entra ID P1 o P2. La P1 offre le funzionalità di base, mentre la P2 aggiunge funzionalità avanzate come l’integrazione con Identity Protection per rilevare rischi in tempo reale (ad esempio, credenziali compromesse, accessi da IP anomali) e automatizzare le risposte. Senza una di queste licenze, la funzionalità non sarà disponibile o sarà limitata a un sottoinsieme di policy predefinite.

Prerequisiti

Prima di implementare qualsiasi policy di accesso condizionale, assicurati di avere:

• Licenza Entra ID P1 o P2: Verifica che tutti gli utenti a cui si applicheranno le policy abbiano la licenza adeguata.
• MFA abilitata e configurata: Gli utenti devono aver registrato almeno un metodo MFA (es. Microsoft Authenticator, SMS, chiamate) per poter soddisfare i requisiti delle policy MFA.
• Account di emergenza: Identifica e crea almeno due account di emergenza (break-glass accounts) con privilegi elevati, esclusi da qualsiasi policy di accesso condizionale. Questi account sono cruciali per recuperare l’accesso al tenant in caso di configurazione errata delle policy.
• Gruppi di sicurezza: Utilizza gruppi di sicurezza di Entra ID per assegnare le policy. Questo semplifica la gestione e riduce il rischio di errori rispetto all’assegnazione a singoli utenti. Crea gruppi per amministratori, utenti standard, utenti con esigenze particolari, ecc.
• Pianificazione e comunicazione: Informa gli utenti sulle nuove policy e su come potrebbero influenzare il loro accesso. Una comunicazione chiara riduce la resistenza e i ticket di supporto.

1. Prima regola: escludere gli account di emergenza

Questo è il passaggio più critico e spesso trascurato. Gli account di emergenza, o ‘break-glass accounts’, sono account con privilegi elevati (come Global Administrator) che vengono utilizzati solo in situazioni di emergenza, ad esempio se tutte le policy di accesso condizionale bloccano inavvertitamente l’accesso a tutti gli amministratori. Questi account devono essere esclusi da tutte le policy di accesso condizionale. Se non lo fai, potresti trovarti in una situazione in cui nessuno può accedere al tenant per correggere un errore di configurazione, con conseguente blocco totale.

La protezione di questi account si basa su controlli procedurali e fisici (es. credenziali conservate in cassaforte, monitoraggio intensivo degli accessi), piuttosto che su policy di accesso condizionale che potrebbero bloccarli. Microsoft raccomanda di configurare almeno due di questi account. La loro attività deve essere monitorata costantemente tramite log di audit e alert specifici per rilevare qualsiasi utilizzo improprio.

2. MFA obbligatoria per gli amministratori

Questa è la policy più importante per la sicurezza del tuo tenant. Gli account con ruoli amministrativi (Global Administrator, Application Administrator, Exchange Administrator, SharePoint Administrator, ecc.) sono obiettivi primari per gli attaccanti. La compromissione di uno di questi account può portare a un controllo totale del tuo ambiente. Richiedere l’MFA per gli amministratori riduce drasticamente il rischio di accessi non autorizzati, anche se la password viene rubata.

Come configurarla:

1. Naviga in Entra ID > Protezione > Accesso condizionale > Nuova policy.
2. Assegna un nome significativo, ad esempio “MFA – Amministratori”.
3. In Utenti o carichi di lavoro identità > Includi, seleziona Ruoli della directory e scegli tutti i ruoli amministrativi rilevanti (ad es., Global Administrator, Security Administrator, Cloud Application Administrator, ecc.).
4. In Controlli di accesso > Concedi, seleziona Richiedi l’autenticazione a più fattori.
5. Imposta la policy su Attiva (dopo averla testata in modalità solo report, come vedremo più avanti).

Questa policy è un requisito standard per la conformità a normative come NIS2 (Art. 21) e ISO 27001:2022, che enfatizzano la protezione degli account privilegiati. Leggi anche: NIS2: Obblighi e Adeguamento Aziende in Italia

3. Bloccare l’autenticazione legacy

L’autenticazione legacy si riferisce a protocolli come POP3, IMAP, SMTP, MAPI, e altre API che non supportano l’autenticazione moderna e, di conseguenza, l’MFA. Questi protocolli sono un vettore di attacco comune, in quanto consentono agli attaccanti di tentare accessi con credenziali rubate senza dover affrontare la sfida MFA. La disabilitazione dell’autenticazione legacy è una raccomandazione di sicurezza chiave di Microsoft e CISA.

Come configurarla:

1. Crea una nuova policy di accesso condizionale, ad esempio “Blocco Autenticazione Legacy”.
2. In Utenti o carichi di lavoro identità > Includi, seleziona Tutti gli utenti (o un gruppo specifico se vuoi applicarla gradualmente).
3. In App cloud o azioni > Includi, seleziona Tutte le app cloud.
4. In Condizioni > Client app, seleziona Sì e poi spunta Client di posta elettronica/protocolli di autenticazione legacy.
5. In Controlli di accesso > Blocca accesso.
6. Imposta la policy su Attiva.

Un output tipico quando si elenca lo stato delle policy dopo la creazione:

DisplayName                           State
----------                           -----
MFA - Amministratori                 Enabled
Blocco Autenticazione Legacy         Enabled

Attenzione: prima di attivare questa policy su tutti gli utenti, verifica l’uso di client legacy nel tuo ambiente. Strumenti come Outlook 2010 o alcune applicazioni di terze parti potrebbero smettere di funzionare. Monitora i log di accesso per identificare gli utenti e le app che ne fanno uso.

4. MFA per tutti gli utenti, con le eccezioni giuste

Dopo aver protetto gli amministratori e bloccato i protocolli legacy, il passo successivo è estendere l’MFA a tutti gli utenti. Questo eleva significativamente la postura di sicurezza complessiva del tenant. Tuttavia, applicare l’MFA in modo indiscriminato può creare attriti per gli utenti. È qui che le condizioni dell’accesso condizionale diventano utili per creare eccezioni basate su specifici scenari.

Come configurarla:

1. Crea una nuova policy, ad esempio “MFA – Tutti gli utenti”.
2. In Utenti o carichi di lavoro identità > Includi, seleziona Tutti gli utenti. In Escludi, aggiungi gli account di emergenza e, se necessario, gruppi specifici di utenti che non devono usare MFA (ad es. account di servizio, ma con molta cautela).
3. In App cloud o azioni > Includi, seleziona Tutte le app cloud.
4. In Controlli di accesso > Concedi, seleziona Richiedi l’autenticazione a più fattori.
5. In Condizioni puoi aggiungere eccezioni:

• Posizioni: Escludi le posizioni di rete definite come trusted (es. la rete aziendale con IP pubblici noti). Ciò permette agli utenti di non dover fare MFA quando sono in ufficio. Leggi anche: Zabbix Agent 2: Installazione, Configurazione e Plugin
• Dispositivi: Richiedi che il dispositivo sia “Conforme” o “Aderente ad Azure AD Ibrido” per bypassare l’MFA, incentivando l’uso di dispositivi gestiti e sicuri.

1. Imposta la policy su Solo report inizialmente, per poi attivarla.

5. Usare la modalità solo report prima di attivare

Ogni nuova policy di accesso condizionale, o modifica significativa a una esistente, dovrebbe essere implementata prima in modalità Solo report. Questa modalità ti permette di simulare l’applicazione della policy senza che essa influenzi realmente l’accesso degli utenti. I risultati vengono registrati nei log di accesso di Entra ID, consentendoti di vedere quali utenti o applicazioni sarebbero stati bloccati o avrebbero richiesto MFA.

Perché è fondamentale: Evita interruzioni inaspettate. Un errore di configurazione può bloccare l’accesso a intere categorie di utenti o applicazioni critiche. La modalità solo report ti offre la possibilità di identificare e correggere questi problemi prima che abbiano un impatto reale sulla produzione. È una pratica operativa essenziale per qualsiasi sysadmin o security engineer.

Come attivarla: Quando crei o modifichi una policy, nel pannello Abilita policy, seleziona Solo report anziché Attiva.

6. Leggere i log di accesso per capire cosa è stato bloccato

Una volta che le policy sono in modalità Solo report (o anche dopo l’attivazione), è cruciale monitorare i log di accesso per capire il loro impatto. I log di accesso di Entra ID forniscono dettagli preziosi su ogni tentativo di accesso, inclusi i risultati delle policy di accesso condizionale applicate.

Per accedere ai log:

1. Naviga in Entra ID > Monitoraggio e integrità > Log di accesso.
2. Utilizza i filtri per restringere la ricerca. I filtri più utili includono:

• Stato dell’accesso condizionale: “Fallimento” o “Solo report (successo/fallimento)”.
• Utente: Per investigare problemi specifici di un utente.
• App cloud: Per vedere l’impatto su un’applicazione specifica.

Cerca gli eventi in cui lo “Stato dell’accesso condizionale” indica un fallimento o un blocco. Questo ti dirà esattamente quale policy ha causato il blocco e per quale motivo. Analizzare questi log ti aiuta a perfezionare le policy e a risolvere i problemi di accesso per gli utenti.

Utilizzare PowerShell per filtrare specifici eventi di fallimento è anche un approccio efficiente:

# Connessione a Microsoft Graph (se non già connesso)
Connect-MgGraph -Scopes AuditLog.Read.All

# Visualizzare i log di accesso con fallimenti di accesso condizionale (ultimi 20)
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 20 | Format-Table CreatedDateTime, UserDisplayName, AppDisplayName, ConditionalAccessStatus

Questo comando ti darà una panoramica rapida degli accessi bloccati, essenziale per il troubleshooting.

7. Elencare le policy da PowerShell

Gestire le policy di accesso condizionale tramite la GUI del portale di Azure è intuitivo, ma per audit, automazione o semplicemente per una visione d’insieme rapida, PowerShell offre un’alternativa potente. Utilizzando il modulo Microsoft.Graph, è possibile elencare tutte le policy e visualizzare il loro stato, il che è utile per la documentazione o per verificare rapidamente le configurazioni.

Per elencare le policy, assicurati di avere i permessi Policy.Read.All e di essere connesso a Microsoft Graph:

# Connessione a Microsoft Graph con i permessi necessari
Connect-MgGraph -Scopes Policy.Read.All

# Elenco di tutte le policy di accesso condizionale
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State, GrantControls, Conditions

L’output di Get-MgIdentityConditionalAccessPolicy mostrerà il nome della policy, il suo stato (Enabled, Disabled, ReportOnly) e dettagli sui controlli di accesso (GrantControls) e le condizioni (Conditions). Questo è particolarmente utile per identificare rapidamente policy attive o in modalità solo report e per avere una visione d’insieme delle loro regole principali. Leggi anche: Docker Spazio Disco: Prune, Log e Immagini Inutilizzate

Errori comuni e troubleshooting

Errore o messaggio esatto	Causa	Soluzione
“Accesso bloccato dalla policy di accesso condizionale”	Utente o condizione non soddisfatta da una policy attiva.	Controlla i log di accesso per identificare la policy e le condizioni. Modifica la policy o escludi l’utente/gruppo.
“MFA richiesta ma non configurata”	L’utente non ha registrato metodi MFA.	Chiedi all’utente di registrare l’MFA tramite aka.ms/mfasetup.
L’utente non riesce ad accedere a Outlook desktop	Blocco dell’autenticazione legacy attivo.	Verifica se l’utente usa un client obsoleto. Abilita autenticazione moderna sul client o escludi temporaneamente l’utente dalla policy (con cautela).
Amministratore bloccato dopo una nuova policy	Account di emergenza non esclusi o policy troppo restrittiva.	Utilizza un account di emergenza per accedere e disabilitare/modificare la policy.
Policy inattesa applicata (o non applicata)	Ordine delle policy, condizioni sovrapposte o gruppi errati.	Rivedi l’ordine di elaborazione (non è sequenziale come i firewall, ma tutte le policy che corrispondono vengono valutate). Controlla le inclusioni/esclusioni di utenti/gruppi.

Domande frequenti

L’ordine delle policy di accesso condizionale è importante?

No, a differenza dei firewall tradizionali, l’ordine di elaborazione delle policy di accesso condizionale in Entra ID non è sequenziale. Tutte le policy applicabili a un dato utente, app e condizione vengono valutate contemporaneamente. Se anche una sola policy richiede un controllo (ad esempio, MFA) e una sola policy blocca l’accesso, quest’ultima prevale. È importante progettare le policy in modo che non si sovrappongano in maniera contraddittoria.

Posso escludere un utente specifico da una policy?

Sì, ogni policy di accesso condizionale ha una sezione “Escludi” dove puoi specificare utenti o gruppi. Questo è fondamentale per gli account di emergenza o per testare le policy su un sottoinsieme di utenti prima di estenderle. Usa sempre i gruppi per le esclusioni, per facilitare la gestione e ridurre gli errori manuali.

Qual è la differenza tra Entra ID P1 e P2 per l’accesso condizionale?

Entra ID P1 offre le funzionalità di accesso condizionale di base, permettendoti di creare policy basate su utenti, gruppi, app, posizioni e stato del dispositivo. Entra ID P2 include tutte le funzionalità P1 e aggiunge l’integrazione con Identity Protection, che permette di incorporare il rischio utente e il rischio di accesso come condizioni nelle policy. Questo consente risposte dinamiche basate sulla probabilità di compromissione dell’identità.

Come posso testare una nuova policy senza bloccare gli utenti?

La modalità “Solo report” è la soluzione. Quando crei o modifichi una policy, imposta il suo stato su “Solo report” anziché “Attiva”. Questo farà sì che la policy venga valutata e i suoi risultati registrati nei log di accesso, ma senza applicare effettivamente i controlli. Puoi quindi analizzare i log per vedere l’impatto potenziale e affinare la policy prima di attivarla per tutti.

È possibile applicare policy di accesso condizionale a guest o utenti esterni?

Sì, le policy di accesso condizionale possono essere applicate anche agli utenti guest (B2B) che accedono al tuo tenant. Questo è fondamentale per proteggere le risorse condivise con partner esterni o consulenti. Puoi includere gli utenti guest nei gruppi a cui si applicano le policy o creare policy specifiche per loro, garantendo che anche gli accessi esterni rispettino i tuoi standard di sicurezza.

Conclusioni con takeaway operativi

L’implementazione dell’accesso condizionale in Entra ID non è un’opzione, ma un imperativo di sicurezza. Iniziando con le policy di base – esclusione degli account di emergenza, MFA obbligatoria per gli amministratori, blocco dell’autenticazione legacy e MFA per tutti gli utenti con eccezioni intelligenti – puoi costruire una solida base per la protezione del tuo tenant. Ricorda di utilizzare sempre la modalità “Solo report” per testare l’impatto delle tue policy e di monitorare costantemente i log di accesso. Questi passaggi ti permetteranno di rafforzare la tua postura di sicurezza, ridurre la superficie di attacco e garantire la conformità con le normative vigenti, proteggendo le tue identità nel cloud in modo proattivo e scalabile.

Fonti

• What is Conditional Access in Microsoft Entra ID?
• Plan for emergency access accounts in Microsoft Entra ID

Aggiornato: novembre 2026