Conditional Access in Microsoft 365: baseline pratica per tenant piccoli nel 2026

Conditional Access è uno dei punti in cui un tenant Microsoft 365 piccolo può fare il salto di qualità più grande. Non serve avere un SOC, un E5 completo o decine di policy: serve una baseline ragionata, testata e applicata con disciplina. Nel 2026 l'identità è ancora il perimetro reale: posta, SharePoint, Teams, VPN moderne, applicazioni SaaS e pannelli di amministrazione passano quasi sempre da Entra ID. Se un account viene compromesso, il problema non è più solo la mailbox: è l'intera infrastruttura operativa.

L'obiettivo di questa guida non è copiare una configurazione universale. È costruire una base pratica per SysAdmin, MSP e homelab evoluti che gestiscono tenant Microsoft 365 piccoli o medi, con pochi amministratori e utenti spesso ibridi. Le policy vanno sempre provate in modalità report-only e documentate, ma partire da uno schema semplice evita sia il tenant troppo permissivo sia quello ingestibile.

Prerequisiti minimi

Prima di scrivere policy, sistemerei quattro elementi. Primo: almeno due account break-glass cloud-only, esclusi dalle policy di Conditional Access, con password lunghe conservate offline, niente mailbox e monitoraggio degli accessi. Secondo: MFA già registrata per tutti, preferibilmente con metodi moderni. Terzo: gruppi Entra dedicati, ad esempio CA-Admins, CA-All-Users-Pilot, CA-Exclusions-BreakGlass e CA-Service-Accounts. Quarto: log e audit consultabili, perché una policy non osservata è solo una trappola pronta a scattare.

Se usi Intune, aggiungi anche criteri di conformità realistici: cifratura attiva, firewall, antivirus, sistema operativo supportato e assenza di jailbreak/root per il mobile. Non creare subito una compliance policy impossibile: se il 40% dei PC risulta non conforme per un dettaglio minore, gli utenti cercheranno scorciatoie e tu passerai la giornata a fare eccezioni.

Policy 1: MFA per tutti, con priorità ai metodi forti

La prima policy deve richiedere MFA a tutti gli utenti per le applicazioni cloud principali. Escludi solo i break-glass e gli account di servizio che non possono interagire, ma questi ultimi andrebbero ridotti al minimo e protetti con alternative come workload identity, certificati o secret rotation.

Dove possibile, spingi verso metodi resistenti al phishing: passkey/FIDO2, Windows Hello for Business o certificate-based authentication. SMS e chiamate vocali sono meglio di niente, ma non dovrebbero essere la destinazione finale. Per gli amministratori, io eviterei compromessi: niente accesso privilegiato senza MFA forte. È una regola noiosa fino al giorno in cui salva il tenant.

Rollout consigliato: prima gruppo pilota, poi utenti interni, poi guest e collaboratori. Lascia la policy in report-only qualche giorno e controlla i sign-in log: applicazioni vecchie, client obsoleti e automazioni mal fatte emergono subito.

Policy 2: blocco dell'autenticazione legacy

POP, IMAP, SMTP AUTH non controllato e vecchi client Office sono ancora una porta laterale frequente. Una policy dedicata deve bloccare l'autenticazione legacy per tutti gli utenti. Se esiste una stampante o un gestionale che invia posta via SMTP AUTH, non usare questa eccezione come scusa per lasciare aperto tutto il tenant. Isola il caso: account dedicato, password robusta, permessi minimi, connettore o relay autenticato dove possibile, monitoraggio e data di revisione.

Questo è uno dei controlli con il miglior rapporto fatica/beneficio. Prima di abilitarlo, cerca nei log gli accessi legacy degli ultimi 7-30 giorni. Se non ne trovi, attivalo. Se ne trovi, correggi l'applicazione invece di normalizzare il rischio.

Policy 3: amministratori sempre protetti

Gli account con ruoli privilegiati meritano policy separate. Richiedi MFA forte, blocca accessi da paesi non previsti, applica sessioni più corte e valuta l'obbligo di dispositivo conforme o postazione amministrativa dedicata. Per Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator e ruoli di sicurezza, la comodità non può essere il criterio principale.

Una buona pratica è usare account separati: uno standard per posta e lavoro quotidiano, uno privilegiato solo per amministrazione. Se disponibile, usa Privileged Identity Management per rendere i ruoli just-in-time. Nei tenant piccoli spesso sembra eccessivo, ma riduce l'esposizione permanente e obbliga a ragionare sulle elevazioni.

Policy 4: accesso da dispositivi conformi per dati sensibili

Non tutto deve richiedere subito un dispositivo conforme, ma Exchange Online, SharePoint e OneDrive contengono quasi sempre dati sensibili. Una baseline equilibrata è: MFA per tutti da ovunque, e dispositivo conforme per download o accesso completo ai dati aziendali. Per i dispositivi personali puoi consentire accesso web con restrizioni, impedendo download e sincronizzazione se la licenza e le funzionalità disponibili lo permettono.

Qui Intune diventa il pezzo operativo. La conformità non deve essere un bollino estetico: BitLocker attivo, Defender funzionante, sistema aggiornato, blocco schermo e versione minima dell'OS sono controlli concreti. Per l'homelab o il piccolo ufficio, anche solo distinguere tra notebook gestito e PC sconosciuto cambia molto la superficie d'attacco.

Policy 5: rischio, geografia e sessioni

Se hai Entra ID Protection, usa il rischio utente e il rischio di accesso per richiedere MFA, cambio password o blocco. In alternativa, lavora con criteri più semplici: blocco o challenge per paesi mai usati, attenzione agli accessi da reti anonime, session lifetime più corta per portali amministrativi.

Non abusare del blocco geografico: chi viaggia, usa VPN aziendali o lavora con fornitori internazionali può generare falsi positivi. Meglio partire con report-only e una lista di paesi consentiti ragionata. Per gli amministratori, invece, una restrizione più aggressiva ha senso.

Checklist di implementazione

1. Crea due break-glass cloud-only ed escludili esplicitamente.
2. Prepara gruppi pilota e gruppi di esclusione nominativi, non dinamiche opache.
3. Abilita le policy in report-only e controlla i sign-in log.
4. Blocca legacy authentication dopo aver censito client e applicazioni.
5. Richiedi MFA forte agli amministratori prima degli utenti standard.
6. Integra Intune solo con criteri di conformità misurabili e sostenibili.
7. Documenta ogni eccezione con proprietario, motivo e scadenza.
8. Controlla mensilmente log, esclusioni e account senza MFA.

Errori da evitare

Il primo errore è escludere metà azienda per evitare ticket. Il secondo è non avere break-glass e scoprire il problema durante un blocco. Il terzo è creare dieci policy sovrapposte senza naming chiaro: dopo sei mesi nessuno capisce più perché un accesso viene negato. Usa nomi leggibili, ad esempio CA001-Block-Legacy-Auth-AllUsers o CA010-Require-PhishingResistant-MFA-Admins.

Il quarto errore è confondere sicurezza con fastidio. Se una policy produce troppi prompt MFA, gli utenti approveranno tutto in automatico. Meglio meno prompt, più mirati, con metodi forti e segnali di rischio.

Conclusione

Una baseline Conditional Access efficace non deve essere enorme. Per un tenant piccolo io partirei da cinque pilastri: MFA moderna per tutti, amministratori blindati, blocco legacy, dispositivi conformi per i dati sensibili e controllo periodico dei log. È una configurazione realistica, mantenibile e abbastanza robusta da fermare molti attacchi comuni contro Microsoft 365.

La parte importante è trattarla come un processo, non come una schermata da configurare una volta. Ogni nuovo gestionale, stampante, consulente o dispositivo personale può introdurre un'eccezione. E ogni eccezione deve avere una scadenza. È lì che si vede la differenza tra un tenant “configurato” e un tenant davvero amministrato.