Cosa sono gli Account Guest Azure?
Gli Account Guest Azure sono identità B2B create nel tenant Microsoft Entra ID per collaboratori esterni, partner, fornitori o utenti invitati a gruppi, Teams, SharePoint e applicazioni aziendali. Il problema non è l'esistenza dei guest, ma la mancanza di governo: chi può invitarli, quali risorse ereditano, quali controlli di autenticazione ricevono e quando il loro accesso viene davvero revocato.
Microsoft documenta che le External collaboration settings definiscono chi può invitare guest e quanto i guest possono vedere nella directory. Microsoft raccomanda anche access reviews e Conditional Access dedicato per guest ed external users. Nelle implementazioni reali, il rischio compare quando queste leve non vengono trattate come un unico modello operativo.
Account Guest Azure: dove nasce il rischio vero
| Area | Errore tipico | Perché conta |
|---|---|---|
| Invito | troppi utenti possono invitare esterni | un account interno compromesso può introdurre nuove identità nel tenant |
| Visibilità directory | i guest vedono più del necessario | si facilita enumerazione e movimento laterale organizzativo |
| Accesso | i guest finiscono in gruppi o app troppo ampie | il rischio è nell'autorizzazione ereditata, non nel solo invito |
| Autenticazione | non esiste un baseline dedicata per guest | l'accesso esterno resta protetto peggio di quello interno |
| Ciclo di vita | nessuno rivede sponsor, ultimo accesso o bisogno reale | il tenant accumula guest dormienti ma ancora efficaci |
Come il problema diventa una catena di abuso
1. Invito troppo facile
Se i membri normali possono invitare esterni o se il processo di approvazione è solo formale, un attaccante con una credenziale interna valida può introdurre una propria identità esterna.
2. Accesso ereditato a gruppi, Teams o app
L'account guest entra come userType = Guest, ma il vero rischio dipende da cosa eredita: gruppi Microsoft 365, applicazioni Entra integrate, SharePoint, Teams e workflow con owner poco attenti.
3. Policy esterne più deboli delle policy interne
Microsoft permette di applicare Conditional Access specificamente a All guest and external users. Se il tenant non usa questa distinzione, il guest può finire sotto una baseline meno rigorosa del dipendente pur accedendo agli stessi dati.
4. Nessuno chiude il ciclo di vita
Un guest senza sponsor chiaro, senza access review e senza controllo sull'ultimo accesso tende a sopravvivere oltre il progetto che lo aveva giustificato. A quel punto diventa superficie di attacco persistente.
Cosa verificare prima
Chi può invitare guest
Controlla le External collaboration settings e documenta se l'invito è limitato a ruoli amministrativi o se membri normali e altri guest possono ancora invitare. Questo singolo setting cambia molto il rischio operativo.
Che accesso ereditano i guest
Non basta contare gli account. Devi verificare:
- gruppi Microsoft 365 con guest attivi
- applicazioni assegnate tramite gruppi che includono guest
- risorse SharePoint e Teams ancora condivise con sponsor non più presenti
- guest che mantengono accesso a ruoli o workflow sensibili
Che policy si applica a guest ed external users
Serve una baseline chiara per guest, non un riuso passivo della baseline interna. Controlla MFA, authentication strength, app incluse, location, eccezioni e cross-tenant trust.
Quali guest sono ormai orfani
Usa signInActivity, sponsor, membership e access review per separare guest attivi da guest che dovrebbero già essere stati rimossi.
Inventario operativo
Get-MgUser -Filter "userType eq 'Guest'" `
-Property Id,DisplayName,UserPrincipalName,CreatedDateTime,SignInActivity,ExternalUserState |
Select-Object DisplayName,UserPrincipalName,CreatedDateTime,
@{N='LastSignIn';E={$_.SignInActivity.LastSignInDateTime}},ExternalUserState
Un guest senza accesso recente ma ancora membro di gruppi sensibili è spesso più urgente di molti guest usati davvero in modo corretto.
Rilevamento e telemetria
Segnali da monitorare
- inviti creati da utenti non amministrativi
- guest aggiunti a gruppi o app rilevanti
- login guest da tenant, paesi o applicazioni inattese
- access reviews incomplete o sponsor non definiti
- guest vecchi ancora attivi in gruppi con accesso reale
Query orientative
AuditLogs
| where OperationName in ("Invite external user", "Add member to group", "Add app role assignment to user")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources
SigninLogs
| where UserType == "Guest"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessStatus, ClientAppUsed, IPAddress
Remediation e hardening
Limita gli inviti
Se il tenant non ha una ragione forte per consentire inviti aperti, riduci l'invito a ruoli definiti o a workflow approvati. Questo abbassa subito il rischio di onboarding incontrollato.
Applica Conditional Access ai guest
I guest devono avere una baseline propria. MFA, app incluse, eccezioni e metodi ammessi vanno decisi per gli esterni, non assunti per ereditarietà.
Usa access reviews e sponsor reali
Un guest senza sponsor, senza review periodica o senza bisogno ancora attuale deve perdere l'accesso. La correzione non è solo bloccare il login, ma rimuovere membership, app assignment e, quando appropriato, l'account stesso.
Rivedi cross-tenant access e trust esterni
Se ti fidi di segnali MFA o compliance emessi da altri tenant, devi sapere esattamente da quali tenant e per quali casi d'uso. La fiducia esterna non deve essere globale per comodità.
Validazione dopo il cambiamento
- prova un invito da un utente che non dovrebbe più poter invitare
- verifica che un nuovo guest cada nella policy di Conditional Access prevista
- conferma che i guest non più giustificati spariscano da gruppi e applicazioni
- documenta sponsor, owner e ultimo accesso dei guest ancora legittimi
Controlli aggiuntivi su trust tra tenant e review periodiche
Per gli Account Guest Azure conviene controllare separatamente anche due punti spesso dimenticati: i cross-tenant access settings e la qualità delle access reviews. Se un tenant si fida dei segnali MFA o compliance di un partner senza scope preciso, il rischio non è più limitato al guest singolo ma al modello di fiducia tra tenant. Allo stesso modo, un'access review approvata in modo meccanico non riduce davvero la superficie di attacco. Serve capire chi sponsorizza l'account, quale app o gruppo giustifica ancora l'accesso e da quanto tempo il guest non viene usato.
Cross-tenant access: cosa controllare davvero
Microsoft distingue in modo esplicito i cross-tenant access settings dalle normali policy di invito B2B. Questo significa che un tenant può decidere se fidarsi o meno dei claim di MFA, compliance del dispositivo o hybrid join emessi da tenant esterni. Il punto operativo è semplice: questa fiducia non andrebbe mai lasciata ampia per default. Va invece limitata ai tenant partner realmente necessari, a specifici utenti o gruppi, e alle applicazioni che hanno una motivazione di business chiara.
Nel review pratico conviene chiedere tre cose:
- da quali tenant esterni stai accettando claim di MFA o di device compliance
- quali applicazioni o gruppi possono essere raggiunti grazie a questa fiducia
- chi approva oggi nuove eccezioni cross-tenant e con quale scadenza
Se queste domande non hanno risposte chiare, la configurazione è probabilmente troppo larga anche se nessun incidente è ancora visibile nei log.
Gruppi, app e ownership: il vero punto debole
Molti problemi con i guest non nascono dall'invito iniziale, ma dal fatto che l'account finisce dentro gruppi che assegnano accesso a più applicazioni, siti SharePoint o team di progetto contemporaneamente. In questi casi la remediation non consiste solo nel rimuovere il guest, ma nel capire quale owner ha concesso l'accesso, quale gruppo lo propaga e se esiste ancora un processo periodico che riveda quella membership.
Microsoft raccomanda access reviews proprio per questo: separare il guest ancora giustificato da quello che continua a esistere solo per inerzia. Per i team tecnici, una regola utile è trattare come prioritari i guest che soddisfano almeno due condizioni: nessun sign-in recente, sponsor non chiaro, membership in gruppi con applicazioni enterprise o accesso documentale esteso. Questo tipo di triage produce di solito risultati più rapidi di una semplice lista di tutti i guest presenti nel tenant.
Sequenza di chiusura per guest non più giustificati
Una chiusura ordinata dovrebbe seguire sempre la stessa sequenza:
- identificare gruppi, app e risorse condivise ancora collegate al guest
- confermare con sponsor o owner se l'accesso è ancora necessario
- rimuovere membership e assegnazioni prima della rimozione dell'account
- bloccare il sign-in se serve una finestra di verifica
- eliminare o disattivare il guest solo dopo aver confermato che le dipendenze operative sono chiuse
Questa sequenza evita due errori comuni: lasciare accessi indiretti attivi dopo la rimozione apparente dell'utente, oppure cancellare il guest senza capire quale gruppo o workflow verrà ricreato alla prossima sincronizzazione o al prossimo invito.
Cosa verificare dopo l'access review
Una review chiusa non basta se il risultato non viene applicato davvero ai gruppi e alle app. Dopo ogni ciclo conviene controllare se le membership sono state rimosse, se gli owner hanno confermato il bisogno reale e se i guest senza sponsor vengono bloccati o cancellati entro la finestra prevista. Questo punto è particolarmente importante per Teams e SharePoint, dove una condivisione dimenticata può sopravvivere molto più a lungo della relazione di progetto che l'aveva generata.
Riferimenti
- Microsoft Learn: Configure external collaboration settings
- Microsoft Learn: Restrict guest user access permissions
- Microsoft Learn: Conditional Access for guests and external users
- Microsoft Learn: Manage guest access with access reviews
Letture correlate
- Lacune Accesso Condizionale Azure: Bypass MFA
- Hardening Tenant Azure: Security Defaults
- Accesso Privilegiato Azure: Troppi Admin Globali
- App Azure con Privilegi Eccessivi nel Tenant
- Azure Identity Protection: Criteri di Rischio
- Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta
Gli Account Guest Azure vanno valutati insieme a inviti, Conditional Access, access reviews e trust esterni. Il rischio non è l'account guest isolato, ma il fatto che nessuno governi davvero il suo ciclo di vita e il suo raggio di accesso.
