Retencao do log Security no DC: verificar o histórico

O que é uma revisão da retencao do log Security no DC?

Uma revisão da retencao do log Security no DC estabelece quais eventos Security um investigador ainda consegue ler em cada controlador de domínio, nos seus arquivos e no destino central de registos. O resultado útil é um conjunto de evidências datado, associado a uma política organizacional aprovada. Um tamanho máximo de ficheiro configurado, um evento antigo ou uma ligação de encaminhamento saudável representa apenas parte dessas evidências.

Três perguntas precisam de respostas separadas: os eventos necessários foram gerados, continuam legíveis localmente e o sistema central previsto recebeu-os e conservou-os? Comece pelas verificações da política de auditoria efetiva para a geração de eventos. Esse guia utiliza auditpol para examinar as definições de auditoria; esta revisão trata do histórico legível, do comportamento do canal, dos arquivos e da prova de uma cópia central.

Este procedimento abrange os controladores de domínio do Active Directory e os respetivos canais Windows Security. Não avalia a retenção de registos de auditoria do Microsoft Entra. Os comandos abaixo são exemplos baseados na documentação para operadores Windows autorizados; não foram executados num domínio de cliente para este artigo. A documentação e o comportamento do collector foram revistos em 4 de outubro de 2026.

Como funcionam a capacidade do canal e o modo de retenção

A Microsoft documenta três comportamentos relevantes através de wevtutil: com a retenção desativada, os novos registos substituem os mais antigos quando a capacidade é atingida; com a retenção ativada e a cópia de segurança automática desativada, os registos existentes permanecem e os novos registos são descartados quando o registo fica cheio. A cópia de segurança automática exige a retenção ativada e cria uma cópia do registo quando este atinge o tamanho máximo. A definição /ms controla um limite em bytes, não um número garantido de dias. Consulte a referência do comando wevtutil.

Trate cada controlador de domínio separadamente. O histórico de um servidor com pouca atividade não pode representar um controlador mais ocupado, e uma exportação da configuração não substitui uma leitura de eventos bem-sucedida. Guarde as definições efetivas juntamente com as observações, em vez de encerrar a revisão apenas com base nas definições.

Defina a política antes de atribuir um veredito. Peça ao responsável que identifique os conjuntos de eventos, o período necessário, as responsabilidades locais e centrais, os requisitos de acesso e o comportamento de recuperação aceitável. Registe a versão da política e a aprovação. O guia de mapeamento de conformidade associa controlos identificados a evidências de produção; aplique essa abordagem à política de retenção real, em vez de inventar uma duração regulamentar universal.

Deteção: recolher um registo datado para cada DC

Passo 1: ler a configuração efetiva do canal Security

Execute estes comandos localmente em cada DC identificado, com acesso autorizado. A sintaxe está documentada no Learn; Security é o canal selecionado para este procedimento.

wevtutil gl Security
Get-WinEvent -ListLog Security
Get-WinEvent -ListLog Security | Format-List -Property *

A referência de Get-WinEvent documenta -ListLog, as propriedades de configuração, a ordenação dos eventos, -MaxEvents, -Oldest e a leitura de registos guardados através de -Path. Recolha LogMode, MaximumSizeInBytes, FileSize, RecordCount, IsLogFull e LogFilePath quando forem devolvidos. Guarde a saída original, a identidade do host, a hora de recolha com o fuso horário, o operador e o resultado do comando.

Não exclua silenciosamente um DC porque uma leitura falhou. Guarde o erro e classifique as respetivas evidências como indisponíveis até à investigação. Um erro de permissões, um resultado vazio e um registo lido com êxito são resultados distintos. O registo de revisão deve tornar os três visíveis ao responsável.

Passo 2: ler ambas as extremidades da sequência de eventos disponível

Get-WinEvent -LogName Security -MaxEvents 1 -Oldest |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName
Get-WinEvent -LogName Security -MaxEvents 1 |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName

A ordem predefinida apresenta os mais recentes primeiro; -Oldest inverte-a. Guarde os carimbos de data/hora e as identidades devolvidos sem pressupor que provam uma cobertura ininterrupta. Harmonize a apresentação dos fusos horários antes de comparar fontes. Estas leituras limitadas identificam as extremidades da sequência disponível, em vez de calcular os carimbos de data/hora mínimo e máximo de todos os registos.

Para a revisão, anote o período observado e as suas limitações. Se o primeiro registo legível for posterior ao início exigido pela política, investigue se um arquivo ou uma cópia central aprovada fornece o histórico em falta. Se for anterior, continue a verificar os conjuntos de eventos necessários e as interrupções conhecidas. Um carimbo de data/hora antigo, por si só, não estabelece a completude.

Passo 3: registar as evidências e a decisão

Utilize uma linha por DC e depois linhas associadas para arquivos e destinos centrais. Evite uma única célula de aprovação/reprovação para todo o domínio que oculte um servidor inacessível. O seguinte registo de evidências é uma proposta, não uma saída medida:

O revisor deve distinguir uma insuficiência demonstrada de uma pergunta sem resposta. Um arquivo ilegível constitui uma lacuna de evidência, mesmo que o ficheiro exista. Uma consulta central que omite um DC é um teste incompleto, mesmo que o destino devolva muitos registos de outros servidores. Preserve estas distinções no ticket de remediação.

Verificar os arquivos e a cópia central

Um inventário de arquivos deve conduzir a leituras reais. Adapte esta sintaxe documentada de -Path a cada localização aprovada de arquivos Security; o caminho abaixo é um exemplo, não um ficheiro descoberto.

Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1 -Oldest
Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1

Registe as falhas juntamente com as leituras bem-sucedidas. Depois pesquise nos arquivos os conjuntos de eventos e períodos exigidos pela política. Uma amostra legível nas extremidades estabelece apenas que esses registos podem ser abertos; a revisão continua a precisar de uma pesquisa explícita que abranja as perguntas de investigação relevantes.

Para WEC ou outro destino de registos, selecione eventos conhecidos da fonte e localize os registos centrais correspondentes. Guarde o computador de origem, o canal, o fornecedor, o identificador do evento, o carimbo de data/hora e os dados relevantes do evento para comparação. Documente qualquer transformação no pipeline de ingestão, em vez de pressupor que um número de registo atribuído pelo destino é o número do registo de origem.

Separe a receção da possibilidade de pesquisa. O conjunto de evidências deve mostrar o destino central de ingestão e a consulta utilizada por um investigador, incluindo filtros, intervalo temporal e resultado. Um registo visível num registo de entrada, mas indisponível através do percurso de pesquisa aprovado, deixa uma lacuna prática na investigação. Inversamente, uma amostra central bem-sucedida não certifica todos os registos nem todos os DCs.

Remediação: cumprir a política aprovada e testar a recuperação (Remediation)

Passo 1: resolver a lacuna específica

Escolha a alteração com base nas evidências: capacidade local, tratamento de registos cheios, acesso aos arquivos, âmbito da subscrição, armazenamento central ou pipeline de pesquisa. Atribua um responsável e um passo de verificação. As decisões sobre tamanho e modo exigem o volume de eventos esperado e o cenário de interrupção desse ambiente; este artigo não prescreve um limite universal em bytes nem um período de retenção.

Antes de alterar um canal, preserve a configuração atual e as evidências necessárias. Aplique a configuração aprovada através do processo gerido pela equipa e depois repita as leituras da configuração e dos eventos. Registe tanto a definição pretendida como o resultado observado. Não limpe um registo Security para fazer desaparecer uma preocupação antiga sobre retenção, nem trate uma capacidade maior como prova de que o histórico anteriormente perdido regressou.

Passo 2: rever as definições documentadas de entrega WEF

O guia da Microsoft sobre WEF para deteção de intrusões explica que WEF lê eventos existentes do canal; não ativa a sua geração nem redimensiona o registo de origem. O registo local armazena temporariamente os eventos durante a desconexão. A substituição pode causar perda de eventos sem notificação de lacuna ao WEC. O guia também documenta marcadores, heartbeats, a opção de ler eventos existentes e definições de entrega personalizadas.

Estes são parâmetros de exemplo da Microsoft, a rever numa shell com privilégios elevados para uma subscrição de teste aprovada no WEC, não recomendações de dimensionamento de produção:

Wecutil ss "testSubscription" /cf:Events
Wecutil ss "SubscriptionNameGoesHere" /cm:Custom
Wecutil ss "SubscriptionNameGoesHere" /dmi:1
Wecutil ss "SubscriptionNameGoesHere" /dmlt:10

/cf:Events seleciona o formato dos eventos; /cm:Custom seleciona a entrega personalizada; /dmi define o número máximo de eventos por entrega, enquanto /dmlt define a latência máxima de entrega em milissegundos. Substitua os nomes de exemplo apenas depois de rever a subscrição pretendida. Ler eventos existentes pode recolher o histórico disponível; não pode recriar eventos substituídos ou nunca gerados.

Passo 3: validar uma interrupção aprovada

Planeie um teste controlado com o responsável pela monitorização, um âmbito definido, uma condição de paragem e um procedimento de recuperação. Escolha uma atividade inofensiva já abrangida pelas definições de auditoria e pela subscrição necessárias. Registe os eventos correspondentes da fonte antes, durante e depois da interrupção. Especifique antecipadamente quais os registos que deverão ser pesquisáveis centralmente e quando a equipa os irá avaliar.

Restabeleça a recolha e depois verifique esses registos através do percurso central de pesquisa aprovado. Guarde as evidências da fonte, a cronologia da interrupção, as definições da subscrição, os resultados centrais e os erros. Investigue discrepâncias, mesmo que a conectividade tenha sido recuperada. Relate explicitamente qualquer intervalo em falta e identifique se os arquivos sobreviventes ou outra cópia aprovada o podem fornecer.

Passo 4: encerrar a revisão de evidências

O encerramento deve identificar exatamente o que foi avaliado: a população de DCs, os eventos necessários, o período da política, o histórico local disponível, os arquivos, o destino central e o percurso de pesquisa. Anexe as exceções por resolver com o responsável e a data de revisão. Se o teste apenas abrangeu um controlador ou eventos selecionados, indique esse âmbito e agende as verificações restantes.

Mantenha as evidências datadas. Repita a revisão após alterações que afetem a população de DCs, a configuração de registos, os arquivos ou a recolha central. A tarefa útil de manutenção consiste em atualizar a prova subjacente e investigar discrepâncias, em vez de copiar o veredito anterior para um novo relatório.

Como a EtcSec deteta este problema

No etc-collector, no commit 9f698083354a1cb7f625df5cb490a515823c3257, AUDIT_LOG_RETENTION_SHORT emite um único resultado Info com Count=1 constante. O seu Detect() não lê campos de DetectorData e devolve o lembrete mesmo sem dados de DCs. Não mede a capacidade do registo nem a retenção legível, não consegue distinguir um ambiente conforme de um deficiente e não fica automaticamente verde após a remediação.

O percurso de recolha AD inspecionado obtém objetos do diretório e dados de GPO através de LDAP; este detetor não invoca nenhum fornecedor de registos de eventos nem lê um canal Security local. Utilize o lembrete para solicitar as evidências por DC descritas acima, não como prova de um défice de retenção.

Registe a revisão manual e a decisão aprovada juntamente com o lembrete. Mantenha a prova do histórico legível e os resultados da pesquisa central disponíveis para o responsável que aceita o encerramento.