• Cloud, Guide, Microsoft 365, Sicurezza
• 18 Novembre 2025

Cosa potrebbe succedere se organizzi una festa e nessuno controlla la distribuzione degli inviti? Qualcuno degli invitati potrebbe condividere il suo invito con altri, qualcuno potrebbe portare degli amici, qualcun’altro potrebbe fingersi un invitato legittimo. Il risultato? Potresti trovarti molte più persone di quelle che avevi preventivato e perderesti totalmente il controllo della festa.

La stessa cosa succede sul tuo tenant Microsoft 365. Ogni volta che un contenuto viene condiviso all’esterno o una persona fuori dalla tua organizzazione viene invitata a collaborare (ad esempio via Teams), un utente guest viene creato nella tua directory.

La collaborazione è fondamentale e utilissima per le attività di tutti i giorni. Espone, però, a rischi di utilizzo non legittimo o esfiltrazione di contenuti. É importante, quindi, che l’amministratore del tenant mantenga il controllo e l’efficienza dell’ambiente e si prenda cura anche del ciclo di vita degli utenti esterni.

Il rischio concreto è che alcuni guest mantengano l’accesso alle risorse per un tempo indefinito o illimitato, anche dopo aver terminato la collaborazione, esponendo potenzialmente i dati aziendali. Se non vengono rimossi dopo l’uso, i guest rimangono silenti (ma ancora autorizzati all’accesso) per molto tempo. Non è difficile trovare tenant dove il numero di guest è pari o superiore a quello dei membri!

Inoltre, i guest potrebbero non utilizzare account aziendali o dispositivi gestiti. Questo aumenta il rischio legato all’impossibilità di validare le modalità e gli strumenti per accedere ai dati aziendali.

In questa guida troverai molti consigli utili e concreti, con esempi pratici, per gestire al meglio gli utenti guest del tuo tenant. Il tutto condito con un po’ di teoria per aiutarti a comprendere meglio le scelte consigliate.

Cominciamo!

Cos’è un guest e come si riconosce?

Un guest (utente ospite) in Microsoft 365 è una persona esterna all’organizzazione che ha ricevuto il permesso di accedere a risorse come gruppi Teams o documenti. Può avere un account di posta elettronica aziendale (M365, Google Workspace, ecc…) o personale (come Outlook, Gmail, ecc…). Gli utenti guest sono riconoscibili nell’interfaccia di amministrazione di Microsoft 365 come “Guest users” e possono partecipare a riunioni, chat, condivisione documenti e attività di gruppo specifiche per cui sono stati autorizzati. Il loro accesso è gestito tramite Microsoft Entra ID e possono autenticarsi con le loro credenziali o con un codice di accesso monouso. Essi hanno accesso limitato solo alle risorse condivise specificamente con loro.

Figura 1 – Esempio di utente Guest in Entra ID

Riconosciamo due tipologie di guest:

• Guest esterno, è una persona esterna alla nostra organizzazione che accede alle risorse condivise con il proprio account (aziendale o personale). Non ha altre relazioni con la nostra infrastruttura se non i permessi di accesso e collaborazione a cui è stata invitata. Questi utenti consultano le risorse condivise attraverso dei dispositivi aziendali o personali non gestiti dalla nostra organizzazione.
• Guest interno, è una persona esterna alla nostra organizzazione a cui viene creato un account come membro del nostro dominio. Questo tipo di utenti sono, solitamente, consulenti o contractors che lavorano con continuità per la nostra organizzazione o che hanno necessità di ruoli e privilegi elevati che vanno gestiti e monitorati. Non è raro che, a questo tipo di utenze, venga assegnato un dispositivo aziendale gestito.

Questa divisione ci sarà utile più avanti nell’articolo.

Cosa si può fare per gestire la situazione?

Microsoft 365 ci mette a disposizione diversi strumenti utili e potenti. A seconda del livello di licenze in nostro possesso, è possibile intervenire su più livelli per automatizzare e mettere in sicurezza i vari processi.

Andiamo con ordine. Possiamo individuare queste aree di intervento:

• Controllo degli accessi (Conditional Access)
• Gestione dei permessi per invitati e invitanti
• Controllo delle attività (per SharePoint e OneDrive)
• Gestione del ciclo di vita

Vediamole singolarmente in dettaglio

Controllo degli accessi

Siccome gli account guest non possono essere sotto il nostro controllo e non possiamo validare le condizioni dei dispositivi da cui gli utenti accedono alle nostre risorse, il minimo che possiamo fare è richiedere che soddisfino una richiesta di MFA. Questo è il primo passo fondamentale.

Per abilitare la richiesta MFA, possiamo creare una Conditional Access Policy dedicata (questa funzionalità richiede una licenza Entra ID Premium P1 o superiore).

Vediamola in pratica:

Dal portale Entra Admin Center (https://entra.microsoft.com) accediamo al menù Conditional Access e creiamo una nuova policy

Figura 2 – Creazione di una nuova Conditional Access Policy

Diamo un nome il più possibile parlante alla policy. Ad esempio: External Users – Require MFA. Si applica agli utenti esterni (guests) e scatena la richiesta MFA. Semplice e chiaro.

Dobbiamo, poi, assegnare questa policy agli utenti esterni. Per farlo, selezioniamo Selected Users dal menù Include sotto Assignments – Users e mettiamo la spunta su Guest or external users. Selezioniamo tutte le voci nel menù.

Figura 3 – Assegnazione delle policy agli utenti esterni (guests)

La policy dovrà impattare tutti i possibili usi dell’account da parte dell’ospite. Quindi in Target resources selezioniamo All resources.

Figura 4 – Applicazione delle policy all’accesso a tutte le applicazioni

Continuando, dobbiamo abilitare l’accesso ma previa conferma dell’identità tramite MFA. Quindi, in Grant, andiamo a consentire l’accesso ma spuntiamo Require multifactor authentication.

Figura 5 – Consentire l’accesso richiedendo MFA

Infine, abilitiamo e creiamo la policy.

Figura 6 – Abilitare e creare una Conditional Access Policy

Da questo momento, ogni accesso alle nostre risorse da parte di un utente esterno sarà consentito solamente previa conferma dell’identità tramite secondo fattore.

Come protezione aggiuntiva, è possibile limitare l’accesso degli utenti esterni ai portali amministrativi del nostro ambiente. In pratica, verranno mantenuti solamente gli accessi legati alla collaborazione. Per ottenere questo risultato, creiamo una seconda Conditional Access Policy. Le differenze da quella appena creata sono due. Come Target resources andiamo a scegliere i Microsoft Admin Portals.

Figura 7 – Scelta dei Microsoft Admin Portals come target per la conditional access policy

Il Grant, questa volta, sarà Block.

Figura 8 – Impostazione di Block per l’accesso

L’ultimo controllo che è opportuno mettere in atto riguarda il controllo della persistenza delle sessioni. Per impostazione predefinita, un accesso tramite utente guest potrebbe persistere sul client per un tempo indeterminato e, potenzialmente, esporre i dati aziendali ad accessi indesiderati. É buona prassi limitare la durata delle sessioni autenticate (questo valore temporale è soggettivo per ogni organizzazione, tipicamente si considera un turno di lavoro di 8 ore) e impedire che le sessioni possano persistere alla chiusura del browser. Questo controllo si attua, ancora una volta, con una Conditional Access Policy. In questo caso, andremo a lavorare con la gestione della sessione utente. Nota, questi settings possono essere implementati in una policy dedicata (per favorire granularità e troubleshooting mirato) oppure essere inclusi nella policy creata all’inizio di questo articolo per la richiesta MFA.

In Session all’interno di Access controls, andiamo a selezionare e impostare la Sign-in frequency a 8 ore e impostiamo la Persistent browser session a Never persist.

Figura 9 – Gestione e limitazione sessione utente tramite conditional access policy

In questo modo, gli utenti esterni saranno obbligati a ripetere l’autenticazione ogni 8 ore, anche se mantengono il browser aperto. Ogni volta, invece, che chiudono e riaprono la sessione web, verrà loro richiesto di autenticarsi.

Gestione dei permessi per invitati e invitanti

Per impostazione predefinita, chiunque all’interno dell’organizzazione può invitare dei guests. Sempre per impostazione predefinita, anche un guest può invitare altri guest. Questo comportamento potrebbe non essere in linea con le politiche dell’organizzazione e andrebbe governato.

Per gestire chi può invitare, dobbiamo accedere agli External collaboration settings presenti sul portale Entra Admin Center all’interno delle funzionalità di External Identities:

Figura 10 – Impostazioni per la gestione dell’invito dei guest

All’interno di questa pagina, troviamo i Guest invite settings che ci permettono di determinare chi può invitare persone esterne all’organizzazione. Si può andare dall’impostazione più permissiva (chiunque può invitare, compresi gli stessi guests) a quella più restrittiva (guest non permessi). Come via di mezzo, abbiamo la possibilità di autorizzare all’invito tutti gli utenti interni (members) e utenti esterni se in possesso di un permesso specifico. In alternativa, l’invito degli esterni può essere consentito solo ad utenti in possesso di uno specifico ruolo. La scelta, anche in questo caso, è soggettiva per ciascuna organizzazione. A livello operativo, la possibilità per gli utenti di invitare esterni in autonomia favorisce la collaborazione e non richiede impegno aggiuntivo per lo staff IT. Il consiglio è quindi di scegliere la via intermedia come in figura:

Figura 11 – Solo gli utenti interni ed esterni autorizzati possono invitare guests

Capita spesso che gli utenti esterni invitati non dispongano di una email aziendale ma utilizzino account personali (es. outlook.com, gmail.com, ecc…). Oppure, ci sono casi in cui una organizzazione collabori solo ed esclusivamente con alcune altre organizzazioni (es. contractors, fornitori, ecc…). Gli External collaboration settings ci danno la possibilità di limitare i destinatari degli inviti provenienti dai nostri utenti. Potremmo impedire che particolari domini possano essere oggetto di invito (es. domini personali) oppure consentire inviti solo verso particolari domini impostati da noi. La scelta dipende, ovviamente, dalle necessità dell’organizzazione. In questo caso, l’impostazione predefinita (e consigliata per la maggior parte delle organizzazioni) prevede che gli inviti a collaborare possano essere inviati a qualsiasi dominio:

Figura 12 – Limitare i domini dei guest che possono essere invitati a collaborare

Controllo delle attività (per SharePoint e OneDrive)

Attraverso policy di SharePoint, è possibile forzare una esperienza limitata nell’accesso alle risorse da dispositivi non gestiti. Questa funzionalità richiede una licenza Entra ID Premium P1 o superiore.

Gli utenti guest, per loro natura, non accedono quasi mai da dispositivi gestiti dalla nostra organizzazione (salvo specifici casi visti all’inizio dell’articolo, ricordi i Guest Interni?). Sebbene questo tipo di policy non si applica tecnicamente soltanto ai guests (se assegnata a dei member users modifica la loro esperienza d’uso con dispositivi non gestiti), ci permette di aggiungere uno strato di controllo ulteriore sull’uso dei dati aziendali. Questo controllo si concretizza nel vincolo ad un accesso web-based ai contenuti e, al tempo stesso, nel blocco dell’accesso e della sincronizzazione dei dati tramite applicazioni.

Per abilitare questa policy, dobbiamo accedere al portale amministrativo di SharePoint, da https://admin.microsoft.com selezioniamo SharePoint dal menù Admin centers

Figura 13 – Accesso al portale SharePoint admin center

Dal menù Policies selezioniamo Access control e, successivamente, la policy per Unmanaged devices.

Figura 14 – Abilitazione esperienza SharePoint limitata per dispositivi non gestiti

Selezionando Allow limited, web-only access e salvando la selezione, abiliteremo l’esperienza limitata su dispositivi non gestiti.

Nota bene: L’esperienza limitata su dispositivi non gestiti viene messa in pratica tramite due Conditional Access Policies. Queste policies sono, per impostazione predefinita, applicate a tutti gli utenti del tenant. É buona prassi, dopo aver attivato la funzione da SharePoint, verificare le impostazioni delle CAP e adeguarle alle proprie esigenze. Nel nostro caso, andrebbe modificato lo scope di attivazione da All users alle sole tipologie di guest.

Figura 15 – Conditional Access Policies create automaticamente da SharePoint per esperienza limitata su dispositivi non gestiti

Sempre dal pannello amministrativo di SharePoint, possiamo decidere le modalità di condivisione predefinite per la nostra organizzazione. Accedendo al menù Sharing sotto Policies, possiamo decidere tra 4 livelli di condivisione possibile. Da quello predefinito dove chiunque può accedere ai nostri contenuti senza autenticazione (sconsigliato) a quello più restrittivo dove non è permessa la condivisione esterna (sconsigliato se dobbiamo collaborare). Nel mezzo, ci sono due modalità intermedie che coinvolgono proprio i nostri cari utenti guest. La modalità più restrittiva prevede la condivisione solo con guest già presenti nella nostra organizzazione, questo vuol dire che un esterno deve essere invitato da qualcuno (admin?) prima di ricevere un invito a collaborare. La modalità più flessibile, invece, prevede che un utente diventi guest del nostro tenant alla ricezione di un invito a collaborare.

Figura 16 – Esempio di external sharing flessibile

Ci sono diversi altri settings interessanti nella pagina, ti invito ad esplorarli e testarli nella tua organizzazione. Ti segnalo una impostazione che, secondo me, ha senso abilitare: il permesso di default quando si condivide un contenuto impostata a View. In questo modo, un utente che condivide qualcosa senza badare troppo alle impostazioni della condivisione, non darà permessi di scrittura sui contenuti alla leggera.

Figura 17 – Permesso di default sulla condivisione dei contenuti

Gestione del ciclo di vita

Quante volte si sono visti tenant con un numero di utenti guest molto elevato. A volte anche superiore al numero dei membri effettivi dell’organizzazione. Questo non è un problema insito nei guests in quanto tali ma in una fondamentale mancanza di gestione del loro ciclo di vita. Quando un collaboratore lascia l’organizzazione per qualsiasi motivo, l’IT viene informato e procede alla rimozione dell’utente e di tutti i permessi associati. Quando, invece, un guest conclude una collaborazione, difficilmente chi amministra il tenant ne viene informato. Ne risulta che tali account rimangono vivi all’interno dell’organizzazione con conseguente rischio di utilizzo non autorizzato delle eventuali risorse cui hanno accesso.

Al di là di processi e procedure che andrebbero formalizzate in azienda per la gestione degli utenti esterni, esiste la possibilità di automatizzare un processo di revisione di questi account e ridurre la loro eccessiva permanenza nella nostra organizzazione. La soluzione di chiama Access Review ed è contenuta nelle licenze Entra ID Governance, Entra ID Suite, Entra ID Premium P2.

Vediamo in dettaglio come funziona.

Dobbiamo accedere al portale amministrativo Entra (https://entra.microsoft.com) e portarci nella sezione ID Governance. Qui troveremo il menù Access reviews e potremo procedere alla creazione di un nuovo flusso.

Figura 18 – Accesso amministrativo alle funzionalità di Access Review

Per prima cosa, dobbiamo scegliere a cosa dobbiamo applicare il processo di revisione. Nel nostro caso, sceglieremo Teams + Groups. Possiamo scegliere se verificare tutti i gruppi che contengono guests o concentrarci su alcuni gruppi specifici (potremmo avere flussi di revisione diversi a seconda dell’obiettivo).

Figura 19 – Selezione dell’oggetto per la revisione

Nel passaggio successivo, scegliamo chi dovrà operare da revisore. Potremo scegliere se lasciare il compito agli owners dei vari gruppi, se delegare specifiche persone o i manager degli utenti oggetto di revisione. Possiamo anche lasciare al guest il compito di completare la revisione. Qui la scelta dipende dalle necessità dell’organizzazione, per questa guida il sceglierò di lasciare all’utente finale la gestione del processo. Sceglierò quindi User review their own access. Vedremo poi cosa succederà.

Scegliamo quanto deve durare il processo, se deve avere una ricorrenza e quando vogliamo farlo partire. Possiamo anche decidere quando terminarlo o se farlo girare per sempre.

Figura 20 – Impostazioni di una Access Review di 6 giorni con ricorrenza ogni quarter

Ci sono poi una serie di impostazioni per la revisione, dall’applicazione automatica dei risultati alle risorse (es. la rimozione di un utente da un gruppo di cui non deve più essere membro) all’invio di mail riepilogative, alla richiesta di giustificazione per il mantenimento degli accessi. Per i dettagli di tutte queste impostazioni, ti rimando alla documentazione ufficiale che risulta molto chiara.

C’è una impostazione, in particolare, di cui mi interessa parlarti. É quella che governa l’azione da intraprendere se l’utente revisionato non risponde alla revisione:

Figura 21 – Azioni possibili nel caso un utente non risponda alla revisione

Le voci del menù sono abbastanza parlanti. Possiamo non fare nulla, rimuovere l’accesso (consigliato), approvare l’accesso (mantiene la condizione attuale, è una sorta di approvazione d’ufficio) oppure intraprendere le raccomandazioni di Microsoft (in questo caso, verrebbero comunque rimossi tutti gli accessi).

Quando lasciamo all’utente la possibilità di confermare o meno la necessità di appartenere ad un gruppo come guest, durante la campagna di revisione verranno inviate delle mail di richiesta simile a questa:

Figura 22 – Email di richiesta inviata da Access Review

L’utente potrà così, in autonomia, dichiarare di aver ancora bisogno degli accessi garantiti oppure no.

Il risultato sarà quello di avere attivi nel nostro tenant solamente gli account guest realmente operativi e in collaborazione con i nostri utenti.

Conclusioni

La collaborazione tra le persone è di fondamentale importanza per le attività quotidiane di tutte le organizzazioni. Quali responsabili delle infrastrutture dobbiamo tenere sempre in considerazione gli aspetti di sicurezza, anche quelli apparentemente nascosti dietro dei “semplici” utenti esterni. Tutte le azioni che compiamo, anche se piccole e apparentemente insignificanti, ci portano ogni volta un po’ più vicini al concetto di Zero Trust.

Spero che questa guida ti abbia fornito qualche informazione utile per iniziare a gestire correttamente gli utenti guest sul tuo tenant Microsoft 365.