Tema: privacy-engineering
-
Tratar um pedido de titular de dados como processo de engenharia: exportação e exclusão
Trate o pedido de uma pessoa por uma cópia ou pela exclusão dos seus dados como um job: entrada com verificação, um exportador por armazenamento do mapa de dados gerando um manifesto, entrega por download autenticado com expiração, exclusão pelo pipeline, exceções listadas com códigos de motivo e teste com titular sintético em cadência fixa; quais pedidos devem ser atendidos e quando não é abordado.
-
Privacidade diferencial em um parágrafo e onde ela não se aplica
A privacidade diferencial limita o quanto o registro de uma única pessoa pode alterar a distribuição de saída de um mecanismo de consulta, adicionando ruído calibrado e debitando cada resposta de um orçamento. Serve para divulgações agregadas repetidas sobre populações grandes, mas não para dados em nível de registro, grupos pequenos, operações exatas ou análises internas pontuais.
-
Checklist de revisão de privacidade para uma funcionalidade
Dez perguntas que o revisor responde antes de uma funcionalidade ir para produção: inventário de novos dados pessoais, decisões de minimização, job de retenção, acesso e registro de acessos, cobertura de exportação e exclusão, finalidades de preferência, fluxos para terceiros, uma análise LINDDUN rápida, dados de teste e registro do resultado; apenas propriedades de engenharia, sem avaliação jurídica.
-
Dados de teste sem dados pessoais de produção
Forneça dados realistas a desenvolvimento, CI e staging gerando-os: classifique colunas, escreva geradores com seed que passem nos validadores da aplicação, crie volume com generate_series, copie da produção apenas distribuições, marque os registros gerados de forma reconhecível e elimine o atalho de fazer dump da produção.
-
Registros de consentimento e preferências como dados: o que foi escolhido, quando e por qual canal
Modele as escolhas de uma pessoa como eventos append-only (sujeito, finalidade, escolha, momento, origem, versão do texto), com uma visão derivada do estado atual que todo consumidor lê no ponto de uso; um booleano na linha do usuário não responde o que foi acordado no momento de uma ação nem quais usuários um bug de banner afetou.
-
Logs de acesso a dados pessoais: registrar quem leu qual registro
Um log de acesso a dados pessoais registra leituras, e não apenas gravações: ator, titular, objeto, motivo e momento, emitidos no caminho de leitura da aplicação e conciliados com o log de instruções do banco de dados para os caminhos que o contornam. Ele deve responder a perguntas centradas no titular, como quem consultou o registro de determinada pessoa no último ano.
-
Tornar visíveis para a equipe as leituras de tabelas com dados pessoais reduz consultas amplas a essas tabelas
Hipótese: se todas as instruções contra tabelas com dados pessoais forem registradas em log (o parâmetro log_statement do PostgreSQL define quais instruções SQL são registradas) e o log for mostrado à equipe num resumo semanal, a proporção de leituras amplas (sem predicado sobre um identificador de pessoa, ou com lista de colunas em curinga) diminui, e o número de leituras estreitas legítimas se mantém. Propõe-se um teste de antes e depois, sem alegar resultado.
-
Minimização de dados como disciplina de schema e de logging
Guarde apenas os dados pessoais de que uma funcionalidade precisa, na menor precisão que a atende, e mantenha identificadores fora dos logs por meio de allowlists de campos; cada coluna, campo de log e armazenamento derivado que contenha dados pessoais é uma decisão de projeto com finalidade, responsável e prazo de validade, não uma escolha padrão.
-
Implementar uma política de retenção como jobs de exclusão
Uma política de retenção só existe na prática quando cada classe de dados tem um mecanismo que exclui no prazo: remoção de partições em tabelas particionadas por tempo, regras de ciclo de vida no armazenamento de objetos e jobs de DELETE em lotes e idempotentes nos demais casos, cada um com uma métrica do registro mais antigo restante e um alerta quando essa idade ultrapassa o prazo.
-
Como as equipes verificam que uma exclusão removeu todas as cópias dos dados de uma pessoa, e o que a verificação encontrou?
Pergunta em aberto: um job de exclusão que reporta conclusão não significa que os dados sumiram (versões mortas de linhas antes do VACUUM, versões de objetos, caches, índices, cópias analíticas, backups, logs, terceiros). Quais equipes verificam de ponta a ponta, com que método, e quais armazenamentos ainda continham dados após uma exclusão concluída?
-
Pseudonimização versus anonimização como técnicas de engenharia
A pseudonimização troca identificadores diretos por tokens, mantém um caminho de volta (uma chave ou uma tabela de correspondência) e preserva um registro por pessoa; a anonimização busca eliminar a associação entre registros e pessoas para todos. Use HMAC com chave por finalidade para os pseudônimos e trate uma tabela pseudonimizada como dado pessoal que ainda contém quase-identificadores.
-
Modelagem de ameaças à privacidade com LINDDUN: visão geral
Percorra um diagrama de fluxo de dados elemento a elemento com os sete tipos de ameaça do LINDDUN (linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, non-compliance), registre cenários por elemento e escolha mitigações de um menu curto; um formato de uma sessão, inspirado numa sessão STRIDE.
-
Pipelines de exclusão entre serviços, armazenamentos derivados e backups
Modele a exclusão dos dados de uma pessoa como um job com um estado por armazenamento do mapa de dados: dispare um evento, exija que cada serviço responsável informe a conclusão com contagens, trate explicitamente o armazenamento de objetos versionado e os armazenamentos derivados, limite por quanto tempo os backups retêm os dados ou destrua chaves por titular, e mantenha uma lista de supressão para repetir a exclusão após restaurações.
Legível por máquina: JSON