Entra ID Convidado Política de Acesso Condicional, Configurações de Colaboração Externa — Os Seis Padrões Que Trabalham Contra Você

A sua Entra ID Convidado Política de Acesso Condicional, Configurações de Colaboração Externa são, na verdade, duas superfícies de controle separadas que a maioria dos tenants configura uma vez, durante a configuração inicial, e nunca revisita. O Acesso Condicional decide se um convidado autenticado é desafiado para MFA, um dispositivo em conformidade ou um método de autenticação mais forte. As Configurações de Colaboração Externa decidem quem pode se tornar convidado em primeiro lugar, o que um convidado pode ver assim que entra, e por quanto tempo essa conta de convidado pode existir. Um tenant pode ter excelente cobertura de MFA para funcionários e ainda assim deixar cada um desses padrões específicos de convidado exatamente onde a Microsoft os distribui — o que, para vários deles, é a opção mais permissiva.

Este artigo percorre seis lacunas específicas nessa superfície de controle de convidados, cada uma associada a um padrão ou mecanismo documentado da Microsoft: nenhuma política de Acesso Condicional realmente avalia logins de convidados, convidados podem convidar outros convidados, convidados podem navegar pelo diretório, contas de convidado nunca expiram, ninguém percebe um convidado que nunca fez login, e convidados podem acessar aplicativos corporativos aos quais nunca foram atribuídos. Nenhuma dessas lacunas exige que um atacante explore uma vulnerabilidade — elas exigem apenas que um administrador tenha aceitado a configuração pronta de fábrica do tenant. Para o panorama completo de como auditar um tenant de ponta a ponta, veja Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático.

Entra ID Convidado Política de Acesso Condicional, Configurações de Colaboração Externa, Definidos

O acesso de convidado no Entra ID começa com um convite — a colaboração B2B cria um objeto de usuário com UserType definido como Guest no seu diretório, respaldado por credenciais no próprio tenant de origem do convidado ou em seu provedor de identidade. A partir desse ponto, dois grupos de configurações independentes regem o que o convidado pode fazer.

As Configurações de Colaboração Externa, em Entra ID > Identidades Externas, controlam as permissões de convite de convidados, a visibilidade do diretório para convidados, o autoatendimento de inscrição e as listas de permissão/bloqueio de domínio. O Acesso Condicional é um mecanismo de políticas separado que avalia cada login, incluindo logins de convidados, contra regras de atribuição que podem direcionar tipos específicos de convidados e usuários externos — usuários convidados de colaboração B2B, usuários membros de colaboração B2B, usuários B2B direct connect, usuários convidados locais, usuários de provedores de serviço e outros usuários externos — cada um dos quais pode ser incluído ou excluído independentemente, para um tenant ou para todos os tenants.

Esses dois sistemas não se comunicam entre si. Um convidado pode ser convidado sob as configurações de colaboração mais permissivas e ainda assim ser bloqueado por uma política de Acesso Condicional rígida, ou ser convidado sob configurações de colaboração rígidas e ainda assim passar livremente por uma política de Acesso Condicional que nunca avalia convidados. Revisar um sem o outro é apenas metade do panorama — veja Contas de Convidado Azure: Riscos do Tenant para o modelo mais amplo de exposição de convidados no qual as seis lacunas deste artigo se encaixam.

Como os Convidados Escapam da Cobertura do Acesso Condicional

GUEST_NO_CA_POLICY [HIGH] dispara quando nenhuma política de Acesso Condicional habilitada inclui explicitamente um tipo de usuário convidado ou externo. A verificação lê a atribuição de usuários incluídos de cada política habilitada, então uma baseline de "Todos os usuários" não conta como cobertura de convidados — exatamente a distinção sobre a qual gira o restante desta seção.

A própria documentação da Microsoft diz que a opção de atribuição Todos os usuários no Acesso Condicional inclui "todos os usuários no diretório, incluindo convidados B2B" — então, em teoria, uma única política de MFA baseline com escopo em Todos os usuários já cobre todo convidado. Na prática, a mesma documentação explica três formas pelas quais essa cobertura desaparece silenciosamente.

Exclusões sobrepõem inclusões, incondicionalmente

A Microsoft afirma claramente: "Quando as organizações incluem e excluem um usuário ou grupo, o usuário ou grupo é excluído da política. A ação de exclusão sobrepõe a ação de inclusão em uma política." Se qualquer grupo de exclusão que contenha convidados for anexado a uma política — por qualquer motivo, a qualquer momento — essa política deixa de protegê-los, silenciosamente, sem aviso no admin center. Uma política que ainda aparece como "Ativada" no admin center enquanto exclui silenciosamente sua população de convidados parece, à primeira vista, idêntica às políticas somente relatório abordadas em Acesso Condicional Modo Somente Relatório, Exclusões Obsoletas: Políticas Que Não Estão Realmente em Vigor — ambas deixam o tenant com uma falsa sensação de cobertura aplicada.

Políticas de risco de usuário não podem ser resolvidas para usuários externos, então a própria orientação da Microsoft é criar uma exclusão

O risco de usuário exige uma redefinição de senha que o tenant de recurso não consegue realizar em uma identidade externa, então a correção documentada pela Microsoft é: "Você pode impedir que políticas baseadas em risco afetem usuários externos criando um grupo no Microsoft Entra ID que contenha todos os usuários externos da sua organização. Em seguida, adicione esse grupo como exclusão para suas políticas de Acesso Condicional baseadas em risco de usuário e risco de login." Observe até onde essa recomendação vai: apenas a política de risco de usuário é irresolvível para uma identidade externa — a Microsoft é igualmente explícita ao afirmar que "a política de risco de login é aplicada se o usuário convidado externo satisfizer o controle de concessão." Seguir a orientação ao pé da letra, portanto, derruba a cobertura funcional de risco de login junto com a de risco de usuário, que é quebrada. Esse grupo de "todos os usuários externos", uma vez que existe por um motivo legítimo, é a alavanca mais fácil de usar na próxima vez que um login de convidado quebrar alguma coisa — e reutilizá-lo contra a baseline de MFA ou de conformidade de dispositivo (não apenas contra a política de risco para a qual foi criado) é como um tenant acaba com zero políticas realmente avaliando logins de convidados, mesmo que "Todos os usuários" tecnicamente os inclua.

Restringir o escopo a funções ou grupos em vez de Todos os usuários

Restringir o escopo de uma política a funções de diretório ou grupos específicos em vez de Todos os usuários exclui estruturalmente os convidados sempre que essas funções ou grupos são preenchidos a partir de dados internos de RH ou de função que os objetos de convidado não carregam.

Para outros modos de falha de cobertura baseline relacionados, mas não específicos de convidados, veja Lacunas de Cobertura da Política Baseline de Acesso Condicional Entra ID: Nenhuma Política para Admins, Todos os Usuários ou Todos os Apps e a revisão mais ampla de exclusões e escopo em Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real.

As Configurações de Colaboração Externa Que Vêm Totalmente Abertas

Duas das seis lacunas estão inteiramente nas Configurações de Colaboração Externa, e ambas têm como padrão a extremidade mais permissiva de uma escala de quatro ou três opções.

GUEST_TO_GUEST_INVITE — convidados podem convidar convidados por padrão

As configurações de convite de convidados têm quatro opções, de "Qualquer pessoa na organização pode convidar usuários convidados, incluindo convidados e não administradores (mais inclusiva)" até "Ninguém na organização pode convidar usuários convidados, incluindo administradores (mais restritiva)." A documentação da Microsoft é explícita sobre qual delas um tenant usa por padrão: "Por padrão, todos os usuários da sua organização, incluindo usuários convidados de colaboração B2B, podem convidar usuários externos para a colaboração B2B." Essa é a opção mais inclusiva da lista. A menos que um administrador a tenha restringido manualmente, todo convidado que você já convidou sempre teve permissão permanente para convidar mais convidados para o seu tenant — sem aprovação, sem notificação a você, sem registro além da entrada de log de auditoria do próprio convite. Fortalecimento do Tenant Azure: Security Defaults aborda isso junto com os outros padrões de colaboração que os tenants deixam intocados.

GUEST_DIRECTORY_VISIBILITY — o padrão não é a opção restritiva

O acesso de usuário convidado tem três níveis: mesmo acesso que membros, acesso limitado, ou restrito apenas ao próprio perfil. A Microsoft marca a opção intermediária como padrão: "Usuários convidados têm acesso limitado a propriedades e associações de objetos de diretório: (Padrão) Esta configuração bloqueia os convidados de certas tarefas de diretório, como enumerar usuários, grupos ou outros recursos de diretório. Os convidados podem ver a associação de todos os grupos não ocultos." O comportamento pronto de fábrica permite que qualquer convidado enumere a associação de todo grupo não oculto no seu diretório — incluindo, se você não tiver bloqueado isso separadamente, grupos com associação atribuível a função ou privilegiada; veja Entra ID: Grupos Privilegiados Aninhados, Atribuíveis a Funções e Convidados em Grupos de Segurança para o que um convidado pode aprender apenas com essa visibilidade.

Ambas as configurações estão na mesma página do admin center (Identidades Externas > Configurações de colaboração externa). A Microsoft documenta um atraso de propagação especificamente para o nível de acesso de convidado: depois de salvar a configuração restrita, "as alterações podem levar até 15 minutos para entrar em vigor para os usuários convidados."

Convidados Que Ninguém Está Governando

GUEST_NO_EXPIRATION_POLICY — um convidado convidado diretamente não tem nenhuma expiração anexada

Um convidado convidado diretamente por e-mail, fora do gerenciamento de direitos (entitlement management), é o que a própria terminologia da Microsoft chama de ungoverned (não governado). A documentação de gerenciamento de direitos da Microsoft traça a linha com precisão: convidados que solicitam acesso por meio de um pacote de acesso podem ser convertidos para governed (governado), o que significa que "sua conta será excluída ou desabilitada em um número especificado de dias após a expiração de sua última atribuição de pacote de acesso." Mas "usuários convidados que já existiam no seu tenant por terem sido convidados são ungoverned", e uma vez que um convidado ungoverned perde sua última atribuição de pacote de acesso, "eles permanecerão no tenant indefinidamente." Um convidado convidado diretamente que nunca foi anexado a um pacote de acesso não tem absolutamente nenhum mecanismo de expiração — nem um padrão longo, nem um curto, nenhum. Ele persiste até que um humano o perceba e o remova manualmente, ou até que um administrador construa retroativamente um processo de ciclo de vida para capturá-lo.

GUEST_NEVER_SIGNED_IN — invisível para uma revisão de acesso padrão até ultrapassar a janela de inatividade

O relatório de convidados inativos do Entra ID (ID Governance > Painel > Governança de acesso de convidados) é a ferramenta criada para capturar isso, e trata os convidados que nunca fizeram login como sua própria categoria: o relatório separa explicitamente "convidados que nunca fizeram login ou que fizeram login pelo menos uma vez", e para o grupo que nunca fez login, "os dias de inatividade são calculados com base na data de criação" em vez da última data de login, já que não existe uma. O limite de inatividade padrão é de 90 dias. Dois detalhes importam operacionalmente: esse relatório exige uma licença Entra ID Governance ou Entra Suite, então tenants sem essa licença não conseguem sequer abri-lo, e as revisões de acesso criadas para remover convidados inativos deliberadamente ignoram qualquer convidado criado mais recentemente do que a janela de inatividade configurada — "isso garante que os convidados possam fazer login uma vez antes de serem removidos" — então um convidado recém-criado, que nunca fez login, fica invisível para a limpeza durante toda a duração dessa janela.

Acesso a Aplicativos Aos Quais Convidados Nunca Foram Atribuídos

GUEST_APP_ACCESS_UNRESTRICTED [MEDIUM] — a Microsoft declara o padrão claramente, em sua orientação sobre como restringir um aplicativo a um conjunto de usuários: "Aplicativos registrados em um tenant do Microsoft Entra estão, por padrão, disponíveis para todos os usuários do tenant que se autenticam com sucesso." O controle que muda isso é Exigir atribuição de usuário, e ele é opt-in por aplicativo, não ativado por padrão. Assim que um convidado é convidado — para um projeto, um documento compartilhado, uma reunião —, ele se torna "um usuário do tenant" para qualquer outro aplicativo que não tenha ativado a atribuição, quer isso tenha sido intencional ou não.

Por que essa lacuna sobrevive a uma revisão de portal

A lacuna é fácil de passar despercebida em uma revisão de portal por causa de como ela falha: "Quando a atribuição de usuário não é exigida, os usuários não atribuídos não veem o aplicativo em seus Meus Aplicativos, mas ainda podem fazer login no próprio aplicativo (também conhecido como login iniciado pelo SP) ou podem usar a URL de Acesso do Usuário." Um aplicativo que parece bloqueado — porque nenhum convidado aparece em sua lista de usuários atribuídos, e nenhum convidado o vê em sua página Meus Aplicativos — ainda pode estar acessível a qualquer convidado que tenha o link direto de login, que muitas vezes é apenas a URL normal de login do aplicativo. Status de atribuição e visibilidade não são a mesma coisa, e apenas a atribuição realmente controla o acesso.

Convidados com funções de diretório elevadas agravam especificamente essa lacuna; veja Função Admin Convidado Entra Cross-Tenant B2B Trust: Como Usuários Externos Chegam a Administrador Global para o que acontece quando um convidado subatribuído também acaba detendo permissões administrativas.

Detecção

Nenhuma dessas seis lacunas aparece como uma assinatura de ataque — são estados de configuração que você precisa consultar diretamente.

Restringindo uma revisão à sua população de convidados

Para restringir uma revisão de acesso apenas à sua população externa, a regra de grupo dinâmico que a Microsoft fornece como exemplo é:

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

Troque o filtro de domínio pelo seu próprio, ou remova-o para capturar todos os tipos de convidado.

Remediação (Remediation)

1. Restringir convites de convidados

Nas configurações de colaboração externa, afaste-se do padrão "Qualquer pessoa... incluindo convidados". Se um punhado de pessoas realmente precisa de direitos de convite sem uma função administrativa completa, atribua a elas a função Guest Inviter em vez de deixar os convites abertos para todos:

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

Uma pegadinha antes de executar: Get-MgDirectoryRole "retorna apenas funções que foram ativadas", e "nem todas as funções integradas são ativadas inicialmente." Em um tenant onde Guest Inviter nunca foi atribuída pelo admin center, $role retorna vazio e a última linha falha. Atribua a função uma vez no portal — o que a ativa implicitamente — ou ative-a primeiro com a API Activate directoryRole.

2. Reforçar a visibilidade do diretório para convidados

Mude para "restrito a propriedades e associações de seus próprios objetos de diretório", a menos que um cenário de colaboração específico realmente exija que os convidados naveguem pela associação de grupos.

3. Dê aos convidados uma política de Acesso Condicional dedicada e habilitada

Direcione explicitamente "usuários convidados ou externos" (todos os subtipos que você usa), exigindo no mínimo MFA — não confie apenas em uma baseline de "Todos os usuários". Depois, audite a lista de exclusão de cada política habilitada existente em busca de um grupo "usuários convidados ou externos" ou "todos os usuários externos", e confirme que cada um é intencional e ainda necessário — não uma exclusão de política de risco que vazou para a sua baseline de MFA.

4. Converter convidados em pacotes de acesso governados

Faça isso sempre que um convidado corresponder a um projeto ou engajamento definido, para que a política de ciclo de vida realmente anexe uma expiração. Para convidados que nunca passarão pelo gerenciamento de direitos, construa uma revisão de acesso recorrente contra o grupo dinâmico de convidados acima, com um limite de inatividade e uma decisão de "bloquear, depois remover" aplicada automaticamente.

5. Ativar o relatório de convidados inativos

Isso exige licenciamento Entra ID Governance / Entra Suite. Revise a categoria de nunca fez login em um cronograma — essas contas ficam invisíveis para uma revisão de acesso padrão até ultrapassarem sua janela de inatividade.

6. Exigir atribuição em aplicativos corporativos

Defina "Atribuição exigida" como Sim em todo aplicativo corporativo que não deva estar aberto para o tenant inteiro, e então atribua explicitamente os usuários ou grupos — não convidados por padrão — que precisam dele. Reverifique aplicativos adicionados fora do seu processo padrão de onboarding; aplicativos SAML SSO, aplicativos Application Proxy que usam pré-autenticação do Microsoft Entra, e aplicativos OAuth 2.0/OpenID Connect aos quais um usuário ou administrador deu consentimento, todos suportam esse controle.

Como o EtcSec Detecta Isso

O EtcSec verifica cada auditoria Azure/Entra em relação a todos esses seis achados: GUEST_NO_CA_POLICY, GUEST_TO_GUEST_INVITE, GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, GUEST_NEVER_SIGNED_IN e GUEST_APP_ACCESS_UNRESTRICTED. Eles não funcionam todos da mesma forma, e essa diferença importa quando você está decidindo o que um resultado limpo realmente prova.

Três são avaliados em relação ao estado real do seu tenant, então seu resultado muda quando você corrige a configuração subjacente. GUEST_NO_CA_POLICY lê a atribuição de usuários incluídos de cada política de Acesso Condicional habilitada. GUEST_TO_GUEST_INVITE lê a política de convite de convidados do tenant. GUEST_NEVER_SIGNED_IN enumera contas de convidado sem login interativo nem não interativo e reporta a contagem. Esses três são os que dizem se a correção do trimestre passado ainda está em vigor depois que o próximo administrador mexer nas Configurações de Colaboração Externa ou no Acesso Condicional.

Os outros três — GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY e GUEST_APP_ACCESS_UNRESTRICTED — são levantados como avisos em nível de tenant em toda auditoria Azure, em vez de serem alternados por uma única flag do tenant. Leia-os como um lembrete permanente para reverificar esse controle no portal, não como evidência de que ele está atualmente mal configurado.

Referências Primárias

• Configurar as configurações de colaboração externa
• Acesso Condicional: usuários, grupos, agentes e identidades de carga de trabalho
• Autenticação e Acesso Condicional para usuários B2B
• Converter o ciclo de vida do usuário convidado no gerenciamento de direitos
• Monitorar e limpar contas de convidado obsoletas
• Gerenciar o acesso a aplicativos
• Restringir um aplicativo do Microsoft Entra a um conjunto de usuários
• Restringir as permissões de acesso do usuário convidado
• Listar directoryRoles (Microsoft Graph)
• Personalizar e filtrar logs de atividade no Microsoft Entra ID