Quase todas as propostas comerciais de ferramentas de registo, arquivo ou auditoria incluem hoje a palavra «imutável». Armazenamento imutável, logs imutáveis, cópias de segurança imutáveis. A palavra transmite segurança, e é por isso que aparece com tanta frequência. O problema é que descreve uma propriedade do sistema do fornecedor, e não aquilo que um auditor, um regulador ou um tribunal precisa de ver: uma prova que possa ser confirmada de forma independente.
Este guia destina-se a equipas de segurança, conformidade e compras que precisam de avaliar alegações sobre trilhos de auditoria. Não pretende desvalorizar a imutabilidade, que é útil e muitas vezes necessária, mas separar duas perguntas que costumam ser confundidas: «pode este registo ser alterado?» e «consigo provar a um terceiro que não foi?»
Duas propriedades diferentes
A imutabilidade é um controlo preventivo. Um sistema de armazenamento WORM (write once, read many), um bloqueio de objetos com período de retenção ou uma base de dados append-only tentam impedir que um registo seja modificado ou apagado depois de escrito. Se o controlo funcionar como prometido, o registo mantém-se.
A verificabilidade é uma propriedade de evidência. Significa que qualquer parte interessada, com a informação adequada, consegue confirmar que um registo está hoje exatamente igual ao que era num determinado momento, sem ter de confiar na palavra de quem o guarda. A verificação assenta tipicamente em impressões digitais criptográficas (funções de hash), carimbos temporais e num ponto de referência que não é controlado apenas pela entidade que produziu o registo.
As duas propriedades complementam-se, mas não se substituem. Um sistema pode ser imutável e, ainda assim, não oferecer forma nenhuma de o demonstrar fora do próprio sistema. E um registo pode ser verificável mesmo que esteja guardado num suporte comum, desde que a sua impressão digital tenha sido fixada num local independente.
A imutabilidade é uma promessa sobre o comportamento de um sistema. A verificabilidade é uma prova que um terceiro consegue confirmar por si próprio.
Porque é que «imutável» não chega numa auditoria
A confiança continua depositada no operador
Quando um fornecedor afirma que os registos são imutáveis, a garantia depende da configuração correta do sistema, das permissões de quem o administra e da ausência de falhas. Muitos mecanismos de retenção incluem modos que permitem a utilizadores com privilégios especiais encurtar ou remover a retenção. Mesmo nos modos mais estritos, a garantia continua a ser uma afirmação sobre um sistema que o auditor não controla.
A imutabilidade não diz nada sobre o que foi escrito
Um registo imutável preserva fielmente aquilo que lá foi colocado. Se os dados já estavam adulterados no momento da escrita, se um evento nunca chegou a ser registado, ou se um processo automático falhou silenciosamente durante horas, o suporte imutável preserva essa realidade incompleta com o mesmo rigor. A pergunta relevante não é apenas «foi alterado depois?», mas também «está completo e corresponde à origem?».
A prova tem de sobreviver ao sistema
Auditorias, litígios e inspeções regulatórias podem ocorrer anos depois dos factos. Nessa altura, o fornecedor original pode ter sido substituído, o sistema pode ter sido migrado e as pessoas que o configuraram podem já não estar na organização. Uma alegação de imutabilidade raramente sobrevive a uma migração. Uma prova verificável, desde que o método de verificação esteja documentado, sim.
Oito perguntas a fazer a qualquer fornecedor
As perguntas seguintes ajudam a transformar uma alegação genérica numa avaliação concreta. Não existe uma resposta única correta para todas, mas respostas vagas devem ser tratadas como um sinal de alerta.
- Quem consegue verificar, e com que acesso? Um auditor externo consegue confirmar a integridade de um registo sem credenciais de administração e sem pedir ajuda ao fornecedor?
- O que é exatamente selado? O ficheiro completo, cada linha de uma tabela, cada evento de log, ou apenas um resumo diário? A granularidade determina o que é possível provar.
- Onde fica o ponto de referência? Se a impressão digital de referência estiver guardada no mesmo sistema que os dados, quem comprometer um pode comprometer o outro.
- Como é tratado o tempo? O carimbo temporal vem do relógio do servidor ou de uma fonte independente e verificável? Consegue provar que um registo existia antes de uma determinada data?
- Como se deteta uma omissão? Apagar um registo ou deixar de o escrever deixa algum vestígio? Mecanismos como cadeias de hashes ou numeração sequencial permitem detetar lacunas.
- O que acontece com dados pessoais? Se o conteúdo tiver de ser apagado ao abrigo do RGPD, a prova de integridade sobrevive sem expor o conteúdo original? Selar impressões digitais em vez de dados resolve esta tensão.
- Em que formato é exportada a prova? A evidência pode ser entregue a um regulador num formato documentado e verificável com ferramentas comuns, ou só é legível dentro da plataforma?
- Como evolui a criptografia? Existe um plano para substituir algoritmos que venham a ser considerados fracos, sem perder a validade das provas já emitidas?
Como é uma verificação independente na prática
O princípio é simples. No momento em que um registo é criado ou certificado, calcula-se a sua impressão digital com uma função de hash criptográfica, como SHA-256. Essa impressão digital, um valor curto e único para aquele conteúdo exato, é selada com um carimbo temporal num registo independente. O conteúdo original permanece onde sempre esteve.
Mais tarde, para verificar, recalcula-se a impressão digital do ficheiro tal como está hoje e compara-se com a que foi selada. Se forem iguais, o conteúdo não mudou desde o momento do selo. Se diferirem, mesmo que por um único bit, a alteração torna-se evidente. Este processo não exige confiança em quem guarda o ficheiro: exige apenas acesso ao ficheiro, ao registo de referência e a um método de cálculo público.
É este desenho que torna possível, por exemplo, um portal de verificação público onde qualquer destinatário de um relatório confirma a sua autenticidade sem ter conta na plataforma de quem o emitiu.
Sinais de alerta numa proposta
- A palavra «imutável» aparece sem explicação do mecanismo que a garante.
- A verificação só é possível através da interface do fornecedor, com sessão iniciada.
- Não é claro o que acontece às provas se o contrato terminar.
- A deteção de alterações depende de alguém se lembrar de comparar manualmente.
- O fornecedor não consegue explicar como seria detetada a remoção de um registo.
Nenhum destes pontos é, por si só, eliminatório. Mas cada um representa uma parte da cadeia de confiança que continua a depender de uma promessa em vez de uma prova.
Como a ROOTKey ajuda
A ROOTKey foi desenhada em torno da distinção descrita neste artigo. Cada ativo recebe uma impressão digital única, permanentemente selada num registo público independente - um registo com carimbo temporal do seu estado exato. Numa implementação à medida, os dados ficam na sua própria infraestrutura; apenas a impressão digital é registada.
A partir desse selo, a monitorização contínua compara os seus dados com o registo e aciona um alerta perante qualquer modificação. Cada ação é selada com carimbo temporal criptográfico, formando uma cadeia de custódia pronta para auditores e exportável para reguladores. E qualquer destinatário pode confirmar a integridade de um documento emitido através da ROOTKey no portal público de verificação, sem depender da palavra de ninguém.