Bloccare Microsoft 365 con una policy di accesso condizionale

Perché l’accesso condizionale è il punto giusto dove bloccare Microsoft 365

Se vuoi impedire accessi non autorizzati a Microsoft 365, la leva più pulita non è il firewall e nemmeno la sola MFA: è la policy di accesso condizionale di Microsoft Entra ID. Il motivo è semplice: il controllo avviene nel momento in cui l’identità chiede un token, quindi prima che Outlook, Teams, SharePoint, Exchange Online o il portale web diventino davvero utilizzabili.

In pratica stai decidendo chi può autenticarsi, da dove, con quale livello di rischio e con quali prerequisiti. Se la regola è fatta bene, blocchi i casi sbagliati senza dover rincorrere ogni singola app. Se è fatta male, invece, ti tagli fuori da solo. È un controllo potente proprio perché sta a monte.

Il punto da non perdere è questo: l’accesso condizionale non è un “interruttore generale” da attivare e basta. Va progettato come una catena di eccezioni ordinate, con una policy di blocco finale e una serie di policy che concedono accesso solo quando il contesto è accettabile.

Prima regola: non partire dal blocco, partire dal perimetro

La tentazione classica è creare una policy che blocca tutto e poi aggiungere eccezioni a mano. Funziona solo in laboratorio. In produzione conviene fare il contrario: definire prima il perimetro di ciò che deve restare disponibile e poi bloccare il resto.

Il perimetro minimo da chiarire è questo:

• quali utenti devono avere accesso a Microsoft 365;
• quali app sono incluse: tutte o solo alcune;
• quali condizioni rendono accettabile l’accesso: MFA, dispositivo conforme, dispositivo ibrido joined, posizione geografica, rischio utente o rischio accesso;
• quali account non vanno mai colpiti dalla policy, almeno all’inizio: break-glass, service account, account tecnici gestiti in altro modo.

Se non hai ancora un inventario di questi elementi, il gap non va mascherato: va chiuso prima di applicare un blocco severo. Il modo corretto è verificare in Microsoft Entra admin center la sezione Protection > Conditional Access e controllare sia le policy esistenti sia gli account esclusi. Se l’informazione non c’è, il lavoro non è “fare la policy”: è raccogliere i requisiti.

Struttura pratica di una policy di blocco

Una policy utile per bloccare Microsoft 365 ha sempre una logica leggibile anche mesi dopo. La formula più robusta è:

1. target: utenti o gruppi specifici;
2. cloud app: Microsoft 365 o app selezionate;
3. condizione: posizione, dispositivo, rischio, client app, piattaforma;
4. grant: consenti solo se soddisfi i requisiti, altrimenti blocca;
5. esclusioni: account di emergenza e casi davvero giustificati;
6. modalità iniziale: report-only prima dell’enforcement.

Il blocco vero e proprio spesso si ottiene con una policy che richiede condizioni non negoziabili. Per esempio:

• blocca accessi da paesi non autorizzati;
• blocca client legacy;
• blocca utenti non protetti da MFA;
• blocca dispositivi non conformi quando l’accesso arriva da applicazioni sensibili;
• blocca sessioni con rischio alto rilevato da Identity Protection.

La scelta dipende dal tuo obiettivo. Se vuoi fermare accessi da reti esterne, il blocco per località è il più immediato. Se vuoi ridurre il rischio di furto credenziali, il controllo su MFA e rischio utente è più sensato. Se vuoi proteggere dati aziendali su endpoint non gestiti, il requisito di dispositivo conforme è quello giusto.

Il punto delicato: bloccare senza rompere l’operatività

Molti ambienti falliscono non perché la policy sia troppo severa, ma perché non considerano i flussi legittimi che non sembrano tali a prima vista. Ecco i casi che vanno sempre verificati prima di abilitare il blocco:

• sincronizzazione di Outlook su dispositivi mobili personali;
• client di posta legacy o applicazioni che usano autenticazione non moderna;
• amministrazione remota da jump box o VPN aziendale;
• servizi automatici che leggono mailbox o file in SharePoint;
• utenti fuori sede che cambiano spesso IP o paese;
• dispositivi appena reimpostati, ancora non conformi nel momento del primo accesso.

Qui l’approccio corretto è usare report-only e poi validare il comportamento con i log. Non serve immaginare cosa succederà: lo vedi in Sign-in logs e nel What If tool della Conditional Access. Se un accesso verrebbe bloccato, il log mostra quale policy lo ha intercettato e perché.

Questo è il modo serio di lavorare: prima osservi, poi applichi. E se qualcosa non torna, correggi la regola o l’eccezione, non il principio di sicurezza.

Policy di blocco: esempio architetturale sensato

Una configurazione tipica, in un tenant aziendale, può seguire questa logica:

1. Policy 1: richiedi MFA per tutti gli utenti con esclusione degli account di emergenza.
2. Policy 2: blocca client legacy per tutte le app Microsoft 365.
3. Policy 3: richiedi dispositivo conforme per SharePoint, OneDrive e Exchange da fuori rete aziendale.
4. Policy 4: blocca accessi da paesi non approvati.
5. Policy 5: in presenza di rischio utente medio o alto, richiedi password reset o blocca.

Il vantaggio di questa suddivisione è operativo: se un utente non entra, capisci subito quale anello della catena ha fallito. Una policy monolitica che fa tutto insieme è più difficile da diagnosticare e più facile da rompere.

Se l’obiettivo è “bloccare Microsoft 365” in senso stretto, devi però evitare l’errore di colpire indiscriminatamente tutti i servizi. Spesso è meglio distinguere tra:

• accesso al portale e alle app web;
• accesso da client desktop;
• accesso a servizi di collaborazione come Teams e SharePoint;
• accessi amministrativi.

In questo modo puoi lasciare un percorso di accesso più rigido agli admin e più flessibile agli utenti finali, senza mischiare i due mondi.

Come evitare il lockout totale

La regola operativa più importante è banale ma viene ignorata spesso: tieni sempre almeno due account break-glass esclusi da tutte le policy di accesso condizionale, protetti da credenziali forti e monitorati. Non usarli per il giorno per giorno, non sincronizzarli con processi automatici, non affidarli a persone che li usano come account normali.

Se questa informazione ti manca, non andare avanti a tentativi. Il controllo da fare è nel portale Entra, nella lista degli account esclusi dalle policy, e nei log di accesso per verificare che gli account di emergenza non siano stati coinvolti in test o enforcement.

In più, prima di passare da report-only a on, assicurati di avere una via di recupero:

• accesso amministrativo alternativo;
• documentazione delle esclusioni;
• procedura di rollback rapida;
• un secondo amministratore pronto a validare il cambiamento.

Questa non è paranoia, è gestione del blast radius. Se sbagli una policy di blocco, l’impatto non è locale: può fermare email, Teams, file condivisi e processi aziendali in pochi minuti.

Verifica: cosa guardare prima di abilitare il blocco

La verifica non si fa “a sensazione”. Si fa con tre artefatti concreti:

1. Sign-in logs: vedi se la policy sarebbe stata applicata e con quale risultato.
2. What If: simuli un utente, un’app, una posizione e un dispositivo.
3. Stato policy: controlli se la regola è in Report-only, On o Off.

Un test utile è prendere un utente standard, un admin e un account mobile, poi simulare tre contesti: rete aziendale, rete esterna e paese non consentito. Se il comportamento non è coerente con il disegno, la policy va corretta prima della messa in esercizio.

Se usi il CLI o i log esportati, cerca almeno questi campi: utente, app, risultato, policy applicata, motivo del blocco, tipo di client, posizione e device state. Senza questi dati stai lavorando al buio.

Bloccare per posizione geografica: utile, ma non da solo

Il blocco per paese è spesso il primo tentativo quando si vuole fermare accessi indesiderati. Ha senso, ma non basta. Gli IP possono cambiare, i provider mobile possono uscire da altre geografie, e alcune VPN fanno apparire il traffico come proveniente da paesi non attesi.

Quindi il blocco geografico va usato come uno strato, non come tutta la strategia. È efficace soprattutto per ridurre rumore e attacchi di massa da aree che non fanno parte del business. Se il tuo team lavora solo in Italia e in UE, bloccare il resto del mondo è una misura sensata. Se hai utenti distribuiti globalmente, serve una strategia più fine.

La verifica qui è semplice: controlla nei sign-in logs la colonna della posizione e confrontala con le eccezioni approvate. Se trovi falsi positivi, non allargare subito il paese consentito: prima verifica se il problema è il client, la VPN o un provider mobile.

Bloccare accessi non compliant: il caso dei dispositivi gestiti

Se la tua azienda usa Intune o un sistema equivalente di gestione endpoint, la policy di accesso condizionale può diventare il punto di enforcement per i dispositivi conformi. Questo è il caso più pulito quando vuoi proteggere dati aziendali da endpoint fuori controllo.

La logica è lineare:

• dispositivo conforme: accesso consentito;
• dispositivo non conforme o sconosciuto: accesso bloccato o limitato;
• dispositivo personale: accesso eventualmente consentito solo via browser e con vincoli aggiuntivi.

Qui la parte critica è la sincronizzazione tra stato del device e identità. Se Intune segnala conformità in ritardo, la policy di accesso condizionale può bloccare utenti legittimi appena dopo il provisioning. In quel caso il problema non è la policy in sé, ma il tempo di propagazione dello stato.

La verifica utile è controllare il device in Entra ID e lo stato di conformità in Intune. Se un device è conforme ma la policy lo vede ancora come non conforme, hai un problema di timing o di registrazione, non di blocco vero e proprio.

Quando conviene usare un approccio progressivo

Non tutti i blocchi devono essere immediati. In ambienti grandi o poco documentati, conviene spesso partire con una policy che registra e non applica, poi passare a un blocco parziale e infine a un enforcement completo.

Un percorso pratico è questo:

1. crea la policy in report-only;
2. osserva i log per qualche giorno lavorativo;
3. correggi le esclusioni legittime;
4. abilita il blocco solo per un sottoinsieme di utenti o app;
5. estendi il controllo al resto del tenant quando i falsi positivi sono sotto soglia.

Questo approccio riduce il rischio di sorpresa e ti permette di misurare l’effetto reale. Se l’obiettivo è sicurezza senza interruzioni, la metrica da guardare è il tasso di accessi bloccati rispetto agli accessi totali, insieme ai ticket generati dagli utenti.

Osservabilità minima da tenere sempre sotto mano

Per non trasformare la policy in una scatola nera, tieni sotto osservazione almeno questi elementi:

• numero di sign-in falliti per policy;
• policy più colpita;
• app più impattata;
• paesi o reti da cui arrivano i blocchi;
• dispositivi non conformi più frequenti;
• client legacy ancora in uso.

Se il dato non c’è, il gap si chiude esportando i sign-in logs e filtrando per risultato. In ambienti più strutturati, conviene portare questi eventi in un SIEM o in un sistema di monitoraggio per individuare pattern ricorrenti.

Un aumento improvviso dei blocchi può indicare tre cose: una policy troppo severa, un cambio di comportamento degli utenti, oppure un tentativo reale di accesso malevolo. Senza telemetria non distingui i tre casi.

Conclusione operativa: il blocco giusto è quello che sai spiegare

Bloccare Microsoft 365 con una policy di accesso condizionale non significa chiudere tutto. Significa scegliere con precisione chi entra, da quale contesto e con quale livello di fiducia. La differenza tra una policy buona e una policy pericolosa sta nella capacità di essere letta, verificata e rollbackabile.

Se hai un tenant piccolo, la strada più sicura è iniziare con MFA obbligatoria, blocco dei client legacy e una policy geografica prudente. Se hai dispositivi gestiti, aggiungi il requisito di conformità. Se hai utenti esposti a rischio alto, integra le condizioni di risk-based access. In tutti i casi, resta valido lo stesso principio: osserva prima, applica dopo, e tieni sempre un’uscita di emergenza.

Assunzione: tenant Microsoft Entra con licenze che includono Conditional Access e accesso amministrativo separato per test e rollback.