Questão de Segurança da Informação — Autorização e Controle de Acesso (RBAC, ABAC, MAC, DAC e ACL) — FCC 2026

Mitigação de consultas LDAP anônimas no Active Directory

Gabarito: letra C. Para eliminar consultas LDAP anônimas de forma nativa e segura, o analista deve configurar uma GPO que exija LDAP Signing (assinatura LDAP) e ajustar as ACLs para remover o acesso de leitura do grupo Logon Anônimo. Essa é a abordagem recomendada pela Microsoft para mitigar ataques como o LDAP relay e o pass-the-hash em ambientes Windows Server.

O problema descrito é clássico: por padrão, o Active Directory permite que qualquer usuário não autenticado realize consultas LDAP anônimas na porta 389, o que pode ser explorado para enumerar usuários, grupos e políticas do domínio. A solução nativa e segura envolve duas camadas complementares: exigir assinatura LDAP (para impedir que um atacante modifique ou faça relay das requisições) e restringir as permissões de leitura do grupo "Logon Anônimo" nas ACLs do diretório (para impedir que consultas anônimas retornem dados).

A assinatura LDAP (LDAP Signing) é um recurso que adiciona integridade às comunicações LDAP, garantindo que os pacotes não sejam alterados em trânsito. Quando exigida via GPO, o servidor rejeita conexões que não estejam assinadas, dificultando ataques de man-in-the-middle e relay. Já o ajuste das ACLs remove a capacidade de leitura do grupo "Logon Anônimo", que é o grupo que representa conexões não autenticadas. Combinadas, essas medidas garantem que consultas anônimas não sejam mais possíveis e que, mesmo que tentadas, não retornem informações.

É importante destacar que a alternativa correta não sugere desabilitar completamente o acesso anônimo (o que poderia quebrar a compatibilidade com aplicações legadas), mas sim restringir o que esse acesso pode fazer. Essa é a abordagem mais equilibrada: mantém a funcionalidade onde necessário, mas elimina a exposição indevida de dados.

A pegadinha da questão está em alternativas que propõem políticas inexistentes (como "RestrictAnonymous" ou "RestrictALL") ou soluções que não resolvem o problema (como DNSSec ou certificados autoassinados). O candidato precisa conhecer as políticas reais do Windows Server e entender que a mitigação correta envolve tanto a assinatura do protocolo quanto o controle de acesso no diretório.

Alternativa A — ❌ Incorreta

A política RestrictAnonymous existe no Windows, mas não no nível 0 para "impedir qualquer comunicação de rede que não utilize autenticação mútua Kerberos". Na verdade, a política RestrictAnonymous controla o acesso anônimo a recursos de rede, mas não tem relação com autenticação Kerberos. Além disso, o nível 0 é o mais permissivo (permite enumeração anônima), não o mais restritivo. A alternativa confunde o propósito da política e inverte o efeito dos níveis.

Alternativa B — ❌ Incorreta

Não existe uma política chamada RestrictALL no Windows Server. Essa é uma invenção da banca para confundir o candidato. A política correta para exigir assinatura LDAP é configurada via GPO em "Configuração do Computador > Políticas > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança", com a opção "Servidor de rede: assinar digitalmente comunicações (sempre)" ou similar.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a solução nativa e recomendada pela Microsoft. Configurar uma GPO para exigir LDAP Signing garante a integridade das comunicações LDAP, impedindo ataques de relay. Ajustar as ACLs para remover o acesso de leitura do grupo Logon Anônimo impede que consultas não autenticadas retornem dados do diretório. Essa combinação resolve a vulnerabilidade sem quebrar a compatibilidade com aplicações que precisam de acesso LDAP autenticado.

Alternativa D — ❌ Incorreta

DNSSec (DNS Security Extensions) é um protocolo que protege a integridade das respostas DNS, não tem relação com consultas LDAP anônimas. Forçar comunicação via SMB assinado de forma anônima também não resolve o problema, pois o SMB é um protocolo diferente do LDAP e a assinatura anônima não impede consultas LDAP não autenticadas.

Alternativa E — ❌ Incorreta

Migrar para a porta 636 (LDAPS) adiciona criptografia, mas não resolve o problema de consultas anônimas — um atacante pode simplesmente usar LDAPS anonimamente. Além disso, usar certificados autoassinados gerados individualmente em cada estação é uma prática insegura e inviável, pois cada estação teria um certificado diferente, impossibilitando a validação centralizada. A alternativa mistura conceitos de criptografia com controle de acesso sem resolver a vulnerabilidade real.

Gabarito: letra C