Ruolo Admin Guest Entra Trust B2B Cross-Tenant: Come un Utente Esterno Arriva a Global Administrator

Ruolo Admin Guest Entra Trust B2B Cross-Tenant: cosa controllano davvero queste impostazioni

Ruolo admin guest Entra trust B2B cross tenant raggruppa due dei livelli meno controllati della governance delle identità esterne di Microsoft Entra ID, e la loro combinazione forma uno dei percorsi di escalation dei privilegi più silenziosi della piattaforma: un account guest esterno che detiene direttamente un ruolo di directory, dietro Cross-Tenant Access Settings che, per impostazione predefinita, permettono ad altre organizzazioni Microsoft Entra di raggiungere il vostro tenant. Nessuna delle due metà è esotica di per sé — la collaborazione B2B e l'assegnazione di ruoli di directory sono entrambe funzionalità Entra fondamentali e documentate — ma la combinazione delle due viene raramente controllata come un unico controllo.

Questo è un angolo diverso rispetto a due lacune correlate che vale la pena conoscere prima. Se la vostra preoccupazione riguarda chi può invitare i guest, se serve loro l'MFA, o se si accumulano account inattivi, vedete Account Guest Azure: la superficie di attacco dimenticata. Se la vostra preoccupazione riguarda un guest che eredita un privilegio finendo in un gruppo di sicurezza annidato in un gruppo assegnabile a ruoli, vedete Gruppi privilegiati nidificati in Entra ID, gruppi assegnabili a ruoli e guest nei gruppi di sicurezza. Questo articolo copre qualcosa a monte di entrambi: un guest che detiene direttamente un ruolo Microsoft Entra — senza gruppo, senza nidificazione — e la configurazione di trust B2B a livello di tenant che decide, a monte, quali organizzazioni esterne possono raggiungere l'identità di origine di quel guest.

Cinque controlli compongono questo livello di governance:

Come un guest finisce con un ruolo di directory, e come le impostazioni di trust allargano la porta

Assegnare un ruolo a un guest non è un caso speciale nell'RBAC di Entra

Il modello di assegnazione dei ruoli di Microsoft Entra non tratta un principal guest in modo diverso da un principal membro quando si tratta di detenere un ruolo di directory. Lo stesso workflow di assegnazione dei ruoli — New-MgRoleManagementDirectoryRoleAssignment in PowerShell, o POST /roleManagement/directory/roleAssignments in Microsoft Graph — che assegna Helpdesk Administrator a un dipendente interno assegna con altrettanta facilità Global Administrator a un oggetto guest esterno. La documentazione API di Microsoft per elencare le assegnazioni di ruoli lo mostra esplicitamente: il suo esempio di espansione del principal in una risposta di assegnazione di ruolo include utenti guest ("userType": "Guest") che detengono un ruolo di directory proprio accanto agli utenti membri, senza alcun trattamento speciale.

Questo conta perché i permessi di directory predefiniti di un guest sono volutamente ristretti. Il livello di permesso guest di Microsoft Entra (l'impostazione authorizationPolicy.guestUserRoleId) è per impostazione predefinita Accesso limitato (GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3), e può essere ristretto ad Accesso limitato ulteriormente (2af84b1e-32c8-42b7-82bc-daa82404023b), il che impedisce a un guest persino di enumerare l'appartenenza ai gruppi oltre ai propri. Ma quell'impostazione governa la visibilità predefinita degli oggetti di directory per ogni guest — non è un tetto su ciò che un'assegnazione di ruolo esplicita può concedere a un singolo guest. Un guest a cui viene assegnato Global Administrator ha permessi amministrativi completi sul tenant, indipendentemente da quanto restrittivo sia il livello di permesso guest predefinito. Le stesse linee guida Zero Trust di Microsoft elencano Ai guest non vengono assegnati ruoli di directory altamente privilegiati come raccomandazione specifica, avvertendo che un account guest compromesso con un ruolo elevato offre agli attaccanti un percorso per elevare i privilegi, creare account backdoor e persistere nel tenant — e gli strumenti di postura di terze parti lo tracciano come un finding autonomo a sé stante: il catalogo delle esposizioni di Tenable elenca esplicitamente «Guest Account With a Privileged Role», citando come rischio principale una tracciabilità ridotta e una postura di sicurezza più debole lato tenant di origine.

I Cross-Tenant Access Settings decidono quali identità esterne possono persino raggiungere quell'assegnazione

Un'assegnazione di ruolo di directory a un guest è contenuta solo quanto lo è l'identità esterna che vi sta dietro. I Cross-Tenant Access Settings di Microsoft Entra controllano questo dall'altra direzione — sono regole predefinite, a livello di tenant, che si applicano a qualsiasi altra organizzazione Microsoft Entra a meno che non configuriate eccezioni specifiche per organizzazione. Secondo i valori iniziali predefiniti documentati da Microsoft:

• Collaborazione B2B (b2bCollaborationInbound / b2bCollaborationOutbound): tutti i vostri utenti interni sono abilitati per la collaborazione B2B per impostazione predefinita — possono invitare guest esterni, ed essere invitati altrove come guest, senza che sia richiesta alcuna allowlist per organizzazione.
• Trust in entrata (inboundTrust): i claim MFA e dispositivo (dispositivo conforme, join ibrido Microsoft Entra) provenienti da organizzazioni esterne non sono considerati attendibili per impostazione predefinita. Se un amministratore abilita successivamente «Considera attendibile l'autenticazione a più fattori dai tenant di Microsoft Entra» a livello predefinito anziché per singolo partner, il claim MFA di ogni organizzazione Microsoft Entra esterna viene accettato — l'accesso condizionale smette di riverificare l'MFA per qualsiasi guest, di qualsiasi tenant, compresi quelli di cui non avete mai sentito parlare. Questo è B2B_INBOUND_TRUST_ALL.
• Connessione diretta B2B (b2bDirectConnectInbound / b2bDirectConnectOutbound): bloccata in entrambe le direzioni, a livello di tenant, per impostazione predefinita — Microsoft documenta questa come l'unica impostazione di questa famiglia distribuita chiusa: «la connessione diretta B2B in uscita è bloccata per l'intero tenant, e la connessione diretta B2B in entrata è bloccata per tutte le organizzazioni Microsoft Entra esterne». B2B_DIRECT_CONNECT_ENABLED scatta quando una modifica a livello predefinito — non una modifica intenzionale per singolo partner — la apre.
• Accesso in uscita: anch'esso aperto per impostazione predefinita — i vostri utenti possono essere invitati nelle risorse di qualsiasi organizzazione Microsoft Entra esterna a meno che l'accesso in uscita non sia limitato. B2B_OUTBOUND_UNRESTRICTED segnala esattamente questo valore predefinito in uscita non limitato.

Sia le allowlist/blocklist sia le impostazioni di accesso cross-tenant vengono verificate al momento dell'invito, ma se un dominio esterno non è presente in nessuna delle due liste, Microsoft Entra ricade su qualunque sia il valore predefinito impostato per l'accesso cross-tenant — che, di fabbrica, è aperto alla collaborazione.

La catena di escalation

Passo 1 — Un'organizzazione esterna invita, o viene invitata, senza restrizione specifica per organizzazione

Poiché le impostazioni predefinite di collaborazione B2B permettono l'accesso in entrata e in uscita verso qualsiasi organizzazione Microsoft Entra esterna, un account guest proveniente praticamente da qualsiasi tenant può essere invitato nel vostro — oppure un account dipendente compromesso può invitarne uno — senza incontrare un controllo di allowlist.

Passo 2 — Le impostazioni di trust in entrata sopprimono una nuova verifica MFA

Se il trust in entrata è configurato per accettare claim MFA da organizzazioni esterne a livello predefinito, Microsoft Entra verifica se il token del guest porta già un claim MFA soddisfatto nel suo tenant di origine — un tenant che non controllate e non potete controllare. Nessuna nuova verifica viene emessa nel vostro tenant se quel claim è presente, indipendentemente da quanto sia debole o forte l'applicazione dell'MFA nel tenant di origine.

Passo 3 — All'oggetto guest viene assegnato direttamente un ruolo di directory

Da qualche parte nella storia del tenant — un impegno una tantum con un fornitore, un workaround di tipo «break-glass», un amministratore che ha usato «assegna temporaneamente Global Admin al guest» come scorciatoia mai revocata — l'ID oggetto del guest è stato passato a una chiamata di assegnazione di ruolo. Nulla nell'RBAC di Entra ID blocca questo a livello di API, e a meno che qualcuno non interroghi specificamente l'appartenenza ai ruoli per i principal guest, non emerge in una revisione di routine «chi sono i nostri amministratori» che elenca i nomi a occhio.

Passo 4 — La sessione privilegiata persiste attraverso il tenant di origine del guest

Poiché l'autenticazione per quel guest avviene ancora nel suo tenant di origine, le vostre policy di accesso condizionale, i rilevamenti del rischio di accesso e l'applicazione di password/MFA nel vostro tenant vedono solo ciò che le impostazioni di trust lasciano passare. Una compromissione delle credenziali del tenant di origine del guest diventa, transitivamente, una compromissione di un'identità privilegiata nel vostro.

Rilevamento

# Microsoft Graph — postura predefinita attuale dell'accesso cross-tenant
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default

# Microsoft Graph — tutte le eccezioni specifiche per partner
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Microsoft Graph — tutte le assegnazioni di ruolo di directory con principal espanso;
# filtrare la risposta lato client per principal.userType eq 'Guest'
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal

// Log di audit di Microsoft Entra — assegnazioni di ruolo che ricadono su un UPN guest
AuditLogs
| where OperationName in ("Add member to role", "Add eligible member to role")
| where TargetResources[0].userPrincipalName contains "#EXT#"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].userPrincipalName)

// Log di audit di Microsoft Entra — modifiche all'impostazione predefinita di accesso cross-tenant
AuditLogs
| where Category == "CrossTenantAccessSettings"
| where OperationName has "default"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)

Remediation

1. Inventariate ogni assegnazione di ruolo di directory detenuta da un guest, poi decidete per ciascuna: serve un accesso permanente, serve un ruolo in generale, oppure non è mai stata revocata dopo un impegno di breve durata. Trattate «non sappiamo perché questo guest ha questo ruolo» come un incidente, non come una nota di configurazione.
2. Spostate qualsiasi accesso privilegiato legittimo di un guest in PIM come assegnazione idonea e limitata nel tempo, con approvazione richiesta, anziché come assegnazione diretta permanente. Vedete Accesso privilegiato Azure: troppi amministratori globali per capire perché l'accesso privilegiato permanente è già un finding comune anche per gli account membro, e Funzionalità Azure AD Premium P2 per ciò che serve per abilitare PIM.
3. Impostate l'accesso predefinito di collaborazione B2B in entrata e in uscita su Blocca, poi aggiungete impostazioni specifiche per organizzazione solo per i tenant esterni con cui collaborate realmente. La stessa guida di Microsoft è di identificare prima gli accessi in entrata/uscita, così che un passaggio del predefinito a Blocca non interrompa un accesso di business attivo.
4. Portate il trust MFA e dispositivo in entrata fuori dall'ambito predefinito. Se dovete considerare attendibile l'MFA di un partner specifico, configuratelo come eccezione specifica per quel partner soltanto — non come predefinito generale applicato a qualsiasi tenant Microsoft Entra invitato in futuro.
5. Lasciate la connessione diretta B2B bloccata per impostazione predefinita — la stessa postura iniziale di Microsoft — e abilitatela, per organizzazione, solo per i partner validati tramite configurazione reciproca.
6. Limitate l'accesso in uscita agli utenti e ai gruppi che hanno effettivamente bisogno di collaborare esternamente, invece di lasciare tutti gli utenti interni idonei al B2B in uscita per impostazione predefinita.
7. Eseguite access review mirate specificamente all'appartenenza ai ruoli privilegiati, non solo all'appartenenza ai gruppi — una revisione che controlla solo «chi è nel gruppo Global Admins» non intercetta un guest con un'assegnazione di ruolo diretta al di fuori di qualsiasi gruppo. Rafforzate più in generale le impostazioni predefinite del tenant usando Hardening del tenant Azure: correggere le impostazioni predefinite non sicure come checklist complementare.

Come EtcSec rileva questo problema

L'audit Entra ID di EtcSec controlla direttamente questo livello di governance. Guest User with Administrative Role (GUEST_ADMIN_ROLE) segnala qualsiasi principal guest che detiene un'assegnazione di ruolo di directory. Cross-Tenant Access Open (B2B_CROSS_TENANT_OPEN) e Outbound B2B Access Unrestricted (B2B_OUTBOUND_UNRESTRICTED) verificano la postura predefinita della collaborazione B2B in entrata/uscita rispetto alle eccezioni specifiche per organizzazione. Inbound Trust for All Organizations (B2B_INBOUND_TRUST_ALL) segnala un trust MFA/dispositivo configurato a livello predefinito anziché per singolo partner. B2B Direct Connect Enabled (B2B_DIRECT_CONNECT_ENABLED) conferma che la connessione diretta non è stata aperta oltre la postura bloccata per impostazione predefinita di Microsoft.

Per gli angoli di governance dei guest adiacenti che questo articolo non copre, vedete Account Guest Azure: la superficie di attacco dimenticata per policy di invito, requisiti MFA e pulizia degli account inattivi, e Gruppi privilegiati nidificati in Entra ID, gruppi assegnabili a ruoli e guest nei gruppi di sicurezza per i guest che raggiungono un privilegio tramite nidificazione di gruppi anziché con un'assegnazione diretta. Per la revisione più ampia in cui rientrano questi controlli, vedete Come controllare la sicurezza di Microsoft Entra ID.