Registos temporais em blockchain: explicado
Por BlockchainSignPublicado a
Os logs de auditoria têm uma fraqueza estrutural: são normalmente escritos, armazenados e administrados pela mesma organização cujo comportamento registam. Os registos temporais em blockchain são uma resposta a isso, e são mais estreitos e baratos do que o nome sugere.
O problema
Um log de auditoria serve para responder "o que aconteceu, e quando". Funciona bem até alguém com acesso à base de dados ter motivo para o alterar.
As mitigações padrão ajudam, mas não fecham a lacuna. O armazenamento apenas-leitura (write-once) ainda tem um administrador. Enviar os logs para um terceiro transfere a confiança em vez de a eliminar. A cadeia criptográfica — onde cada entrada faz hash da anterior — torna a adulteração detetável dentro do log, mas quem pode reescrever o log pode recalcular a cadeia.
O que falta é uma âncora: um valor publicado num local inacessível ao proprietário do log.
O que são realmente os registos temporais em blockchain
Não, em qualquer design sensato, escrever cada linha do log na blockchain. Isso seria absurdamente caro e publicaria dados que quase certamente não quer tornar públicos.
O padrão prático:
- Os logs são escritos normalmente, com cada entrada a fazer hash da anterior.
- Num intervalo definido — hora a hora, diariamente — o hash atual do cabeçalho (head hash) é escrito numa blockchain pública.
- Essa transação é um compromisso: todas as entradas anteriores ficam agora fixas.
Alterar uma entrada após a publicação da sua âncora exige alterar todos os hashes subsequentes, que já não correspondem ao valor na cadeia. A adulteração torna-se visível para qualquer pessoa que verifique, incluindo pessoas fora da organização.
O custo é uma transação por período, não por entrada.
O que oferece e o que não oferece
| Fornecido | |
|---|---|
| Detetar alteração de entradas passadas | Sim, após a sua âncora |
| Detetar eliminação de entradas passadas | Sim |
| Impedir a alteração | Não — torna-a detetável |
| Proteger entradas desde a última âncora | Não — essa janela está sem âncora |
| Provar que as entradas eram verdadeiras | Não — apenas prova que não mudaram |
| Manter o conteúdo do log privado | Sim — apenas os hashes são publicados |
| Verificável por um externo | Sim |
Dois limites merecem destaque. Tudo o que passou desde a última âncora está desprotegido, pelo que o intervalo de ancoragem é a sua janela de exposição. E uma âncora nada diz sobre se uma entrada era precisa no momento da escrita — apenas que não mudou desde então.
Quando vale a pena
Vale a pena onde o log pode precisar de ser acreditado por alguém com motivos para duvidar de si: manutenção de registos regulamentados, preservação de evidências, registos de cadeia de custódia, sistemas críticos para a segurança, arranjos multipartidários onde cada lado mantém o seu próprio log.
Não vale a pena para logs operacionais comuns. As saídas de depuração (debugging) não precisam de prova de integridade, e adicionar formalidade a isso não ajuda ninguém.
O teste é saber se um externo terá alguma vez de confiar no log. Se a resposta for não, a cadeia criptográfica sozinha é suficiente.
Fazer isto sem uma equipa de blockchain
O mecanismo é simples o suficiente para não precisar de ser um projeto. Calcule o hash do cabeçalho no seu intervalo, registre temporalmente esse único valor e mantenha o certificado junto do ficheiro do log. Isso é um ficheiro por período, e é a mesma operação do que registrar temporalmente qualquer outro documento — a única diferença é o que aponta.
A mesma abordagem cobre casos relacionados: uma exportação noturna da base de dados, um manifesto de compilação, uma versão assinada, uma captura de configuração. Em qualquer lugar onde queira poder afirmar "isto estava exatamente neste estado neste momento" e ter um externo que o verifique.
Veja como registrar temporalmente uma versão de software para a versão deste método focada em artefactos de compilação, e cadeia de custódia para ficheiros digitais para o enquadramento probatório.