Minimização de dados como disciplina de schema e de logging

O que é

Minimização de dados é o hábito de engenharia de armazenar apenas os dados pessoais de que uma funcionalidade precisa, na menor precisão que atenda à finalidade e apenas enquanto essa finalidade durar. Ela aparece em três lugares: no schema (quais colunas existem e com que precisão), nos logs (quais campos são emitidos) e nos armazenamentos derivados (analytics, índices de busca, caches), que copiam dados dos dois primeiros. A NIST SP 800-122 descreve a tarefa posterior como identificar as PII em um sistema e decidir qual nível de proteção é adequado para cada ocorrência; a minimização é a etapa anterior, que evita que essa ocorrência chegue sequer a ser criada. O OWASP Logging Cheat Sheet lista dados que não devem ser gravados diretamente nos logs, mas removidos, mascarados, convertidos em hash ou criptografados, entre eles valores de identificação de sessão, tokens de acesso, senhas, dados de cartão de pagamento e dados pessoais sensíveis.

Por que importa

Todo campo armazenado é um passivo com custos recorrentes: precisa ser protegido, exportado quando solicitado, apagado ao fim do período de retenção e explicado depois de um incidente. Um campo que nunca foi armazenado não custa nada. Os logs costumam ser o caminho do vazamento, porque são escritos por todas as camadas, copiados para vários sistemas e lidos por mais pessoas do que o banco de dados.

Como aplicar

• Pergunte, para cada coluna, na revisão do schema: qual funcionalidade a lê, com que precisão e por quanto tempo? Guarde o ano de nascimento quando só se usa uma faixa etária, uma região em vez do endereço completo, um booleano "tem número de telefone" quando só o fato importa.
• Separe colunas sensíveis, raramente necessárias, em uma tabela própria com acesso mais restrito, para que os joins comuns nunca as toquem.
• Faça logging por allowlist: o helper de logging estruturado aceita campos nomeados e descarta todo o resto; uma mensagem de texto livre nunca recebe o corpo de uma requisição nem um objeto de usuário despejado com %r ou JSON.stringify.
• Substitua identificadores nos logs por pseudônimos estáveis (um hash com chave) quando for necessária correlação e por nada quando não for.
• Aplique as mesmas regras aos armazenamentos derivados: o schema dos eventos de analytics lista os campos permitidos e rejeita os desconhecidos na ingestão.
• Marque colunas e campos de log com uma classificação (personal, sensitive, none) na definição do schema, para que ferramentas posteriores de exportação, exclusão e revisão possam encontrá-los.

Armadilhas

A minimização decidida na fase de projeto se desgasta com logs de depuração "temporários" que acabam permanecendo, colunas JSON que aceitam qualquer chave e SDKs de terceiros que coletam dados por conta própria. Dados com precisão reduzida ainda podem identificar uma pessoa em combinação (ano de nascimento, região e gênero); reduzir a precisão é uma redução, não anonimização. Um campo removido do schema continua existindo em backups antigos e no arquivo de logs até que estes expirem.