Mike Masciulli Diretor Executivo, Produtos e Serviços de Migração

A migração do AD não aumentou a sua segurança. Em muitos ambientes, tem mesmo o efeito contrário.

«Como é que sabes?»

Essa é a questão incómoda a que volto sempre quando falo com organizações que planeiam fusões, transições para a nuvem e projetos de modernização.

Com demasiada frequência, as empresas gastam milhões num projeto de migração e consolidação do Active Directory (AD) e tratam-no como uma simples transferência de dados: transferem os utilizadores, os grupos e as aplicações para uma nova floresta, declaram o sucesso e assumem que a parte difícil já passou.

Mas se mantiver os mesmos erros de delegação, aninhamento de grupos, relações de confiança e contas com privilégios excessivos, poderá recriar as mesmas vias de ataque num novo ambiente — e, por vezes, torná-las mais difíceis de detetar. Uma transição limpa não significa necessariamente uma postura de segurança sólida.

Aqui estão onze riscos comuns que observo em migrações típicas do AD. Se abordar a migração do AD com uma mentalidade que priorize a segurança, poderá reduzir a exposição a riscos herdados, em vez de os transportar para o novo ambiente.


1. Privilégios administrativos herdados

Uma migração do AD pode tornar-se um mecanismo de escalada de privilégios quando os direitos de administrador de domínio ou de administrador empresarial herdados são transferidos para o ambiente de destino sem uma análise prévia. O que parece ser continuidade é, na verdade, a transferência de antigos erros administrativos para um novo ambiente que deveria ter sido construído com base nas práticas de segurança atuais.

Já vi migrações que mantiveram estruturas de privilégios que existiam há décadas. Se os antigos privilégios sobrevivem, os antigos riscos sobrevivem com eles.


2. Recriação de vias de ataque legadas

Se mantiver os atalhos de aninhamento de grupos, delegação e coexistência sem analisar as relações de privilégios antes da transição, os atacantes poderão continuar a utilizar as mesmas rotas de movimento lateral de que já dispunham. A migração pode decorrer sem problemas do ponto de vista operacional, mas, do ponto de vista da segurança, o mesmo caminho de ataque continua a existir.

Em alguns casos, a migração gera um resultado ainda mais perigoso: uma ponte entre um ambiente de origem comprometido e o ambiente de destino. O que não se consegue validar durante a migração acaba frequentemente por se tornar um incidente para outra pessoa mais tarde.


3. Divulgação de credenciais durante a migração

Os períodos de migração são instáveis. As credenciais são partilhadas, são adicionadas relações de confiança, a sincronização alarga-se e as alterações legítimas geram ruído suficiente para esconder atividades maliciosas à vista de todos.

Em abril de 2026, a Microsoft alterou a configuração padrão do KDC do Kerberos para dar preferência ao AES em contas sem definições explícitas de encriptação, uma mudança que pode causar falhas nas contas de serviço dependentes do RC4 durante a coexistência, caso as equipas não tenham identificado essas dependências antecipadamente. Tal como explico na minha publicação «RC4 e a migração do AD: Descubra os cenários de falha escondidos no seu domínio de origem», os projetos de migração estão particularmente expostos a riscos, uma vez que as ferramentas padrão podem transferir uma conta sem ter em conta as suas configurações de encriptação.

Se acrescentarmos o risco de os atacantes se aproveitarem das relações de confiança — ou mesmo criarem «florestas fantasmas» para obter acesso enquanto as equipas estão concentradas na transição —, torna-se evidente que a janela de migração é uma das fases de maior risco no ciclo de vida da identidade.


4. Abuso do SID-History

O atributo SID-History é útil para garantir a continuidade, mas pode ser perigoso se não for devidamente gerido. Os especialistas em testes de penetração têm-no utilizado meses após a migração para aceder a recursos antigos através de identidades que já não deveriam ter qualquer relevância.

Na prática, um invasor pode atribuir o histórico de SID de uma conta administrativa a uma conta com privilégios mais limitados e recuperar o acesso efetivo no ambiente de origem. Pior ainda, esses SIDs antigos permanecem frequentemente durante anos, porque as organizações nunca os eliminam completamente.


5. ACLs defeituosas ou excessivamente permissivas

A tradução de listas de controlo de acesso (ACL) sem validação é uma das formas mais rápidas de provocar desvios nas permissões. Dados confidenciais de RH ou financeiros podem tornar-se acessíveis a amplos grupos de utilizadores — e, muitas vezes, as organizações só se apercebem disso quando uma auditoria falha ou quando um utilizador acede a dados que nunca deveria ter visto.

Em ambientes amplos e desorganizados, com um grande número de grupos, é fácil que essa dispersão aconteça, a menos que se identifique o que realmente precisa de ser destacado.


6. Falhas nas contas de serviço e privilégios ocultos

As dependências de identidade dos serviços são frequentemente mal documentadas, razão pela qual as aplicações de negócio podem deixar de funcionar dias após uma migração. No entanto, os problemas com as contas de serviço não se limitam apenas a questões de disponibilidade. Muitas vezes, revelam palavras-passe desatualizadas, direitos excessivos, dependências não documentadas e percursos de autenticação que ninguém pretendia manter.

Se não configurar corretamente as contas de serviço, não atualizar as ACLs nos serviços e objetos COM e não tiver em conta as identidades geridas pelo sistema, poderá desativar a fonte e descobrir tarde demais que as aplicações críticas no destino ainda dependem dela. Nessa altura, a «migração concluída» transforma-se numa «interrupção das operações» — e os privilégios antigos podem ainda estar incorporados na camada de serviços.


7. Colisões de identidade e mapeamentos incorretos

Uma lógica de correspondência deficiente pode causar colisões de identidade perigosas. Um exemplo simples é associar o CEO de uma empresa adquirida a alguém com um nome semelhante no ambiente de destino. A pessoa errada pode herdar o pseudónimo, o endereço de e-mail ou as filiações em grupos errados.

Isto vai além da simples organização dos diretórios. Um mapeamento incorreto de objetos gera acessos indevidos, exposição de dados e problemas de autenticação difíceis de rastrear, o que compromete a confiança em toda a migração.


8. Coexistência que amplia o impacto da violação

A conectividade durante a migração pode ampliar o impacto de uma violação. Se a origem e o destino não estiverem suficientemente isolados durante a coexistência, a própria infraestrutura de migração pode tornar-se a ponte que os atacantes utilizam para alargar a violação da floresta antiga à nova.

A coexistência é útil do ponto de vista operacional, mas pode ser perigosa se for considerada confiável por defeito. Uma floresta reconstruída não é, automaticamente, uma floresta reforçada.


9. Lacunas em matéria de conformidade e auditoria

Quando os auditores perguntam quem teve acesso durante a migração, por que razão as permissões foram alteradas ou quando é que o SID-History foi adicionado, «não temos a certeza» não é uma resposta aceitável.

Se a migração não contar com fluxos de trabalho auditáveis e relatórios compreensíveis, as equipas de segurança não poderão comprovar o controlo sobre as alterações de identidade. Isso torna-se uma discussão particularmente difícil com auditores, equipas jurídicas e seguradoras cibernéticas, que exigem provas, e não suposições.


10. Lacunas forenses após a transição

O registo não é opcional durante a migração. Se surgirem atividades suspeitas semanas mais tarde e os registos estiverem incompletos, pouco claros ou em falta, perderá a capacidade de reconstruir o que aconteceu e como o invasor conseguiu entrar.

Se não for possível quantificar a via de ataque com segurança, também não será possível provar que a eliminou. Essa é uma posição difícil de defender após um incidente.


11. Uma nova floresta com velhas portas traseiras

Todos estes riscos mais amplos têm origem no mesmo erro: acumular falhas porque ninguém quer causar problemas neste momento.

Contas inativas, SIDs órfãos e configurações duvidosas sobrevivem à migração. A dívida de segurança permanece oculta até que uma auditoria posterior, uma iniciativa na nuvem ou uma violação de segurança venha a revelar o problema.

E essa é a suposição mais perigosa de todas: acreditar que uma floresta reconstruída é segura simplesmente por ser nova. O verdadeiro teste de uma migração do AD não é saber se os utilizadores conseguem iniciar sessão na segunda-feira. É saber se o novo ambiente é substancialmente mais difícil de comprometer do que aquele que substituiu.


Transforme a sua migração do AD numa transformação de segurança

As migrações para o AD representam algumas das melhores oportunidades que uma organização poderá ter para reduzir as vias de ataque, eliminar a exposição de sistemas legados e modernizar a segurança de identidades. Mas isso só acontece se a segurança for integrada no plano de migração desde o início, e não tratada como um trabalho de limpeza após a transição.

Se a sua organização está a planear uma migração do AD, uma integração de fusões e aquisições ou um projeto de modernização da floresta, este é o momento de decidir se pretende apenas transferir a infraestrutura ou melhorar significativamente o seu nível de segurança.

Na Semperis, encaramos a migração como um evento de segurança, e não como um simples exercício de «lift-and-shift». Ajudamos as organizações a reduzir os riscos associados aos sistemas legados durante a migração, em vez de os arrastarem para o futuro e terem de arcar com as consequências mais tarde. Saiba mais sobre os nossos serviços de migração do AD.


Saiba mais sobre a migração bem-sucedida do AD