Registros de auditoria encadeados por hashes: o que provam e o que não provam

Uma cadeia de hashes pode fornecer evidências fortes de que um conjunto de registros de auditoria não foi editado, reordenado ou discretamente inserido no meio depois que a cadeia foi criada. Ela não prova que o aplicativo registrou todos os eventos relevantes, que um carimbo de tempo corresponde ao horário real ou que uma pessoa identificada realizou uma ação. Tratar a cadeia como prova de tudo isso é a maneira mais rápida de uma equipe montar um pacote de evidências impressionante que desmorona diante da primeira pergunta séria.

Já vi análises de incidentes pararem porque as pessoas pediram a um registro respostas que ele nunca foi projetado para fornecer. A cadeia foi verificada sem problemas, mas ninguém conseguiu determinar se o serviço havia registrado a solicitação negada, se a identidade do operador era verdadeira ou se o relógio do sistema havia sofrido desvio. A criptografia estava correta. O pacote de evidências estava incompleto.

Para desenvolvedores que executam agentes com acesso a APIs e SSH, essa distinção é ainda mais importante. Um agente pode realizar muitas ações rapidamente, e a pergunta posterior costuma ser precisa: qual processo solicitou essa chamada, sob qual autoridade, qual solicitação exata o executor enviou, o que voltou e alguém aprovou a ação? Uma cadeia de hashes protege parte dessa história. O restante precisa ser registrado por você.

Uma cadeia válida prova a continuidade dos registros, não a realidade

Uma cadeia de hashes válida prova que cada registro disponível inclui um compromisso com o registro anterior e que a sequência permaneceu internamente consistente desde o ponto inicial escolhido. Se alguém alterar um evento antigo, trocar dois eventos de posição ou inserir um registro entre dois registros existentes, a verificação falhará, a menos que essa pessoa consiga recalcular todos os vínculos posteriores e substituir todos os checkpoints confiáveis.

Isso é uma evidência importante. Ela permite que um investigador diga: «Estes registros formam a mesma sequência que produziu esta cabeça de cadeia conhecida». A formulação importa. A afirmação depende de uma cabeça de cadeia conhecida ou de outra referência confiável. Se a única cópia da cadeia e seu resumo final estiverem na mesma máquina controlada por um invasor, ele poderá reescrever os dois.

Uma cadeia de hashes não prova estas afirmações:

• O aplicativo observou todos os eventos que deveriam ter sido registrados.
• O conteúdo do evento descreve com precisão o que aconteceu fora do registrador.
• O horário do evento corresponde a um relógio confiável.
• Uma pessoa, e não um processo comprometido usando a credencial dela, causou a ação.
• A cadeia começou antes de um invasor obter o controle do sistema.

Essas são proposições diferentes, que exigem evidências diferentes. Não chame um registro de «à prova de adulteração». Um software não recebe esse status por usar SHA-256. Uma cadeia torna as alterações detectáveis sob determinadas premissas. Essa é a propriedade útil e defensável.

A diferença entre integridade e completude merece atenção especial. Integridade pergunta se os registros disponíveis foram alterados. Completude pergunta se há registros faltando. Uma cadeia responde bem à primeira pergunta. Ela só ajuda com a segunda quando evidências externas definem os checkpoints esperados e o conjunto de eventos que o registrador deveria emitir.

O formato do registro determina o que o hash realmente cobre

Uma cadeia protege apenas os bytes que entram no resumo. Antes de discutir algoritmos, defina um formato canônico para os eventos e inclua todos os campos de que um investigador precisará para interpretar a ação.

Um registro mínimo pode ter esta aparência:

{
  "sequence": 1842,
  "event_id": "7b2ea6de-9c3f-4bb4-b1d7-8b13fbb1c5b9",
  "recorded_at": "2025-03-08T17:14:22.481Z",
  "actor": {"kind": "agent_process", "process_id": "p-91f"},
  "action": "http.request",
  "target": "api.example.internal/v1/releases",
  "request_digest": "sha256:...",
  "result": {"status": 201, "response_digest": "sha256:..."},
  "previous_hash": "sha256:..."
}

O gravador serializa o registro de uma única forma definida, aplica hash a esses bytes e armazena o resumo resultante como referência do predecessor no registro seguinte. Conceitualmente:

record_hash[n] = SHA-256(canonical_record[n])
canonical_record[n+1].previous_hash = record_hash[n]

O campo previous_hash precisa estar nos próprios bytes cobertos por record_hash[n]. Omiti-lo é um erro de implementação constrangedor, mas real. Nesse projeto, os registros carregam elementos decorativos em formato de resumo sem vincular a sequência.

A canonicalização não é um detalhe. Dois serializadores JSON podem ordenar os campos de um objeto de maneira diferente, escapar Unicode de formas diferentes ou formatar números de maneira diferente. Um verificador que reconstrói o JSON, em vez de verificar os bytes armazenados exatos, pode rejeitar registros legítimos ou, pior, criar divergências sobre o significado do registro. Armazene a representação original em bytes, especifique a codificação e teste a verificação com implementações independentes.

A cadeia deve cobrir o contexto, não apenas o corpo da solicitação. Um registro que diz «implantado» é uma evidência fraca. Um registro que vincula a versão do executor, o tipo de ação, o identificador do alvo, a identidade autenticada do processo, a decisão de autorização, o resumo da solicitação, o resumo da resposta, o número de sequência e o horário registrado oferece algo que um revisor pode avaliar. Isso ainda não prova que cada campo é verdadeiro, mas impede que um editor posterior altere a história campo por campo.

A publicação especial 800-92 do NIST, Guide to Computer Security Log Management, apresenta o mesmo ponto prático em termos operacionais mais simples: os registros precisam conter informações suficientes sobre evento, origem, usuário, status e horário para permitir a análise, e as organizações precisam proteger os dados dos registros. Uma cadeia perfeita em torno de registros vagos preserva registros vagos com perfeição. Isso não é um projeto de auditoria.

O primeiro registro e a cauda ausente continuam expostos

Toda cadeia tem um primeiro registro, frequentemente chamado de registro gênese. Seu valor predecessor é definido por convenção, como o resumo de uma sequência vazia de bytes, ou faz referência a um checkpoint anterior. A cadeia pode estabelecer continuidade depois desse ponto. Ela não consegue estabelecer por que esse ponto é o início da história.

Considere um serviço que grava os registros de 1 a 10.000 no armazenamento local. Um invasor obtém controle total, exclui os registros de 1 a 7.000, altera o campo de sequência dos registros restantes e cria uma nova cadeia a partir do que antes era o registro 7.001. A cadeia forjada é validada. Um revisor sem um checkpoint anterior não encontra nenhum defeito criptográfico.

O mesmo problema existe na cauda. Uma falha, perda de energia ou invasor pode impedir que os últimos eventos cheguem ao armazenamento persistente. O último registro mantido pode ser validado corretamente, mesmo que uma ação tenha ocorrido momentos depois. A cadeia prova que o fim retido não foi alterado posteriormente. Ela não prova que esse é o verdadeiro evento final.

Você reduz essas duas lacunas emitindo checkpoints fora do controle do gravador. Um checkpoint contém pelo menos o identificador da cadeia, o número de sequência, o resumo do registro e o horário do checkpoint. Envie-o para uma conta separada, um armazenamento de gravação única, um serviço externo de carimbo de tempo ou um coletor administrado de forma independente. Um checkpoint assinado é melhor que um não assinado porque vincula a declaração a uma identidade de assinatura.

A RFC 3161 descreve um protocolo de carimbo de tempo em que uma autoridade assina evidências de que observou uma impressão de mensagem em um horário determinado. Isso pode sustentar uma afirmação limitada e útil: a autoridade tinha esse resumo até aquele horário. Não informa se o conteúdo do evento era honesto, se eventos anteriores foram omitidos antes do checkpoint enviado ou se o ator tinha autorização. Use esse recurso para evidências de horário e existência, não como substituto dos registros operacionais.

A frequência dos checkpoints é uma decisão de risco. Checkpoints frequentes reduzem o intervalo em que alguém pode remover uma cauda ainda não ancorada. Eles também criam mais registros externos para reter e reconciliar. Não finja que checkpoints horários protegem uma reconstrução de incidentes em escala de minutos. Declare o intervalo máximo sem ancoragem no seu procedimento operacional.

Um hash não transforma um carimbo de tempo em horário confiável

Um carimbo de tempo no registro informa o que o relógio do registrador indicava quando ele criou o registro. Isso pode ser suficiente para depuração comum. É uma evidência fraca para perguntas que envolvem prazos, janelas de negociação, acesso após o encerramento de uma conta ou a ordem de eventos entre máquinas.

Um administrador pode alterar o relógio local. Uma máquina virtual pode retomar a execução com um horário antigo. A sincronização de horário pela rede pode falhar. Mesmo um host corretamente sincronizado registra quando o aplicativo gravou o evento, o que pode ser diferente do momento em que um serviço remoto recebeu a solicitação ou confirmou a alteração.

Mantenha estes horários separados quando a distinção for importante:

• observed_at: quando o componente de origem observou o evento.
• recorded_at: quando o gravador de auditoria criou o registro.
• remote_at: horário retornado pelo sistema remoto, se ele fornecer um.
• checkpoint_at: quando uma testemunha independente aceitou uma cabeça de cadeia.

Não transforme tudo em um único campo timestamp. Cada horário tem uma origem e um modo de falha diferente. Assim, o investigador pode trabalhar com um intervalo, em vez de depender de uma precisão falsa.

Se precisar de evidências de horário, registre como o host sincroniza seu relógio, retenha alertas de integridade da sincronização e preserve recibos de checkpoints assinados. Em operações de alto impacto, compare o registro local com o próprio registro de auditoria do serviço remoto. Uma solicitação registrada às 10:02:01 e uma alteração remota registrada às 10:02:05 podem descrever a mesma ação. A cadeia protege seu registro contra edições; a corroboração o conecta ao sistema externo.

Uma recomendação comum diz: «Use um banco de dados somente para anexação e carimbos de tempo, e o problema de auditoria estará resolvido». Ela é popular porque parece operacionalmente simples. Está errada porque o comportamento de anexação dentro de um único serviço pouco informa sobre a confiabilidade do relógio, eventos ausentes, identidade ou efeitos externos. Use armazenamento somente para anexação se fizer sentido, mas deixe claro qual evidência ainda falta.

A atribuição exige uma trilha de identidade fora do resumo

Uma cadeia de hashes pode preservar uma declaração de atribuição como actor = [email protected]. Ela não prova que Alice forneceu a credencial, que o provedor de identidade a autenticou corretamente ou que um invasor não usou a sessão ativa dela. O resumo protege a frase, não a verdade da frase.

Para ações de agentes, a identidade do processo costuma ser mais útil que um campo de usuário vago. Registre o identificador do processo do agente, o processo pai quando disponível, a autoridade de assinatura do executável, o horário de inicialização, o identificador da sessão e a conta humana ou de serviço que autorizou a sessão. O nome do processo, sozinho, é uma evidência fraca. Qualquer programa pode escolher um nome conhecido.

A assinatura de código permite uma afirmação limitada: o sistema operacional pode identificar que um executável possui uma assinatura associada a uma autoridade de assinatura e que essa assinatura é válida segundo as regras da plataforma. Isso não prova que o operador do executável tinha boas intenções. Ajuda a distinguir uma compilação conhecida de um binário arbitrário com o mesmo nome de arquivo.

Autenticação e autorização também precisam de registros separados. Autenticação informa qual credencial ou principal o sistema aceitou. Autorização informa por que o sistema permitiu aquela ação naquele momento. Uma caixa de diálogo de aprovação, atribuição de função, escopo de token ou chamado de alteração pode ser a evidência de autorização. Inclua uma referência estável ou um resumo dessa decisão no registro da ação e mantenha o registro da decisão original sob controles de acesso.

Assinaturas digitais melhoram essa camada quando usadas corretamente. Se um gravador de auditoria assinar cabeças de cadeia periodicamente, um verificador poderá confirmar que o titular de uma chave privada produziu essas assinaturas. Isso acrescenta uma declaração de origem além de um hash sem chave. Ainda depende da custódia da chave privada, do status do certificado, dos registros de rotação e da relação entre o titular do certificado e uma identidade operacional real.

Não esconda tudo em uma única string user. Durante um incidente, as pessoas precisam separar o humano que aprovou uma execução, o processo que solicitou a ação, o serviço que a executou e a autoridade da credencial que a aceitou. Esses podem ser quatro atores diferentes.

A evidência de autorização responde a uma pergunta diferente da atividade

Um registro de atividade responde: «O que o executor fez?». Um registro de autorização responde: «Por que ele pôde fazer isso?». As equipes costumam mesclar os dois porque ambos aparecem durante a mesma solicitação. Essa mistura torna as investigações mais difíceis.

Suponha que um agente solicite um comando SSH. O executor registra o host solicitado, o resumo do comando, o resultado, a identidade do processo e o horário. Separadamente, a camada de autorização registra que um novo processo recebeu aprovação, quem aprovou, o que a aprovação abrangia e quando ela expirava. Se o comando SSH for executado depois, o evento de atividade deverá fazer referência ao registro de autorização aplicável.

Esse projeto permite que o revisor faça as perguntas certas. O comando foi emitido? Confira o registro de atividade. A sessão tinha permissão? Confira o registro de autorização. A tela de aprovação exibiu uma identidade correta? Confira os registros da interface e da identidade do processo. O host remoto executou o comando? Confira os registros do servidor ou o estado resultante.

A aprovação de uma sessão e a aprovação de cada uso de uma credencial sensível produzem evidências diferentes. A aprovação da sessão estabelece que uma pessoa permitiu que determinado processo operasse durante sua existência. A aprovação por ação estabelece uma decisão mais restrita, próxima de uma operação específica. Nenhuma é automaticamente superior. A escolha depende da frequência das ações, do impacto e da possibilidade real de uma pessoa avaliar solicitações repetidas.

A fadiga de aprovação é uma falha de projeto, não um motivo para parar de registrar aprovações. Se uma pessoa vê centenas de solicitações indistinguíveis, os cliques resultantes oferecem pouca evidência de uma autorização consciente. Agrupe trabalhos de baixo risco sob uma decisão de sessão com escopo definido, reserve confirmações repetidas para credenciais ou ações cujo alvo e impacto possam ser avaliados por uma pessoa e registre o escopo em termos claros.

Um evento de aprovação também não prova, sozinho, que houve consentimento informado. Ele prova que o mecanismo de aprovação registrou uma decisão. Os detalhes do processo exibidos ao usuário, a relação entre essa exibição e o processo em execução e o próprio registro de auditoria determinam se a decisão terá peso posteriormente.

A completude depende de onde as ações podem escapar do registrador

Você não consegue obter um registro completo das ações de um agente adicionando uma cadeia de hashes a um arquivo depois que o agente já possui credenciais brutas. Assim que recebe um token de API ou uma chave privada SSH, o agente pode chamar outro cliente, copiar o segredo ou fazer uma solicitação sem usar o caminho auditado. A cadeia pode preservar fielmente as solicitações que viu e deixar de registrar justamente as importantes.

A completude começa pelo controle do limite da ação. O componente que mantém a credencial deve executar a solicitação de rede ou a operação SSH e registrar a decisão e o resultado antes de devolver uma resposta. O agente deve receber o resultado, não o segredo. Isso muda a afirmação de «pedimos ao agente que registrasse seu trabalho» para «o titular da credencial observou cada uso por este canal».

Mesmo assim, o escopo precisa ser explícito. Se um desenvolvedor também puder usar a mesma credencial em um terminal, a trilha cobrirá o uso mediado pelo agente, mas não todo uso da credencial. Se um agente puder alcançar um segundo caminho de rede que contorne o executor, a trilha não cobrirá esse caminho. Uma afirmação de completude precisa indicar o canal, o principal e o período abrangidos.

O Sallyport segue esse limite para seus canais HTTP e SSH compatíveis: o cofre criptografado mantém as credenciais de API e SSH fora do agente, enquanto o aplicativo executa a ação e a registra. Isso dá à trilha de auditoria um escopo mais forte que o de um registro de atividade mantido pelo agente, mas não permite fazer afirmações sobre ações realizadas por um caminho de credencial não relacionado.

Um teste de falha útil é desenhar todas as rotas entre um agente e um efeito externo. Inclua clientes HTTP diretos, ferramentas de shell, arquivos locais que contenham tokens, sessões de navegador, serviços de metadados em nuvem, variáveis de CI e configuração SSH. Cada rota fora do executor registrado é uma exceção a qualquer afirmação de completude. Feche-a, isole-a ou registre a exceção com honestidade.

Confidencialidade, acesso e retenção precisam de controles próprios

As cadeias de hashes não revelam nada por si mesmas, mas os registros de auditoria costumam conter informações que você não colocaria em um registro comum da aplicação. URLs de solicitações podem revelar identificadores de clientes. Linhas de comando podem conter segredos. Respostas podem conter dados pessoais. Uma cadeia que dificulta alterações nesses registros também pode tornar difícil desfazer uma divulgação descuidada.

Criptografe o armazenamento de auditoria e restrinja quem pode lê-lo. Quando possível, mantenha separada a capacidade de verificar a integridade e a capacidade de descriptografar o conteúdo. Um verificador pode recalcular hashes sobre os bytes criptografados dos registros e comparar as referências aos predecessores sem ver o conteúdo protegido. Isso é útil quando um revisor precisa confirmar que um arquivo selado continua íntegro antes de um investigador autorizado abri-lo.

A redação deve ocorrer antes que o registro entre na cadeia. Substituir um segredo depois de gravá-lo altera os bytes e quebra a cadeia. Em vez disso, registre um resumo do corpo sensível da solicitação, uma referência estável ao token, informações de tamanho quando apropriado ou uma declaração estruturada de que um campo foi omitido. Documente a regra de redação. Caso contrário, dois registros parecidos podem ter sido redigidos por lógicas diferentes.

A retenção também afeta o valor probatório. Se uma tarefa de retenção excluir registros antigos, ela deverá produzir seu próprio registro, identificando o intervalo excluído, a regra de retenção aplicável, o horário da exclusão e o último checkpoint antes dela. Preserve o checkpoint em um arquivo separado. Uma cadeia não pode fazer o material excluído reaparecer, mas as evidências retidas podem mostrar que a exclusão ocorreu segundo um processo definido, em vez de silenciosamente.

O registro de acesso também importa. Registre quem exportou um arquivo de auditoria, quem o descriptografou e quem alterou a configuração de retenção. Os registros de auditoria atraem atenção durante um incidente. A cadeia protege os registros antigos contra alterações discretas, mas um grupo amplo de leitores ainda pode copiar conteúdos sensíveis ou pressionar um operador a suprimir registros futuros.

Verifique o arquivo antes de precisar dele

A verificação deve ser uma operação rotineira com resultado salvo, não um comando que alguém tenta pela primeira vez durante uma interrupção. Seu procedimento deve identificar o intervalo exato do arquivo, a versão do verificador, a origem do checkpoint esperado, o horário da verificação, o operador e o resultado.

Um verificador precisa detectar pelo menos quatro falhas: registros malformados, uma referência incorreta ao predecessor, um registro cujo resumo não corresponde aos bytes armazenados e uma divergência entre a cabeça calculada e um checkpoint esperado. A saída deve ser fácil de preservar. Por exemplo:

$ audit verify --archive agent-actions-2025-03-08.log --checkpoint checkpoints/2025-03-08.json
chain_id: agent-actions-prod-a
records_checked: 1842
first_sequence: 1
last_sequence: 1842
computed_head: sha256:4e7c...a912
checkpoint_head: sha256:4e7c...a912
result: VALID

Um resultado VALID significa que o verificador conferiu os bytes fornecidos contra o checkpoint fornecido. Não significa «todas as ações de produção estão presentes» ou «os eventos são verdadeiros». Escreva essa limitação diretamente no procedimento. Sob pressão, as pessoas que leem um resultado verde podem atribuir a ele um significado maior do que realmente tem.

Teste casos destrutivos em um arquivo que não seja de produção. Altere um byte no corpo de um registro. Mova dois registros. Exclua um registro do meio. Substitua a cabeça do checkpoint. Trunque a cauda. O verificador deve rejeitar cada caso, exceto o truncamento normal da cauda sem um checkpoint final esperado, situação em que pode informar um prefixo válido. Esse resultado está correto e deve causar preocupação pelo motivo certo.

O Sallyport oferece verificação offline da cadeia por meio de sp audit verify, e seu verificador consegue conferir a cadeia de auditoria criptografada sem uma chave do cofre. Execute essa verificação depois das exportações e pratique a reconciliação com as visualizações separadas de sessão e atividade antes que uma investigação exija esse trabalho.

Um pacote de evidências precisa de registros que discordem de forma produtiva

Uma investigação defensável usa vários registros com modos de falha diferentes. A concordância entre fontes independentes tem mais peso que um único registro que repete suas próprias premissas.

Para uma ação sensível de um agente, retenha o registro de atividade encadeado por hashes, o registro da sessão ou da aprovação, a identidade autenticada do processo, a versão de configuração relevante, o recibo do checkpoint externo e o próprio registro do sistema-alvo ou o resultado observável. Você não precisa de todas as fontes para cada solicitação comum. Precisa de fontes suficientes para o impacto de estar errado.

Espere que as fontes discordem às vezes. O registro de atividade local pode preceder o carimbo de tempo do serviço remoto porque a entrega pela rede levou tempo. Uma solicitação pode receber uma resposta de sucesso enquanto o sistema remoto reverte a operação mais tarde. Um registro de sessão pode mostrar uma aprovação, enquanto o registro da ação não mostra uso da autoridade concedida. Essas diferenças são evidências a investigar, não defeitos a serem apagados.

Escreva as afirmações exatas que seu sistema consegue sustentar. Por exemplo: «Este arquivo contém uma sequência não modificada de registros do executor até o checkpoint X». Em seguida, escreva as afirmações que ele não consegue sustentar sem outros registros: «Este arquivo, sozinho, não prova que não houve uso direto da credencial». Limites claros tornam as afirmações fortes mais confiáveis.

A primeira ação prática é escolher uma operação de agente de alto impacto e reconstruí-la do início ao fim. Identifique o limite da ação, os campos gravados antes da execução, os campos gravados depois dela, as evidências de aprovação, o destino do checkpoint, a corroboração remota e todos os caminhos alternativos. Se alguma parte depender de alguém se lembrar do que aconteceu, você ainda não tem uma trilha de auditoria. Tem uma história que talvez não sobreviva ao contato com um incidente.