🏢Active DirectoryPasswordCompliance

Política de palavras-passe AD: por que diferem ANSSI e CIS

Compare ANSSI e CIS atributo a atributo, verifique a política do domínio AD e corrija os desvios face a uma referência identificada.

Younes AZABARPor Younes AZABAR12 min de leitura
Política de palavras-passe AD: por que diferem ANSSI e CIS

O que é a conformidade da política de palavras-passe AD?

A conformidade da política de palavras-passe AD depende da regra exata que está a ser avaliada. Um domínio pode cumprir os critérios numéricos citados para a verificação ANSSI da política de palavras-passe da EtcSec e, ainda assim, falhar a verificação CIS com a mesma configuração. As verificações leem atributos que se sobrepõem, mas aplicam limiares diferentes e abrangem definições diferentes.

A pergunta útil é, portanto: que atributo falhou, face a que referência documentada e com que versão do detetor? Um resultado identificado como ANSSI ou CIS deve conduzir a essas evidências. Por si só, não pode estabelecer a conformidade com uma publicação inteira.

Esta comparação separa os dois predicados dos detetores documentados numa análise do collector de setembro de 2026 das recomendações subjacentes. A comparação documental utiliza o CIS Microsoft Windows Server 2012 R2 Benchmark v2.2.0, de 28 de abril de 2016, secções 1.1 e 1.2. Trata-se de uma edição histórica. O catálogo CIS atual lista o Server 2022 v5.1.0, que não foi lido para este artigo.

O nosso guia prático ANSSI para Active Directory explica por que motivo um programa de segurança AD precisa de um conjunto definido de documentos complementares, em vez de uma alegação de conformidade baseada num único PDF.

Como diferem as verificações ANSSI e CIS

A tabela seguinte distingue as recomendações das fontes das condições citadas para Detect(). Os valores descrevem a configuração que satisfaz as condições numéricas citadas, e não as próprias expressões de falha.

A análise do collector cita ad/compliance/anssi/r1-password-policy.go e ad/compliance/cis/password-policy.go. Os ficheiros Go completos não estavam disponíveis para esta comparação. Por conseguinte, a tabela permite tirar conclusões sobre esses excertos; não estabelece ramificações não citadas, tratamento de erros ou cobertura de dados de recolha em falta.

DefiniçãoOrientações do documento ANSSIExcerto do detetor ANSSICIS 2012 R2 v2.2.0 históricoExcerto do detetor CIS
minPwdLengthPG-078 R21: o comprimento depende do nível de segurança exigidoPelo menos 12 caracteresSecção 1.1.4: pelo menos 14 caracteresPelo menos 14 caracteres
pwdHistoryLengthAs recomendações PG-078 citadas não estabelecem o limiar de 12 palavras-passe do detetorPelo menos 12 palavras-passeSecção 1.1.1: pelo menos 24 palavras-passePelo menos 24 palavras-passe
lockoutThresholdPG-078 R10: limitar as tentativas de autenticação ao longo do tempo; o intervalo fixo do detetor é distinto1–10 tentativas falhadasSecção 1.2.2: 1–10 tentativas falhadas1–5 tentativas falhadas
maxPwdAgePG-078 R24/R25 distinguem contas comuns de contas privilegiadasSem teste de antiguidade no predicado citadoSecção 1.1.2: diferente de zero, no máximo 60 diasDiferente de zero, no máximo 365 dias
minPwdAgeNão se atribui aqui um limiar numérico correspondenteSem teste no predicado citadoSecção 1.1.3: pelo menos 1 diaPelo menos 1 dia
Complexidade, representada em pwdPropertiesPG-078 R23: implementar regras de complexidadeNão documentada no excertoSecção 1.1.5: ativadaNão documentada no excerto

As fontes das colunas documentais são ANSSI-PG-078 e o PDF histórico CIS Server 2012 R2 v2.2.0. As colunas dos detetores provêm dos predicados citados, reproduzidos abaixo. São limiares de implementação, não uma atribuição de todos os números à ANSSI. As diferenças de 60/365 dias e 10/5 tentativas mostram também por que motivo uma alegação ao nível documental deve indicar a edição.

A complexidade é uma questão separada

A Microsoft define pwdProperties como um campo de bits da política do domínio para complexidade e restrições de armazenamento. O seu sinalizador DOMAIN_PASSWORD_COMPLEX tem o valor 1. Inspecionar comprimento, histórico e antiguidade não permite estabelecer o estado desse sinalizador.

Uma avaliação completa deve, portanto, registar explicitamente a complexidade. Os excertos fornecidos para estas duas verificações não mostram uma condição de complexidade. É uma limitação da evidência de implementação disponível, não uma prova de que os detetores completos a ignoram. Não transforme um campo não documentado numa aprovação presumida.

Casos em que os resultados divergem

Estes exemplos são configurações hipotéticas avaliadas face aos predicados numéricos citados. Não são resultados de um ambiente de cliente nem de uma execução real do collector. Para estes exemplos, assume-se que as durações são expressas em dias, que a ausência de expiração é representada por maxPwdAge == 0 e que os restantes campos contêm valores válidos. Estas suposições correspondem às comparações citadas; a conversão dos valores do diretório pelo collector não foi verificada.

ExemploComprimento mínimoHistóricoLimiar de bloqueioAntiguidade máximaAntiguidade mínimaExcerto ANSSIExcerto CIS
Comprimento abaixo do mínimo CIS12245365 dias1 diaSatisfeitoFalha no comprimento
Histórico abaixo do mínimo CIS14125365 dias1 diaSatisfeitoFalha no histórico
Mais tentativas falhadas permitidas142410365 dias1 diaSatisfeitoFalha no limiar de bloqueio
Política predefinida sem expiração14245Sem expiração1 diaSatisfeitoFalha na antiguidade máxima
Alterações imediatas de palavras-passe14245365 dias0 diasSatisfeitoFalha na antiguidade mínima
Referência numérica comum14245365 dias1 diaSatisfeitoSatisfeito

Cada linha isola uma razão para a divergência. Uma política real pode falhar várias condições em simultâneo; por isso, retenha todos os atributos em falha, em vez de comunicar apenas o primeiro encontrado. Isto torna o plano de correção específico: uma falha no histórico exige uma alteração do histórico, enquanto uma falha na antiguidade exige uma decisão explícita sobre a expiração.

Pode acontecer o inverso?

Para estes predicados citados com as mesmas entradas válidas, satisfazer as condições numéricas CIS implica satisfazer as condições numéricas ANSSI. Um comprimento mínimo de 14 também cumpre 12; um histórico de 24 cumpre 12; um limiar de bloqueio entre 1 e 5 também está entre 1 e 10. As condições de antiguidade exclusivas do CIS acrescentam requisitos sem flexibilizar os requisitos comuns.

Não existe, portanto, um exemplo demonstrado de aprovação CIS e falha ANSSI para este par de excertos. Se uma auditoria comunicar essa combinação, compare os valores recolhidos, a versão do detetor e os detalhes completos das constatações antes de a explicar como uma diferença entre normas. Entradas, implementações ou âmbitos de auditoria diferentes exigem evidências próprias.

A última linha também não estabelece a conformidade completa com o benchmark. Diz apenas que estas cinco entradas numéricas satisfazem as expressões citadas. A complexidade continua a exigir uma verificação separada, e um benchmark completo contém controlos adicionais.

Deteção: ler a política de palavras-passe predefinida do domínio

Utilize o módulo PowerShell do Active Directory para recolher a política predefinida do domínio. Substitua o domínio de exemplo pelo domínio em análise:

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' |
    Select-Object DistinguishedName, MinPasswordLength, PasswordHistoryCount,
        LockoutThreshold, MaxPasswordAge, MinPasswordAge, ComplexityEnabled

Esta é uma única pipeline de leitura baseada na documentação Microsoft de Get-ADDefaultDomainPasswordPolicy. Não foi executada num domínio real para este artigo.

Leia o resultado como evidência relativa a um domínio e a um momento de recolha específicos. Preserve o distinguished name juntamente com os valores, para que uma revisão posterior possa determinar se os dois resultados de auditoria descrevem realmente a mesma política. Não compare uma definição GPO recordada de memória com um resultado recente do collector assumindo que têm entradas idênticas.

MinPasswordLength é uma contagem de caracteres. PasswordHistoryCount corresponde ao número de palavras-passe retidas; a página de esquema Microsoft de pwdHistoryLength documenta o atributo do diretório. As propriedades de antiguidade são durações, enquanto comprimento, histórico e limiar de bloqueio são contagens. Mantenha essas unidades explícitas ao transferir evidências para uma folha de auditoria.

O comando devolve a política predefinida do domínio. Não estabelece a política efetiva de cada utilizador quando se aplicam políticas de palavras-passe granulares. A Microsoft documenta uma consulta separada da política de palavras-passe resultante para utilizadores; não alargue um resultado relativo à política predefinida do domínio a uma alegação de conformidade conta a conta.

Correção (Remediation): corrigir o atributo em falha face a uma referência identificada

Primeiro, decida que referência e edição regem a alteração. Documente o resultado exigido e, depois, altere os atributos que não o cumprem. Uma definição que elimina uma constatação pode deixar outra intacta, como mostra a tabela de exemplos.

Para um exemplo que satisfaça ambos os predicados numéricos citados e os critérios numéricos da tabela histórica, utilize comprimento 14, histórico 24, limiar de bloqueio 5, antiguidade máxima de 60 dias e antiguidade mínima de 1 dia. O valor de 60 dias provém da secção histórica CIS 1.1.2; a escolha mais restritiva de 5 tentativas provém do excerto do detetor CIS. Ative a complexidade para o critério separado de complexidade do documento citado. Este é um exemplo de comparação, não uma recomendação para adotar hoje um benchmark histórico.

O exemplo de configuração seguinte utiliza parâmetros documentados pela Microsoft para Set-ADDefaultDomainPasswordPolicy:

Set-ADDefaultDomainPasswordPolicy -Identity 'example.com' `
    -MinPasswordLength 14 -PasswordHistoryCount 24 -LockoutThreshold 5 `
    -MaxPasswordAge '60.00:00:00' -MinPasswordAge '1.00:00:00' `
    -ComplexityEnabled $true -WhatIf

-WhatIf apresenta uma pré-visualização da operação proposta sem a aplicar. Este exemplo foi verificado face à documentação; não foi executado num domínio real. Um administrador deve testar a alteração pretendida, aplicá-la através do processo de gestão de políticas da organização e repetir a consulta de leitura acima. Uma pré-visualização não é um resultado de correção bem-sucedida.

Decidir deliberadamente sobre a expiração

ANSSI-PG-078 R24 desaconselha a expiração por defeito para contas não sensíveis quando palavras-passe robustas e sistemas de suporte o permitem; R25 mantém a expiração para contas privilegiadas. O texto anterior privilegia a autenticação de dois fatores para essas contas e aborda a expiração quando se utiliza autenticação apenas por palavra-passe. Essa distinção entre contas não pode ser estabelecida por um único valor de antiguidade para todo o domínio. A ausência de uma constatação de antiguidade do detetor ANSSI não valida toda a política de expiração.

Se a referência escolhida exigir uma antiguidade máxima diferente de zero, mantenha esse requisito ou documente a exceção através do seu processo de auditoria. Eliminar uma constatação do painel e justificar uma exceção são resultados diferentes; registe qual deles alcançou.

Verificar a alteração e a exposição restante

Retenha o resultado da política antes e depois da alteração, a edição da referência e a razão de cada atributo alterado. Volte a executar ambas as verificações sobre a mesma recolha recente e analise individualmente quaisquer constatações restantes. Se a configuração mudou, mas a constatação não, concilie o momento de recolha e os valores comunicados antes de fazer outra alteração da política.

A conformidade da política de palavras-passe também exige um contexto operacional. O nosso artigo sobre password spraying explica como algumas tentativas distribuídas por muitas contas podem evitar bloqueios evidentes por conta e por que motivo a mitigação combina controlos de palavras-passe, autenticação mais forte e monitorização correlacionada. Passar uma verificação do limiar de bloqueio não deve ser usado como evidência de que o spraying foi eliminado.

Como a EtcSec deteta este problema

O catálogo do site contém tanto ANSSI_R1_PASSWORD_POLICY como CIS_PASSWORD_POLICY. A análise do collector fornece as seguintes condições de falha para as respetivas implementações de Detect():

ANSSI_R1_PASSWORD_POLICY
ad/compliance/anssi/r1-password-policy.go
minPwdLength < 12 OR pwdHistoryLength < 12
OR lockoutThreshold == 0 OR lockoutThreshold > 10

CIS_PASSWORD_POLICY
ad/compliance/cis/password-policy.go
minPwdLength < 14 OR pwdHistoryLength < 24
OR maxPwdAge > 365 OR maxPwdAge == 0
OR minPwdAge < 1 OR lockoutThreshold > 5 OR lockoutThreshold == 0

Os limiares de antiguidade acima são expressos em dias nesta comparação, de forma coerente com o exemplo maxAge=120j da análise (linha 127). Os excertos não estabelecem como o collector converte intervalos LDAP em bruto nem como representa políticas sem expiração. Explicam por que motivo a mesma política pode gerar constatações diferentes e por que motivo cada constatação deve identificar o atributo em falha.

A evidência de implementação é a análise do collector em docs/research/ad/2026-09-13-ad-catalogue-gap-diff.md, linhas 123 e 124, respetivamente. Estas linhas citam os ficheiros Go identificados; os números de linha do código-fonte Go não estavam disponíveis. Os ficheiros-fonte completos não estavam disponíveis nesta análise. A cobertura de complexidade, o comportamento perante dados em falta e quaisquer outras ramificações não citadas continuam por verificar. Estas constatações são sinais de configuração úteis; os seus nomes não transformam um predicado parcial numa avaliação ANSSI ou CIS completa.

Referências primárias

Explore as paginas de identidade que sustentam este tema