Conformidade AD e Azure: NIS2, ISO 27001, CIS

O Que É Conformidade em AD e Azure?

Conformidade em AD e Azure só se torna útil quando os requisitos das estruturas normativas são traduzidos em evidências de produção. Em ambientes construídos sobre o Active Directory e o Microsoft Entra ID, isso significa comprovar como a política de senhas, o acesso privilegiado, o MFA, o registro de auditoria, a governança de ciclo de vida e os controles de acesso de terceiros são efetivamente aplicados.

A parte difícil é a tradução. O texto das estruturas normativas é intencionalmente genérico, enquanto a evidência técnica de que um auditor ou responsável de segurança realmente precisa é específica: qual política de senha está ativa, quais contas administrativas ainda mantêm privilégio permanente, quais proteções de login são aplicadas, quais logs são retidos e quais caminhos de convidado ou entre locatários (cross-tenant) permanecem abertos.

Este artigo mapeia requisitos de conformidade comuns para controles técnicos de identidade que podem ser verificados no AD e no Azure sem transformar o exercício em uma auditoria feita apenas em planilhas.

Como Funciona

Revisões de conformidade focadas em identidade normalmente examinam cinco áreas:

• Política de autenticação, como comprimento e complexidade de senha, MFA e exposição a protocolos legados
• Controle de acesso privilegiado, como escopo de funções administrativas, acesso just-in-time e governança de contas break-glass
• Auditoria e monitoramento, como a Política de Auditoria Avançada nos Controladores de Domínio, os logs de auditoria do Entra e a periodicidade de revisão
• Ciclo de vida de acesso, como provisionamento, limpeza de contas obsoletas e desprovisionamento
• Acesso externo e de aplicativos, como governança de convidados, consentimento de aplicativos e confiança entre locatários (cross-tenant)

Cada área pode ser traduzida em um conjunto de verificações técnicas e evidências de suporte.

Mapeamento de Estruturas de Conformidade para AD e Azure

Diretiva NIS2

O Article 21(1) da NIS2 exige que os Estados-Membros garantam que entidades essenciais e importantes adotem "medidas técnicas, operacionais e organizacionais adequadas e proporcionadas" para gerenciar seus riscos de cibersegurança. Para identidade, isso normalmente se traduz nos seguintes controles:

CIS Controls v8.1

Os CIS Controls transformam o hardening de identidade em ações defensivas priorizadas. A numeração segue o CIS Controls v8.1, a versão atual, e permanece inalterada em relação à v8:

ISO 27001:2022

Os controles do Anexo A da ISO 27001 mais frequentemente mapeados para a segurança de diretórios incluem:

Expectativas de Hardening de Diretório no Estilo ANSSI

Para organizações que buscam alinhamento com as diretrizes no estilo ANSSI, os temas práticos de identidade são consistentes — consulte o Guia ANSSI Active Directory para o conjunto completo de recomendações:

• reduzir a autenticação legada e a criptografia legada onde a compatibilidade de aplicativos permitir
• isolar ou reforçar contas privilegiadas em vez de permitir que identidades de uso diário mantenham privilégio permanente
• documentar exceções para sistemas legados em vez de mantê-las silenciosamente por tempo indeterminado
• validar que os controles de monitoramento, acesso privilegiado e senha estão sendo aplicados em produção, e não apenas declarados em política

A Avaliação de Lacunas de Conformidade

Etapa 1 - Estabeleça a Linha de Base do Seu Estado Atual

# Linha de base da política de senha
Get-ADDefaultDomainPasswordPolicy |
  Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# Linha de base do Acesso Condicional do Entra
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {$_.State -eq "enabled"} |
  Select-Object DisplayName, State

# Linha de base da política de auditoria em um controlador de domínio
auditpol /get /category:"Account Logon","DS Access","Account Management" |
  Select-String "Success|Failure"

Etapa 2 - Mapeie as Lacunas para Controles Nomeados

$policy = Get-ADDefaultDomainPasswordPolicy

# A expiração de senha deliberadamente NÃO é pontuada como um controle. A Microsoft removeu as
# políticas de expiração de senha de suas linhas de base de segurança do Windows em 2019 e chama a
# expiração periódica de "an ancient and obsolete mitigation of very low value" (uma mitigação
# antiga e obsoleta, de valor muito baixo). Capture o MaxPasswordAge como evidência, e só pontue
# quando uma estrutura normativa ou uma política interna ainda exigir rotação.
$policy.MaxPasswordAge

$checks = @{
    "Min password length >= 14"   = $policy.MinPasswordLength -ge 14
    "Password complexity enabled" = $policy.ComplexityEnabled
    "DS Changes audit enabled"    = (auditpol /get /subcategory:"Directory Service Changes") -match "Success"
    "Kerberos audit enabled"      = (auditpol /get /subcategory:"Kerberos Authentication Service") -match "Success"
}

$checks.GetEnumerator() | ForEach-Object {
    [PSCustomObject]@{
        Control = $_.Key
        Status  = if ($_.Value) { "PASS" } else { "FAIL" }
    }
} | Format-Table -AutoSize

Etapa 3 - Priorize pela Exposição, Não pela Contagem de Itens Marcados

1. Crítico: Ausência de MFA para identidades privilegiadas, ausência de controle sobre atribuições de função de alto risco, delegação irrestrita (unconstrained delegation), principais capazes de DCSync
2. Alto: Política de senha fraca, cobertura de auditoria ausente, número excessivo de administradores permanentes, governança fraca de convidados
3. Médio: Contas obsoletas, ausência de LAPS, processo de revisão de funções incompleto, ausência de controles granulares onde necessário
4. Baixo: Lacunas de documentação, inconsistência de nomenclatura, problemas de apresentação não materiais

Detecção

A evidência de conformidade é fraca se existir apenas no momento da auditoria. Os controles que importam devem ser revisáveis de forma contínua.

Verificações Contínuas de Conformidade

# Alteração (drift) em grupos privilegiados nos últimos 7 dias, verificada em cada controlador de domínio.
# O whenChanged NÃO é replicado - cada DC mantém seu próprio valor - portanto consultar um único DC
# perde silenciosamente uma alteração gravada em outro lugar.
$cutoff = (Get-Date).AddDays(-7)
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-ADGroup "Domain Admins" -Properties whenChanged -Server $dc |
      Where-Object {$_.whenChanged -gt $cutoff} |
      Select-Object @{Name="DC";Expression={$dc}}, Name, whenChanged
}

# Contas habilitadas inativas há 90+ dias.
# -Filter não é um script block do PowerShell: ele só aceita <atributo> <operador> <valor>, então o
# limite (cutoff) precisa ser calculado antes. LastLogonDate também não está no conjunto de
# propriedades padrão, então precisa ser solicitado explicitamente ou a coluna volta vazia.
$inactive = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true -and LastLogonDate -lt $inactive' -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate

Remediação

Sequência Prioritária de Remediação

1. Aplicar o MFA para contas privilegiadas e acesso sensível na nuvem
2. Reduzir o privilégio permanente, revisando atribuições de função e usando elevação just-in-time quando disponível
3. Habilitar a cobertura de auditoria nos Controladores de Domínio e no Entra, para que falhas de controle sejam revisáveis
4. Corrigir a higiene de senhas, incluindo comprimento, complexidade, listas de senhas banidas e proliferação de exceções
5. Limpar identidades obsoletas e órfãs no AD e no Azure
6. Revisar o acesso de convidados e entre locatários, para que o acesso de terceiros seja governado
7. Documentar exceções justificadas, com responsável, motivo e data de revisão

Como a EtcSec Detecta Isso

A EtcSec mapeia achados técnicos para as famílias de controles mais frequentemente referenciadas em trabalhos de conformidade.

Cada achado relevante ajuda a responder três perguntas práticas:

• qual controle de identidade está ausente ou fraco
• quais contas, funções ou objetos são afetados
• quais evidências a equipe de segurança deve coletar para comprovar que a lacuna foi fechada

A categoria Compliance é útil quando você quer transformar achados técnicos brutos em um backlog de remediação acionável, em vez de uma planilha genérica de estrutura normativa.

Pacote de Evidências de Conformidade em AD e Azure

Uma revisão de conformidade robusta geralmente falha por dois motivos: o controle nunca foi implementado em produção, ou a equipe não consegue comprová-lo. Construa um pacote de evidências que resista tanto a um questionamento interno quanto a uma auditoria externa:

• saída atual da política de senha e quaisquer exceções granulares aprovadas
• exportações de associação a funções privilegiadas e grupos privilegiados, incluindo atribuições permanentes
• estado do Acesso Condicional ou dos Padrões de Segurança para o locatário em escopo
• saída da política de auditoria do Controlador de Domínio para as subcategorias usadas na detecção
• configurações de acesso de convidados, entre locatários e de aplicativos para as populações cobertas pela revisão
• responsável, motivo da exceção e data de revisão para tudo que ainda não consegue atingir o estado-alvo

Esse pacote de evidências é o que transforma a Conformidade em AD e Azure de um exercício de apresentação em uma revisão de controles repetível.

Executando Uma Revisão em Vez de Três

Organizações que enfrentam a NIS2, a ISO 27001 e os CIS Controls ao mesmo tempo raramente precisam de três ciclos de revisão separados. As três estruturas normativas convergem para o mesmo punhado de elementos primitivos de identidade — MFA, governança de acesso privilegiado, higiene de senhas e cobertura de auditoria — de modo que uma única revisão técnica pode produzir evidências que satisfazem os três mapeamentos ao mesmo tempo.

Uma abordagem prática de sequenciamento:

1. Construa primeiro uma única linha de base de controles. Capture a política de senha, o estado do Acesso Condicional, a saída da política de auditoria e a associação a grupos privilegiados uma única vez. Todo mapeamento de estrutura normativa acima parte do mesmo punhado de pontos de dados.
2. Marque os achados em relação a todas as estruturas que eles satisfazem, não apenas uma. Uma única lacuna de MFA em uma conta de Administrador Global é, simultaneamente, uma lacuna de NIS2 Article 21(2)(j), uma lacuna de CIS Control 6 e uma lacuna de ISO 27001 A.8.5. Registrá-la uma vez com múltiplas marcações evita coletar a mesma evidência três vezes.
3. Priorize pelo valor para o atacante e só depois preencha a papelada. Corrigir primeiro as lacunas de maior exposição — delegação irrestrita, contas capazes de DCSync, acesso permanente de Administrador Global sem MFA — fecha achados nas três estruturas normativas antes mesmo de marcar um único item de conformidade.
4. Mantenha a documentação de exceções em um único lugar. Um aplicativo legado que não suporta MFA é um único registro de exceção, com um único responsável e uma única data de revisão — não três justificativas separadas registradas contra três estruturas normativas diferentes.

Esse sequenciamento é mais importante para equipes que herdaram o trabalho de conformidade como efeito colateral de uma revisão de segurança, em vez de equipes que partem de um documento de estrutura normativa em branco. A evidência técnica subjacente — política de senha, cobertura de auditoria, estado do acesso privilegiado — não muda dependendo de qual estrutura normativa está exigindo.

Lacunas Comuns Que Reaparecem a Cada Trimestre

Mesmo equipes maduras tendem a reabrir as mesmas lacunas de conformidade de identidade:

• exceções de aplicativos legados que silenciosamente preservam autenticação fraca
• identidades privilegiadas obsoletas que nunca foram removidas após um projeto ou mudança de equipe
• exclusões de Acesso Condicional adicionadas durante um incidente e nunca revisadas
• caminhos de acesso de convidados que permanecem mais amplos do que a política escrita permite
• controles de monitoramento que foram documentados uma vez, mas não são mais validados nos Controladores de Domínio atuais ou no escopo atual do locatário

Se essas lacunas não forem rastreadas como dívida operacional com um responsável definido, o mapeamento de conformidade parecerá saudável enquanto a superfície de ataque permanece, em grande parte, inalterada.

Leitura Relacionada

Para o lado técnico das mesmas famílias de controles, consulte Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM, Azure Identity Protection: Bloqueando Credenciais Vazadas, Auditar a segurança do Active Directory: o que revisar primeiro e como comprovar a remediação e Registros de Aplicativo Azure: Apps com Privilegios Excessivos. Esses artigos ajudam a transformar a linguagem das estruturas normativas em passos concretos de hardening e validação.