Como auditar Active Directory em um ambiente air-gapped sem falsa confianca
Se voce precisa saber como auditar Active Directory em um ambiente air-gapped, comece por uma pergunta de escopo, nao por uma pergunta sobre ferramenta. Muitas equipes dizem « air-gapped » quando, na pratica, querem dizer « sem acesso direto a Internet », « isolado logicamente » ou « fortemente segmentado ». Essa distincao importa porque o metodo de auditoria, a cadeia de evidencia e os controles aceitaveis mudam conforme o modelo real de conectividade.
A orientacao de implementacao da CISA para a BOD 23-01 deixa esse limite claro: muitos ambientes descritos como air-gapped sao, na verdade, apenas logicamente isolados, e qualquer sistema conectado diretamente ao ambiente operacional, ou conectado a outro sistema que por sua vez esteja conectado a esse ambiente, nao e tratado como fisicamente air-gapped nessa orientacao. Para uma auditoria de Active Directory, essa e uma regra operacional util: nao presuma isolamento apenas porque a rede nao tem navegacao web direta.
Este artigo usa termos praticos de auditoria em vez de afirmar uma taxonomia universal de fornecedor:
| Modelo de isolamento | Significado pratico para uma auditoria de AD | Consequencia para a auditoria |
|---|---|---|
| Sem Internet | O ambiente nao tem acesso direto de saida para a Internet, mas ainda existe roteamento interno local. | Uma auditoria local e viavel, mas fluxos gerenciados pela nuvem podem nao ser utilizaveis. |
| Isolado logicamente | O acesso e restrito por gateways, jump hosts, brokers ou caminhos de transferencia controlados. | O escopo e a transferencia de evidencias importam tanto quanto a propria auditoria. |
| Segmentado | O ambiente e roteavel, mas limitado por firewalls, VLANs ou ACLs. | Trate-o como conectado para riscos de privilegio e protocolo. |
| Fisicamente air-gapped | Nao existe caminho de rede para a Internet nem para o ambiente operacional mais amplo. | Coleta, revisao e exportacao exigem um fluxo totalmente local. |
O ponto nao e semantica. O ponto e evitar falsa confianca. Uma floresta Active Directory isolada ainda pode ter deriva de privilegios, delegacao insegura, configuracoes fracas de protocolo, contas privilegiadas obsoletas, caminhos de GPO gravaveis, certificate templates expostos ou uma audit policy fraca. Se o diretorio muda, ele continua precisando ser medido.
Por que o isolamento nao remove o risco de AD
O isolamento reduz alguns caminhos de ataque externos, mas nao remove o risco de identidade dentro do perimetro que ainda precisa ser defendido. Active Directory continua concentrando grupos privilegiados, configuracoes Kerberos, relacoes de confianca, delegacao, ACLs, Group Policy e, muitas vezes, servicos de certificados. Esses planos de controle continuam sendo criticos para a seguranca, mesmo que o ambiente nunca toque um servico SaaS publico.
E por isso que um ambiente isolado continua precisando da mesma disciplina central de revisao descrita em Como auditar a seguranca do Active Directory: checklist pratica. Grupos privilegiados continuam acumulando excecoes, contas de servico antigas sobrevivem a migracoes e as permissoes do diretorio continuam derivando entre uma limpeza e outra. Se voce ja executa revisoes periodicas, a mesma licao apresentada em Auditoria recorrente de Active Directory: por que auditorias anuais ficam obsoletas e como monitorar a postura continuamente se aplica com ainda mais forca em redes isoladas: uma limpeza pontual nao permanece correta sozinha.
A orientacao da ANSSI de 2023 para administracao segura de sistemas baseados em Active Directory e util aqui porque ela nao trata o AD como um diretorio estatico. Ela o trata como um plano de administracao que precisa ser compartimentado, monitorado e governado com disciplina. Na pratica, isso significa que um AD air-gapped ou isolado ainda deve ser avaliado como um plano de controle vivo, e nao como uma ilha legada que seria mais segura apenas porque e mais dificil de alcancar a partir da Internet.
O que voce pode auditar sem acesso a Internet
Uma revisao offline bem delimitada pode cobrir a maior parte da superficie de controle que realmente importa em um ambiente AD:
- Estrutura de identidade e privilegio: grupos privilegiados, grupos aninhados, direitos delegados, principals com capacidade de DCSync, administradores obsoletos, contas de servico e anomalias de ownership.
- Configuracoes de seguranca do diretorio: LDAP signing, channel binding, exposicao a NTLM, SMB signing, SMBv1, cached logons, politica Kerberos, implantacao de LAPS e configuracao de trusts.
- Integridade de Group Policy e SYSVOL: links de GPO, security filtering, heranca de permissoes, exposicao de senhas em SYSVOL e hardened UNC paths.
- Visibilidade de mudancas: se a audit policy, o desenho de coleta de eventos e o modelo de retencao sao realmente suficientes para detectar localmente alteracoes criticas de AD.
- AD CS, se existir: exposicao do papel de CA, risco de certificate templates, superficies de enrollment e problemas de strong certificate binding.
Por isso, auditar Active Directory offline nao e apenas possivel; muitas vezes e mais concreto do que as equipes imaginam. A Microsoft documenta que os dados de AD sao acessiveis por meio dos protocolos de diretorio e que Group Policy e dividida entre metadados no diretorio e conteudo baseado em arquivos no SYSVOL. Isso significa que uma auditoria offline seria nao precisa se limitar a capturas de tela ou entrevistas pontuais com administradores. Ela pode coletar evidencias diretamente do diretorio e dos compartilhamentos de arquivos associados.
Fontes de dados que devem ser coletadas localmente
A auditoria offline mais confiavel usa varias fontes locais de dados porque uma unica fonte nao responde a todas as perguntas.
| Fonte de dados | O que ela mostra | Por que isso importa offline |
|---|---|---|
| LDAP ou LDAPS | Usuarios, grupos, computadores, atributos relevantes para ACL, configuracoes de delegacao, trusts, politica de senha e Kerberos, metadados de certificate templates | O inventario principal e a analise de misconfiguration saem do proprio diretorio. |
| SYSVOL via SMB | Arquivos de GPO, scripts, configuracoes de policy, artefatos de preferences, indicios de consistencia de replicacao | A seguranca de GPO nao pode ser revisada corretamente apenas por LDAP. |
| Logs de eventos de seguranca | Mudancas no diretorio, mudancas na politica de auditoria, acesso a objetos, logons privilegiados, mudancas de pertencimento a grupos | Voce precisa de evidencia local para deriva e validacao pos-remediacao. |
| Topologia WEF/WEC, se usada | Se os eventos realmente estao centralizados dentro do perimetro isolado | O desenho de coleta local importa quando nao existe caminho para um SIEM em nuvem. |
| Logs de CA e certificados, se AD CS existir | Enrollment, atividade de templates, eventos de emissao e exposicao de papeis | Abuso de certificados continua relevante em ambientes Windows isolados. |
| Metadados do snapshot | Data da auditoria, escopo dos DC, dominios excluidos, hosts inacessiveis, privilegios usados | Sem isso, reruns sao dificeis de comparar e findings ficam dificeis de sustentar. |
Dois detalhes sao faceis de ignorar.
Primeiro, a documentacao da Microsoft sobre Group Policy importa porque toda GPO possui tanto dados de diretorio quanto um componente de sistema de arquivos em SYSVOL. Se voce consultar apenas LDAP, vai perder parte da superficie de policy. Essa e uma das razoes pelas quais auditorias offline frequentemente subestimam riscos ligados a scripts, arquivos de preferences ou integridade de caminhos de policy.
Segundo, use LDAPS em vez de presumir que LDAP em texto claro e aceitavel porque o ambiente e interno. A documentacao atual do collector da EtcSec e explicita nesse ponto em modo standalone: ldaps:// e o caminho suportado e recomendado para coleta de AD, enquanto LDAP sem criptografia nao e a base suportada para producao.
Como construir um workflow de auditoria offline seguro
Um workflow offline defensavel depende principalmente de repetibilidade.
1. Definir exatamente o limite de confianca
Documente se o ambiente e fisicamente air-gapped, logicamente isolado ou apenas desconectado da Internet publica. Se a exportacao de dados for possivel por meio de um jump host, um broker ou um processo manual de transferencia, registre isso. O relatorio de auditoria deve explicar o modelo de conectividade, porque as premissas da revisao dependem dele.
2. Coletar a partir de um host local confiavel
Execute o motor de auditoria a partir de um host dentro do mesmo limite de confianca que o diretorio que esta sendo revisado. Evite laptops administrativos improvisados. Use, quando possivel, um host de revisao dedicado e mantenha a configuracao do collector e seus outputs sob change control.
3. Coletar juntos os dados do diretorio e do SYSVOL
Nao separe a revisao de identidade da revisao de GPO. Em AD isolado, parte da deriva mais perigosa em termos operacionais vive na relacao entre objetos do diretorio e conteudo de policy baseado em arquivos. Por isso, artigos como Ataques NTLM relay: sequestrando autenticacao sem quebrar senhas e SMB Signing Disabled: Why It Still Enables NTLM Relay continuam relevantes em ambientes « offline »: a exposicao subjacente de protocolo e caminho de arquivo e local, nao dependente da Internet.
4. Preservar um snapshot comparavel
Guarde a data da auditoria, o conjunto de domain controllers alcançados, se todos os dominios esperados foram incluidos e se AD CS ou trusts estavam no escopo. Um relatorio sem contexto de coleta e dificil de comparar depois. Se voce quer que as remediacoes se sustentem, precisa de uma baseline limpa de antes e depois, nao de um PDF exportado uma unica vez sem metadados de coleta.
5. Medir novamente depois da limpeza
Depois que os findings forem corrigidos, execute novamente o mesmo escopo e compare as mesmas classes de evidencia. Essa e a unica forma confiavel de provar que a deriva de privilegios, o hardening de protocolos ou a limpeza de policy realmente se mantiveram depois da change window.
Registro de eventos e deteccao em AD isolado
Offline nao significa invisivel. Significa que a visibilidade precisa ser projetada localmente.
A documentacao da Microsoft sobre Windows Event Forwarding e util aqui porque explica o que o WEF realmente faz e o que ele nao faz. O WEF pode encaminhar eventos das fontes para um collector, mas continua passivo em relacao a geracao dos eventos. Ele nao habilita por voce as subcategorias corretas de auditoria e nao redimensiona logs por voce. Se os domain controllers nao estiverem registrando os eventos certos, um Windows Event Collector local apenas centralizara evidencias incompletas com mais rapidez.
Por isso, a configuracao de advanced audit policy precisa fazer parte da propria revisao. A Microsoft tambem recomenda planejamento e validacao piloto antes de uma implantacao ampla, porque as perguntas reais sao volume de eventos, utilidade operacional e se as equipes conseguem entender os eventos que estao coletando.
Para uma revisao de AD isolado, comece com uma baseline local de deteccao mais enxuta:
| Objetivo | Evidencia local a verificar |
|---|---|
| Integridade da audit policy | Mudancas de audit policy como Event ID 4719 e prova de que subcategorias criticas estao habilitadas nos DC |
| Visibilidade de mudancas no diretorio | Cobertura de Directory Service Changes, incluindo Event ID 5136 quando apropriado |
| Acesso a objetos sensiveis | Auditoria de acesso a objetos como Event ID 4662 quando configurada intencionalmente para objetos de alto valor |
| Rastreio de mudancas privilegiadas | Mudancas de membros de grupo, uso de contas admin e padroes de logon privilegiado |
| Centralizacao dentro do limite isolado | Assinaturas WEF/WEC, saude do collector local, retencao e procedimento de exportacao |
Isso nao sao deteccoes baseadas em um unico evento. Sao classes de evidencia que precisam ser correlacionadas com o inventario e com a baseline esperada. Se sua policy diz que ninguem deve obter direitos equivalentes a DCSync e que nenhum grupo privilegiado deve mudar fora de uma janela controlada, seus logs precisam sustentar essa afirmacao localmente.
Se voce precisar de um mapa mais detalhado evento por evento, Monitoramento de segurança AD: eventos que importam aprofunda muito mais o lado de logging de seguranca do Windows.
Findings para priorizar em AD air-gapped
Um ambiente isolado nao deveria alterar muito a ordem das suas prioridades. Ele deveria alterar o metodo de coleta.
Deriva de privilegios e caminhos administrativos obsoletos
Comece pelas mesmas perguntas apresentadas em Desvio de acesso privilegiado no Active Directory: como direitos admin voltam após auditorias e Contas obsoletas e superprivilegiadas no AD: quem esta efetivamente privilegiado hoje, como esse acesso foi obtido e se ele ainda seria aprovado caso fosse revisto agora.
Isso inclui:
- membros diretos e aninhados em grupos privilegiados
- contas com capacidade de DCSync
- direitos delegados que concedem
GenericAll,WriteDACL,WriteOwnerou caminhos equivalentes de escalacao - deriva relacionada a AdminSDHolder
- contas desabilitadas ou dormentes que ainda mantem pertencimento a grupos privilegiados
Hardening de protocolos e superficie de relay
Em seguida, priorize as configuracoes de protocolo que continuam perigosas mesmo dentro de redes isoladas:
- LDAP signing e channel binding
- SMB signing
- exposicao a SMBv1
- configuracoes NTLM e fallback desnecessario
- weak certificate mapping ou emissao insegura de certificados se AD CS existir
Ambientes offline costumam manter configuracoes legadas por mais tempo porque as change windows sao mais dificeis e os testes de interoperabilidade sao mais lentos. Isso nao torna a exposicao menos real.
Higiene de senha de administrador local
Senhas compartilhadas de administrador local continuam sendo um problema de movimento lateral em ambientes Windows isolados. Windows LAPS nao implantado: por que senhas locais compartilhadas ainda importam continua relevante aqui porque o risco e a reutilizacao local de credenciais entre sistemas, nao a conectividade com a Internet.
Kerberos, contas de servico e delegacao
Contas de servico, SPNs antigos, delegacao constrained ou unconstrained e postura de criptografia fraca tambem continuam sendo verificacoes prioritarias em AD isolado. Se o ambiente contiver servidores legados de linha de negocio, a probabilidade de encontrar padroes antigos de contas de servico costuma ser maior, nao menor.
Remediacao e validacao sem dependencia de nuvem
A remediacao em um AD air-gapped deve ser conduzida da mesma forma que qualquer outra mudanca de identidade Windows de alto risco: corrigir a condicao perigosa, executar novamente a mesma coleta de evidencia e provar o resultado dentro do mesmo limite.
⚠️ Aviso: nao trate relatorios exportaveis como prova por si so. Um relatorio so e defensavel se o escopo de coleta, os privilegios usados e o metodo de rerun forem estaveis o suficiente para comparacao ao longo do tempo.
Uma sequencia pratica se parece com isto:
- Remova ou reduza primeiro os caminhos de privilegio de maior risco: contas privilegiadas obsoletas, ACLs inseguras, direitos DCSync desnecessarios, delegacao insegura e configuracoes fracas de protocolo.
- Verifique novamente a integridade de GPO e SYSVOL apos cada mudanca de protocolo ou de policy, especialmente se voce alterou SMB, hardened UNC paths ou administrative templates.
- Valide que a audit policy local continua cobrindo as mudancas que importam para voce e que o desenho WEF/WEC continua capturando essas mudancas quando aplicavel.
- Execute novamente exatamente o mesmo escopo de auditoria e compare findings de antes e depois em vez de confiar em verificacoes manuais pontuais.
- Documente o que ainda permanece intencionalmente aceito por restricoes operacionais, especialmente em ambientes legados isolados nos quais o trabalho de compatibilidade leva mais tempo.
Esse ultimo ponto importa. Em ambientes isolados, excecoes sao frequentemente justificadas como temporarias. Se voce nao as documentar com owner e data de revisao, elas se transformam em arquitetura permanente.
Como a EtcSec suporta auditorias de AD air-gapped
Para esse caso de uso, o limite de produto importante e simples: o modo standalone do collector da EtcSec nao exige dependencia de SaaS. A documentacao local descreve um modo de servidor standalone em que o collector roda dentro do seu ambiente e se comunica localmente com o Active Directory, incluindo LDAP ou LDAPS para os dados do diretorio e acesso SMB ao SYSVOL para revisar Group Policy.
Isso importa em ambientes isolados porque a auditoria pode permanecer dentro do mesmo limite de confianca do diretorio que esta sendo revisado. Para uma avaliacao somente de AD, voce pode manter o escopo local sem presumir acesso de saida a servicos de nuvem.
Quando o ambiente estiver pronto para uma medicao de postura, os checks da EtcSec mais uteis nesse contexto sao os que comprovam a saude dos controles locais, e nao uma exposicao generica a Internet. Exemplos incluem LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, DCSYNC_CAPABLE, ACL_GENERICALL, KERBEROASTING_RISK e ADMIN_SD_HOLDER_MODIFIED.
O ponto central nao e que um AD air-gapped precise de um padrao de revisao diferente. O ponto central e que o workflow de coleta e validacao precisa poder operar localmente, ser executado novamente localmente e ser comparado localmente.
Controles relacionados
- caminhos de administracao dedicados e higiene de workstations privilegiadas
- enforcement de LDAP signing, channel binding e SMB signing
- implantacao de Windows LAPS e rotacao de senhas de administradores locais
- revisao de acessos privilegiados e remocao de caminhos administrativos obsoletos
- desenho WEF/WEC mais advanced audit policy validada nos DC
- revisao de integridade de GPO e SYSVOL
- revisao de AD CS quando existirem servicos de certificados
- nova medicao recorrente em vez de limpeza unica
Referencias primarias
- CISA: BOD 23-01 Implementation Guidance
- Microsoft Open Specifications: MS-ADOD
- Microsoft Open Specifications: MS-GPOD
- Microsoft Learn: Use Windows Event Forwarding to Assist in Intrusion Detection
- Microsoft Learn: Planning and Deploying Advanced Security Audit Policies
- Microsoft Learn: Advanced Audit Policy Configuration Settings
- Microsoft Learn: 4719 System Audit Policy Was Changed
- Microsoft Learn: 5136 A Directory Service Object Was Modified
- Microsoft Learn: 4662 An Operation Was Performed on an Object
- Microsoft Learn: Active Directory Domain Services LDAP Signing Requirements
- ANSSI: Recommandations pour l'administration securisee des SI reposant sur AD
- NIST SP 800-53 Rev. 5
Continue Reading
Requisitos NIS2 para segurança de identidade: o que equipes de AD e Entra precisam comprovar
Desvio acesso privilegiado Active Directory: como direitos admin voltam após auditorias

