Account Guest Azure: la Superficie di Attacco Dimenticata nel Tuo Tenant

Che cosa sono gli Account Guest di Azure?

Gli account guest di Azure Entra ID (collaborazione B2B) consentono a utenti esterni - partner, appaltatori, fornitori, revisori - di accedere alle risorse Microsoft 365 senza disporre di un account nel tuo tenant. Gli account guest si autenticano tramite il proprio tenant di origine, ma ottengono l'accesso alle tue risorse in base alle autorizzazioni che assegni loro.

Gli account guest sono una funzionalità legittima e ampiamente utilizzata. Il problema è la governance. Le organizzazioni invitano utenti esterni per progetti a breve termine e non li rimuovono mai. Le impostazioni di invito vengono lasciate ai valori predefiniti, il che consente a ogni utente del tenant - inclusi i guest esistenti - di invitare chiunque. La MFA non è obbligatoria per i guest. Il risultato è una popolazione crescente di identità esterne con livelli di accesso variabili - molte dimenticate, alcune appartenenti a persone che hanno lasciato la propria organizzazione anni fa.

Come Funziona

Gli account guest differiscono dagli account member in due aspetti fondamentali:

1. L'autenticazione avviene nel tenant di origine del guest - non controlli le loro policy MFA, i requisiti delle password o la postura di sicurezza. Puoi comunque obbligarli a usare la tua MFA: per impostazione predefinita, le impostazioni di accesso cross-tenant non considerano attendibili le attestazioni di MFA o del dispositivo provenienti da altre organizzazioni Microsoft Entra, quindi la tua policy di Accesso Condizionale continua ad applicarsi a loro. Ciò che non puoi fare è ereditare alcuna garanzia dal modo in cui il loro tenant di origine li ha autenticati.
2. La governance del ciclo di vita è opt-in - Entra ID dispone di un meccanismo nativo che rimuove automaticamente i guest (le Access Review con Applica automaticamente i risultati alla risorsa, e Blocca l'accesso per 30 giorni, quindi rimuovi l'utente dal tenant come azione sui guest respinti), ma è disattivato per impostazione predefinita e richiede un abbonamento Microsoft Entra ID Governance o Entra ID P2. Un tenant che non lo attiva mai non ha alcun offboarding automatico.

I diritti di invito sono aperti per impostazione predefinita. Il comportamento documentato da Microsoft è che "tutti gli utenti della tua organizzazione, inclusi gli utenti guest della collaborazione B2B, possono invitare utenti esterni alla collaborazione B2B" - quindi non si tratta solo dei tuoi member: un guest già esistente può invitarne un altro, senza alcuna supervisione o approvazione IT. Nelle organizzazioni con collaborazione B2B attiva, è comune trovare centinaia di account guest, con una percentuale significativa priva di attività nell'ultimo anno.

La Catena di Attacco

Fase 1 - Enumerare gli Account Guest

# signInActivity richiede AuditLog.Read.All E una licenza Entra ID P1/P2.
# Directory.Read.All da solo restituisce i guest ma non i loro dati di accesso.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"

# Elenca tutti gli account guest con la data dell'ultimo accesso.
# -All è obbligatorio: senza, viene restituita solo la prima pagina (massimo 500 quando
# signInActivity è selezionato) e il resto dei guest viene omesso silenziosamente.
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity,createdDateTime" |
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object LastSignIn

# Trova i guest inattivi da 180+ giorni.
# signInActivity NON viene restituito per impostazione predefinita: omettendo -Property ogni guest
# risulta come se non avesse mai effettuato l'accesso, quindi questo filtro li individua tutti.
$cutoff = (Get-Date).AddDays(-180)
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity" |
  Where-Object { $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff }

Fase 2 - Sfruttare le Impostazioni di Invito senza Restrizioni

Se i diritti di invito dei guest non sono limitati, qualsiasi account member compromesso può invitare identità esterne controllate dall'attaccante per ottenere un accesso persistente:

# Utilizzo di un account member compromesso per invitare un'identità esterna controllata dall'attaccante
# Permesso delegato con privilegio minimo: User.Invite.All
New-MgInvitation `
  -InvitedUserEmailAddress "[email protected]" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage $false

Fase 3 - Accedere alle Risorse senza MFA

Se i guest non sono soggetti a una policy di Accesso Condizionale che richieda la MFA, un account guest compromesso fornisce accesso diretto a tutte le risorse condivise senza verifiche aggiuntive - file di SharePoint, canali Teams, contenuti di OneDrive. Il caso peggiore è quello di un guest che detiene anche un ruolo di directory di Entra, dove un trust B2B cross-tenant completamente aperto diventa un percorso verso il ruolo di Amministratore Globale - vedi Ruolo Admin Guest di Entra e Trust B2B Cross-Tenant: Come gli Utenti Esterni Raggiungono l'Amministratore Globale.

Fase 4 - Movimento Laterale tramite Risorse Condivise

Gli account guest hanno spesso accesso a contenuti condivisi sensibili che possono essere esfiltrati direttamente. Documenti di progetto, contratti, dati dei clienti - tutti visibili ai guest con le autorizzazioni appropriate. L'appartenenza ai gruppi è il percorso più diretto: un guest aggiunto a un gruppo privilegiato nidificato o assegnabile a ruoli eredita molto più del semplice accesso ai file, come descritto in Gruppi Privilegiati Nidificati di Entra ID, Gruppi Assegnabili a Ruoli e Guest nei Gruppi di Sicurezza.

Fase 5 - Persistere tramite Account Dimenticati

Gli account guest obsoleti persistono indefinitamente. Un attaccante che compromette un account guest dimenticato ottiene un accesso persistente e a bassa visibilità, che viene raramente rivisto o revocato.

Rilevamento

Eventi del Log di Controllo di Entra ID

Questi sono i nomi delle attività così come appaiono nel log di controllo (audit log) di Microsoft Entra. Gli accessi dei guest non sono eventi di audit - risiedono nei log di accesso (sign-in logs), che sono una fonte separata.

Query di Rilevamento SIEM (Elastic)

I nomi dei campi riportati di seguito seguono l'integrazione Elastic Azure Logs.

Inviti ai guest (KQL):

azure.auditlogs.operation_name: "Invite external user"

L'evento di audit registra chi ha effettuato l'invito (initiated_by), non i ruoli di directory di quella persona - l'integrazione espone initiated_by.user.id, .displayName, .ipAddress e .userPrincipalName, e nient'altro. "Inviti da account non amministratori" deve quindi essere risolto confrontando lo UPN dell'iniziatore con gli attuali titolari di ruoli amministrativi, non con un singolo filtro su un campo roles.

Account guest che accedono ai portali di amministrazione (KQL):

azure.signinlogs.properties.user_type: "Guest" AND
azure.signinlogs.properties.app_display_name: ("Azure Portal" OR "Microsoft Azure Management")

Inviti guest massivi (>5 in 1 ora) - ES|QL: KQL si limita a filtrare; non ha alcun ruolo nell'aggregazione, trasformazione o ordinamento dei dati, quindi una regola di rilevamento burst non può proprio essere scritta in KQL. Usa ES|QL:

FROM logs-azure.auditlogs-*
| WHERE azure.auditlogs.operation_name == "Invite external user"
| STATS invites = COUNT(*)
    BY inviter = azure.auditlogs.properties.initiated_by.user.userPrincipalName,
       window = DATE_TRUNC(1 hour, @timestamp)
| WHERE invites > 5

Remediation

1. Limitare i Diritti di Invito

Entra ID > Identità esterne > Impostazioni di collaborazione esterna:
Impostazioni di invito guest: "Solo gli utenti assegnati a ruoli amministrativi specifici possono invitare"

Con questa impostazione, solo i titolari del ruolo Amministratore Utenti o Invito Guest possono inviare inviti, il che crea una traccia di audit e previene l'abuso degli inviti. Nota cosa questa impostazione NON fa: limita chi può invitare, ma non aggiunge un flusso di approvazione. Se hai bisogno di approvazioni, anteponi all'accesso guest gli access package di entitlement management con approvatori nominati.

2. Richiedere la MFA per gli Utenti Guest

Policy di Accesso Condizionale:
Nome: Richiedi MFA - Utenti Guest
Utenti > Includi > Seleziona utenti e gruppi > Guest o utenti esterni:
  seleziona ogni tipo applicabile (utenti guest di collaborazione B2B,
  utenti member di collaborazione B2B, utenti B2B direct connect,
  utenti guest locali, utenti fornitori di servizi, altri utenti esterni)
Risorse di destinazione > Includi: Tutte le risorse (in precedenza 'Tutte le app cloud')
Controlli di accesso > Concedi: Richiedi autenticazione a più fattori
Abilita policy: Attivato

Non esiste un'unica casella di controllo "Tutti i guest e gli utenti esterni" - devi scegliere i tipi di utenti esterni che vuoi coprire. Poiché le impostazioni di trust cross-tenant non considerano attendibile per impostazione predefinita la MFA del tenant di origine, i guest soddisfano questa policy eseguendo la MFA nel tuo tenant.

3. Rimuovere gli Account Guest Obsoleti

# L'eliminazione di un utente richiede uno scope in scrittura - User.DeleteRestore.All è
# quello con il privilegio minimo. AuditLog.Read.All è ciò che rende leggibile signInActivity.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","User.DeleteRestore.All"

$cutoff = (Get-Date).AddDays(-90)

# -All e -Property non sono opzionali qui. Senza -Property i dati di accesso
# sono assenti, ogni guest soddisfa il test $null, e questo script elimina
# l'intera popolazione di guest.
$staleGuests = Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "id,displayName,userPrincipalName,signInActivity" |
  Where-Object {
    $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff
  }

Write-Host "Found $($staleGuests.Count) stale guest accounts"

# Esporta e rivedi l'elenco prima di eliminare qualsiasi cosa, poi rimuovi -WhatIf.
$staleGuests | Select-Object DisplayName, UserPrincipalName,
  @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Export-Csv .\stale-guests.csv -NoTypeInformation

$staleGuests | ForEach-Object {
  Remove-MgUser -UserId $_.Id -WhatIf
}

Un guest eliminato in questo modo rimane recuperabile per 30 giorni prima che Microsoft Entra ID lo rimuova definitivamente.

4. Configurare le Access Review Trimestrali

Entra ID > ID Governance > Access review:
Crea review ricorrenti trimestrali per tutti gli account guest
Revisori: Proprietari delle risorse o proprietari dei gruppi
Applica automaticamente i risultati alla risorsa: Abilita
Se i revisori non rispondono: Rimuovi l'accesso
Azione da applicare sugli utenti guest respinti:
  Blocca l'accesso per 30 giorni, quindi rimuovi l'utente dal tenant

Le ultime due righe sono ciò che trasforma una review in un vero offboarding: la sola rimozione dell'accesso lascia l'oggetto guest nel tenant. L'azione di eliminazione dell'account B2B è disponibile quando la review ha come target Team e gruppi selezionati - non è offerta nella review "Tutti i gruppi Microsoft 365 con utenti guest". Licenze: le access review richiedono un abbonamento Microsoft Entra ID Governance o Microsoft Entra Suite; alcune funzionalità operano con Entra ID P2.

5. Implementare Livelli di Accesso per i Guest

Usa l'entitlement management di Entra ID per automatizzare il ciclo di vita dei guest con date di scadenza automatiche. Come le access review, è una funzionalità di Microsoft Entra ID Governance ed è concessa in licenza separatamente da Entra ID P1.

Come EtcSec Rileva Questo Problema

EtcSec verifica la governance degli account guest a ogni scansione di Azure, identificando i rischi di proliferazione e gli accessi incontrollati.

GUEST_INVITATION_UNRESTRICTED segnala i tenant la cui policy di invito guest è ancora aperta a tutti - l'impostazione predefinita - invece di essere ristretta a un insieme controllato di persone abilitate a invitare. Questa è la causa principale della proliferazione incontrollata di guest.

GUEST_NO_MFA_REQUIRED segnala i tenant in cui gli utenti guest non sono soggetti a una policy di Accesso Condizionale che richieda la MFA, lasciando le identità esterne con un'autenticazione più debole rispetto agli utenti interni.

GUEST_STALE_90_DAYS elenca gli account guest abilitati il cui ultimo accesso registrato risale a più di 90 giorni fa, fornendo un elenco prioritizzato per la revisione e la pulizia degli accessi. I guest che non hanno mai effettuato l'accesso sono un caso diverso e vengono segnalati separatamente da GUEST_NEVER_SIGNED_IN.

Domande Frequenti

Gli account guest di Azure sono un rischio per la sicurezza per impostazione predefinita? Gli account guest in sé non sono intrinsecamente rischiosi, ma una governance scadente crea un rischio significativo. I problemi principali sono: nessun requisito di MFA per i guest, diritti di invito senza restrizioni e account obsoleti che non vengono mai rimossi. Un programma guest ben governato comporta un rischio basso; uno non gestito diventa una superficie di attacco importante.

Con quale frequenza dovrei rivedere gli account guest? Microsoft non pubblica un'unica cadenza obbligatoria: le Access Review di Entra ID possono essere pianificate settimanalmente, mensilmente, trimestralmente o annualmente, e l'intervallo corretto dipende da quanto sono sensibili le risorse condivise. Trimestrale è la baseline EtcSec. Le Access Review possono automatizzare l'esito con la rimozione automatica in caso di mancata risposta, il che mantiene il processo gestibile anche per i tenant di grandi dimensioni; richiede un abbonamento Entra ID Governance o Entra ID P2.

Un account guest può essere usato per muoversi lateralmente all'interno dell'organizzazione? Sì. Un guest con accesso a Teams può vedere tutti i messaggi e i file in quei canali. Se il guest ha anche accesso a SharePoint, può leggere e potenzialmente esfiltrare documenti. Il danno è delimitato dalle autorizzazioni del guest, ma i guest obsoleti con privilegi eccessivi sono estremamente comuni nella realtà.

Priorità di Revisione

Account Guest Azure: la Superficie di Attacco Dimenticata nel Tuo Tenant dovrebbe essere trattato come un'esposizione reale all'interno del tuo tenant Entra ID e Azure, non come un'unica impostazione isolata. Inizia definendo il perimetro della revisione: quali admin, guest, service principal, app registration, esclusioni di policy e account break-glass sono coinvolti, quali workflow di business dipendono da essi, quali privilegi espongono e quali eccezioni di emergenza sono state aggiunte nel tempo. Questa fase di definizione del perimetro previene una remediation superficiale, perché il sintomo tecnico è spesso più piccolo del raggio d'impatto operativo. Documentando il percorso completo dalla configurazione al privilegio, il team può dare priorità ai cambiamenti che riducono il rischio rapidamente senza interrompere l'accesso in produzione. Questo crea anche una baseline difendibile per la validazione successiva e fornisce al management una spiegazione chiara del perché il problema sia rilevante ora.

Controlli Adiacenti da Rivedere

Quando gli attaccanti raggiungono il tuo tenant Entra ID e Azure, raramente si fermano al primo punto debole. Attorno a Account Guest Azure: la Superficie di Attacco Dimenticata nel Tuo Tenant, in genere verificano se il percorso esposto può essere concatenato con autenticazione legacy, governance debole dei guest, consenso applicativo troppo ampio, account di emergenza obsoleti e ruoli mai rivisti. Questo significa che i difensori dovrebbero rivedere non solo la debolezza principale, ma ogni dipendenza vicina che trasforma l'accesso in persistenza o escalation di privilegi. Verifica quali identità, ruoli, autorizzazioni e assunzioni di trust possono essere riutilizzati da un operatore motivato. Se una correzione chiude un solo oggetto lasciando intatti i percorsi di privilegio adiacenti, il rischio effettivo cambia a malapena. Una revisione disciplinata delle opportunità di concatenamento è ciò che trasforma l'argomento di questo articolo in un esercizio pratico di hardening, piuttosto che in una singola casella da spuntare.

Evidenze e Telemetria da Raccogliere

Una risposta solida a Account Guest Azure: la Superficie di Attacco Dimenticata nel Tuo Tenant richiede evidenze che possano essere riviste sia dal team di engineering sia da quello di detection. Raccogli i log di accesso, i log di audit, le modifiche alle assegnazioni di ruolo, gli eventi di consenso, le modifiche alle credenziali delle applicazioni e i segnali di accesso a rischio, confronta le modifiche recenti con le finestre di manutenzione note e isola gli account o i sistemi che hanno cambiato comportamento senza un motivo di business chiaro. Usa queste evidenze per rispondere a tre domande: quando è comparso il percorso a rischio, chi può ancora utilizzarlo e se esiste un'esposizione simile altrove nel tuo tenant Entra ID e Azure. Una buona revisione della telemetria aiuta anche a distinguere il debito tecnico ereditato dall'abuso attivo. Questa distinzione è importante, perché il piano di remediation per una configurazione errata obsoleta è diverso dal piano per un percorso che mostra già attività simili a quelle di un attaccante o eccezioni di policy ripetute.

Account Guest Azure: Validazione Prima della Chiusura

Una revisione solida di Account Guest Azure dovrebbe concludersi con evidenze di produzione, non con la supposizione che il percorso a rischio sia scomparso. Prima di chiudere il finding, riverifica le assegnazioni di ruolo, l'ambito delle policy, le autorizzazioni delle app o le impostazioni dei guest, le evidenze di accesso, audit o rischio provenienti dal tenant reale, e il percorso di eccezione che potrebbe ricreare silenziosamente l'esposizione. Conferma che lo stato più sicuro si applichi all'ambito che conta realmente: l'OU di produzione, l'assegnazione di ruolo effettiva, il percorso applicativo o il percorso di trust e delega che un attaccante sfrutterebbe davvero. Registra il proprietario tecnico, la dipendenza di business e la condizione di rollback, in modo che la revisione successiva possa stabilire se lo stato più sicuro è stato mantenuto.

Usa una breve checklist di chiusura:

• verifica che lo stato a rischio sia scomparso dal punto di vista dell'attaccante, non solo da uno screenshot dell'amministratore
• conserva un export o un campione di log prima/dopo che dimostri che l'ambito interessato è cambiato
• documenta il proprietario e la decisione di eccezione se il controllo non ha potuto essere applicato completamente

Per l'esposizione adiacente, incrocia il risultato con App Azure con Privilegi Eccessivi nel Tenant, Azure Tenant Hardening: Correggere le Impostazioni Predefinite Insicure, Come Auditare la Sicurezza di Microsoft Entra ID (Azure AD): Guida Pratica alla Revisione, e Conformità AD e Azure: NIS2, ISO 27001, CIS Controls. La stessa lacuna di controllo spesso ricompare in percorsi di identità vicini, lacune di logging o autorizzazioni delegate, motivo per cui la fase di validazione finale è importante quanto il finding iniziale.

Account Guest Azure: Evidenze da Conservare per il Prossimo Ciclo di Revisione

Il prossimo revisore non dovrebbe dover ricostruire il caso a memoria. Conserva le evidenze che hanno originariamente giustificato il finding, la prova che la modifica è stata applicata, e la nota che spiega perché lo stato finale è accettabile. Per questo argomento, le evidenze più utili di solito combinano l'export del tenant o lo screenshot che mostra l'ambito interessato, le evidenze di accesso, audit o policy che dimostrano che il controllo ora si applica, e la nota su proprietario, approvazione ed eccezione per lo stato finale. Questo pacchetto compatto rende molto più rapide le revisioni trimestrali o post-modifica e aiuta a spiegare se il problema è stato rimosso, ridotto o formalmente accettato.

Se una successiva modifica ad admin, policy o applicazione riapre il percorso, queste evidenze storiche rendono anche più facile dimostrare cosa è cambiato. Questo è ciò che trasforma Account Guest Azure da un controllo puntuale in un processo di assurance ripetibile.

Fonti

• Microsoft Learn - Configure external collaboration settings (ambito di invito predefinito, opzioni di invito guest, ruolo Guest Inviter)
• Microsoft Learn - List users (Microsoft Graph) (signInActivity richiede Entra ID P1/P2 e AuditLog.Read.All)
• Microsoft Learn - Get-MgUser e Remove-MgUser
• Microsoft Learn - Manage guest access with access reviews e What are access reviews? (applicazione automatica, licenze)
• Microsoft Learn - Cross-tenant access overview (le attestazioni MFA del tenant di origine non sono attendibili per impostazione predefinita)
• Microsoft Learn - Conditional Access: target resources e users and groups
• Microsoft Learn - Entra audit log activity reference (nomi delle attività per gli utenti invitati)
• Elastic - Azure exported fields e KQL

Letture Correlate

Rivedi questo argomento insieme a Entra ID: Lacune nell'Accesso Condizionale che Lasciano Esposizioni Reali, Azure Tenant Hardening: Correggere le Impostazioni Predefinite Insicure, Accesso Privilegiato Azure: Troppi Amministratori Globali, App Azure con Privilegi Eccessivi nel Tenant, e Azure Identity Protection: Bloccare le Credenziali Compromesse. Questi articoli correlati mostrano come le stesse debolezze di identità tendano solitamente a concatenarsi in una valutazione reale, invece di presentarsi come finding isolati.

• Entra ID: Lacune nell'Accesso Condizionale che Lasciano Esposizioni Reali
• Azure Tenant Hardening: Correggere le Impostazioni Predefinite Insicure
• Accesso Privilegiato Azure: Troppi Amministratori Globali
• App Azure con Privilegi Eccessivi nel Tenant
• Azure Identity Protection: Bloccare le Credenziali Compromesse

L'uso di questi riferimenti mantiene la discussione sulla remediation focalizzata sull'intero percorso di attacco, piuttosto che su una singola lacuna di controllo.

Checklist di Validazione

Prima di chiudere la revisione, riesegui gli stessi controlli che hanno rilevato il problema e conferma che il percorso a rischio non esista più dal punto di vista dell'attaccante. Verifica in produzione, e non solo in staging o nella documentazione, le identità, i privilegi, i percorsi di ereditarietà e i controlli compensativi rilevanti. Registra il proprietario tecnico, la dipendenza di business prevista e le evidenze che dimostrano che la nuova configurazione è al contempo più sicura e operativamente sostenibile. Questa fase di validazione finale è ciò che mantiene l'articolo ancorato al modo in cui i team riducono realmente il rischio di identità.

Confermare nella Pratica i Controlli sul Ciclo di Vita dei Guest

La remediation degli account guest dovrebbe includere una revisione di chi sponsorizza gli utenti esterni, di come viene ricertificato l'accesso e di quali percorsi di collaborazione continuano a creare identità guest longeve con autorizzazioni ampie. I programmi più resilienti combinano restrizioni sugli inviti, access review periodiche e controlli sulla titolarità, in modo che l'accesso guest rimanga legato a un'effettiva esigenza di business, invece di protrarsi indefinitamente dopo la fine del progetto.