Como a criptografia funciona,
e o que ela protege.

Criptografado nem sempre significa a mesma proteção.

Considere o armazenamento de um endereço de entrega. Criptografia de transporte, disco e dados protege fronteiras diferentes.

Criptografia de transporte / TLS

Protege a comunicação entre navegador e servidor. O servidor receptor pode processar o endereço; TLS não protege automaticamente o conteúdo do banco nem uma aplicação comprometida.

Criptografia de armazenamento

Protege contra roubo de discos e mídias de backup. Se o banco descriptografa leituras normais de forma transparente, usuários com acesso de leitura SQL ainda podem ver endereços.

Criptografia antes do armazenamento

Criptografe o endereço na aplicação e armazene o texto cifrado. Separe permissões de leitura do banco das permissões de uso de chaves para proteger contra o roubo apenas do banco.

O OneNym combina essas camadas com autorização por finalidade. Criptografia forte importa, assim como limitar os caminhos de descriptografia.

A implementação descriptografa o endereço inteiro na memória e retorna somente os campos permitidos. Não é criptografia por campo. Destinatários devem proteger o texto recebido; clientes também devem gerenciar logs e armazenamento anteriores ao cadastro. Guia de primeiros passos

Proteja a chave de dados com uma chave separada.

Uma DEK criptografa o endereço; uma KEK protege essa DEK. Isso é criptografia de envelope. A seguir, um exemplo com uma DEK dedicada por endereço.

1. Gere uma DEK com uma fonte aleatória criptograficamente segura e criptografe o endereço com criptografia autenticada.
2. Encapsule a DEK com uma KEK gerenciada por um serviço de gestão de chaves. O encapsulamento criptografa e protege a chave.
3. Armazene texto cifrado, DEK encapsulada, versão da chave e metadados de descriptografia. Não armazene uma DEK em texto em claro no banco.
4. Quando precisar do endereço, autorize tenant, finalidade, registro e campos.
5. O serviço autorizado desencapsula a DEK, descriptografa o endereço e retorna apenas campos permitidos.

Banco de dados                  Serviço de gestão de chaves
Endereço criptografado          KEK que protege a DEK
DEK encapsulada                 Permissões de uso e auditoria
Nonce / tag / versão da chave
          ↓ Serviço autorizado acessa ambos
       Descriptografia temporária → Processamento da entrega

Mesmo uma KEK não exportável pode ser abusada se suas permissões de uso forem roubadas. Separe acessos ao banco e ao KMS, administração, operações emergenciais e credenciais de serviço. Proteja também a memória descriptografada e os caches de chaves.

Gerencie KEKs por serviços de chaves na nuvem.

O Vault usa Azure Key Vault para gerenciar a KEK. Separe os direitos sobre a chave que protege as chaves de dados (DEK) do acesso à base.

Serviços de nuvem controlam chaves e acesso às operações criptográficas. O OneNym primeiro autoriza tenants, registros, campos e finalidades. Aplicações de negócio recebem permissões limitadas da API do cofre, não acesso direto à KEK.

Dois tipos diferentes de rotação de chaves.

Rotacionar uma KEK pode reencapsular DEKs sem alterar o texto cifrado dos dados. Uma DEK comprometida exige criptografar novamente os dados com uma nova DEK. A rotação não recupera texto em claro roubado nem cópias de chaves e textos cifrados antigos.

Detecte substituições e proteja a confidencialidade.

Criptografia autenticada como AES-GCM detecta alterações pelo tag de autenticação. Rejeite falhas. Nunca reutilize um nonce com a mesma chave AES-GCM, inclusive entre tentativas e múltiplos servidores.

Vincule ID do tenant, ID do registro e versão do esquema como dados autenticados adicionais (AAD). Texto cifrado copiado do tenant A para o registro do tenant B falha na verificação contra o contexto esperado de B.

AAD não é criptografado; não inclua endereços secretos. Obtenha os IDs esperados de solicitações autenticadas e registros confiáveis. Confiar nos IDs fornecidos junto com um texto cifrado substituído não preserva a fronteira.

O que permanece protegido em uma invasão?

Apenas uma cópia do banco é roubada

A criptografia correta protege os endereços se não houver chaves ou outras cópias em texto em claro. Avalie separadamente a exposição de contagens, IDs, horários e tamanhos.

Banco e permissões de descriptografia são comprometidos

Criptografia sozinha não impede o acesso. Limite o impacto com autorização restrita, controles de uso, detecção de anomalias e revogação.

O servidor de entrega é comprometido

Endereços descriptografados durante o processamento legítimo podem ser roubados. Não retorne campos além dos necessários para a entrega.

Um endereço já foi enviado a um parceiro

Revogar a chave do cofre não apaga texto em claro compartilhado. Gerencie também a retenção e a exclusão pelos parceiros.

Perguntas antes da implantação.

Além de perguntar se AES é usado, verifique quem pode usar chaves, se a descriptografia é limitada e auditada, quanto demora para a revogação chegar aos caches e como chaves perdidas são tratadas. Fronteiras de proteção e evidências operacionais sustentam a avaliação.

Referências técnicas

Para princípios gerais de criptografia e gestão de chaves, consulte Cryptographic Storage Cheat Sheet da OWASP; para hierarquias de chaves, consulte orientações da Microsoft sobre criptografia em repouso. Esta página explica o projeto de proteção do OneNym; chaves por registro são uma configuração ilustrativa.