Criptografia aplicada por caso de uso: dados sensíveis, tokens e PII

O que muda quando o “caso de uso” é o centro da decisão

Quando o foco é “dados sensíveis, tokens e PII”, a pergunta principal deixa de ser “qual algoritmo usar?” e passa a ser “qual propriedade eu preciso garantir neste fluxo específico?”. Em sistemas reais, o mesmo dado pode exigir controles diferentes dependendo de onde ele nasce, por onde trafega, onde é armazenado, quem acessa e por quanto tempo precisa existir. Neste capítulo, o objetivo é mapear decisões criptográficas e de design que aparecem repetidamente em três cenários: (1) dados sensíveis de negócio (segredos operacionais, credenciais, chaves, documentos), (2) tokens (sessão, acesso, refresh, reset de senha, links mágicos), e (3) PII (dados pessoais identificáveis, como nome, e-mail, CPF, endereço, data de nascimento).

Em vez de repetir fundamentos, vamos trabalhar com padrões práticos: classificação do dado, minimização, separação de responsabilidades, criptografia por campo, tokenização, pseudonimização, e controles de acesso e auditoria que complementam a criptografia. A criptografia é uma peça: ela reduz impacto em caso de vazamento, mas não substitui governança, logging, validação de entrada, segregação de ambientes e políticas de retenção.

Classificação rápida: sensível, token, PII (e combinações)

Dados sensíveis (não necessariamente PII)

São dados cujo vazamento causa dano direto ao negócio, à segurança ou à operação. Exemplos: segredos de integração (API keys), credenciais de banco, chaves privadas, relatórios internos, preços negociados, estratégias, documentos jurídicos. Aqui, a prioridade costuma ser confidencialidade e controle de acesso estrito, com trilha de auditoria e rotação quando aplicável.

Tokens

Tokens são “chaves temporárias” que representam uma autorização, uma sessão ou um direito de executar uma ação. O risco típico é que um token roubado permite impersonação. Portanto, o foco é reduzir a janela de uso, limitar escopo, impedir replay e tornar o token inutilizável fora do contexto esperado (ex.: dispositivo, cliente, IP, nonce, prova de posse).

PII

PII é qualquer dado que identifica ou pode identificar uma pessoa. Além de confidencialidade, PII exige: minimização (coletar o mínimo), finalidade (usar apenas para o propósito), retenção limitada, e capacidade de atender solicitações (ex.: exclusão, exportação). Do ponto de vista técnico, PII frequentemente precisa ser pesquisável (busca por e-mail/CPF), o que cria tensão entre criptografia forte e requisitos de consulta.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Um mesmo campo pode ser PII e sensível

Exemplo: número de documento e histórico financeiro. Isso influencia o desenho: talvez você precise de criptografia por campo, mascaramento em logs e telas, e um identificador substituto para joins e analytics.

Decisões práticas por tipo de dado

1) Dados sensíveis: “segredos” e documentos

Para segredos operacionais (credenciais, chaves de integração), a regra prática é: não trate como “dados de aplicação”. Segredos devem ter ciclo de vida próprio (provisionamento, rotação, revogação) e acesso mínimo. Para documentos sensíveis (PDFs, contratos, laudos), o desafio é controlar acesso e compartilhamento, além de proteger em armazenamento e backup.

• Segredos de integração: evite persistir em texto claro em banco; prefira armazenamento dedicado e acesso via identidade de serviço. Se precisar armazenar, use criptografia de aplicação com chaves gerenciadas e controle de acesso por função.
• Documentos: criptografia em repouso é necessária, mas muitas vezes insuficiente; considere criptografia por objeto com chaves por arquivo/cliente, e políticas de expiração/remoção.
• Logs: dados sensíveis não devem aparecer em logs. Se inevitável, aplique redaction/mascaramento antes de persistir.

2) Tokens: sessão, acesso e ações críticas

Tokens são frequentemente confundidos com “dados a serem criptografados”. Em muitos casos, o melhor é não criptografar o token, e sim projetá-lo para ser seguro por construção: aleatório, curto, com expiração, e validado no servidor. Em outros casos, você quer um token auto-contido (carrega claims) e então precisa garantir integridade e, às vezes, confidencialidade.

• Token opaco (referência): um identificador aleatório que aponta para estado no servidor (sessão, autorização). Vantagem: revogação e rotação fáceis; você controla tudo no servidor. Desvantagem: exige armazenamento e lookup.
• Token auto-contido: carrega dados (ex.: escopo, usuário, expiração). Vantagem: validação sem consulta. Desvantagem: revogação difícil; risco de vazamento de claims se não houver confidencialidade.
• Tokens de ação (reset de senha, confirmação de e-mail): devem ser de uso único, com expiração curta e vinculados ao contexto (usuário, propósito, e preferencialmente ao canal).

3) PII: confidencialidade + utilidade (busca, relatórios, integrações)

PII costuma ter dois requisitos conflitantes: proteger contra vazamento e ainda permitir operações de negócio (busca, deduplicação, relatórios, integrações). Três padrões aparecem com frequência:

• Criptografia por campo: armazena o valor cifrado e só decifra em pontos controlados. Bom para dados que raramente são consultados por igualdade/ordenação.
• Pseudonimização: substitui PII por um identificador (pseudônimo) e mantém a tabela de mapeamento protegida. Bom para reduzir exposição em sistemas downstream.
• Busca por igualdade com derivado: mantém um “índice” derivado (ex.: hash com chave/pepper) para permitir busca por igualdade sem armazenar o valor em claro. Exige cuidado com normalização e com ataques de dicionário.

Padrões de arquitetura que reduzem exposição

Minimização e separação de domínios

Um erro comum é espalhar PII e segredos por múltiplos serviços “porque é conveniente”. Um padrão mais seguro é isolar PII em um domínio/serviço dedicado (ou módulo) com API restrita, e fornecer aos demais serviços apenas identificadores ou dados minimizados. Isso reduz superfície de ataque e simplifica auditoria.

Camadas de proteção: criptografia + controle de acesso + observabilidade segura

Criptografia não impede abuso por um usuário interno com permissões excessivas. Para PII e segredos, combine:

• Controle de acesso por função e por propósito (ex.: atendimento vê e-mail mascarado; financeiro vê dados completos).
• Auditoria imutável de acessos a PII (quem acessou, quando, por qual motivo).
• Mascaramento em UI e logs (ex.: mostrar apenas últimos dígitos).
• Alertas para padrões anômalos (ex.: exportações massivas).

Passo a passo: criptografia por campo para PII (com envelope e metadados)

Use este passo a passo quando você precisa armazenar PII (ex.: endereço, data de nascimento) e acessá-la apenas em fluxos específicos, sem necessidade de busca por ordenação. A ideia é cifrar no nível da aplicação e armazenar, junto, metadados mínimos para permitir rotação e validação.

1) Defina quais campos serão cifrados e quais podem ficar em claro

Exemplo: em um cadastro, você pode manter em claro um identificador interno (user_id) e talvez um e-mail mascarado para exibição, mas cifrar endereço completo e documento. Evite cifrar campos que precisam de consulta por faixa/ordenação (ex.: data para relatórios) sem um plano, pois isso quebra consultas.

2) Normalize o dado antes de cifrar

Normalização reduz inconsistências e ajuda em deduplicação/validação. Exemplo: e-mail em lowercase e trim; CPF apenas dígitos. Para campos que serão cifrados, normalizar também evita múltiplas representações do mesmo valor.

3) Use um formato de armazenamento que carregue versão e parâmetros

Mesmo sem entrar em detalhes de algoritmos, você precisa guardar: versão do esquema, identificador da chave (key id), e o payload cifrado. Isso permite rotação e migração sem “quebrar” registros antigos.

// Exemplo de estrutura (JSON) armazenada no banco em uma coluna TEXT/JSONB: {   "v": 1,   "kid": "pii-key-2026-01",   "ct": "base64(...)" }

4) Faça envelope: chave de dados por registro e chave mestra gerenciada

O padrão prático é: gerar uma chave de dados (DEK) para cifrar o campo (ou conjunto de campos) e proteger essa DEK com uma chave mestra (KEK) gerenciada. Isso facilita rotação e limita impacto. Em implementações comuns, você armazena a DEK cifrada junto do registro (ou por “lote”/tenant) e usa o serviço de chaves para desembrulhar quando necessário.

5) Controle estritamente onde ocorre a decifragem

Decifre apenas no serviço que precisa exibir/usar a PII, e apenas no momento necessário. Evite decifrar para montar objetos grandes que serão logados ou enviados para múltiplos serviços. Uma prática útil é separar DTOs: um DTO “safe” (sem PII) para logs e eventos, e um DTO “sensitive” para uso interno.

6) Reduza vazamento acidental: logs, métricas e erros

Garanta que exceções, traces e métricas não incluam payloads com PII. Padronize mensagens de erro e use redaction automática em middlewares. Em incidentes reais, vazamentos por log são tão comuns quanto vazamentos por banco.

Passo a passo: busca por igualdade em PII sem armazenar valor em claro

Use este padrão quando você precisa buscar por igualdade (ex.: “encontre usuário por e-mail/CPF”), mas não quer armazenar o valor em claro. A abordagem é manter dois campos: (1) o valor cifrado (para recuperação) e (2) um índice derivado para busca.

1) Normalize o valor de entrada

Para e-mail: lowercase, trim, normalização de unicode quando aplicável. Para CPF: apenas dígitos. A normalização deve ser idêntica na gravação e na consulta.

2) Gere um índice derivado com segredo (pepper) e contexto

O índice não deve ser um hash simples do valor, pois isso permite ataques de dicionário. Use uma derivação com segredo (pepper) mantido fora do banco, e inclua contexto (ex.: tenant_id) para evitar correlação entre bases.

// Pseudocódigo: normalized = normalize(email) index = HMAC(pepper, tenant_id + ":" + normalized) // Armazene index (base64/hex) em coluna com índice no banco

3) Armazene: (a) índice derivado para busca, (b) valor cifrado para leitura

Na consulta, você calcula o índice do valor informado e busca por igualdade no banco. Ao encontrar o registro, você decifra o valor cifrado apenas se realmente precisar exibir/usar o dado.

4) Planeje rotação do pepper e migração do índice

Rotacionar o segredo do índice exige recomputar índices. Uma estratégia é versionar o índice: manter index_v1 e index_v2 durante migração, ou armazenar um campo “index_version” e aceitar múltiplas versões na busca até completar o backfill.

5) Entenda limitações

• Funciona bem para igualdade; não resolve “contains”, ordenação ou busca aproximada sem técnicas adicionais.
• Se o espaço de valores for pequeno (ex.: UF, sexo, faixas), mesmo com segredo pode haver risco de inferência por frequência; nesses casos, considere não tratar como PII crítica ou não indexar dessa forma.

Tokenização e pseudonimização: quando substituir é melhor do que cifrar

Tokenização de PII para sistemas downstream

Em pipelines de dados, integrações e analytics, muitas vezes você não precisa do valor real (ex.: CPF), apenas de um identificador consistente para correlacionar eventos. Tokenização cria um token estável (ou por período) que representa a PII sem revelá-la. O mapeamento token->PII fica em um cofre/serviço restrito.

• Token estável: mesmo token para o mesmo valor (útil para joins). Risco: correlação ao longo do tempo; mitigue com escopo por tenant e controles de acesso.
• Token rotativo: muda por período (ex.: mensal). Reduz correlação, mas dificulta joins históricos.

Pseudonimização em eventos e mensageria

Ao publicar eventos, prefira enviar user_id interno e atributos não identificáveis. Se um consumidor realmente precisa de PII, ele deve chamar um endpoint autorizado para obter o dado, em vez de receber PII no evento. Isso reduz replicação de PII em filas, DLQs e reprocessamentos.

Tokens na prática: desenho seguro por finalidade

Token de sessão (web)

Para sessão, o padrão mais robusto é token opaco com estado no servidor: um identificador aleatório armazenado em cookie com flags de segurança, apontando para uma sessão no backend. Isso facilita logout, revogação e detecção de anomalias (ex.: mudança brusca de localização). Se você usar token auto-contido, trate revogação e rotação como requisitos explícitos (ex.: lista de revogação, jti, expiração curta).

Token de acesso e refresh

Separe propósitos: token de acesso curto e token de refresh mais protegido. O refresh deve ter controles adicionais (ex.: rotação a cada uso, detecção de reutilização, binding ao cliente). Evite armazenar refresh token em locais expostos (ex.: localStorage em web) quando o modelo de ameaça inclui XSS.

Token de reset de senha / link mágico

Este é um caso clássico de erro: gerar token previsível, não expirar, permitir múltiplos usos, ou não invalidar ao trocar senha. Um desenho seguro inclui: token aleatório, expiração curta, uso único, e armazenamento de apenas um verificador no servidor (não o token em claro).

Passo a passo: reset de senha com token de uso único

• 1) Solicitação: usuário informa e-mail. Responda sempre com mensagem genérica (para não revelar se existe conta).
• 2) Geração: gere um token aleatório (ex.: 32 bytes) e associe a um registro de reset com expiração (ex.: 15–30 min) e contador de tentativas.
• 3) Armazenamento seguro: armazene no banco apenas um verificador derivado do token (ex.: HMAC com segredo do servidor). Assim, se o banco vazar, o atacante não obtém tokens válidos.
• 4) Envio: envie o token por canal apropriado (e-mail/SMS) em link HTTPS. Não registre o token em logs.
• 5) Validação: ao receber o token, derive o verificador e compare com o armazenado; valide expiração e se já foi usado.
• 6) Consumo: marque como usado (one-time), invalide resets anteriores do mesmo usuário e, após troca de senha, invalide sessões/refresh tokens existentes conforme política.

// Pseudocódigo do verificador stored = HMAC(server_secret, token) // salvar stored_hash, expires_at, used=false // na validação candidate = HMAC(server_secret, token_from_link) // comparar candidate == stored_hash

PII em integrações e exportações: evitar “criptografia como desculpa”

Exportações (CSV, relatórios, data lakes) são uma fonte recorrente de incidentes. Mesmo que o banco esteja protegido, uma exportação pode circular por e-mail, tickets e pastas compartilhadas. Trate exportação como um produto com controles:

• Escopo mínimo: exporte apenas colunas necessárias e apenas o período necessário.
• Mascaramento por padrão: e-mail mascarado, documento parcial, telefone truncado.
• Criptografia no arquivo: se o arquivo precisa sair do sistema, proteja-o com criptografia forte e distribuição segura de chave/senha (idealmente fora do mesmo canal).
• Auditoria: registre quem exportou, filtros usados e destino.
• Retenção: expiração automática de links e remoção de arquivos temporários.

Checklist de decisão rápida por caso de uso

Quando armazenar PII cifrada por campo

• Você precisa recuperar o valor original em alguns fluxos.
• O dado não precisa ser ordenado/filtrado por faixa com frequência.
• Você consegue restringir onde a decifragem ocorre e auditar acessos.

Quando preferir pseudonimização/tokenização

• Downstream não precisa do valor real, apenas de consistência para correlação.
• Você quer reduzir replicação de PII em filas, caches, logs e data lakes.
• Você quer impor um “ponto único” de acesso à PII (serviço cofre).

Quando usar índice derivado para busca por igualdade

• Você precisa buscar por e-mail/CPF com performance.
• Você aceita limitações (igualdade apenas) e planeja rotação do segredo.
• Você normaliza entradas de forma consistente e evita logs com valores brutos.

Quando tokens devem ser opacos (estado no servidor)

• Você precisa revogar rapidamente e ter controle fino de sessão.
• Você quer detectar anomalias e limitar uso por contexto.
• Você quer reduzir risco de vazamento de claims no cliente.

Quando tokens auto-contidos fazem sentido

• Você precisa validar sem consulta e aceita expiração curta.
• Você consegue lidar com revogação (por design) e com vazamento de metadados.
• Você mantém claims minimizados e evita colocar PII no token.