Função Admin Convidado Entra Cross-Tenant B2B Trust: Como Usuários Externos Chegam a Administrador Global

Função de Admin Convidado no Entra e Confiança B2B Cross-Tenant: O que Essas Configurações Realmente Controlam

A função de admin convidado no Entra e a confiança B2B cross-tenant estão entre as camadas menos revisadas da governança de identidades externas do Microsoft Entra ID, e a combinação das duas forma um dos caminhos de escalação de privilégio mais silenciosos da plataforma: uma conta de convidado externa com uma função de diretório atribuída diretamente, protegida por configurações de acesso cross-tenant que permitem, por padrão, que outras organizações Microsoft Entra alcancem seu tenant. Nenhuma das duas metades é exótica isoladamente — colaboração B2B e atribuição de funções de diretório são recursos centrais e documentados do Entra — mas a combinação raramente é auditada como um único controle.

Este é um ângulo diferente de duas lacunas relacionadas que vale conhecer primeiro. Se sua preocupação é quem pode convidar convidados, se eles precisam de MFA, ou se contas obsoletas se acumulam, veja Contas de Convidado Azure: Riscos do Tenant. Se sua preocupação é um convidado herdando privilégio ao cair em um grupo de segurança aninhado em um grupo atribuível a funções, veja Entra ID: Grupos Privilegiados Aninhados, Atribuíveis a Funções e Convidados em Grupos de Segurança. Este artigo cobre algo anterior a ambos: um convidado com uma função do Microsoft Entra atribuída diretamente — sem grupo, sem aninhamento — e a configuração de confiança B2B em nível de tenant que decide quais organizações externas conseguem sequer alcançar a identidade de origem desse convidado.

Cinco verificações compõem esta camada de governança:

Como um Convidado Acaba com uma Função de Diretório, e Como as Configurações de Confiança Ampliam a Porta

Atribuir uma função a um convidado não é um caso especial no RBAC do Entra

O modelo de atribuição de funções do Microsoft Entra não trata um principal do tipo convidado de forma diferente de um principal do tipo membro quando o assunto é manter uma função de diretório. O mesmo workflow de atribuição de função — New-MgRoleManagementDirectoryRoleAssignment no PowerShell, ou POST /roleManagement/directory/roleAssignments no Microsoft Graph — que atribui Helpdesk Administrator a um funcionário interno atribui Global Administrator a um objeto de convidado externo com a mesma facilidade. A própria documentação da API da Microsoft para listar atribuições de função mostra isso explicitamente: seu exemplo de expansão do principal em uma resposta de atribuição de função inclui usuários convidados ("userType": "Guest") com uma função de diretório lado a lado com usuários membros, sem qualquer tratamento especial.

Isso importa porque as permissões de diretório padrão de um convidado são propositalmente restritas. O nível de permissão de convidado do Microsoft Entra (a configuração authorizationPolicy.guestUserRoleId) é, por padrão, Acesso limitado (GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3), e pode ser reforçado para Acesso restrito (2af84b1e-32c8-42b7-82bc-daa82404023b), o que impede um convidado de sequer enumerar a associação a grupos além da sua própria. Mas essa configuração rege a visibilidade padrão de objetos de diretório para todo convidado — não é um teto para o que uma atribuição de função explícita pode conceder a um único convidado. Um convidado com Global Administrator atribuído tem permissões administrativas completas do tenant, independentemente de quão restritivo seja o nível de permissão padrão dos convidados. A própria orientação de segurança Zero Trust da Microsoft lista Convidados não recebem funções de diretório de alto privilégio como uma recomendação nomeada, alertando que uma conta de convidado comprometida com uma função elevada dá aos atacantes um caminho para escalar privilégios, criar contas backdoor e persistir no tenant — e ferramentas de postura de terceiros rastreiam isso como um achado próprio: o catálogo de exposição da Tenable lista explicitamente "Guest Account With a Privileged Role", citando auditabilidade reduzida e uma postura de segurança mais fraca no tenant de origem como o risco central.

As configurações de acesso cross-tenant decidem quais identidades externas conseguem sequer alcançar essa atribuição

Uma atribuição de função de diretório a um convidado só é tão contida quanto a identidade externa por trás dela. As Configurações de Acesso Cross-Tenant do Microsoft Entra controlam isso a partir da outra direção — são regras padrão em nível de tenant que se aplicam a toda outra organização Microsoft Entra, a menos que você configure exceções específicas por organização. Segundo os padrões iniciais documentados pela Microsoft:

• Colaboração B2B (b2bCollaborationInbound / b2bCollaborationOutbound): todos os seus usuários internos estão habilitados para colaboração B2B por padrão — eles podem convidar convidados externos, e ser convidados em outro lugar como convidados, sem que uma lista de permissões por organização seja exigida.
• Confiança inbound (inboundTrust): claims de MFA e dispositivo (dispositivo compatível, Microsoft Entra hybrid join) de organizações externas não são confiáveis por padrão. Se um admin habilitar depois "Confiar em autenticação multifator de tenants Microsoft Entra" no escopo padrão em vez de por parceiro, o claim de MFA de toda organização Microsoft Entra externa passa a ser aceito — o Conditional Access para de reverificar MFA para qualquer convidado, de qualquer tenant, incluindo aqueles dos quais você nunca ouviu falar. Isso é o B2B_INBOUND_TRUST_ALL.
• B2B direct connect (b2bDirectConnectInbound / b2bDirectConnectOutbound): bloqueado em ambas as direções, em todo o tenant, por padrão — a Microsoft documenta esta como a única configuração desta família que já vem fechada: "o B2B direct connect outbound está bloqueado para todo o seu tenant, e o B2B direct connect inbound está bloqueado para todas as organizações Microsoft Entra externas." O B2B_DIRECT_CONNECT_ENABLED dispara quando uma mudança no escopo padrão — não uma intencional por parceiro — o abre.
• Acesso outbound: também aberto por padrão — seus usuários podem ser convidados para os recursos de qualquer organização Microsoft Entra externa, a menos que o acesso outbound seja limitado. O B2B_OUTBOUND_UNRESTRICTED sinaliza exatamente esse padrão outbound sem escopo.

Tanto as listas de permissão/bloqueio quanto as configurações de acesso cross-tenant são verificadas no momento do convite, mas se um domínio externo não está em nenhuma das listas, o Microsoft Entra recorre ao que estiver configurado como padrão de acesso cross-tenant — que, pronto para uso, é aberto para colaboração.

A Cadeia de Escalação

Passo 1 — Uma organização externa convida, ou é convidada, sem restrição específica por organização

Como as configurações padrão de colaboração B2B permitem acesso inbound e outbound para toda organização Microsoft Entra externa, uma conta de convidado de praticamente qualquer tenant pode ser convidada para o seu — ou uma conta de funcionário comprometida pode convidar uma — sem passar por uma verificação de lista de permissões.

Passo 2 — As configurações de confiança inbound suprimem um novo desafio de MFA

Se a confiança inbound estiver configurada para aceitar claims de MFA de organizações externas no escopo padrão, o Microsoft Entra verifica o token do convidado em busca de um claim de MFA já satisfeito em seu tenant de origem — um tenant que você não controla e não consegue auditar. Nenhum novo desafio é emitido no seu tenant se esse claim estiver presente, independentemente de quão fraca ou forte seja de fato a exigência de MFA do tenant de origem.

Passo 3 — O objeto convidado recebe uma função de diretório atribuída diretamente

Em algum ponto da história do tenant — um engajamento pontual com um fornecedor, um workaround de break-glass, um admin usando "atribuir Global Admin temporariamente ao convidado" como atalho que nunca foi revertido — o ID do objeto do convidado foi passado para uma chamada de atribuição de função. Nada no RBAC do Entra ID bloqueia isso no nível da API, e a menos que alguém esteja consultando especificamente a associação a funções para principals do tipo convidado, isso não aparece em uma revisão rotineira de "quem são nossos admins" que lista nomes visualmente.

Passo 4 — A sessão privilegiada persiste através do tenant de origem do convidado

Como a autenticação para esse convidado ainda acontece no seu tenant de origem, suas políticas de Conditional Access, detecções de risco de sign-in e a aplicação de senha/MFA no seu tenant só veem o que as configurações de confiança deixam passar. Um comprometimento das credenciais do tenant de origem do convidado se torna, transitivamente, um comprometimento de uma identidade privilegiada no seu.

Detecção

# Microsoft Graph — postura padrão atual de acesso cross-tenant
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default

# Microsoft Graph — toda exceção específica por parceiro
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Microsoft Graph — todas as atribuições de função de diretório com principal expandido;
# filtrar a resposta no lado cliente para principal.userType eq 'Guest'
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal

// Logs de auditoria do Microsoft Entra — atribuições de função caindo sobre um UPN de convidado
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)

// Logs de auditoria do Microsoft Entra — mudanças na configuração padrão de acesso cross-tenant
AuditLogs
| where Category == "CrossTenantAccessSettings"
| where OperationName has "default"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)

Remediação

1. Inventarie toda atribuição de função de diretório mantida por um convidado, e decida para cada uma: isso precisa de acesso permanente, precisa de alguma função, ou nunca foi revertida após um engajamento de curto prazo. Trate "não sabemos por que este convidado tem essa função" como um incidente, não como uma nota de configuração.
2. Migre qualquer acesso privilegiado legítimo de convidado para o PIM como atribuição elegível e limitada no tempo, com aprovação exigida, em vez de uma atribuição direta permanente. Veja Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM para entender por que o acesso privilegiado permanente já é um achado comum mesmo em contas de membros, e Recursos do Azure AD Premium P2: PIM, Identity Protection e Access Reviews que Ninguem Ativou para o que o PIM exige para ser habilitado.
3. Configure o acesso padrão inbound e outbound de colaboração B2B como Bloquear, e adicione configurações específicas por organização apenas para os tenants externos com os quais você realmente colabora. A própria orientação da Microsoft é identificar primeiro os sign-ins inbound/outbound, para que uma mudança de padrão para bloqueio não corte o acesso de negócio ativo.
4. Tire a confiança de MFA e dispositivo inbound do escopo padrão. Se você precisa confiar em MFA de um parceiro específico, configure isso como uma exceção específica por organização apenas para esse parceiro — não como um padrão genérico aplicado a todo tenant Microsoft Entra que já foi convidado.
5. Deixe o B2B direct connect bloqueado por padrão — a postura inicial da própria Microsoft — e só habilite, por organização, para parceiros que você validou por meio de configuração mútua.
6. Reduza o escopo do acesso outbound aos usuários e grupos que realmente precisam colaborar externamente, em vez de deixar todos os usuários internos elegíveis para B2B outbound por padrão.
7. Execute access reviews com escopo específico para associação a funções privilegiadas, não apenas associação a grupos — uma revisão que só verifica "quem está no grupo de Global Admins" perde um convidado com uma atribuição de função direta fora de qualquer grupo. Reforce as configurações padrão do tenant de forma mais ampla usando Fortalecimento do Tenant Azure: Security Defaults como checklist complementar.

Como o EtcSec Detecta Isso

A auditoria de Entra ID do EtcSec verifica esta camada de governança diretamente. Usuário Convidado com Função Administrativa (GUEST_ADMIN_ROLE) sinaliza qualquer principal do tipo convidado com uma atribuição de função de diretório. Acesso Cross-Tenant Aberto (B2B_CROSS_TENANT_OPEN) e Acesso B2B Outbound Irrestrito (B2B_OUTBOUND_UNRESTRICTED) verificam a postura padrão inbound/outbound de colaboração B2B contra exceções específicas por organização. Confiança Inbound para Todas as Organizações (B2B_INBOUND_TRUST_ALL) sinaliza confiança de MFA/dispositivo configurada no escopo padrão em vez de por parceiro. B2B Direct Connect Habilitado (B2B_DIRECT_CONNECT_ENABLED) confirma que o direct connect não foi aberto além da postura bloqueada por padrão da Microsoft.

Para os ângulos adjacentes de governança de convidados que este artigo não cobre, veja Contas de Convidado Azure: Riscos do Tenant para política de convite, exigências de MFA e limpeza de contas obsoletas, e Entra ID: Grupos Privilegiados Aninhados, Atribuíveis a Funções e Convidados em Grupos de Segurança para convidados que alcançam privilégio via aninhamento de grupos em vez de uma atribuição direta. Para a revisão mais ampla em que essas verificações se encaixam, veja Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático.