Entra ID: Criteri Accesso Condizionale Guest Impostazioni Collaborazione Esterna — i Sei Valori Predefiniti che Giocano Contro di Te

I tuoi criteri di accesso condizionale guest e le impostazioni di collaborazione esterna in Entra ID sono in realtà due superfici di controllo separate che la maggior parte dei tenant configura una sola volta, durante la configurazione iniziale, e non rivede mai più. L'accesso condizionale decide se un guest già autenticato deve superare la MFA, un dispositivo conforme, o un metodo di autenticazione più forte. Le impostazioni di collaborazione esterna decidono chi può diventare guest in primo luogo, cosa un guest può vedere una volta dentro, e per quanto tempo quell'account guest può continuare a esistere. Un tenant può avere un'ottima copertura MFA per i dipendenti e lasciare comunque ognuno di questi valori predefiniti specifici per i guest esattamente dove Microsoft li consegna — il che, per diversi di essi, è l'opzione più permissiva.

Questo articolo esamina sei falle precise in questa superficie di controllo dei guest, ciascuna collegata a un valore predefinito o meccanismo documentato da Microsoft: nessun criterio di accesso condizionale valuta davvero gli accessi dei guest, i guest possono invitare altri guest, i guest possono esplorare la directory, gli account guest non scadono mai, nessuno nota un guest che non ha mai effettuato l'accesso, e i guest possono raggiungere applicazioni aziendali che non sono mai state loro assegnate. Nessuna di queste falle richiede che un attaccante sfrutti una vulnerabilità — richiedono solo che un admin abbia accettato la configurazione di fabbrica del tenant. Per il quadro completo di come auditare un tenant end-to-end, vedi Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica.

Criteri di Accesso Condizionale Guest e Impostazioni di Collaborazione Esterna Entra ID, Definizione

L'accesso guest in Entra ID inizia con un invito — la collaborazione B2B crea un oggetto utente con UserType impostato su Guest nella tua directory, sostenuto da credenziali del tenant di origine del guest o del suo provider di identità. Da quel momento, due gruppi di impostazioni indipendenti governano cosa può fare il guest.

Le External Collaboration Settings, sotto Entra ID > External Identities, controllano i permessi di invito dei guest, la visibilità della directory per i guest, la registrazione self-service, e le liste di domini consentiti/bloccati. L'Accesso Condizionale (Conditional Access) è un motore di criteri separato che valuta ogni accesso, compresi quelli dei guest, secondo regole di assegnazione che possono mirare a tipi specifici di guest e utenti esterni — utenti guest di collaborazione B2B, utenti membro di collaborazione B2B, utenti di connessione diretta B2B, guest locali, utenti provider di servizi, e altri utenti esterni — ciascuno dei quali può essere incluso o escluso indipendentemente, per un tenant o per tutti i tenant.

Questi due sistemi non comunicano tra loro. Un guest può essere invitato con le impostazioni di collaborazione più permissive e comunque essere bloccato da un criterio di accesso condizionale rigoroso, oppure essere invitato con impostazioni di collaborazione rigorose e comunque passare senza problemi attraverso un criterio di accesso condizionale che non valuta mai i guest. Esaminarne uno senza l'altro è solo metà del quadro — vedi Account Guest Azure: la Superficie di Attacco Dimenticata nel Tuo Tenant per il modello più ampio di esposizione dei guest in cui si inseriscono le sei falle di questo articolo.

Come i Guest Sfuggono alla Copertura dell'Accesso Condizionale

GUEST_NO_CA_POLICY [HIGH] scatta quando nessun criterio di accesso condizionale abilitato include esplicitamente un tipo di utente guest o esterno. Il controllo legge l'assegnazione degli utenti inclusi di ogni criterio abilitato, quindi una base "Tutti gli utenti" non conta come copertura dei guest — questa è esattamente la distinzione su cui si basa il resto di questa sezione.

La documentazione di Microsoft stessa afferma che l'opzione di assegnazione Tutti gli utenti (All users) nell'accesso condizionale include "tutti gli utenti nella directory, inclusi i guest B2B" — quindi in teoria, un unico criterio MFA di base rivolto a Tutti gli utenti copre già ogni guest. In pratica, lo stesso insieme di documentazione spiega tre modi in cui questa copertura scompare silenziosamente.

Le Esclusioni Prevalgono sulle Inclusioni, senza Condizioni

Microsoft lo afferma chiaramente: "Quando un'organizzazione include ed esclude contemporaneamente un utente o un gruppo, l'utente o il gruppo viene escluso dal criterio. L'azione di esclusione prevale sull'azione di inclusione in un criterio." Se un qualsiasi gruppo di esclusione che contiene guest finisce collegato a un criterio — per qualsiasi motivo, in qualsiasi momento — quel criterio smette di proteggerli, silenziosamente, senza alcun avviso nell'admin center. Un criterio che continua a mostrarsi come "On" nell'admin center escludendo silenziosamente la tua popolazione di guest appare identico, a prima vista, ai criteri in modalità solo report trattati in Accesso condizionale solo report, esclusioni obsolete: cosa significa davvero «applicato» — entrambi i casi lasciano al tenant una falsa sensazione di copertura applicata.

I Criteri di Rischio Utente non Possono essere Risolti per gli Utenti Esterni, quindi la Stessa Microsoft Consiglia di Costruire un'Esclusione

Il rischio utente richiede un reset della password che il tenant di risorse non può eseguire su un'identità esterna, quindi la correzione documentata da Microsoft è: "Puoi impedire che i criteri basati sul rischio influiscano sugli utenti esterni creando un gruppo in Microsoft Entra ID che contenga tutti gli utenti esterni della tua organizzazione. Quindi, aggiungi questo gruppo come esclusione per i tuoi criteri di accesso condizionale basati su rischio utente e rischio di accesso." Nota fino a dove arriva questa raccomandazione: solo il criterio di rischio utente è irrisolvibile per un'identità esterna — Microsoft è altrettanto esplicita nell'affermare che "Il criterio di rischio di accesso viene applicato se l'utente guest esterno soddisfa il controllo di concessione." Seguire la guida alla lettera quindi elimina una copertura di rischio di accesso funzionante insieme a quella di rischio utente non funzionante. Quel gruppo "tutti gli utenti esterni", una volta esistente per un motivo legittimo, è la leva più facile da riutilizzare la prossima volta che un accesso guest rompe qualcosa — e riutilizzarlo contro la base MFA o di conformità dei dispositivi (non solo il criterio di rischio per cui è stato creato) è il modo in cui un tenant finisce con zero criteri che valutano realmente gli accessi dei guest, anche se "Tutti gli utenti" tecnicamente li include.

Limitare l'Ambito a Ruoli o Gruppi invece che a Tutti gli Utenti

Limitare un criterio a ruoli di directory o gruppi specifici invece che a Tutti gli utenti esclude strutturalmente i guest ogni volta che quei ruoli o gruppi sono popolati da dati HR interni o dati di ruolo che gli oggetti guest non possiedono.

Per altre modalità di fallimento della copertura di base non specifiche dei guest, vedi Lacune di Copertura Policy di Base Accesso Condizionale Entra ID: Nessuna Policy per Admin, Tutti gli Utenti o Tutte le App e la revisione più ampia di esclusioni e ambito in Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione.

Le Impostazioni di Collaborazione Esterna Consegnate Spalancate

Due delle sei falle risiedono interamente nelle External Collaboration Settings, ed entrambe hanno per impostazione predefinita l'estremo più permissivo di una scala a quattro o tre opzioni.

GUEST_TO_GUEST_INVITE — i Guest Possono Invitare Guest per Impostazione Predefinita

Le impostazioni di invito dei guest hanno quattro opzioni, da "Anyone in the organization can invite guest users including guests and non-admins (most inclusive)" fino a "No one in the organization can invite guest users including admins (most restrictive)". La documentazione Microsoft è esplicita su quale sia il punto di partenza di un tenant: "Per impostazione predefinita, tutti gli utenti della tua organizzazione, inclusi gli utenti guest della collaborazione B2B, possono invitare utenti esterni alla collaborazione B2B." Questa è l'opzione più inclusiva dell'elenco. A meno che un admin non l'abbia ristretta manualmente, ogni guest che hai mai invitato ha sempre avuto un permesso permanente per invitare altri guest nel tuo tenant — senza approvazione, senza notifica, senza alcuna traccia oltre alla voce del log di audit per l'invito stesso. Azure Tenant Hardening: Security Defaults tratta questo aspetto insieme agli altri valori predefiniti di collaborazione che i tenant lasciano intatti.

GUEST_DIRECTORY_VISIBILITY — il Valore Predefinito non è l'Opzione Restrittiva

L'accesso degli utenti guest ha tre livelli: stesso accesso dei member, accesso limitato, o limitato al solo proprio profilo. Microsoft indica l'opzione intermedia come predefinita: "Guest users have limited access to properties and memberships of directory objects: (Default) This setting blocks guests from certain directory tasks, like enumerating users, groups, or other directory resources. Guests can see membership of all non-hidden groups." Il comportamento di fabbrica consente a qualsiasi guest di enumerare l'appartenenza di tutti i gruppi non nascosti nella tua directory — inclusi, se non l'hai bloccato separatamente, i gruppi con appartenenza assegnabile a ruoli o privilegiata; vedi Gruppi Privilegiati Nidificati Entra ID, Gruppi Assegnabili a Ruoli e Ospiti nei Gruppi di Sicurezza per cosa un guest può apprendere solo da questa visibilità.

Entrambe le impostazioni si trovano sulla stessa pagina dell'admin center (External Identities > External collaboration settings). Microsoft documenta un ritardo di propagazione specifico per il livello di accesso guest: dopo aver salvato l'impostazione ristretta, "The changes can take up to 15 minutes to take effect for guest users."

Guest che Nessuno Governa

GUEST_NO_EXPIRATION_POLICY — un Guest Invitato Direttamente non ha Alcuna Scadenza Associata

Un guest invitato direttamente via email, al di fuori dell'entitlement management, è ciò che la terminologia stessa di Microsoft chiama ungoverned (non governato). La documentazione Microsoft sull'entitlement management traccia il confine con precisione: i guest che richiedono l'accesso tramite un access package possono essere convertiti in governed (governati), il che significa che "their account will be deleted or disabled in specified days after their last access package assignment expires." Ma "guest users that already existed in your tenant by being invited are ungoverned", e una volta che un guest non governato perde la sua ultima assegnazione di access package, "they'll remain in the tenant indefinitely." Un guest invitato direttamente che non è mai stato collegato a un access package non ha assolutamente alcun meccanismo di scadenza — né un valore predefinito lungo, né uno breve, nessuno. Persiste finché un umano non lo nota e lo rimuove manualmente, o finché un admin non costruisce retroattivamente un processo di ciclo di vita per intercettarlo.

GUEST_NEVER_SIGNED_IN — Invisibile a una Access Review Standard finché non Supera la Finestra di Inattività

Il report dei guest inattivi di Entra ID (ID Governance > Dashboard > Guest access governance) è lo strumento costruito per intercettare questo caso, e tratta i guest mai autenticati come una categoria a sé: il report separa esplicitamente "guests who have never signed in or signed in at least once", e per il gruppo mai autenticato, "the inactive days are calculated based on creation date" invece che sull'ultimo accesso, poiché non ne esiste uno. La soglia di inattività predefinita è di 90 giorni. Due insidie contano operativamente: questo report richiede una licenza Entra ID Governance o Entra Suite, quindi i tenant senza quella licenza non possono aprirlo affatto, e le access review costruite per rimuovere i guest inattivi saltano deliberatamente qualsiasi guest creato più di recente della finestra di inattività configurata — "this ensures that guests can sign in once before being removed" — quindi un guest recente, mai autenticato, è invisibile alla pulizia per tutta la durata di quella finestra.

Accesso alle Applicazioni Mai Assegnato ai Guest

GUEST_APP_ACCESS_UNRESTRICTED [MEDIUM] — Microsoft dichiara chiaramente il valore predefinito, nella sua guida su come limitare un'app a un insieme di utenti: "Applications registered in a Microsoft Entra tenant are, by default, available to all users of the tenant who authenticate successfully." Il controllo che cambia questo è Require user assignment (richiedi assegnazione utente), ed è opt-in per applicazione, non attivo per impostazione predefinita. Una volta che un guest è stato invitato — per un progetto, un documento condiviso, una riunione — è "a user of the tenant" per ogni altra applicazione che non ha attivato l'assegnazione, che lo si volesse o meno.

Perché questa Falla Sopravvive a una Revisione del Portale

Questa falla è facile da non notare durante una revisione del portale per il modo in cui fallisce: "When user assignment isn't required, unassigned users don't see the app on their My Apps, but they can still sign in to the application itself (also known as SP-initiated sign-on) or they can use the User Access URL." Un'app che sembra bloccata — perché nessun guest compare nella sua lista di utenti assegnati, e nessun guest la vede nella propria pagina My Apps — può restare comunque raggiungibile da qualsiasi guest in possesso del link di accesso diretto, che spesso è semplicemente l'URL di login normale dell'app. Lo stato di assegnazione e la visibilità non sono la stessa cosa, e solo l'assegnazione controlla realmente l'accesso.

I guest con ruoli di directory elevati aggravano questa specifica falla; vedi Ruolo Admin Guest Entra Trust B2B Cross-Tenant: Come un Utente Esterno Arriva a Global Administrator per cosa succede quando un guest sotto-assegnato risulta anche detenere permessi amministrativi.

Rilevamento

Nessuna di queste sei falle appare come una firma di attacco — sono stati di configurazione che devi interrogare direttamente.

Limitare una Revisione alla Tua Popolazione di Guest

Per limitare una access review alla sola popolazione esterna, la regola del gruppo dinamico che Microsoft fornisce come esempio è:

(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)

Sostituisci il filtro di dominio con il tuo, o rimuovilo per intercettare tutti i tipi di guest.

Remediation

1. Limitare gli Inviti dei Guest

In External collaboration settings, allontanati dal valore predefinito "Anyone... including guests". Se un piccolo numero di persone ha davvero bisogno di diritti di invito senza un ruolo admin completo, assegna loro il ruolo Guest Inviter invece di lasciare gli inviti aperti a chiunque:

Import-Module Microsoft.Graph.Identity.DirectoryManagement

$roleName = "Guest Inviter"
$role = Get-MgDirectoryRole | where {$_.DisplayName -eq $roleName}
$userId = "<user object ID or UPN>"

$DirObject = @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
  }

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

Un'insidia prima di eseguirlo: Get-MgDirectoryRole "only returns roles that have been activated", e "not all built-in roles are initially activated". In un tenant dove Guest Inviter non è mai stato assegnato tramite l'admin center, $role torna vuoto e l'ultima riga fallisce. Assegna il ruolo una volta nel portale — il che lo attiva implicitamente — oppure attivalo prima con l'API Activate directoryRole.

2. Restringere la Visibilità della Directory per i Guest

Passa a "restricted to properties and memberships of their own directory objects" a meno che uno scenario di collaborazione specifico richieda davvero che i guest possano esplorare l'appartenenza ai gruppi.

3. Dare ai Guest un Criterio di Accesso Condizionale Dedicato e Abilitato

Mira esplicitamente a "Guest or external users" (tutti i sottotipi che usi), richiedendo almeno la MFA — non affidarti solo a una base "Tutti gli utenti". Poi verifica la lista di esclusione di ogni criterio abilitato esistente alla ricerca di un gruppo "Guest or external users" o "tutti gli utenti esterni", e conferma che ciascuno sia intenzionale e ancora necessario, e non un'esclusione di un criterio di rischio finita per errore nella tua base MFA.

4. Convertire i Guest in Access Package Governati

Fallo ovunque un guest corrisponda a un progetto o un incarico definito, così che il criterio di ciclo di vita associ davvero una scadenza. Per i guest che non passeranno mai per l'entitlement management, costruisci una access review ricorrente sul gruppo dinamico di guest sopra descritto con una soglia di inattività e una decisione auto-applicata "blocca, poi rimuovi".

5. Attivare il Report dei Guest Inattivi

Questo richiede una licenza Entra ID Governance / Entra Suite. Rivedi periodicamente la categoria mai autenticato — questi account sono invisibili a una access review standard finché non superano la tua finestra di inattività.

6. Richiedere l'Assegnazione sulle Applicazioni Aziendali

Imposta "Assignment required" su Yes per ogni applicazione aziendale che non dovrebbe essere aperta a tutto il tenant, quindi assegna esplicitamente gli utenti o i gruppi — non i guest per impostazione predefinita — che ne hanno bisogno. Ricontrolla le app aggiunte al di fuori del tuo processo standard di onboarding; le app SAML SSO, le app Application Proxy che usano la preautenticazione Microsoft Entra, e le app OAuth 2.0/OpenID Connect a cui un utente o admin ha dato consenso supportano tutte questo controllo.

Come EtcSec Rileva Questo

EtcSec verifica ogni audit Azure/Entra rispetto a tutti e sei questi riscontri: GUEST_NO_CA_POLICY, GUEST_TO_GUEST_INVITE, GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, GUEST_NEVER_SIGNED_IN, e GUEST_APP_ACCESS_UNRESTRICTED. Non funzionano tutti allo stesso modo, e questa differenza conta quando devi decidere cosa dimostra un risultato pulito.

Tre vengono valutati rispetto allo stato reale del tuo tenant, quindi il loro risultato cambia quando correggi l'impostazione sottostante. GUEST_NO_CA_POLICY legge l'assegnazione degli utenti inclusi di ogni criterio di accesso condizionale abilitato. GUEST_TO_GUEST_INVITE legge il criterio di invito guest del tenant. GUEST_NEVER_SIGNED_IN enumera gli account guest privi sia di accesso interattivo che non interattivo e ne riporta il conteggio. Questi tre sono quelli che ti dicono se la correzione dello scorso trimestre è ancora in vigore dopo che il successivo admin ha toccato le External Collaboration Settings o l'Accesso Condizionale.

Gli altri tre — GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, e GUEST_APP_ACCESS_UNRESTRICTED — vengono sollevati come avvisi a livello di tenant su ogni audit Azure invece di essere attivati/disattivati da un singolo flag del tenant. Leggili come un promemoria permanente per riverificare quel controllo nel portale, non come prova che sia attualmente configurato male.

Riferimenti Principali

• Configure external collaboration settings
• Conditional Access: Users, groups, agents, and workload identities
• Authentication and Conditional Access for B2B users
• Convert guest user lifecycle in entitlement management
• Monitor and clean up stale guest accounts
• Manage access to apps
• Restrict a Microsoft Entra app to a set of users
• Restrict guest user access permissions
• List directoryRoles (Microsoft Graph)
• Customize and filter activity logs in Microsoft Entra ID