Dados e privacidade (para DPOs)

Esta página é para quem precisa responder onde o dado mora, quem o alcança, e como o apagamento funciona de verdade. O PEART é auto-hospedado e offline por desenho, o que resolve várias dessas perguntas antes de serem feitas.

Onde o dado mora, e o que sai

Tudo que o PEART guarda mora no host do próprio operador: o banco SQLite, o diretório de evidências cifrado, as renditions e os relatórios. Os catálogos ficam embarcados no binário, então a ferramenta roda em rede isolada sem dependência externa em tempo de execução. Não há telemetria nem call-home; o PEART não reporta nada para ninguém, e roda air-gapped.

O dado que ele guarda é sensível por natureza: achados, passo a passo de exploração, e evidências que frequentemente contêm credenciais, tokens e dados pessoais. É por isso que a evidência é cifrada em nível de arquivo e o produto inteiro é construído em torno de não vazá-la.

Endereços de rede, e por quanto tempo ficam

Duas tabelas gravam endereço de rede. Cada linha de sessão carrega o endereço de onde veio a entrada, e cada registro de auditoria carrega o endereço da requisição que o produziu, os dois ao lado do agente de usuário. Ambos são dado pessoal sob a LGPD e o GDPR por si sós, independentemente do que esteja ao lado deles, e são a única categoria de dado pessoal que o PEART coleta do cliente em vez de receber do engajamento.

Qual endereço é gravado depende da instalação. Sem proxy confiável declarado, é o endereço do par TCP, que atrás de um túnel ou de um terminador local é o endereço do próprio conector e não identifica ninguém. Declarar um proxy confiável, descrito em Configuração, faz dele o endereço real do cliente, que é o motivo de declarar e também o que torna o campo dado pessoal de verdade. Um operador que não queira endereço de cliente na trilha deixa a declaração desligada, e o valor gravado continua sendo um endereço de infraestrutura.

Nenhuma das duas tabelas é varrida por agenda. Linhas de sessão saem junto com a conta a que pertencem, por cascata. Registros de auditoria não são apagados nunca, por desenho: a trilha é só de inserção, e o registro do expurgo de um engajamento é justamente o que deve sobreviver a ele. Então um endereço gravado ao lado da atividade de um engajamento sobrevive ao material do próprio engajamento, e uma resposta de retenção que fale só de achados e evidências estaria errada sobre esse campo.

Apagamento que alcança backups

A parte mais forte da história de privacidade é a destruição criptográfica. Cada engajamento tem sua própria chave de cifragem; destruir essa chave torna o material do engajamento ilegível inclusive em backups antigos que a consultoria já não controla, o que nenhuma exclusão de linha alcança. Essa é a base do mecanismo de expurgo por retenção, e é a resposta honesta ao "e os backups?" que um pedido de direito à eliminação uma hora faz. O próprio expurgo é registrado na trilha de auditoria.

O que é protegido, e o que é declarado

Evidências e backups são cifrados; o banco fica em texto claro por uma decisão documentada, com cifragem de disco no host como controle compensatório, e isso é dito abertamente em vez de subentendido. A trilha de auditoria registra identificadores e nunca valores de conteúdo, então nunca vira uma segunda cópia não cifrada do ativo mais sensível; o endereço e o agente de usuário que ela grava ao lado deles estão tratados acima. O produto não se defende do operador do host nem do administrador da instalação, confiados por desenho com a trilha de auditoria como único controle; isso também é declarado, no docs/security.md seção 13.

Para uma avaliação de proteção de dados, o enquadramento útil é que o PEART dá ao operador os controles (cifragem, destruição criptográfica, expurgo por retenção, uma trilha de auditoria apenas de inserção, auto-hospedagem sem fluxo externo de dado) e declara com clareza as fronteiras que não cruza, para o operador raciocinar sobre o risco residual em vez de confiar numa garantia vaga.