Contas de Convidado Azure: Riscos do Tenant

O Que São Contas de Convidado do Azure?

Contas de Convidado Azure (contas de convidado do Azure Entra ID, B2B collaboration) permitem que usuários externos - parceiros, contratados, fornecedores, auditores - acessem seus recursos do Microsoft 365 sem ter uma conta no seu tenant. As contas de convidado se autenticam no tenant de origem, mas recebem acesso aos seus recursos com base nas permissões que você atribui.

Contas de convidado são um recurso legítimo e amplamente usado. O problema é a governança. As organizações convidam usuários externos para projetos de curto prazo e nunca os removem. As configurações de convite são deixadas no padrão, o que permite que qualquer usuário do tenant - incluindo convidados existentes - convide quem quiser. O MFA não é exigido para convidados. O resultado é uma população crescente de identidades externas com níveis variados de acesso - muitas esquecidas, algumas pertencentes a pessoas que deixaram a organização há anos.

Como Funciona

Contas de convidado diferem de contas de membro em dois aspectos principais:

1. A autenticação acontece no tenant de origem do convidado - você não controla as políticas de MFA, os requisitos de senha nem a postura de segurança dessa organização. Ainda assim, você pode forçar sua própria MFA: por padrão, as configurações de acesso entre tenants não confiam em declarações de MFA ou de dispositivo vindas de outras organizações Microsoft Entra, então sua política de Acesso Condicional continua se aplicando a esses usuários. O que você não consegue fazer é herdar qualquer garantia da forma como o tenant de origem autenticou o usuário.
2. A governança de ciclo de vida é opt-in - o Entra ID tem um mecanismo nativo que remove convidados automaticamente (Access Reviews com Aplicar resultados automaticamente ao recurso e Bloquear login por 30 dias e depois remover o usuário do tenant como ação sobre convidados negados), mas ele fica desativado por padrão e exige uma assinatura Microsoft Entra ID Governance ou Entra ID P2. Um tenant que nunca o ativa não tem nenhum offboarding automático.

Os direitos de convite são abertos por padrão. O comportamento documentado pela Microsoft é que "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" - ou seja, não são apenas os seus membros: um convidado existente pode convidar o próximo, sem qualquer supervisão ou aprovação de TI. Em organizações com colaboração B2B ativa, é comum encontrar centenas de contas de convidado, das quais uma parcela significativa não teve atividade no último ano.

A Cadeia de Ataque

Etapa 1 - Enumerar Contas de Convidado

# signInActivity exige AuditLog.Read.All E uma licenca Entra ID P1/P2.
# Directory.Read.All sozinho retorna os convidados, mas nao os dados de login.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"

# Listar todas as contas de convidado com data do ultimo login.
# -All e obrigatorio: sem ele, apenas a primeira pagina retorna (max. 500
# quando signInActivity e selecionado), e o restante dos convidados e ignorado silenciosamente.
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity,createdDateTime" |
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N="UltimoLogin";E={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object UltimoLogin

# Encontrar convidados inativos ha 180+ dias.
# signInActivity NAO e retornado por padrao: sem -Property, todo convidado
# parece nunca ter feito login, e este filtro captura todos eles.
$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 }

Etapa 2 - Explorar Configurações de Convite Irrestritas

Se os direitos de convite de convidados não forem restritos, qualquer conta de membro comprometida pode convidar identidades externas controladas pelo atacante para obter acesso persistente:

# Usando uma conta de membro comprometida para convidar uma identidade externa controlada pelo atacante
# Permissao delegada de menor privilegio: User.Invite.All
New-MgInvitation `
  -InvitedUserEmailAddress "[email protected]" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage $false

Etapa 3 - Acessar Recursos Sem MFA

Se os convidados não estiverem sujeitos a uma política de Acesso Condicional que exija MFA, uma conta de convidado comprometida oferece acesso direto a todos os recursos compartilhados sem verificação adicional - arquivos do SharePoint, canais do Teams, conteúdo do OneDrive. O pior cenário é um convidado que também possui uma função de diretório do Entra: uma confiança B2B entre tenants totalmente aberta se torna então um caminho até Administrador Global - veja Função Admin Convidado Entra Cross-Tenant B2B Trust: Como Usuários Externos Chegam a Administrador Global.

Etapa 4 - Movimento Lateral via Recursos Compartilhados

Contas de convidado costumam ter acesso a conteúdo compartilhado sensível que pode ser exfiltrado diretamente. Documentos de projeto, contratos, dados de clientes - tudo visível para convidados com as permissões adequadas. A associação a grupos é o caminho mais grave: um convidado adicionado a um grupo atribuível a funções ou a um grupo privilegiado aninhado herda muito mais do que acesso a arquivos, como descrito em Entra ID: Grupos Privilegiados Aninhados, Atribuíveis a Funções e Convidados em Grupos de Segurança.

Etapa 5 - Persistir via Contas Esquecidas

Contas de convidado obsoletas persistem indefinidamente. Um atacante que compromete uma conta de convidado esquecida obtém acesso persistente e de baixa visibilidade, raramente revisado ou revogado.

Detecção

Eventos do Log de Auditoria do Entra ID

Estes são os nomes de atividade como aparecem no log de auditoria do Microsoft Entra. Os logins de convidados não são eventos de auditoria - eles ficam nos logs de sign-in, uma fonte separada.

Consultas de Detecção para SIEM (Elastic)

Os nomes de campo abaixo seguem a integração Elastic Azure Logs.

Convites de convidados (KQL):

azure.auditlogs.operation_name: "Invite external user"

O evento de auditoria registra quem convidou (initiated_by), não as funções de diretório dessa pessoa - a integração expõe apenas initiated_by.user.id, .displayName, .ipAddress e .userPrincipalName, nada além disso. "Convites de contas não administrativas" precisa, portanto, ser resolvido comparando o UPN de quem convidou com os atuais detentores de funções administrativas, e não com um único filtro sobre um campo roles.

Contas de convidado acessando portais de administração (KQL):

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

Convites de convidados em massa (>5 em 1 hora) - ES|QL: o KQL apenas filtra; ele não tem papel algum em agregar, transformar ou ordenar dados, então uma regra de burst não pode ser escrita em KQL. Use 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

Remediação

1. Restringir Direitos de Convite

Entra ID > Identidades Externas > Configurações de colaboração externa:
Configurações de convite de convidado: "Somente usuários com funções de administrador específicas podem convidar"

Com essa configuração, apenas quem tem a função Administrador de Usuários ou Convidador de Convidados pode enviar convites, o que cria uma trilha de auditoria e evita o abuso de convites. Observe o que essa configuração não faz: ela restringe quem pode convidar, mas não adiciona um fluxo de aprovação. Se você precisa de aprovações, coloque o acesso de convidados atrás de pacotes de acesso do entitlement management com aprovadores nomeados.

2. Exigir MFA para Usuários Convidados

Política de Acesso Condicional:
Nome: Exigir MFA - Usuários Convidados
Usuários > Incluir > Selecionar usuários e grupos > Usuários convidados ou externos:
  selecione todos os tipos aplicáveis (usuários convidados de colaboração B2B,
  usuários membros de colaboração B2B, usuários de conexão direta B2B,
  usuários convidados locais, usuários de provedores de serviço, outros usuários externos)
Recursos de destino > Incluir: Todos os recursos (antes chamado de "Todos os aplicativos de nuvem")
Controles de acesso > Conceder: Exigir autenticação multifator
Habilitar política: Ativado

Não existe uma única caixa de seleção "Todos os convidados e usuários externos" - você escolhe os tipos de usuário externo que quer cobrir. Como as configurações de confiança entre tenants não confiam por padrão no MFA do tenant de origem, os convidados atendem a essa política realizando MFA contra o seu tenant.

3. Remover Contas de Convidado Obsoletas

# Excluir um usuario exige um escopo de escrita - User.DeleteRestore.All e
# o menos privilegiado. AuditLog.Read.All e o que torna signInActivity legivel.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","User.DeleteRestore.All"

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

# -All e -Property nao sao opcionais aqui. Sem -Property os dados de login
# ficam ausentes, todo convidado passa no teste $null, e este script exclui
# toda a populacao de convidados.
$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 "Encontradas $($staleGuests.Count) contas de convidado obsoletas"

# Exporte e revise a lista antes de excluir qualquer coisa, depois remova -WhatIf.
$staleGuests | Select-Object DisplayName, UserPrincipalName,
  @{N="UltimoLogin";E={$_.SignInActivity.LastSignInDateTime}} |
  Export-Csv .\convidados-obsoletos.csv -NoTypeInformation

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

Um convidado excluído dessa forma permanece recuperável por 30 dias antes de o Microsoft Entra ID removê-lo permanentemente.

4. Configurar Access Reviews Trimestrais

Entra ID > ID Governance > Access reviews:
Criar revisões trimestrais recorrentes para todas as contas de convidado
Revisores: Proprietários de recursos ou de grupos
Aplicar resultados automaticamente ao recurso: Habilitar
Se os revisores não responderem: Remover acesso
Ação a aplicar sobre convidados negados:
  Bloquear login por 30 dias e depois remover o usuário do tenant

As duas últimas linhas são o que transforma uma revisão em um offboarding real: remover apenas o acesso deixa o objeto do convidado no tenant. A ação de excluir a conta B2B está disponível quando a revisão tem como alvo times e grupos selecionados - ela não é oferecida na revisão "Todos os grupos do Microsoft 365 com usuários convidados". Licenciamento: as access reviews exigem uma assinatura Microsoft Entra ID Governance ou Microsoft Entra Suite; algumas capacidades funcionam com Entra ID P2.

5. Implementar Níveis de Acesso para Convidados

Use o entitlement management do Entra ID para automatizar o ciclo de vida do convidado com datas de expiração automáticas. Assim como as access reviews, esse é um recurso do Microsoft Entra ID Governance, licenciado separadamente do Entra ID P1.

Como o EtcSec Detecta Isso

O EtcSec audita a governança de contas de convidado em cada varredura do Azure, identificando riscos de proliferação e acesso descontrolado.

GUEST_INVITATION_UNRESTRICTED sinaliza tenants cuja política de convite de convidados ainda está aberta para todos - o padrão - em vez de restrita a um conjunto controlado de quem pode convidar. Essa é a causa raiz da proliferação descontrolada de convidados.

GUEST_NO_MFA_REQUIRED sinaliza tenants em que os usuários convidados não estão sujeitos a uma política de Acesso Condicional que exija MFA, deixando identidades externas com autenticação mais fraca que a dos usuários internos.

GUEST_STALE_90_DAYS lista contas de convidado habilitadas cujo último login registrado tem mais de 90 dias, fornecendo uma lista priorizada para revisão de acesso e limpeza. Convidados que nunca fizeram login são um caso diferente e são reportados separadamente por GUEST_NEVER_SIGNED_IN.

Perguntas Frequentes

As contas de convidado do Azure são um risco de segurança por padrão? As contas de convidado em si não são inerentemente arriscadas, mas uma governança fraca cria risco significativo. Os principais problemas são: nenhuma exigência de MFA para convidados, direitos de convite irrestritos e contas obsoletas que nunca são removidas. Um programa de convidados bem governado tem baixo risco; um programa não gerenciado se torna uma grande superfície de ataque.

Com que frequência devo revisar contas de convidado? A Microsoft não publica uma cadência única obrigatória: as Access Reviews do Entra ID podem ser agendadas semanal, mensal, trimestral ou anualmente, e o intervalo certo depende de quão sensíveis são os recursos compartilhados. Trimestral é a linha de base da EtcSec. As Access Reviews podem automatizar o resultado com remoção automática em caso de não resposta, o que mantém o processo gerenciável mesmo em tenants grandes; isso exige uma assinatura Entra ID Governance ou Entra ID P2.

Uma conta de convidado pode ser usada para se mover lateralmente dentro da organização? Sim. Um convidado com acesso ao Teams pode ver todas as mensagens e arquivos nesses canais. Se o convidado também tiver acesso ao SharePoint, ele pode ler e potencialmente exfiltrar documentos. O dano é limitado pelas permissões do convidado, mas convidados obsoletos com privilégios excessivos são extremamente comuns na prática.

Prioridades de Revisão

Contas de Convidado Azure: A Superfície de Ataque Esquecida do Seu Tenant deve ser tratada como uma exposição real dentro do seu tenant Entra ID e Azure, e não como uma configuração isolada. Comece definindo o perímetro de revisão: quais admins, convidados, service principals, app registrations, exceções de política e contas break-glass estão envolvidos, quais fluxos de negócio dependem deles, quais privilégios ficam expostos e quais exceções de emergência se acumularam com o tempo. Essa etapa de escopo evita uma remediação superficial, porque o sintoma técnico costuma ser menor que o raio de impacto operacional. Ao documentar o caminho completo entre configuração e privilégio, o time consegue priorizar mudanças que reduzem risco rapidamente sem quebrar o acesso de produção. Isso também cria uma linha de base defensável para validações futuras e dá à liderança uma explicação clara de por que o problema importa agora.

Controles Adjacentes a Revisar

Quando atacantes chegam ao seu tenant Entra ID e Azure, raramente param no primeiro ponto fraco. Em torno de Contas de Convidado Azure: A Superfície de Ataque Esquecida do Seu Tenant, eles normalmente testam se o caminho exposto pode ser encadeado com autenticação legada, governança fraca de convidados, consentimento amplo de apps, contas de emergência obsoletas e funções nunca revisadas. Isso significa que os defensores devem revisar não apenas a fraqueza principal, mas cada dependência vizinha que pode transformar acesso em persistência ou escalada de privilégio. Confirme quais identidades, funções, permissões e suposições de confiança podem ser reutilizadas por um atacante motivado. Se uma correção fecha apenas um objeto enquanto caminhos de privilégio adjacentes permanecem abertos, o risco efetivo muda pouco. Uma revisão disciplinada das possibilidades de encadeamento é o que transforma este tema de artigo em um exercício prático de hardening.

Evidências e Telemetria a Coletar

Uma resposta sólida para Contas de Convidado Azure: A Superfície de Ataque Esquecida do Seu Tenant precisa de evidências que possam ser revisadas tanto por engenharia quanto por detecção. Colete logs de sign-in, logs de auditoria, mudanças de atribuição de função, eventos de consentimento, mudanças de credenciais de aplicativos e sinais de login arriscado, compare mudanças recentes com janelas de manutenção conhecidas e isole contas ou sistemas cujo comportamento mudou sem uma justificativa de negócio clara. Use essas evidências para responder a três perguntas: quando o caminho arriscado apareceu, quem ainda pode usá-lo e se existe exposição semelhante em outro lugar do seu tenant Entra ID e Azure. Uma boa revisão de telemetria também ajuda a separar dívida técnica herdada de abuso ativo. Essa distinção importa, porque o plano de remediação para uma configuração incorreta antiga é diferente do plano para um caminho que já mostra atividade semelhante à de um atacante ou exceções de política repetidas.

Contas de Convidado Azure: Validação Antes do Fechamento

Uma revisão sólida de Contas de Convidado Azure deve terminar com evidência de produção, não com a suposição de que o caminho arriscado desapareceu. Antes de fechar o achado, revalide atribuições de função, escopo de políticas, permissões de apps ou configurações de convidados, evidências reais de sign-in, auditoria ou risco do tenant, e o caminho de exceção que poderia recriar a exposição silenciosamente. Confirme que o estado mais seguro se aplica ao escopo que realmente importa: a OU de produção, a atribuição de função efetiva, o caminho do aplicativo ou o caminho de confiança e delegação que um atacante realmente exploraria. Documente o responsável técnico, a dependência de negócio e a condição de rollback, para que a próxima revisão consiga avaliar se o estado mais seguro foi mantido.

Use uma checklist curta de fechamento:

• verificar que o estado arriscado desapareceu do ponto de vista do atacante, e não apenas em um screenshot administrativo
• guardar um export antes/depois ou uma amostra de log que prove que o escopo afetado mudou
• documentar o owner e a decisão de exceção se o controle não puder ser aplicado integralmente

Para exposição adjacente, compare o resultado com Registros de Aplicativo Azure: Apps com Privilegios Excessivos, Fortalecimento do Tenant Azure: Security Defaults, Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático e Conformidade AD e Azure: NIS2, ISO 27001, CIS. A mesma lacuna de controle costuma reaparecer em caminhos vizinhos de identidade, falhas de logging ou permissões delegadas excessivas, por isso a validação final importa tanto quanto o achado inicial.

Contas de Convidado Azure: Evidências para Manter no Próximo Ciclo de Revisão

A próxima pessoa a revisar o tema não deveria precisar reconstruir o caso de memória. Guarde a evidência que justificou o achado original, a prova de que a mudança foi aplicada e a nota que explica por que o estado final é aceitável. Para este tema, o conjunto de evidências mais útil costuma combinar a exportação ou captura do tenant que mostra o escopo afetado, a evidência de sign-in, auditoria ou política que comprova a aplicação do controle, e o owner, a aprovação e a nota de exceção do estado final. Esse pacote compacto acelera muito as revisões trimestrais ou pós-mudança e ajuda a explicar se o problema foi removido, reduzido ou aceito formalmente.

Se uma mudança posterior de administração, política ou aplicação reabrir o caminho, esse histórico também facilita provar exatamente o que se desviou. É isso que transforma Contas de Convidado Azure em um processo de assurance repetível, em vez de uma checagem isolada.

Fontes

• Microsoft Learn - Configurar configurações de colaboração externa (escopo padrão de convite, opções de convite de convidado, função Convidador de Convidados)
• Microsoft Learn - Listar usuários (Microsoft Graph) (signInActivity exige Entra ID P1/P2 e AuditLog.Read.All)
• Microsoft Learn - Get-MgUser e Remove-MgUser
• Microsoft Learn - Gerenciar acesso de convidados com access reviews e O que são access reviews? (aplicação automática, licenciamento)
• Microsoft Learn - Visão geral de acesso entre tenants (declarações de MFA do tenant de origem não são confiáveis por padrão)
• Microsoft Learn - Acesso Condicional: recursos de destino e usuários e grupos
• Microsoft Learn - Referência de atividades do log de auditoria do Entra (nomes de atividade de usuários convidados)
• Elastic - Campos exportados do Azure e KQL

Leituras Relacionadas

Vale a pena revisar este tema junto com Falhas de Acesso Condicional Entra ID: Quais Erros Deixam uma Exposição Real, Fortalecimento do Tenant Azure: Security Defaults, Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM, Registros de Aplicativo Azure: Apps com Privilegios Excessivos e Azure Identity Protection: Bloqueando Credenciais Vazadas. Esses artigos mostram como as mesmas fraquezas de identidade costumam se encadear em uma avaliação real, em vez de aparecerem como achados isolados.

• Falhas de Acesso Condicional Entra ID: Quais Erros Deixam uma Exposição Real
• Fortalecimento do Tenant Azure: Security Defaults
• Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM
• Registros de Aplicativo Azure: Apps com Privilegios Excessivos
• Azure Identity Protection: Bloqueando Credenciais Vazadas

Essas referências internas ajudam a manter a discussão de remediação focada no caminho de ataque completo, em vez de uma única lacuna de controle.

Checklist de Validação

Antes de encerrar a revisão, refaça as mesmas verificações que expuseram o problema e confirme que o caminho arriscado não existe mais do ponto de vista do atacante. Verifique as identidades relevantes, os privilégios, os caminhos de herança e os controles compensatórios em produção, e não apenas em staging ou na documentação. Registre o responsável técnico, a dependência de negócio esperada e a evidência que mostra que a nova configuração é mais segura e operacionalmente sustentável. Essa etapa final de validação é o que mantém o artigo fundamentado em como os times realmente reduzem o risco de identidade.

Confirmar os Controles de Ciclo de Vida de Convidados na Prática

A remediação de contas de convidado deve incluir uma revisão de quem patrocina usuários externos, como o acesso é recertificado e quais caminhos de colaboração ainda criam identidades de convidado de longa duração com permissões amplas. Os programas mais resilientes combinam restrições de convite, access reviews periódicas e verificações de ownership, para que o acesso de convidados permaneça vinculado a uma necessidade de negócio real, em vez de persistir indefinidamente após o fim do projeto.