Sincronização Híbrida de Identidade no Entra: Contas Cloud-Only Privilegiadas e Órfãs — o Ponto Cego da Auditoria Híbrida

Sincronização Híbrida de Identidade no Entra: Contas Cloud-Only Privilegiadas e Órfãs Explicadas

A sincronização híbrida de identidade no Entra com contas cloud-only privilegiadas e órfãs é o tema dos dois pontos cegos abordados neste artigo: contas somente na nuvem com funções privilegiadas do Microsoft Entra que nunca passam pela governança de Tier 0 on-premises, e usuários sincronizados órfãos que o Entra Connect deixa para trás depois que a conta on-premises correspondente é excluída. Ambos escapam pelas brechas do pipeline de sincronização que mantém a maioria dos objetos fluindo normalmente entre o Active Directory on-premises e o Microsoft Entra ID, e ambos são pontos cegos de auditoria específicos de ambientes híbridos, não de um lado isolado.

O primeiro é a conta cloud-only privilegiada: um usuário criado diretamente no Entra ID, que nunca foi sincronizado a partir do AD on-premises, e que possui uma função privilegiada do Microsoft Entra ativa ou elegível via PIM. O segundo é o usuário sincronizado órfão: um objeto que o Entra Connect sincronizou a partir do AD em algum momento, cuja conta de origem on-premises já foi excluída ou removida do escopo de sincronização, mas cujo objeto no Entra ID nunca é removido de forma limpa. Nenhum dos dois aparece nas auditorias que a maioria das organizações híbridas já executa, porque essas auditorias são construídas em torno de apenas um lado da fronteira de sincronização — uma revisão de tiering on-premises varre o AD, e mesmo uma auditoria de segurança do Microsoft Entra ID abrangente geralmente assume que toda identidade ainda tem uma contraparte on-premises ativa.

Contas Cloud-Only Privilegiadas: Uma Lacuna Deliberada que Auditorias On-Prem Não Enxergam

Manter contas de Tier 0 fora da sincronização de diretório não é um erro — é a recomendação documentada da Microsoft. A própria orientação da Microsoft afirma claramente que "contas de administrador de Tier 0 são usadas apenas para contas do AD on-premises. Essas contas normalmente não são sincronizadas com o Microsoft Entra ID na nuvem", e separadamente que "contas de Global Administrator (e outros grupos privilegiados) devem ser contas somente na nuvem, sem vínculo com o Active Directory on-premises" (Secure access practices for administrators in Microsoft Entra ID).

O ponto cego não é a arquitetura — é a lacuna de governança que se abre ao redor dela. Uma revisão de tiering on-premises (seja uma auditoria manual contra um modelo como o modelo de tiers da ANSSI, ou uma ferramenta como o PingCastle varrendo o AD) não tem visibilidade nenhuma sobre atribuições de função no Entra ID, porque uma conta cloud-only nunca existiu on-premises. Se o programa de governança do lado da nuvem não foi construído com o mesmo rigor — atribuição elegível via PIM em vez de acesso permanente, Conditional Access exigindo MFA e um dispositivo compatível na ativação, e revisões de acesso periódicas —, um Global Administrator cloud-only pode permanecer com uma atribuição ativa permanente, sem exigência de MFA e sem log de ativação, invisível para as duas metades do programa de auditoria ao mesmo tempo.

Essa lacuna tem uma superfície de ataque concreta associada a ela. O SyncJacking é uma técnica de takeover por hard match, confirmada pelo Microsoft Security Response Center como um problema de escalonamento de privilégio de severidade Importante, na qual um invasor que controla atributos de um objeto do AD on-premises pode forçar o Entra Connect a fazer o hard match desse objeto sobre um usuário já gerenciado na nuvem — inclusive um usuário privilegiado — e assumir sua Source of Authority. A técnica "não deixa rastro nos logs do AD on-premises e apenas rastro mínimo nos logs do Entra ID" (Semperis: Syncjacking Could Enable Entra ID Account Takeover).

A Microsoft já lançou uma mitigação no nível da plataforma. Segundo a própria documentação de troubleshooting da Microsoft: "A partir de 1º de julho de 2026, o Microsoft Entra ID aplica automaticamente o hardening de segurança de hard match", bloqueando um hard match sempre que a conta de nuvem alvo já tiver onPremisesObjectIdentifier definido, possuir uma função privilegiada ativa do Entra, ou for elegível para uma (Microsoft Entra Connect: Troubleshoot errors during synchronization — InvalidHardMatch). Esse hardening protege o caminho de takeover — ele não fecha a lacuna de governança que permitiu que um admin cloud-only não monitorado existisse em primeiro lugar, que é exatamente o que as seções de detecção e correção deste artigo visam. Também vale a pena combinar essa revisão do lado de acesso com as contas de acesso de emergência que todo tenant mantém para um cenário real de break-glass — veja higiene de contas break-glass do Entra ID para saber como elas devem (e não devem) ser delimitadas.

Usuários Sincronizados Órfãos: O Que Acontece Quando o Entra Connect Não Remove uma Conta On-Prem Excluída

Do outro lado da fronteira, excluir um usuário no AD on-premises não garante que seu gêmeo no Entra ID desapareça. Dois mecanismos documentados deixam objetos sincronizados para trás:

Proteção contra exclusão acidental. O Microsoft Entra Connect vem com a proteção contra exclusão habilitada por padrão, limitada a 500 exclusões de objetos por ciclo de exportação. Se uma limpeza em massa on-prem, uma movimentação de OU, ou um filtro de sincronização quebrado causar mais exclusões do que o limite em uma única execução, a exportação simplesmente para — o Synchronization Service Manager reporta stopped-deletion-threshold-exceeded na etapa de Export, e cada uma dessas exclusões permanece não aplicada no Entra ID até que um administrador revise e retome o job (Microsoft Entra Connect Sync: Prevent accidental deletes). Na prática, isso significa que uma única violação de limite não percebida pode deixar dezenas de contas excluídas on-prem ainda totalmente ativas e com aparência de sincronizadas na nuvem.

Exclusão de escopo sem conversão. Quando um objeto é movido para fora do escopo de sincronização (uma mudança de filtro de OU/grupo, por exemplo) em vez de excluído diretamente, o Entra Connect faz um soft-delete do objeto no Entra ID e muda DirSyncEnabled para False — mas, segundo a própria documentação da Microsoft, "esse processo, no entanto, não converte o objeto para gerenciado na nuvem; ele ainda é considerado um objeto sincronizado do Active Directory on-premises", e permanece elegível para um novo hard match posteriormente (Microsoft Entra Connect: Troubleshoot errors during synchronization). Um usuário nesse estado não está nem limpamente excluído, nem genuinamente cloud-native — é um objeto meio migrado para o qual a maioria das revisões de acesso não tem uma categoria clara, em espírito semelhante às contas privilegiadas obsoletas que auditorias on-prem já sinalizam, exceto que esta é invisível do lado do AD porque o objeto de origem já desapareceu.

Detecção: Encontrando Contas Cloud-Only Privilegiadas e Sincronizadas Órfãs

A propriedade onPremisesSyncEnabled do recurso user do Microsoft Graph é a âncora para as duas verificações: ela retorna true para um objeto ativamente sincronizado, false para um objeto que já foi sincronizado mas não é mais, e null para um objeto que nunca foi sincronizado — ou seja, genuinamente cloud-native.

Consultando o Microsoft Graph em Busca de Candidatos a Órfãos

Para obter diretamente a lista de candidatos com SOA revertida / órfãos, a Microsoft documenta esta consulta ao Graph:

GET https://graph.microsoft.com/v1.0/users?$count=true&$filter=OnPremisesSyncEnabled ne true and OnPremisesImmutableId ne null

(Fonte: How to audit and monitor User Source of Authority (SOA) in Microsoft Entra ID.) Filtros avançados em onPremisesSyncEnabled podem exigir o cabeçalho ConsistencyLevel: eventual e $count=true para retornar resultados de forma confiável.

Cruzando Funções Privilegiadas com o Estado de Sincronização

Para o lado cloud-only privilegiado, cruze as atribuições de função (elegíveis via PIM e ativas) com o estado de sincronização:

# Users with an active or eligible Entra role that were never synced from on-prem
Get-MgUser -Filter "onPremisesSyncEnabled eq null" -ConsistencyLevel eventual -CountVariable c -All |
    Where-Object { (Get-MgUserMemberOf -UserId $_.Id) -match "RoleAssignable" }

Correção

Fechando a Lacuna Cloud-Only Privilegiada

1. Estenda a governança de Tier 0 para contas cloud-only privilegiadas. Toda conta cloud-only com função ativa ou elegível do Entra deve ter: atribuição elegível via PIM (não permanente), uma política de Conditional Access exigindo MFA e dispositivo compatível/gerenciado na ativação (muitos tenants têm lacunas aqui — veja lacunas na cobertura da política baseline de Conditional Access), e inclusão na mesma revisão de acesso periódica do Tier 0 on-premises — veja higiene de grupos aninhados e atribuíveis a função para o equivalente do lado de grupos dessa mesma lacuna.
2. Mantenha a exceção estreita. As únicas contas que devem ficar totalmente fora do escrutínio de PIM e CA são as verdadeiras contas de acesso de emergência break-glass — duas, cloud-only, monitoradas, conforme a orientação da Microsoft (veja higiene de contas break-glass). Tudo o mais rotulado como "cloud-only porque Tier 0 não deveria sincronizar" ainda precisa de um dono e de um ritmo de revisão.

Limpando Usuários Sincronizados Órfãos

3. Ajuste a proteção contra exclusão acidental em vez de simplesmente aumentá-la sem critério. Confirme que o limite de exclusão de exportação (Enable-ADSyncExportDeletionThreshold) está definido deliberadamente para o seu ambiente, direcione a notificação de parada para uma caixa de entrada monitorada, e trate todo evento stopped-deletion-threshold-exceeded como um gatilho de investigação antes de retomar a exportação — retomar sem revisão é exatamente o que transforma uma mudança de configuração em dezenas de órfãos ativos.
4. Reconcilie o estado de sincronização obsoleto em um cronograma regular. Consulte onPremisesSyncEnabled = false com um onPremisesLastSyncDateTime antigo, confirme no AD on-premises se o objeto de origem ainda existe, e restaure o mapeamento ou desprovisione formalmente o objeto na nuvem — não o deixe no estado meio migrado.
5. Conecte as exclusões a um processo de saída (leaver) governado. Os Lifecycle Workflows do Microsoft Entra ID Governance podem acionar tarefas de desabilitação/remoção de acesso/exclusão agendada a partir de um sinal autoritativo (feed de RH ou atributo do AD), em vez de depender apenas da exportação de sincronização para propagar um offboarding — isso captura o caso em que a exportação falha silenciosamente.

Preparando-se para o Hardening de Hard Match

6. Planeje o hardening de hard match agora, não em 1º de julho de 2026. Qualquer processo que dependa de refazer o match de uma conta de nuvem privilegiada ou elegível via PIM com um objeto on-premises (recuperação de floresta, runbooks de migração de tenant) será bloqueado por padrão assim que o hardening da Microsoft entrar em vigor. Teste seus runbooks de recuperação contra o workaround documentado — remover temporariamente a função ou a elegibilidade, concluir o hard match e depois restaurá-la — antes de precisar disso sob pressão de um incidente.

Como a EtcSec Detecta Isso

As verificações de Entra ID da EtcSec sinalizam diretamente os dois lados dessa lacuna: HYBRID_CLOUD_ONLY_PRIVILEGED identifica usuários cloud-only com uma função privilegiada, e HYBRID_ORPHANED_CLOUD_USER identifica objetos cujo estado de sincronização indica um provável órfão. Esses achados são combinados com UNRESOLVED_PRIVILEGED_MEMBERS (atribuições de função privilegiada que referenciam um principal que não resolve mais), PA_ADMIN_STALE_ACCOUNT (contas administrativas sem atividade recente) e PA_GLOBAL_ADMIN_NOT_MFA (Global Administrators sem MFA obrigatório), de modo que uma conta cloud-only privilegiada não seja apenas detectada, mas também avaliada com o mesmo padrão de higiene de acesso de qualquer outra identidade de Tier 0.