DATA LIFECYCLE / PRACTICAL DESIGN

Do armazenamento à exclusão,
gerencie o caminho dos dados.

E se um endereço criptografado permanecer em logs ou índices em texto em claro? E se dados excluídos voltarem de um backup? A proteção precisa ir além do cofre.

Separe registros de negócio dos dados pessoais.

No varejo, mantenha IDs substitutos, pedidos, produtos e status de entrega nos sistemas de negócio. Armazene nomes, endereços e telefones no cofre. Processos de entrega autorizados consultam apenas o necessário.

Sistema de pedidos: ID do pedido / ID substituto / produtos / status da entrega
Cofre: nome, endereço e telefone criptografados, mapeados a um ID substituto
Entrega: consultar campos necessários apenas no período autorizado

Armazenamento separado reduz a exposição direta de endereços se o banco de pedidos for roubado. Históricos e IDs substitutos ainda podem identificar pessoas quando combinados com outras informações. IDs substitutos não garantem anonimato.

Na coleta: Defina finalidade e retenção. Não colete campos desnecessários nem registre corpos de solicitações em erros e logs de acesso.
No armazenamento: Separe o texto cifrado das permissões de descriptografia. Inclua réplicas, caches e cópias de análise na gestão dos dados.
No uso: Autorize campos e finalidade. Retorne apenas dados necessários e rastreie novas cópias criadas por transferências a parceiros.

Índices de busca, avisos de exclusão a parceiros e destruição irreversível de chaves são exemplos de projeto. A API atual não oferece busca, avisos automáticos nem eliminação física imediata de backups. Consulte o guia para o escopo real. Guia de primeiros passos

Como pesquisar dados criptografados?

Nonces aleatórios geram textos cifrados diferentes para o mesmo e-mail, impedindo buscas exatas comuns. Prefira IDs substitutos ou de pedidos. Se for preciso comparar dados pessoais, projete um índice de busca separado.

Exemplo de busca exata: HMAC com chave.

Normalize e-mails com regras definidas e calcule um HMAC usando chaves de busca específicas por tenant e campo. Repita na consulta e verifique os dados de origem após a autorização. O índice serve para comparação, não é texto cifrado descriptografável.

Hashes simples permitem testar e-mails ou telefones candidatos. O HMAC também permite tentativas se sua chave for roubada. Repetições e frequências continuam visíveis. Limite consultas em massa às APIs de busca.

Buscas por trechos, prefixos e intervalos podem expor informações adicionais e aumentar custos. Avalie funcionalidade, vazamento e desempenho juntos. A rotação de chaves de busca exige reconstruir índices.

O que a exclusão realmente significa?

Remover dados da tela não basta. Bloqueie a consulta e trate registros de origem, índices, caches, réplicas e parceiros. Registre a retenção dos backups e o comportamento de restauração.

Interromper o uso: rejeitar novas consultas e revogar tokens e autorizações.
Excluir dados ativos: remover registros de origem, índices e réplicas; invalidar caches.
Notificar parceiros: solicitar exclusão e acompanhar ações concluídas e pendentes.
Tratar backups: documentar o que permanece até a expiração e manter registros de exclusão para impedir reutilização após a restauração.

Tornar dados ilegíveis pela destruição das chaves.

A eliminação criptográfica torna as chaves necessárias irrecuperáveis. Exige chaves dedicadas e remoção de backups, chaves encapsuladas, caches e cópias recuperáveis dos serviços. Destruir uma chave compartilhada também afeta outros usuários.

Desativar uma chave de forma reversível não é eliminação irreversível. Isso não remove texto em claro já consultado nem cópias protegidas por outras chaves. Acompanhe bloqueio, exclusão de dados ativos e expiração de backups separadamente.

Recupere com segurança sem trazer dados excluídos de volta.

Restaurar o backup de ontem pode trazer de volta endereços excluídos hoje. Restaure em isolamento, reaplique exclusões e revogações atuais e valide antes de reabrir o acesso. Os registros de exclusão não podem existir apenas nesse mesmo backup antigo.

RPO: janela aceitável de perda de dados: Uma meta de 15 minutos admite perder até 15 minutos de atualizações recentes. Confirme replicação, backups e resultados de testes reais.
RTO: tempo para restaurar o serviço: Uma meta de duas horas inclui chaves, permissões, reaplicação de exclusões e validação, não só o banco. Esses números são exemplos, não garantias de serviço.
Verificações de recuperação: Verifique se dados válidos são descriptografados, dados excluídos não são consultados, tokens antigos são rejeitados e falhas de chave interrompem o processamento sem expor informações.
Evidências de auditoria: Registre responsável, referência do alvo, horário, resultado e versão da chave. Não copie dados pessoais nem tokens brutos para logs.

Evidências para avaliar o projeto.

Analise mapas de localização, permissões de descriptografia, exposição em buscas, status de exclusão e testes de recuperação para avaliar a proteção no armazenamento, uso e descarte.

Conversar sobre integração técnica