Endurecimento Active Directory: o que bloquear primeiro e como validar

O endurecimento Active Directory não é apenas um projeto de GPO nem uma checklist de execução única. Um plano útil de endurecimento do Active Directory reduz o número de caminhos privilegiados, remove protocolos fracos e segredos reutilizáveis, e prova que os controlos continuam a funcionar depois do rollout. Se primeiro precisa do workflow de revisão mais amplo, comece por Auditar a segurança do Active Directory: o que rever primeiro e como provar a remediação. Este artigo é mais estreito: concentra-se no que bloquear primeiro.

O que o endurecimento Active Directory realmente significa

Na prática, endurecer o Active Directory significa reduzir o número de formas pelas quais um atacante pode alcançar controlo privilegiado e depois proteger e monitorizar os caminhos administrativos que permanecem. A estratégia de acesso privilegiado da Microsoft trata explicitamente o acesso privilegiado como a prioridade de segurança mais alta e recomenda limitar ações privilegiadas a um pequeno número de caminhos autorizados, depois fortemente protegidos e monitorizados.

É por isso que um bom trabalho de endurecimento tem de ser ordenado. Se começar com um tuning cosmético de baseline antes de separar identidades privilegiadas, endurecer hosts administrativos e remover segredos reutilizáveis, o plano de controlo pode continuar fácil de alcançar. O Guia ANSSI Active Directory: como aplicar na prática as recomendações de segurança chega à mesma conclusão operacional por outro ângulo: compartimentar primeiro o modelo de administração e depois endurecer os controlos que o suportam.

O endurecimento do Active Directory começa pelos acessos privilegiados e pelos caminhos administrativos

A primeira prioridade é o acesso privilegiado, não porque seja um tema da moda, mas porque a compromissão de contas e caminhos privilegiados costuma fazer ruir o resto do modelo de segurança do diretório. A guidance da Microsoft para secure administrative hosts é direta: nunca se deve administrar um sistema confiável a partir de um host menos confiável, e hosts administrativos dedicados não devem executar software de uso normal do utilizador, como email, browsers ou suites de produtividade.

Isto dá a primeira sequência de endurecimento:

1. Separar contas privilegiadas das identidades do dia a dia.
2. Mover a administração privilegiada para workstations dedicadas, jump hosts ou secure administrative hosts equivalentes.
3. Restringir onde as identidades altamente privilegiadas podem autenticar-se.
4. Medir se sessões privilegiadas ainda estão a ocorrer a partir de dispositivos de utilizador comuns.

É também aqui que entram controlos como o grupo de segurança Protected Users e Authentication Policies / Authentication Policy Silos. São controlos de contenção úteis para as contas certas, mas não pontos de partida universais. A Microsoft documenta caveats importantes: membros de Protected Users devem conseguir autenticar-se com AES, contas de serviço e de computador não devem ser adicionadas, e contas altamente privilegiadas não devem ser adicionadas antes de validar o impacto operacional. Authentication policy silos podem ainda restringir em que hosts determinadas contas de utilizador, computador e serviço altamente privilegiadas têm autorização para autenticar-se, o que os torna úteis depois de os tiers administrativos e respetivos caminhos já estarem definidos.

Reduzir depois a exposição de protocolos e do diretório

Depois de os caminhos privilegiados estarem mais estreitos, o passo seguinte no endurecimento do Active Directory é reduzir a exposição protocolar que ainda permite interceção, adulteração ou hábitos de administração fracos.

LDAP signing e channel binding

A Microsoft documenta LDAP signing e LDAP channel binding como proteções do tráfego LDAP de AD DS. LDAP signing ajuda a verificar autenticidade e integridade, enquanto channel binding liga a camada aplicacional à sessão TLS subjacente para ajudar a impedir hijacking e cenários man-in-the-middle. Na prática, isto significa que um plano sério de endurecimento deve rever se SASL binds sem assinatura ou padrões LDAP inseguros continuam a ser tolerados por controladores de domínio.

O erro clássico é impor a configuração às cegas. Antes de a endurecer, valide que aplicações, appliances, scripts ou middleware legacy ainda dependem de comportamento LDAP fraco. Depois, mantenha prova dessa revisão de compatibilidade e do estado final imposto. O deep dive associado continua em inglês: LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

SMB signing

A guidance da Microsoft sobre SMB signing é igualmente útil como controlo de endurecimento porque protege a integridade das mensagens e ajuda a defender contra relay e spoofing. Exigir SMB signing em caminhos administrativos e de gestão de ficheiros de alto valor costuma ser um controlo a priorizar cedo.

Mais uma vez, a ordem de imposição importa. A Microsoft observa que podem surgir problemas de compatibilidade quando os requisitos de assinatura são aplicados em ambientes com file servers não Microsoft. O movimento correto não é «ativar já em todo o lado», mas «medir onde o SMB sem assinatura ainda importa, validar dependências e só depois impor com evidência». O deep dive associado é Assinatura SMB desativada: porque continua a permitir NTLM relay.

O endurecimento do Active Directory implica reduzir segredos reutilizáveis

Muitas intrusões em AD continuam a acelerar porque segredos reutilizáveis permanecem demasiado fáceis de roubar, reutilizar ou explorar lateralmente. Esta é a terceira prioridade porque muitas vezes limita até onde a compromissão de um único host consegue espalhar-se.

Windows LAPS

A Microsoft documenta Windows LAPS como a funcionalidade integrada que gere e faz backup automaticamente das palavras-passe das contas de administrador local, e que também pode gerir a palavra-passe DSRM em controladores de domínio Windows Server Active Directory. Isso faz dela um controlo central de endurecimento, não uma mera conveniência. Se as palavras-passe de administrador local ou DSRM continuam estáticas, partilhadas ou rodadas manualmente, o ambiente continua a transportar risco lateral evitável.

O objetivo não é apenas o deployment. É preciso validar a rotação de palavras-passe, permissões de recuperação, destino do backup e se as exceções continuam a deixar parte do parque fora do controlo. Deep dive associado: Windows LAPS não implantado: porque as palavras-passe partilhadas de administrador local continuam a importar.

Palavras-passe de contas de serviço e gMSA

A guidance da Microsoft para group Managed Service Accounts é valiosa porque reduz a carga administrativa da gestão de palavras-passe de contas de serviço e simplifica a gestão de SPN. Quando o suporte aplicacional o permite, migrar de contas de serviço tradicionais baseadas em utilizadores para gMSA remove uma classe de palavras-passe de longa duração geridas manualmente.

Isto não é uma ordem de migração universal. Antes da conversão, é preciso validar suporte aplicacional, comportamento de clusters ou farms, dependências de SPN e ownership operacional. Para contas que ainda não podem migrar para gMSA, reduza a idade das palavras-passe, remova privilégios desnecessários e reveja se a conta continua a ser o principal correto para o serviço.

Endurecimento direcionado de políticas de palavra-passe

A guidance da Microsoft sobre fine-grained password policies é útil aqui, mas apenas no scope certo. Fine-grained password policies aplicam-se a objetos de utilizador e grupos de segurança globais, não como substituto universal da governação geral de palavras-passe. Use-as quando precisar de tratamento mais rigoroso para populações selecionadas de contas administrativas ou de serviço, e não como substituto de melhor higiene geral de credenciais. Para a camada adjacente de controlo de palavra-passe, o deep dive continua em inglês: Active Directory Password Security: Misconfigurations That Matter.

Limitar delegação e outros caminhos de escalada

A quarta prioridade é o plano de controlo à volta do próprio diretório: permissões delegadas, controlo de grupos privilegiados, administração de GPO e direitos relacionados com replicação que não deveriam permanecer amplamente alcançáveis.

A documentação da Microsoft sobre Group Policy lembra que um GPO não é apenas «uma definição». Tem um componente AD e um componente de sistema de ficheiros, e é aplicado pela lógica normal de scope do diretório. É por isso que permissões de GPO e scope de links pertencem ao trabalho de endurecimento, e não apenas ao troubleshooting. Se utilizadores de baixo privilégio conseguem influenciar um GPO que alcança sistemas privilegiados, o programa de endurecimento tem uma lacuna estrutural. O artigo adjacente continua em inglês: GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

A mesma lógica aplica-se a permissões relacionadas com replicação. A Microsoft documenta Replicating Directory Changes como uma ACE em cada domain naming context que pode ser explicitamente atribuída a contas. Isso significa que acesso com capacidade de replicação deve ser tratado como privilegiado e revisto explicitamente, não assumido como inofensivo apenas porque não se chama «Domain Admin». O problema mais amplo das cadeias de abuso é coberto em Caminhos de ataque AD: como más configurações se encadeiam até Domain Admin.

Se AD CS estiver implantado, deve ser incluído no mesmo programa de endurecimento. A Microsoft documenta AD CS como o role do Windows Server que emite e gere certificados usados em comunicação segura e autenticação. Por outras palavras, se existir autenticação baseada em certificados no ambiente, endurecer o diretório ignorando o plano de controlo dos certificados deixa uma lacuna material. Mantenha o scope condicional: se AD CS não estiver implantado, não o force para dentro do programa. Se estiver presente, reveja Caminhos de ataque ADCS: como erros em certificados se tornam caminhos de escalada no Active Directory.

Incorporar logging e validação no plano de endurecimento

Endurecimento que não pode ser remedido volta rapidamente à suposição. As recomendações da Microsoft sobre audit policy e recolha de eventos deixam o ponto operacional claro: primeiro são necessárias as definições de auditoria corretas, depois o caminho correto de recolha e retenção.

Windows Event Forwarding e Windows Event Collector podem centralizar os eventos que escolhe encaminhar, mas não substituem o desenho da audit policy. Telemetria sobre alterações de objetos de diretório só é útil quando existem as definições de auditoria necessárias e a cobertura SACL correta. Por exemplo, a Microsoft documenta que o Event 5136 é gerado quando um objeto de serviço de diretório é modificado, mas apenas se o objeto tiver a entrada SACL relevante para a ação de escrita auditada.

Isso leva a uma regra prática para programas de endurecimento:

• manter exportações antes e depois da mudança para composição de grupos privilegiados, estado de GPO, estado das políticas LDAP e SMB e permissões delegadas
• verificar que controladores de domínio e sistemas administrativos registam efetivamente os eventos em que pretende basear-se
• tratar WEF/WEC como infraestrutura de transporte e retenção, não como prova de que o desenho de auditoria está completo

Para a camada de visibilidade por eventos, use Monitoramento de segurança AD: os eventos que realmente importam e Auditoria recorrente de Active Directory: porque auditorias anuais derivam e como voltar a medir continuamente.

Matriz de prioridades de endurecimento do Active Directory

Se AD CS estiver presente, inclua exposição de certificate templates, configuração da CA e enrollment endpoints na mesma matriz como uma linha condicional em vez de os tratar como um projeto futuro separado.

Validação depois das mudanças de endurecimento

Um programa de endurecimento só está concluído quando os controlos continuam a funcionar em condições de produção. Evidências úteis de validação incluem:

1. Prova de que a administração privilegiada agora só se origina em hosts aprovados ou jump paths definidos.
2. Prova de que clientes LDAP continuam a funcionar com a postura alvo para LDAP signing e channel binding.
3. Prova de que workflows administrativos e de ficheiros SMB continuam a funcionar com os requisitos de assinatura previstos.
4. Prova de que Windows LAPS roda segredos de administrador local e DSRM e de que os direitos de recuperação estão estritamente limitados.
5. Prova de que migrações de contas de serviço para gMSA ou para um tratamento operacional mais rigoroso não deixaram SPNs quebrados nem exceções sem gestão.
6. Prova de que permissões delegadas, direitos relacionados com replicação e caminhos de controlo de GPO foram revistos antes e depois da mudança.
7. Prova de que a audit policy e a pipeline de eventos capturam efetivamente os controlos em que pretende confiar.

É também por isso que este pillar fica ao lado, e não por cima, do pillar de auditoria. A pergunta de hardening é «o que bloqueamos primeiro?». A pergunta de auditoria é «o que revemos recorrentemente, e como provamos deriva ou remediação ao longo do tempo?». Ambas importam, mas não são o mesmo workflow.

Como a EtcSec apoia revisões repetíveis de endurecimento AD

A EtcSec encaixa aqui como camada de medição repetível, não como atalho à volta do trabalho real de endurecimento. Um collector local read-only pode ajudar a voltar a medir dispersão de contas privilegiadas, permissões com capacidade de replicação, exposição LDAP signing, exposição SMB signing e cobertura Windows LAPS depois de cada vaga de mudanças. Isso é útil quando precisa de verificar que uma decisão de endurecimento reduziu realmente a exposição, em vez de apenas ter alterado uma definição de política no papel.

Referências principais

• Best practices for securing Active Directory
• Implementing Secure Administrative Hosts
• Privileged access: Strategy
• LDAP signing for Active Directory Domain Services on Windows Server
• Overview of Server Message Block signing in Windows
• Windows LAPS overview
• Group Managed Service Accounts overview
• Protected Users security group
• Authentication Policies and Authentication Policy Silos
• System Audit Policy recommendations
• Use Windows Event Forwarding to help with intrusion detection
• What is Active Directory Certificate Services?
• Group Policy overview for Windows Server
• Configure fine-grained password policies for Active Directory Domain Services in Windows Server
• How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account
• 5136(S): A directory service object was modified
• Recommandations pour l’administration sécurisée des SI reposant sur AD