A pista de auditoria

01Em uma frase #sec_311beda8

A pista de auditoria regista o que aconteceu no REVIEWIT — quem fez o quê, quando, sobre o quê e com que resultado — sob uma forma que se pode demonstrar que não foi alterada posteriormente.

02Uma precisão de vocabulário #sec_fbdaf12f

No REVIEWIT, a palavra auditoria designa sempre a pista de auditoria: o rasto dos atos realizados no produto.

A aquisição de dados no cliente — o inventário dos sites, dos grupos, dos acessos — chama-se recolha. Os dois não têm nada a ver, e confundir os dois leva a procurar provas onde só há inventário.

03O problema #sec_9df23eaa

Uma ferramenta de recertificação produz provas sobre o sistema de informação do cliente. Uma questão se coloca então imediatamente, e é a primeira que um auditor sério faz:

E a ferramenta em si, o que prova o que fez?

Sem resposta, todo o dispositivo repousa na confiança atribuída ao operador. Ora os gestos que mais contam são precisamente aqueles que um operador mal-intencionado teria interesse em apagar: ter excluído um recurso do perímetro, ter implementado uma delegação, ter anulado uma campanha, ter modificado uma regra antes de um prazo.

Três exigências daí decorrem, e são mais duras do que parecem:

Registar as falhas tanto quanto os sucessos. Uma pista que só consigna as ações bem-sucedidas só prova o que funcionou. As tentativas recusadas, os acessos rejeitados, os erros de segurança são muitas vezes a informação mais útil.

Resistir a quem detém a base. Um rasto protegido por um mecanismo que o operador controla não é uma prova contra o operador.

Nunca superestimar a sua própria garantia. Uma pista que anuncia mais proteção do que a que proporciona é pior do que uma pista modesta: produz uma confiança injustificada.

04O partido tomado #sec_19917edd

A integridade da pista não deve depender nem de um motor de base de dados, nem de um anfitrião.

É a decisão estruturante, e foi tomada contra várias soluções mais fáceis.

As funcionalidades de imutabilidade oferecidas pelos motores de base de dados modernos, as tabelas temporais e os serviços geridos de carimbo de data/hora foram todos descartados. Funcionam, mas deslocam a confiança para um terceiro — o editor do motor, o fornecedor de cloud — e prendem o produto: uma pista de auditoria que não sobrevive a uma mudança de anfitrião não é um ativo do cliente.

A garantia é, portanto, inteiramente aplicativa, suportada pelo próprio produto e verificável em qualquer lugar onde funcione. É coerente com o resto da plataforma, que se implementa na região escolhida pelo cliente.

Três princípios complementam esta escolha:

1. A base não se desativa. Não existe qualquer configuração que permita cortar a pista de auditoria — caso contrário, desativaríamos a auditoria a partir da auditoria. O que é configurável é a precisão de certos eventos de leitura, nunca o registo dos atos.

2. Um ato desconhecido escreve-se mesmo assim. O catálogo de ações vive na base e conta hoje perto de duzentas e quarenta entradas. Mas se uma versão do produto emitir um código que o catálogo ainda não conhece, o evento é escrito apesar de tudo. Recusar registar o que não se sabe nomear seria a melhor forma de criar um ângulo morto.

3. Anuncia-se o que é realmente garantido. O relatório de verificação indica o nível de proteção efetivamente em vigor — nunca aquele que está previsto.

05Como funciona #sec_e77f0329

Dois caminhos de captura

É o ponto de arquitetura mais importante, e decorre diretamente da exigência « registar as falhas ».

O caminho transacional serve os atos bem-sucedidos. O evento é depositado na mesma transação que o ato de negócio que descreve. A consequência é absoluta: se o ato falhar e a transação for anulada, não subsiste qualquer rasto órfão; se o ato for bem-sucedido, o seu rasto existe necessariamente. Não pode haver desfasamento entre o que o produto fez e o que a pista conta.

O caminho autónomo serve todo o resto: tentativas recusadas, falhas de autenticação, acessos rejeitados, erros de segurança. Estes eventos não têm, por natureza, qualquer transação de negócio a que se possam agarrar — o ato não teve lugar. Sem este segundo caminho, a pista só provaria os sucessos.

O encadeamento

Cada evento recebe um identificador, uma posição de sequência atribuída à escrita, e uma impressão criptográfica que inclui a do evento anterior. A pista forma assim uma cadeia: modificar um evento passado invalida todos os seguintes.

Cada cadeia abre-se com um evento de génese colocado na primeira posição. Sem ele, poderiam ser eliminados os primeiros eventos de uma cadeia e apresentá-la como completa.

A forma exata dos dados submetidos à impressão é normalizada e versionada: dois sistemas que verificam a mesma pista obtêm o mesmo resultado, hoje como daqui a cinco anos.

O mecanismo foi testado contra sete formas distintas de alteração — modificação de conteúdo, supressão, inserção, reordenamento — todas detetadas.

Os três níveis de garantia

O produto distingue explicitamente o que garante, e nunca reivindica o nível superior.

O relatório de verificação é datado e anuncia o nível real. Enquanto a selagem não estiver em vigor, indica « encadeamento só » — e sobretudo não N1. Esta disciplina é deliberada: um relatório que superestima a sua garantia não vale nada perante um auditor que sabe ler.

A chave de selagem é dedicada

A chave que sela a pista de auditoria não é nunca aquela que assina os documentos produzidos pelo cliente.

A razão é simples: quem pode assinar um relatório não deve poder selar a pista que prova como esse relatório foi produzido. Separar os dois — e separar a base de auditoria do signatário — é a condição para que a selagem queira dizer alguma coisa.

06O que é registado, e o que não o é #sec_548db5ca

Os atos. Tudo o que modifica o estado do dispositivo: campanhas criadas, lançadas, anuladas; decisões tomadas; exclusões colocadas e levantadas; delegações implementadas e revogadas; regras modificadas; papéis atribuídos; pedidos de supressão emitidos e tratados; configuração alterada.

As tentativas e as recusas. Pelo caminho autónomo, como explicado acima.

As leituras — de forma graduada. Rastrear cada exibição de ecrã produziria um volume que afogaria a informação útil. As consultas correntes são, portanto, amostradas, com três exceções sistematicamente registadas:

• os exports, porque fazem sair dados do sistema;
• as consultas de dados pessoais nomeados;
• as consultas de prova, porque saber quem viu o dossier antes de um prazo tem um valor de auditoria.

As conversas com a RITA — por impressão apenas. A pista regista que uma questão foi colocada e o que resultou dela, nunca o texto da questão. Conservar o conteúdo das trocas equivaleria a constituir um histórico do que os utilizadores se perguntam, o que não é o objetivo de uma pista de auditoria.

Os dados de demonstração — marcados como tais. Os conjuntos de dados sintéticos permanecem possíveis, mas a sua proveniência é marcada, e esta marcação propaga-se a tudo o que dela deriva. Uma demonstração nunca deve poder ser confundida com a produção.

07Quem vê o quê #sec_1be12c7e

A visibilidade é descendente: o administrador de um workspace vê os eventos de nível de subscrição que designam o seu workspace — a criação do seu perímetro, a atribuição das suas funcionalidades, a modificação da sua alocação.

É o complemento necessário da governança delegada: uma entidade a quem se confia autonomia deve poder constatar as decisões tomadas acima dela que a dizem respeito. Ela não vê, no entanto, nada das outras entidades.

O auditor dispõe de um acesso de leitura estrita ao conjunto da pista do seu perímetro, e de um motor de busca para navegar nela.

08Uma escolha assumida: o arranque em branco #sec_c32441da

A nova pista de auditoria não retoma o histórico da antiga.

Não é uma renúncia técnica. O antigo jornal não oferecia qualquer garantia de integridade, a sua cobertura era parcial e o seu vocabulário ambíguo. Retomar seria introduzir numa cadeia selada dados sobre os quais nada se pode afirmar — e, portanto, fazer crer que beneficiam de uma garantia que nunca tiveram.

Melhor uma pista curta e sólida do que uma longa pista cuja primeira metade não prova nada. O mesmo raciocínio aplica-se à substituição do dispositivo de autenticação.

09O que o auditor pode esperar #sec_7f268117

• Um relatório de verificação datado, que afirma que a cadeia está intacta — ou designa precisamente onde não está.
• A certeza de que nenhuma ação concluída está ausente, por construção transacional.
• O registo das recusas, e não apenas dos sucessos.
• A origem de cada ato: o autor, a superfície, o momento, o objeto, e o estado antes/depois quando faz sentido.
• Um exportação incremental, para verter a pista no seu próprio instrumento de análise ou no seu SIEM.

10A reter #sec_cc1ba3dd

Um produto de conformidade que não pode prestar contas dos seus próprios atos pede que se acredite na sua palavra. A pista de auditoria de REVIEWIT é construída para que não seja necessário fazê-lo.

É indissociável do produto — não desativável, alimentada na mesma transação que os atos que descreve, incluindo quando esses atos falham. É independente da infraestrutura, portanto portátil e verificável em todo o lado. E é honesta sobre a sua própria força: anuncia o nível de garantia que realmente oferece, nunca aquele que visa.