Prova de auditoria de arquivos Windows: SACLs, 4656/4663

O que é a Prova de auditoria de arquivos Windows?

A Prova de auditoria de arquivos Windows relaciona a política de auditoria efetiva de um servidor, as regras de auditoria de um arquivo e uma tentativa de acesso controlada aos eventos Security resultantes. Uma configuração de Política de Grupo, por si só, não pode estabelecer essa relação. Antes de alterar a política de produção, use arquivos fictícios para determinar quais identidades e direitos sobre arquivos realmente produzem evidências em um servidor dentro do escopo acordado.

Este guia separa três perguntas: Audit File System está habilitado nesse servidor, o arquivo tem uma lista de controle de acesso do sistema (SACL) correspondente e o evento registrado descreve a operação testada? Mantenha as respostas juntas em um registro de revisão. Um valor de política tranquilizador sem evento correspondente deixa a prova incompleta.

O procedimento abaixo não foi executado em um domínio real. Os comandos usam a sintaxe documentada da Microsoft; caminhos e identidades são exemplos a substituir por valores de teste aprovados. As observações esperadas são critérios de aceitação, não resultados de laboratório relatados.

Como funciona a auditoria de arquivos: política, SACL e acesso

A documentação de Audit File System da Microsoft condiciona a auditoria a uma SACL correspondente: a conta solicitante e o acesso solicitado precisam corresponder às suas entradas. A auditoria de sucesso e de falha atende a resultados diferentes. Habilitar a subcategoria sem regras adequadas de auditoria do objeto não estabelece cobertura no nível do arquivo. A Microsoft também recomenda planejar como os eventos coletados serão analisados e remover regras de auditoria excessivas.

As permissões do arquivo e as regras de auditoria têm funções distintas. Revise a lista de controle de acesso discricionário (DACL) para estabelecer o acesso permitido ou recusado pretendido e, depois, revise a SACL para estabelecer quais tentativas devem ser registradas. Adicionar uma regra de auditoria não é motivo para conceder um direito sobre o arquivo que não estaria autorizado.

Escolha o escopo da prova antes de testar. Quais servidores e direitos sobre arquivos precisam ser demonstrados? Identifique o host, o caminho sintético, a identidade de teste, o aplicativo e a operação. Uma leitura local em um servidor membro sustenta esse caso específico; não estabelece cobertura para todos os servidores ou aplicativos. Mantenha o monitoramento de objetos de diretório separado: nosso guia de monitoramento de AD sobre coleta de eventos, mapeamento de campos e validação explica o fluxo mais amplo de monitoramento de identidades, incluindo eventos de diretório. Aqui, o objeto testado é um arquivo fictício.

Uma solicitação de handle não é um direito sobre arquivo utilizado

Essas distinções vêm da referência de 4656 e da referência de 4663 da Microsoft. Cada evento também exige a entrada SACL pertinente. Neste protocolo, uma leitura de arquivo permitida deve ser avaliada com base em um 4663 correspondente; uma solicitação de handle recusada deve ser avaliada com base em um Failure 4656 correspondente.

Verificação: reunir as evidências antes da remediação

Passo 1: registrar a política efetiva no servidor escolhido

Execute o comando a seguir no servidor que hospeda os arquivos fictícios, usando uma conta autorizada a inspecionar a política de auditoria. A Microsoft documenta a seleção de categorias e subcategorias e a opção de relatório CSV em auditpol get:

auditpol /get /subcategory:* /r

Guarde a saída completa com o nome do servidor, o horário da coleta e o operador. Localize File System e registre suas configurações de sucesso e falha. Em um protocolo que cubra acesso permitido e recusado, estabeleça ambas as configurações antes de esperar os dois tipos de evidência. Se um modo estiver desabilitado, registre essa observação e sua consequência em vez de marcar todo o servidor como verificado.

Mantenha a visão da GPO como um artefato separado. Ela registra a configuração declarada; a consulta local registra a política de auditoria do sistema devolvida por esse host. Se uma política por usuário puder afetar a identidade de teste, inspecione-a também usando o seletor documentado /user. Registre qualquer erro de permissão como uma medição incompleta, não como uma política vazia ou desabilitada.

Passo 2: inspecionar as SACLs dos arquivos fictícios realmente usados

Prepare dois arquivos sintéticos pela configuração de teste aprovada, por exemplo C:\AuditProof\allow.txt e C:\AuditProof\deny.txt. Organize as permissões para que a identidade de teste tenha o direito selecionado no primeiro e não o tenha no segundo. Inspecione ambas as DACLs antes de prosseguir; não presuma que um nome de arquivo torna o acesso permitido ou negado.

A Microsoft documenta -Audit como forma de obter dados SACL em Get-Acl. Estes comandos adaptam os parâmetros documentados aos caminhos ilustrativos. Execute cada linha separadamente em Windows PowerShell ou PowerShell no Windows:

$allowAcl = Get-Acl -LiteralPath 'C:\AuditProof\allow.txt' -Audit
$allowAcl.Audit
$allowAcl.Sddl

$denyAcl = Get-Acl -LiteralPath 'C:\AuditProof\deny.txt' -Audit
$denyAcl.Audit
$denyAcl.Sddl

Guarde as entradas de auditoria e o descritor de segurança devolvidos para cada arquivo, ou o erro exato se a inspeção falhar. Revise a identidade, os direitos auditados, os sinalizadores de sucesso e falha e o escopo de herança. Uma contagem de entradas é insuficiente: a entrada pertinente precisa cobrir esta identidade e esta operação neste objeto. Uma regra herdada deve ser avaliada no arquivo realmente utilizado, não inferida apenas a partir de uma pasta superior.

A decisão aqui é concreta: qual SACL cobre a identidade, os resultados e os direitos necessários sem ruído excessivo ou conteúdo sensível? Informe os direitos selecionados e por que são suficientes para a prova. Evite ampliar o escopo apenas para obter mais eventos.

Passo 3: executar separadamente os casos permitido e recusado

Usando o aplicativo de teste escolhido sob a identidade comum de teste, realize a operação selecionada em allow.txt. Depois, tente a mesma operação em deny.txt. Registre os horários de início e fim, o aplicativo, a identidade, o destino e o resultado observado para cada caso. Evite usar o administrador responsável pela inspeção como identidade do teste de acesso; o protocolo precisa exercitar as permissões em análise.

Em um teste de leitura, leia efetivamente o arquivo fictício permitido em vez de apenas selecioná-lo em um seletor de arquivos. No caso recusado, registre a recusa do aplicativo e inspecione as evidências associadas à solicitação de handle. Se a recusa ocorrer antes de chegar ao arquivo pretendido, o caso ainda não demonstra a auditoria desse arquivo. Mantenha esse resultado visível no registro e investigue o caminho de acesso.

Não espere um número fixo de eventos. Inspecione o log Security do host em Event Viewer durante a janela registrada e filtre por 4656 e 4663. Compare os campos de conta, objeto e acesso com a ficha de teste antes de atribuir um evento a um caso.

Passo 4: preservar o evento e explicar a decisão

Para cada evento pertinente, guarde o XML original do evento no local de evidências aprovado. A Microsoft documenta a identidade e o ID de logon do sujeito, o tipo e nome do objeto, as informações do processo, o ID do handle e os campos de acesso. Em 4663, a lista de acesso descreve direitos utilizados; em 4656, descreve direitos solicitados. Para uma leitura de arquivo, o direito documentado ReadData é 0x1; distinga-o da listagem de diretório ou do acesso somente a metadados ao interpretar o objeto e a operação.

Use o ID do handle para correlação quando disponível, junto com host, horário, sujeito, processo e objeto. A Microsoft indica que o campo do handle pode ser 0x0; ele não deve ser a única chave de associação. Escreva se cada evento preservado sustenta a operação permitida ou a solicitação recusada e o que continua sem prova.

Se o contrato de monitoramento incluir coleta central, localize o mesmo evento nesse local e compare seus campos essenciais. Um evento local e um registro utilizável centralmente são itens de evidência separados. Essa comparação é uma etapa de validação proposta, não uma afirmação de que um collector específico preserva esses campos.

Remediação: corrigir a lacuna demonstrada e testar novamente (Remediation)

Passo 5: alterar a política ou a SACL que falhou na verificação

Se faltar auditoria de sucesso ou de falha em File System, corrija a política aplicável ao servidor escolhido. A documentação de auditpol set permite especificar uma subcategoria por nome ou GUID e habilitar cada resultado. Em um piloto aprovado com nome de subcategoria em inglês, o comando correspondente é:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Trate isso como uma alteração local de piloto, preservando as configurações anteriores para reversão. Em uma implantação gerenciada, corrija a política aplicável pelo processo de alteração de GPO da equipe e verifique novamente o estado resultante do host. Uma resposta bem-sucedida do comando, por si só, não encerra a lacuna de evidências de acesso a arquivos.

Em sistemas localizados, use o nome real ou GUID obtido pelo comando auditpol list documentado pela Microsoft:

auditpol /list /subcategory:* /r

Se a política estiver habilitada, mas a SACL não corresponder, corrija a entrada de auditoria para a identidade de teste, o direito e o resultado escolhidos usando o fluxo aprovado de segurança do objeto. Preserve a DACL e a SACL original para revisão. Repita a inspeção antes de repetir o acesso; alterar as permissões de permitir ou negar mudaria o próprio teste.

Passo 6: resolver divergências de política sem declarar sucesso

Quando as configurações legadas da GPO parecerem corretas, mas o comportamento do host for diferente, inspecione a política avançada aplicável e a opção de segurança de substituição por subcategorias. A Microsoft documenta SCENoApplyLegacyAuditPolicy como forma de impedir a aplicação de políticas no nível da categoria. Nosso guia de políticas de auditoria sobre configurações efetivas e conflitos entre políticas legadas e avançadas fornece o contexto mais amplo da configuração.

A decisão ainda por resolver é quais evidências preservar quando o evento esperado está ausente apesar de uma configuração legada tranquilizadora. Mantenha juntos a saída da política local, a SACL real, o resultado do teste, a janela de busca e o local da coleta. Atribua a divergência a um responsável. Após a alteração direcionada, repita a mesma operação e a revisão de evidências; não substitua um caso não resolvido por um teste mais amplo e fácil.

Como a EtcSec detecta esta situação

No commit do collector bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, HDS_5_4_LOG_ACCESS_TO_HEALTH_DATA lê GPOPolicies e seus valores legados de EventAudit.AuditObjectAccess. O provedor SMB preenche esse campo a partir de [Event Audit] em GptTmpl.inf. Ele coleta o audit.csv avançado separadamente, mas este Detect() não o utiliza.

A condição implementada aceita qualquer GPO coletada não nula com EventAudit não nulo e AuditObjectAccess >= 3. Quando existe alguma GPO assim, Count é zero. Caso contrário, Count é um se a coleção de políticas GPO não estiver vazia; uma coleção vazia também resulta em Count zero. Embora o comentário descreva a exigência de exatamente 3, a condição executável é >= 3.

Consequentemente, uma GPO fora do escopo do servidor testado pode suprimir o resultado. Esta verificação não observa a política efetiva por servidor, SACLs, caminhos de arquivos, tentativas de acesso, classificação de dados de saúde ou eventos Security. Nem um resultado nem Count zero estabelece o desfecho deste protocolo de validação. Use o sinal para solicitar evidências delimitadas ao escopo e documentar seus limites.

Encerrar a revisão com um parecer delimitado ao escopo

Registre um parecer para cada servidor, objeto, identidade e direito: demonstrado, falhou ou incompleto. Inclua os artefatos de política/SACL, o resultado real do aplicativo, os eventos pertinentes, qualquer comparação com a coleta central, a decisão de remediação e o resultado do novo teste. Declare as exclusões explicitamente para que um revisor possa distinguir um caso aprovado com arquivo fictício de uma cobertura que nunca foi testada.

Fontes técnicas e implementação do collector revisadas em 4 de outubro de 2026. Os exemplos continuam sendo um procedimento a executar com dados fictícios aprovados, sem capturar conteúdos de dados de saúde.