Setup Conditional Access in Microsoft Entra ID: 5 policy MFA da configurare oggi

Avere MFA attivo “su tutti gli utenti” non è la stessa cosa che avere MFA configurato bene. La differenza la fa Conditional Access: invece di chiedere MFA sempre (esperienza utente fastidiosa che porta gli utenti a creare bypass non autorizzati), Entra ID valuta il contesto di ogni login — utente, device, location, app, rischio rilevato — e decide se chiedere MFA, bloccare l’accesso, o lasciare passare.

Questo tutorial descrive le 5 policy Conditional Access che deployamo come baseline su tutti i clienti SynSphere con Microsoft 365 Business Premium. Le 5 coprono il 90% degli scenari di attacco identità tipici per una PMI italiana, con un impatto operativo trascurabile per gli utenti finali.

Pre-requisiti

Prima di procedere serve verificare:

• Licenza: Microsoft Entra ID P1 (incluso in M365 Business Premium, M365 E3, M365 E5; standalone 5,80 €/utente/mese).
• Ruolo admin: Conditional Access Administrator oppure Global Administrator (per gli step iniziali).
• Per Site Reliability: avere almeno 2 admin con metodi MFA configurati e funzionanti, per evitare lock-out durante la configurazione.
• Break-glass account: configurare almeno un account amministrativo di emergenza (cloud-only, password lunga e custodita in cassaforte) escluso da tutte le policy Conditional Access. Mai meno di un break-glass account.

Setup environment di test

Prima di applicare le policy in produzione, configurale in modalità Report-only per 1-2 settimane. In Report-only la policy NON blocca l’accesso ma logga cosa avrebbe fatto se fosse stata attiva. Questo permette di valutare l’impatto reale prima del rollout senza rischio di lock-out.

Crea un Security Group “CA Pilot Users” con 5-10 utenti volontari (mix di IT, manager, staff). Le prime configurazioni testale solo su questo gruppo, poi estendi a All users quando sei sicuro.

Policy 1 — MFA obbligatoria per tutti gli admin (priorità massima)

Gli account amministrativi sono il primo target degli attacchi: comprometterne uno = controllo del tenant. Questa policy va attivata da subito, mode Enabled (non Report-only), perché il rischio di non averla è troppo alto.

Configurazione:

1. Entra ID admin center → Protection → Conditional Access → Policies → New policy.
2. Name: CA001 - Require MFA for admins.
3. Users:
   • Include → Directory roles → seleziona almeno: Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator, User Administrator.
   • Exclude → seleziona il break-glass account.
4. Target resources → Cloud apps → All cloud apps.
5. Conditions → lascia tutto unconfigured (la policy si applica sempre).
6. Grant → Require multi-factor authentication. Click “Require all the selected controls”.
7. Enable policy → On.
8. Save.

Test prima di andare live: prova a loggarti con un account admin di test (non break-glass), conferma che venga richiesta MFA. Se serve, completa l’enrollment del metodo MFA.

Policy 2 — Block legacy authentication (chiude la porta più larga)

Legacy authentication = protocolli di autenticazione vecchi (POP3, IMAP, SMTP basic auth, Office 2010 e precedenti). Non supportano MFA. Sono la principale via di credential stuffing: un attaccante con username + password compromessi salta MFA usando IMAP basic.

Configurazione:

1. New policy → Name: CA002 - Block legacy authentication.
2. Users → Include All users. Exclude break-glass account + eventuali service account legacy critici (da valutare caso per caso, ma minimizzare).
3. Target resources → All cloud apps.
4. Conditions → Client apps → Configure Yes → seleziona solo:
   • Exchange ActiveSync clients
   • Other clients (questi sono i protocolli legacy)
5. Grant → Block access.
6. Enable policy → Report-only per 7 giorni → analizza i sign-in log per identificare service account o app legacy → On.

Pitfall comune: alcune stampanti multifunzione configurate per scan-to-email usano SMTP basic auth. Se trovi sign-in legacy nei log, decidi se: (a) aggiornare la stampante a moderna auth (consigliato), (b) creare un service account dedicato escluso dalla policy con password forte e MFA via app password.

Policy 3 — MFA per accessi da location non-trusted

Gli utenti tipici di una PMI italiana lavorano dalla sede aziendale (IP statici noti) o da casa (IP residenziali italiani). Login da paesi inusuali è un segnale forte di compromissione. Questa policy chiede MFA aggiuntiva per accessi da location non riconosciute.

Configurazione named locations:

1. Entra ID → Conditional Access → Named locations → New location → IP ranges.
2. Name: Sede Milano. Mark as trusted location: ✓. Aggiungi gli IP statici/range dell’ufficio.
3. Ripeti per altre sedi.
4. Aggiuntivo: New location → Countries → Italy + paesi dove avete clienti/fornitori (es. Germany, France, USA per business EU/US). Mark as trusted: ✗.

Configurazione policy:

1. New policy → Name: CA003 - Require MFA for non-trusted locations.
2. Users → Include All users. Exclude break-glass.
3. Target resources → All cloud apps.
4. Conditions → Locations → Include Any location, Exclude Sede Milano + altre trusted locations.
5. Grant → Require multi-factor authentication.
6. Enable → Report-only 7 giorni → analizza → On.

Effetto: utenti da sede ufficio non vengono disturbati con MFA continua. Utenti da casa, mobile, trasferta ricevono MFA prompt. Login da paesi non whitelisted (es. Russia, China, Nigeria — se non sono mercati attivi) viene sempre richiesta MFA — riduce drammaticamente il successo degli attacchi credential-stuffing.

Policy 4 — Compliant device richiesto per app sensibili

Per applicazioni che gestiscono dati confidenziali (Finance, HR), aggiungere un layer di sicurezza: l’accesso è permesso solo da device gestiti via Intune (compliant). Un utente con username + password + MFA ma da device non gestito (laptop personale random, internet café) non può accedere.

Pre-requisito: utenti finance/HR devono avere device aziendali enrollati in Intune con compliance policy attiva.

Configurazione:

1. New policy → Name: CA004 - Compliant device for sensitive apps.
2. Users → Include security group Finance + HR users (creare prima questo gruppo).
3. Target resources → seleziona specifiche cloud apps: SharePoint Online, OneDrive for Business, eventuali app custom finance/HR.
4. Conditions → vuoto (sempre).
5. Grant → Require device to be marked as compliant. Click “Require all the selected controls”.
6. Enable → Report-only 14 giorni (più lungo perché impatta workflow utenti) → analizza → On.

Edge case: utente finance in trasferta con laptop aziendale che ha problemi compliance temporanei (es. update Windows in corso). Workflow di emergency: admin Intune può marcare temporaneamente il device come compliant via troubleshooting, oppure utilizzare break-glass account.

Policy 5 — Block sign-in da utenti high-risk

Microsoft Entra ID Protection (parte di P2, ma anche con P1 disponibile a livello base) calcola un risk score per ogni sign-in basato su signals (impossible travel, anonymous IP, leaked credentials, atypical sign-in). Questa policy blocca automaticamente i sign-in classificati come high-risk.

Pre-requisito: per la versione completa serve Entra ID P2 (incluso in M365 E5) — oppure ti accontenti delle policy base disponibili in P1.

Configurazione (P2):

1. New policy → Name: CA005 - Block high-risk sign-ins.
2. Users → All users. Exclude break-glass.
3. Target resources → All cloud apps.
4. Conditions → Sign-in risk → seleziona High.
5. Grant → Block access.
6. Enable → On (no Report-only — il rischio di lasciare passare un attacco high-risk è troppo alto).

Versione P1: usa Entra ID Protection alert per investigation manuale (no policy automatica), oppure attiva la baseline policy Require MFA for risky sign-ins (manda MFA invece di block).

Rollout strategy

Settimana 1: Policy 1 (admin MFA) attiva in modalità Enabled subito. Le altre 4 in Report-only su Pilot Group.

Settimana 2-3: Analisi sign-in log Report-only. Filtro per “Conditional Access status: Report-only” → identifica false positive, eccezioni necessarie, service account da escludere.

Settimana 4: Policy 2-3 (block legacy + non-trusted location) → Enabled per All users. Comunicazione utenti pre-rollout: email che spiega “sentirai MFA quando sei fuori sede, è normale”.

Settimana 5-6: Policy 4 (compliant device) → Enabled per gruppi target finance/HR. Policy 5 (high-risk) → Enabled per All users.

Post-rollout: monitor settimanale dei sign-in log per anomalie, review trimestrale delle policy per aggiungere nuove cloud apps/eccezioni.

Pitfall comuni

• ❌ Attivare tutte le policy in Enabled subito senza Report-only → primo lock-out massivo entro 24 ore.
• ❌ Dimenticare il break-glass account → policy bloccano gli admin reali → tenant inaccessibile finché Microsoft Support non interviene (giorni).
• ❌ Trusted locations non aggiornate → utenti in sede vengono trattati come remoti (MFA continua) o vice versa.
• ❌ Block legacy auth senza analisi service account → stampanti scan-to-email smettono di funzionare, ticket helpdesk esplodono.
• ❌ Compliant device policy senza Intune enrollment completato → utenti bloccati da app sensibili anche con credentials corrette.
• ❌ Non comunicare il rollout agli utenti → IT manager riceve telefonate “perché ora mi chiede MFA dappertutto?”.

Verifica e monitoraggio

Post-rollout:

• Entra ID → Sign-in logs: filtra per “Conditional Access status” per vedere policy applicate ai sign-in reali.
• Entra ID → Conditional Access → Insights and Reporting: dashboard con metriche di policy efficacia, sign-in MFA, block trend.
• Microsoft Defender → Alerts: integrazione automatica fra Conditional Access block e alert security.

Per una PMI di 50 utenti il setup completo (5 policy + Report-only + rollout incrementale) richiede tipicamente 3-4 settimane calendar time, di cui circa 8-12 ore-uomo di lavoro IT effettivo. Il ROI in termini di sicurezza è uno dei migliori del bundle M365 Business Premium: una policy ben fatta blocca il 95%+ degli attacchi credential-based prima che riescano.

Per il deploy completo Conditional Access nella tua azienda, contattaci: assessment Entra ID, configurazione policy hardened, simulazione attacco controllata per validation, formazione IT manager. Setup tipico 3-4 settimane.