Logs de auditoria criptografados: o que a verificação offline prova

Um log de auditoria criptografado pode fornecer evidências úteis a um revisor externo sem revelar a ele o conteúdo de um único registro. O revisor pode verificar se os registros de texto cifrado ainda formam a sequência esperada, se um registro anterior foi alterado e em que ponto uma exportação deixa de corresponder ao histórico declarado.

Essas evidências têm limites claros. Um resultado de verificação limpo não prova que toda afirmação registrada é verdadeira, que o arquivo começa no primeiro evento ou que um registro de data e hora corresponde ao tempo real. As equipes enfraquecem sua própria narrativa de auditoria quando chamam tudo isso de «integridade». São afirmações diferentes, e um auditor deve pedir evidências diferentes para cada uma.

O texto cifrado pode carregar uma trilha de integridade

Logs de auditoria criptografados permitem a verificação offline porque o verificador não precisa entender um registro para calcular o hash de seus bytes armazenados. Ele só precisa de um formato de registro sem ambiguidades e de uma regra que vincule cada registro ao registro anterior.

Uma cadeia conceitual simples é esta:

record_1 = Encrypt(event_1)
link_1   = H(record_1)

record_2 = Encrypt(event_2)
link_2   = H(link_1 || record_2)

record_3 = Encrypt(event_3)
link_3   = H(link_2 || record_3)

H é uma função de hash criptográfica. O símbolo || significa concatenação de bytes, não uma junção de texto. Um formato de produção precisa definir os bytes exatos, sua ordem e a forma de codificar seus comprimentos. Se uma implementação calcular o hash incluindo uma quebra de linha que outra omite, elas discordarão por motivos banais de formatação, não por motivos relacionados às evidências.

O verificador lê os registros de texto cifrado exportados na ordem. Para cada registro, calcula o próximo vínculo esperado a partir do vínculo anterior aceito e dos bytes do texto cifrado atual. Depois, compara esse valor com o vínculo armazenado no registro atual ou no seguinte, dependendo do formato. Uma divergência significa que a sequência fornecida não corresponde à regra da cadeia.

Criptografia e encadeamento resolvem problemas diferentes. A criptografia impede que o revisor, um operador de backup ou alguém que obtenha a exportação leia URLs de solicitações, argumentos de comandos, corpos de respostas, nomes ou outros detalhes sensíveis dos registros. A cadeia detecta alterações nos bytes protegidos. Criptografar um log sem uma cadeia protege a confidencialidade, mas deixa o revisor sem condições de distinguir um arquivo intacto de outro no qual um registro foi removido discretamente. Calcular o hash do texto simples antes da criptografia pode detectar algumas alterações, mas costuma criar armadilhas de formato evitáveis e, por si só, não dá ao revisor uma sequência contínua para testar.

Assim, um auditor que vê apenas texto cifrado pode fazer uma afirmação precisa: «Dada esta regra de encadeamento e esta âncora, estes registros criptografados não foram alterados nem movidos dentro da sequência fornecida». Essa afirmação é valiosa. Não a transforme em uma afirmação sobre o significado dos registros ocultos.

Uma cadeia válida prova continuidade, não verdade

Uma cadeia de hashes prova uma propriedade restrita de integridade: os vínculos posteriores dependem dos bytes armazenados anteriormente. Ela não prova que o software registrou uma ação corretamente, que registrou todas as ações ou que um funcionário não fabricou um histórico limpo, mas enganoso.

Considere um agente de compilação que envia uma solicitação de implantação. Um logger pode registrar a solicitação antes da chamada de rede, depois dela ou somente após receber uma resposta de sucesso. As três opções podem produzir uma cadeia perfeita. Ainda assim, elas respondem a perguntas diferentes:

• Um registro anterior à chamada mostra uma ação tentada.
• Um registro posterior à chamada pode mostrar que a aplicação chegou ao seu próprio ponto de conclusão.
• Um recibo do provedor pode mostrar que o serviço remoto aceitou a solicitação.
• Uma captura de rede pode mostrar o tráfego, mas talvez não identifique a intenção do usuário por trás dele.

Uma cadeia não resolve essa lacuna semântica. A aplicação decide o que cada registro afirma. O desenho da auditoria precisa declarar esse significado claramente, incluindo se falhas, recusas, novas tentativas, cancelamentos e respostas parciais geram registros.

Essa distinção importa principalmente depois de um incidente. Alguém perguntará: «O agente apagou o repositório?» Um registro local descriptografado pode dizer que o gateway de ações enviou uma solicitação de exclusão. Sozinho, ele não pode provar que o provedor executou a solicitação. Um registro de evento do provedor pode responder a essa pergunta posterior. Por outro lado, um evento do provedor pode provar que uma exclusão ocorreu, mas não mostrar qual processo local a solicitou. Os investigadores precisam combinar evidências, em vez de tratar um único log como uma história completa.

O mesmo problema aparece com a identidade do agente. Um registro pode identificar um processo, uma autoridade de assinatura de código, uma sessão ou uma aprovação de usuário. Essas identidades descrevem atores diferentes. Se o registro disser «sessão 42 do agente», o auditor não deve reescrever isso como «Alice fez isso» sem registros separados que vinculem a aprovação de Alice àquela sessão. A cadeia preserva os bytes. Ela não corrige uma interpretação ampla demais desses bytes.

A primeira âncora confiável define o alcance da prova

Uma cadeia não tem um início significativo até que o auditor possua uma âncora que o autor do log não possa reescrever junto com o arquivo. O vínculo inicial, um resumo de ponto de verificação ou um compromisso assinado pode cumprir esse papel. Sem um deles, um invasor que controle o armazenamento pode apagar o log inteiro, gerar uma cadeia nova a partir de um primeiro registro diferente e entregar uma substituição perfeitamente consistente.

Esse é o erro mais comum em projetos internos. As equipes executam um verificador sobre um arquivo e concluem que o arquivo está completo. O verificador só estabeleceu que o arquivo é autoconsistente. A completude exige um compromisso anterior com um ponto esperado do histórico.

Um ponto de verificação prático contém informações suficientes para que um revisor futuro identifique a afirmação. No mínimo, preserve:

log identity: agent-actions-prod
checkpoint sequence: 18427
checkpoint digest: 7f...c2
record format version: 3
hash algorithm: SHA-256
checkpoint captured by: release-control process
checkpoint captured at: 2025-03-08T18:20:00Z

O resumo acima é apenas ilustrativo. Um registro real de evidências precisa do resumo completo, da codificação exata dos bytes e de uma cópia durável fora do armazenamento do log. Mantenha o ponto de verificação em um sistema com limites de falha e de acesso diferentes. Um commit de controle de versão, um anexo de chamado com acesso restrito, um artefato de release assinado, um armazenamento somente para acréscimos ou um registro mantido por um auditor externo podem ajudar, desde que as pessoas que podem reescrever o log não possam também reescrever silenciosamente todos os pontos de verificação.

Os pontos de verificação também permitem que um auditor verifique um intervalo, em vez de um arquivo inteiro. Se o auditor confia no ponto de verificação da sequência 18.427 e recebe registros até a sequência 19.100, o verificador pode testar se o segmento posterior deriva do ponto confiável. Isso limita a afirmação sobre as evidências a uma janela declarada, o que é melhor do que fingir que o log tem um histórico ininterrupto desde a instalação.

Um ponto de verificação não precisa revelar o conteúdo dos registros. O compromisso pode conter apenas um resumo, um número de sequência, a versão do formato e a identidade do log. Isso torna a ancoragem externa compatível com registros criptografados. Também evita um mau hábito: exportar detalhes sensíveis de auditoria apenas para que outra equipe confirme que o arquivo existia.

Campos de tempo são afirmações até que uma parte independente os vincule

Um registro de data e hora dentro de um registro criptografado pode ordenar eventos de acordo com o relógio do autor, mas não pode, por si só, provar quando um evento ocorreu no mundo externo. Qualquer pessoa que controle o relógio da máquina, o processo ou o formato do log pode criar uma cadeia válida contendo valores de tempo falsos.

As equipes costumam confundir sequência com tempo. Uma cadeia pode estabelecer que o registro 108 veio depois do registro 107 segundo a regra de encadeamento. Ela não pode estabelecer que o registro 108 ocorreu às 09:17 UTC apenas porque o registro contém esse texto. Até contadores monotônicos têm limites: mostram a ordem em um log, mas não informam quanto tempo físico passou entre as entradas.

Se a auditoria precisa de tempo confiável, vincule os pontos de verificação a uma fonte fora do controle do autor. Uma autoridade independente de carimbo de data e hora, um recibo de serviço remoto ou um coletor de eventos administrado separadamente pode acrescentar essa evidência. Cada opção faz uma afirmação de confiança diferente. Um carimbo independente diz que outra parte viu um compromisso no máximo até determinado horário. Um recibo de serviço remoto diz que esse serviço observou uma solicitação ou um resultado. Nenhum deles torna o texto do evento verdadeiro por mágica.

A RFC 3161 descreve um protocolo de carimbo de data e hora no qual uma autoridade devolve um token assinado sobre uma impressão da mensagem, geralmente um hash. Para logs criptografados, a parte útil é essa impressão da mensagem. A autoridade pode registrar um ponto de verificação sem receber os registros criptografados nem suas chaves de descriptografia. A limitação é igualmente importante: o token vincula um resumo ao horário declarado pela autoridade. Ele não inspeciona os registros ocultos, não valida sua semântica nem prova que o resumo enviado representa um arquivo completo.

Problemas de relógio também geram divergências inocentes durante a verificação. Uma estação de trabalho pode estar com o fuso horário incorreto, um processo pode gravar a hora local em vez de UTC ou um operador pode exportar arquivos em uma ordem diferente da ordem dos eventos. Armazene uma representação clara do tempo, mas mantenha o número de sequência da cadeia separado de qualquer afirmação temporal. Durante a revisão, pergunte qual afirmação é necessária: ordem, horário operacional aproximado ou horário testemunhado de forma independente.

A verificação offline precisa preservar os bytes originais das evidências

Um verificador offline verifica bytes, não uma representação desses bytes feita para facilitar a leitura. Uma equipe de auditoria pode invalidar evidências válidas ao abrir uma exportação em um editor, converter finais de linha, serializar JSON novamente, truncar um arquivo durante uma cópia ou combinar segmentos na ordem errada.

Trate a exportação recebida como um objeto de evidência. Copie-a bit a bit para um armazenamento controlado antes que alguém a examine. Registre de onde ela veio, quando o destinatário a recebeu, quem a manuseou e o resumo do arquivo recebido. Esse registro de manuseio não torna uma fonte defeituosa confiável, mas impede que o próprio processo de revisão acrescente ambiguidades.

O fluxo de verificação deve separar coleta, checagem de integridade e acesso ao conteúdo:

1. Preserve a exportação criptografada e calcule um resumo do arquivo para o registro de evidências.
2. Obtenha o ponto de verificação confiável pelo canal independente documentado, não por uma anotação dentro da mesma exportação.
3. Execute o verificador sobre uma cópia de trabalho intocada e retenha o status de saída e a saída produzida.
4. Se a verificação passar, decida se a revisão precisa de descriptografia. Se precisar, conceda esse acesso por um processo separado.
5. Se a verificação falhar, pare de editar e preserve tanto a cópia que falhou quanto o ponto de verificação declarado.

É nessa terceira etapa que um artefato de linha de comando faz diferença. Em uma máquina com as ferramentas de linha de comando do Sallyport instaladas, um auditor pode executar:

sp audit verify

O comando verifica offline a cadeia de hashes criptografada e não precisa da chave do cofre. Preserve a versão da ferramenta, a invocação exata do comando, a identidade do arquivo de entrada caso a ferramenta aceite um caminho de exportação e a saída resultante do terminal junto com o registro do caso. Uma captura de tela é uma evidência fraca porque oculta o executável, os argumentos e a origem da entrada.

Essa verificação deve ocorrer antes de qualquer solicitação de descriptografia. Se a cadeia falhar, abrir os registros pode ajudar a diagnosticar a origem, mas não transforma o arquivo que falhou em evidência intacta. Se a cadeia passar, a equipe de revisão muitas vezes consegue responder a uma pergunta preliminar, como se o histórico exportado mudou depois da coleta, mantendo os segredos operacionais protegidos.

Um vínculo quebrado indica onde investigar, não quem causou o problema

Quando a verificação para por causa de uma divergência, a falha diz que o verificador não conseguiu derivar o vínculo armazenado a partir do predecessor e do texto cifrado fornecidos. Ela não identifica o autor da divergência. Corrupção durante a transferência, uma exportação incompleta, um erro de análise, uma incompatibilidade de versão do formato e uma adulteração deliberada podem produzir o mesmo sintoma inicial.

Trabalhe de trás para frente a partir da primeira relação que falhou. Preserve o último registro aceito, o primeiro registro rejeitado, os vínculos armazenados neles e o ponto de verificação esperado. Depois, compare as cópias das evidências em cada transferência. Se o resumo do arquivo mudou entre o host que o produziu e o armazenamento de evidências, investigue primeiro o transporte ou a coleta. Se permaneceu estável, mas a cadeia falha de forma consistente em uma nova exportação, investigue a aplicação produtora e suas suposições sobre o formato.

Um padrão de falha pode reduzir as possibilidades:

• Uma divergência no primeiro registro fornecido costuma indicar o ponto de verificação errado, um segmento anterior ausente ou uma exportação que começa depois do limite pretendido.
• Uma divergência perto do fim costuma indicar truncamento durante a cópia ou uma gravação parcial que alguém exportou cedo demais.
• Falhas depois de todos os registros normalmente apontam para versões de formato incompatíveis ou para um verificador que calcula uma codificação de bytes diferente.
• Uma única divergência, com registros posteriores que de outra forma seriam encadeados, pode sugerir um registro alterado, danificado ou omitido.

Não repare o arquivo para ver se os registros restantes são verificados. Esse exercício pode ajudar desenvolvedores a depurar um analisador, mas destrói a disciplina necessária para uma conclusão de auditoria. Mantenha uma cópia forense intocada. Crie qualquer derivação de diagnóstico separadamente, documente sua transformação e nunca a substitua pelas evidências originais.

Um verificador bem projetado deve informar detalhes suficientes para apoiar essa investigação sem expor o conteúdo criptografado. Um número de sequência, o deslocamento do registro, o resumo esperado, o resumo observado e a versão do formato normalmente bastam. O relatório deve evitar despejar texto cifrado se essa saída for circular por sistemas de chamados ou conversas. O texto cifrado pode ser ilegível sem as chaves, mas ainda merece controle e pode se tornar sensível se as chaves vazarem mais tarde.

Exclusão e truncamento precisam de defesas diferentes

Uma cadeia detecta uma alteração em um registro intermediário porque os vínculos posteriores deixam de corresponder. Ela também pode revelar a remoção de um registro intermediário quando o próximo registro restante se refere a um predecessor que o verificador não recebeu. Mas uma cadeia simples nem sempre consegue revelar um truncamento no fim.

Imagine um arquivo com os registros de 1 a 500. Um invasor remove os registros de 451 a 500 e entrega ao auditor apenas os registros de 1 a 450. Os primeiros 450 registros podem ser verificados perfeitamente. A cadeia não tem um registro posterior apontando para 451, e o revisor precisa de uma expectativa externa de que o histórico deveria continuar.

Essa expectativa pode vir de um ponto de verificação no registro 500, de uma contagem diária assinada, de um sistema externo que conheça o último número de sequência ou de um processo de retenção que registre os intervalos de exportação concluídos. A afirmação útil é específica: «O arquivo inclui todos os registros até a sequência 500». Uma cadeia sozinha sustenta apenas: «O arquivo fornecido é consistente até a sequência 450».

A exclusão antes do primeiro registro fornecido tem o mesmo problema. Se um revisor recebe uma cadeia que começa no registro 200, não pode inferir se os registros de 1 a 199 existiram. O formato da exportação deve informar se ela é um arquivo completo, da origem ao estado atual, ou um segmento delimitado. Segmentos delimitados precisam de seu ponto de verificação inicial. Arquivos completos ainda precisam de um valor de origem confiável ou de um compromisso externo se um adversário puder substituir o arquivo inteiro.

Contagens de registros ajudam a detectar perdas acidentais, mas não bastam sozinhas. Um arquivo pode manter 500 registros depois que alguém substitui um registro criptografado por outro, e uma contagem não detectará isso. Use contagens como evidência complementar à cadeia e ao ponto de verificação, não como substitutas.

É aqui que uma trilha que evidencia adulterações difere de uma afirmação de armazenamento somente para gravação. A trilha fornece evidências que permitem ao revisor detectar certas alterações. O armazenamento somente para gravação tenta impedir alterações por meio de controles de acesso ou do comportamento do armazenamento. Programas de auditoria fortes usam os dois e testam os dois. Tratar um como prova do outro deixa uma lacuna grande o suficiente para que uma revisão de incidente passe por ela.

O verificador precisa conhecer o formato, não adivinhá-lo

Algoritmos criptográficos não salvam um formato de registro ambíguo. Um verificador precisa de uma especificação exata de como o autor transforma um evento em texto cifrado e de como combina metadados, vínculos anteriores e texto cifrado para calcular o próximo hash.

Evite entradas de hash que dependam de formatos convenientes para exibição. A ordem dos membros de um objeto JSON, espaços em branco, normalização Unicode e campos opcionais podem variar entre implementações embora expressem o mesmo objeto visível. Se a cadeia cobrir JSON serializado, defina uma serialização canônica e teste-a entre implementações em diferentes linguagens. Melhor ainda, encadeie um envelope binário com comprimentos de campos explícitos e bytes de versão.

Um envelope mínimo pode incluir um identificador do log, uma sequência monotonicamente crescente, o resumo do vínculo anterior, o identificador do algoritmo de criptografia, o texto cifrado, a tag de autenticação e uma versão do formato. O autor deve incluir enquadramento suficiente para que o verificador rejeite um registro de outro log em vez de aceitá-lo apenas porque os bytes formam, por acaso, um vínculo válido.

O versionamento exige cuidado. Se a versão 2 alterar o envelope do registro, o verificador deve declarar que aplicou as regras da versão 2 na transição. Não faça um verificador voltar silenciosamente a outro analisador. Esse retorno silencioso transforma um recurso de compatibilidade em uma forma de conceder uma aprovação falsa a evidências malformadas.

A publicação FIPS 180-4 do National Institute of Standards and Technology especifica a família SHA-2 e define a função de hash sobre uma sequência de bits, não sobre a intenção de uma aplicação. Esse detalhe árido traz um alerta prático. A propriedade de integridade está ligada exatamente aos bytes de entrada. Equipes que dizem «calculamos o hash do evento» muitas vezes ainda não decidiram se calculam o hash de uma string UTF-8, de uma linha de banco de dados, de um objeto compactado ou de um envelope criptografado. Enquanto não decidirem, não terão uma verificação de auditoria reproduzível.

Teste o formato com casos deliberadamente difíceis: campos vazios, texto não ASCII, textos cifrados grandes, gravações interrompidas, um registro na fronteira entre versões e registros copiados entre arquiteturas compatíveis. Teste também mutações. Inverta um byte em um texto cifrado, troque dois registros adjacentes, remova um registro do meio e trunque o arquivo. O verificador deve falhar de forma previsível e identificar o primeiro ponto em que sua relação esperada se rompe.

Logs de agentes precisam de dois níveis de evidência

Agentes autônomos geram duas perguntas de auditoria relacionadas: qual execução obteve autoridade e qual ação usou essa autoridade. Uma única linha do tempo pode conter as duas, mas os revisores devem manter as afirmações separadas.

Um registro de sessão responde a perguntas sobre o processo que se conectou ao gateway de ações, a autoridade de assinatura de código associada a esse processo, quando uma pessoa autorizou a execução e quando um operador a revogou. Um registro de ação responde a perguntas sobre uma determinada solicitação HTTP ou SSH executada pelo gateway. Uma execução pode ter uma autorização e muitos registros de ação. Um revisor que vê apenas o histórico da sessão não pode inferir todos os efeitos externos, e um revisor que vê apenas registros de ação pode não saber por que aquele processo tinha autoridade.

O Sallyport mantém um diário Sessions e um diário Activity projetados a partir de um único log de auditoria criptografado, encadeado por hashes e write-blind. Essa organização dá ao auditor duas visões do mesmo histórico protegido, mantendo uma única trilha de integridade para verificação.

A expressão «write-blind» precisa de precisão. Ela significa que o componente que acrescenta evidências de auditoria não deve ter um caminho conveniente para ler e reescrever registros antigos como parte de seu trabalho normal. Isso não significa que o autor do log seja incapaz de produzir afirmações falsas. Um agente comprometido pode solicitar ações prejudiciais. Um gateway comprometido pode registrar dados incorretos e ainda preservar uma cadeia matematicamente válida. O projeto reduz uma classe de risco de reescrita, mas não elimina a necessidade de integridade do software, aprovação de sessões, aprovação de ações quando necessária e comparação com evidências do sistema remoto.

Para ações HTTP, preserve metadados protegidos suficientes para distinguir o destino, o método, a referência da credencial, o contexto de aprovação, a classe do resultado e o identificador de correlação, evitando material secreto no registro. Para ações SSH, diferencie o host pretendido, o limite do comando, o contexto da sessão e o resultado. O registro criptografado pode carregar esses detalhes para investigadores autorizados. O verificador offline não precisa vê-los para testar se a sequência mudou.

Essa separação permite que as equipes enviem um pacote de integridade a um revisor de segurança que não tenha permissão permanente para inspecionar segredos de produção. Ela também torna o trabalho durante um incidente menos caótico. Primeiro, estabeleça se as evidências fornecidas continuam intactas. Depois, conceda o menor acesso de descriptografia necessário para interpretar os eventos.

Uma afirmação de auditoria deve corresponder às evidências que você consegue mostrar

Um relatório de auditoria útil declara seu escopo em linguagem simples. Ele identifica o segmento exportado, o formato da cadeia, a versão do verificador, a origem do ponto de verificação, o resultado da verificação e os limites que permanecem. O relatório pode parecer menos dramático do que «os logs são imutáveis», mas resiste ao escrutínio técnico.

Use uma linguagem como: «O verificador aceitou os registros 18.428 a 19.100 como uma cadeia contínua de texto cifrado, enraizada no ponto de verificação 18.427, que o processo release-control preservou separadamente». Essa afirmação diz o que as evidências sustentam. Se a equipe também tiver um carimbo de data e hora externo assinado, diga isso separadamente. Se tiver comparado determinadas ações com registros de eventos de um provedor, diga isso separadamente também.

Evite frases como «nada foi apagado» a menos que um ponto de verificação final ancorado ou outra fonte independente sustente essa afirmação. Evite «o agente fez isso» quando as evidências identificam apenas um processo local. Evite «neste momento exato» quando o único relógio pertencia ao host sob análise. Essas não são distinções jurídicas. Elas determinam se outro engenheiro conseguirá reproduzir sua conclusão quando o incidente estiver confuso e todos quiserem uma resposta simples.

O primeiro teste operacional é simples: exporte uma amostra que não esteja em produção, preserve um ponto de verificação fora do local da exportação, execute o verificador offline, remova um registro em uma cópia e execute-o novamente. Se a equipe não conseguir explicar os dois resultados e os limites de cada um, ela tem criptografia e hashes, mas ainda não tem uma prática de auditoria capaz de resistir quando o acesso ao texto simples se tornar o ponto em disputa.