Você não pode continuar dizendo ao seu conselho que “criptografia em repouso” é suficiente. Seus advogados sabem que não, seus clientes presumem algo melhor e todo engenheiro com acesso a psql ainda pode dar SELECT nos dados mais sensíveis do seu sistema. Mesmo assim, você precisa pesquisá-los: encontrar um usuário por e-mail, deduplicar telefones, filtrar por intervalo de data de nascimento. Criptografia totalmente homomórfica não vai salvá-lo em 2026. Criptografia pesquisável prática vai — se você escolher os padrões certos, aceitar os vazamentos certos e operacionalizar isso.
O que mudou: a criptografia pesquisável em nível de campo saiu da pesquisa para o roadmap
O burburinho da semana passada sobre a Supabase adicionar busca criptografada em nível de campo via CipherStash é mais do que uma atualização de produto — é o sinal de que a criptografia pesquisável finalmente está cruzando o abismo. Você não precisa mais operar um serviço de cripto sob medida para fazer consultas de igualdade e de intervalo funcionarem em dados criptografados. E você não precisa escolher entre “ninguém pode consultar nada” e “DBAs podem ler tudo”.
A pegadinha: você precisa ser explícito sobre quais consultas vai suportar, o que está disposto a vazar (ordem, frequência, padrões de acesso) e onde as chaves vivem. Fingir que esses trade-offs não existem vai ou explodir sua performance ou entregar a atacantes um canal lateral explorável.
Comece com um modelo de ameaças, não com uma biblioteca
Se você não escreve contra quem está se protegendo, vai superdimensionar ou subdimensionar a solução. Aqui está o framework rápido de pontuação que usamos com CTOs:
Adversários com os quais você provavelmente se preocupa
- Insiders da nuvem e snapshots do banco: Backups gerenciados de Postgres, logs do banco, acessos de suporte. Criptografia em repouso protege discos, não operadores.
- Exfiltração via SQL injection ou réplica de leitura mal configurada: Atacantes automatizados que conseguem despejar tabelas, mas não conseguem rodar seu código de app.
- Solicitações legais ou desvio de residência de dados: Você pode precisar provar que a equipe de produção (ou até sua nuvem) não consegue decriptar certos campos.
Adversários contra os quais você provavelmente não vai vencer só com criptografia
- Camada de aplicação totalmente comprometida: Se um atacante assume o processo que detém as chaves, ele pode decriptar. Compense com rate limits, detecção de anomalias e chaves de curta duração, mas assuma que a decriptação é possível.
- Padrões de acesso perfeitamente ocultos: Oblivious RAM ainda não é prático para o seu SaaS. Aceite que padrões de acesso vazam sem um custo pesado.
Traduza isso em uma política: “Proteger PII de operadores do banco e da nuvem; tolerar vazamento de padrões de consulta; assumir que comprometimento do app equivale a decriptação; criptografar campo a campo com chaves que o DB nunca vê.”
Estrutura de decisão: escolha técnicas por consulta, não por tabela
Criptografia pesquisável é um conjunto de técnicas. Use a ferramenta mais leve que entregue a semântica da sua consulta e cubra seu modelo de ameaças.
1) Mapeie seus padrões de consulta
- Igualdade: Encontrar por e-mail, telefone, SSN/CPF/CNPJ, ID de fatura.
- Prefixo: Buscar e-mail pelo usuário ou telefone por código do país + DDD.
- Intervalo/Ordenação: Intervalos de data de nascimento, valores de pedido entre X e Y, ordenar por last_activity_at.
- Fuzzy/Texto: Busca por nome, endereço contém substring.
Depois classifique por sensibilidade. E-mail, telefone, SSN/CPF são alta sensibilidade. CEP, cidade ou estado são menores (mas ainda PII em muitos regimes). Não desperdice complexidade criptográfica em agregados não sensíveis.
2) Escolha o primitivo certo por campo
Estes são os blocos que realmente chegam à produção em 2026:
- Deterministic Encryption (DE) para igualdade: Canonicalize a entrada (e-mail em minúsculas, E.164 para telefone), depois criptografe com um modo determinístico (por exemplo, AES-SIV). Mesmo plaintext → mesmo ciphertext, permitindo comparações de igualdade e índices por hash. Vazamento: frequência (mesmos valores produzem o mesmo ciphertext), padrões de igualdade entre linhas.
- Blind Indexes para igualdade e prefixo: Calcule um HMAC com um sal secreto sobre o valor canonicalizado (ou seus n-gramas para busca por prefixo) e indexe esses tokens. Armazene apenas tokens no DB, não plaintext nem sais. Vazamento: igualdade de tokens e contagem de tokens; mitigado por sais por tenant e um pepper em um KMS.
- Revelação de ordem ou intervalos bucketizados: Criptografia que revela ordem existe, mas o vazamento pode ser feio. Um padrão pragmático é a bucketização: mapear um campo numérico/temporal para buckets (por exemplo, mês, faixas de R$ 10) e indexar tokens de bucket. Granularidade mais grossa → menos vazamento e índices menores, mas mais falsos positivos para filtrar no app.
- Busca criptografada no cliente ou no serviço para texto: Se você precisa de full-text search em campos sensíveis, aceite que vai empurrar a indexação para um cliente ou para um serviço dedicado de busca criptografada que mantém chaves no lado da aplicação (CipherStash é uma opção). Tentar acoplar busca textual fuzzy ao Postgres com garantias criptográficas é como projetos morrem.
Choque de realidade: 80% das consultas sobre campos sensíveis em SaaS B2B são de igualdade ou intervalo grosseiro. Você consegue protegê-las hoje sem matemática mirabolante.
3) Gerenciamento de chaves que não torpedeia a latência
- Envelope keys por tenant: Gere uma Data Encryption Key (DEK) por tenant ou dataset. Criptografe as DEKs com uma Key Encryption Key (KEK) em um KMS gerenciado (AWS KMS, GCP KMS). Armazene a DEK criptografada junto aos metadados do tenant.
- Aqueça o cache: Na inicialização do app ou no acesso do tenant, decripte a DEK via KMS uma vez e mantenha-a em memória com um TTL curto (por exemplo, 10–15 minutos). Espere ~1–3 ms por decriptação no KMS quando aquecido; não faça isso por linha.
- Rotacione sem downtime: Versione as DEKs. Em escrita, use a DEK v2; em leitura, tente v2 e depois faça fallback para v1. Faça backfill em lotes.
- Divida a confiança: Mantenha sais/pepper para blind indexes no KMS ou em um serviço com HSM; nunca os armazene no DB.
4) Contas de desempenho e armazenamento (para você não chutar)
- Igualdade com DE ou blind index: Sobrecarga de armazenamento ~1,1–1,3x por campo (ciphertext + token). A sobrecarga de latência de consulta é dominada por rede/IO; espere +5–15 ms p95 acima de uma busca indexada típica, impulsionada pela tokenização na camada de app e pós-filtragem.
- Prefixo com n-gramas: Se você indexa 3-gramas para a parte local do e-mail, vai armazenar ~L-2 tokens por valor (L = número de caracteres no segmento prefixável). Inchaço de índice de 2–4x é comum; mantenha campos de prefixo limitados e normalizados.
- Intervalos bucketizados: Com buckets mensais para datas, uma janela de 10 anos é 120 buckets. A maioria das consultas atinge 1–3 buckets. Espere amplificação de falsos positivos de 1,2–1,5x que você filtra no app. Sobrecarga fim a fim de +10–30 ms p95 é típica.
- Busca de texto criptografada via serviço: Índices podem ser 2–5x o texto bruto, e a ingestão adiciona +20–80 ms por escrita dependendo do batching. Leituras adicionam um salto de rede; reserve +25–60 ms p95.
Estes são números de ordem de grandeza que vimos em Postgres 14–16 e KMS gerenciados em regiões us-east. Sua topologia de VPC e o comportamento do ORM variam mais do que a cripto.
Uma arquitetura concreta que chega à produção
Este é o padrão que recomendamos para startups e scale-ups em Postgres (incluindo Supabase/Postgres-as-a-service):
PII Vault + Blind Indexes + serviço de busca criptografada opcional
- PII Vault microservice: Um serviço fino que mantém DEKs e sais em memória, conversa com o KMS e expõe funções de encrypt/decrypt/index via um RPC rigidamente controlado. Apenas seus tiers de app e workers podem chamá-lo. Ele registra eventos de tokenização, não plaintext.
- Canonicalização no lado da aplicação: Coloque em minúsculas, faça trim e normalize. Para Brazil, remova acentos em nomes para tokens de busca, imponha E.164 em telefones e valide formatos de CPF/CNPJ antes da criptografia. O objetivo da canonicalização é evitar múltiplos ciphertexts para “o mesmo” valor.
- Schema no Postgres: Para cada campo sensível, armazene o ciphertext (bytea) e uma ou mais colunas de blind index (bytea ou bytea de comprimento fixo). Crie índices B-tree ou hash nas colunas de blind index; nunca indexe o próprio ciphertext.
- Triggers ou escritas na camada de app: Em insert/update, chame o vault: criptografe o plaintext e compute tokens; grave ciphertext + tokens em uma única transação. Preferimos na camada de app para manter o vault e os sais fora do DB, mas triggers são aceitáveis se chamarem uma extensão segura ou um RPC estilo FDW.
- Padrão de consulta: Converta a entrada do usuário em tokens no app, consulte pelos tokens, busque linhas candidatas e decripte apenas o subconjunto que você retorna. Nunca traga ciphertexts para o cliente.
- Serviço de busca criptografada (opcional): Para os 10–20% de campos que precisam de busca fuzzy ou ranqueada, envie documentos para um serviço de busca criptografada acoplado ao seu vault (por exemplo, CipherStash ou equivalente gerenciado). Mantenha seu DB como fonte de verdade e faça o join por identificadores estáveis.
Com isso, seu DB e seu provedor de nuvem não conseguem ler PII, mas seu app ainda responde 95% das consultas de produto com latência aceitável.
Construir vs. Comprar em 2026
Você tem três opções críveis:
- Faça você mesmo com um vault e Postgres: Máximo controle, mínimo lock-in de fornecedor, mas você precisa dominar canonicalização, geração de tokens e rotação. Espere 4–6 semanas para uma equipe sênior entregar igualdade + prefixo + intervalos bucketizados em 3–5 campos, depois mais 2–3 semanas para colocar em produção rotação de chaves, logs de auditoria e dashboards.
- Use uma camada gerenciada de busca criptografada (por exemplo, CipherStash): Tempo para valor mais rápido para consultas difíceis, APIs consistentes e rotação embutida. Você terá um salto extra e custo de fornecedor, mas ganha um modelo de vazamento mais claro e menos “armadilhas”.
- Empurre parte da busca para o cliente: Para apps de consumo, mover busca por nome/endereço para o dispositivo (com índices locais) pode eliminar completamente o vazamento no servidor. Isso é real no Android 17 e no iOS moderno, mas há restrições de UX e offline.
Nosso heurístico: se você precisa de mais do que igualdade + intervalos por mês em 2–3 campos, compre a camada. Se a maioria das consultas são buscas por e-mail/telefone/ID, construa o vault; você recuperará o investimento em controle e custo.
Tiros no pé comuns (e como evitá-los)
- Usar hash em vez de HMAC para blind indexes: SHA-256 sem chave é um presente para atacantes com rainbow tables. Use um HMAC com chave, sais por tenant e um pepper mantido em serviço.
- Criptografar no banco de dados: Se seu DB consegue decriptar, seu DBA da nuvem também consegue. Mantenha chaves e tokenização apenas no lado do app ou do vault.
- Pular a canonicalização: “John.Smith+promo@example.com” deve ser igual a “johnsmith@example.com” na sua semântica de busca. Defina, teste e congele a canonicalização por campo.
- Índices de prefixo sem limite: Explosões de n-gramas acontecem rápido. Limite o comprimento de prefixo suportado (por exemplo, primeiros 5 caracteres da parte local) e torne isso um requisito de produto.
- Rotacionar DEKs sem versionamento: Sempre escreva a versão da chave usada para criptografar nos metadados do ciphertext. Leituras devem tentar a mais nova primeiro, depois versões antigas, então falhar.
- Sem orçamento para falsos positivos: Buckets de intervalo e n-gramas exigem filtragem no app. Torne isso explícito nos seus SLOs de latência e monitore p95/p99 separadamente dos tempos do DB.
Migração sem indisponibilidade no fim de semana
30 dias: prove o padrão
- Escolha dois campos: e-mail e data de nascimento. Entregue deterministic encryption + blind index de igualdade para e-mail; tokens de bucket por mês para data de nascimento.
- Habilite dual-write: colunas em texto claro permanecem autoritativas por enquanto; grave ciphertext + tokens em paralelo.
- Adicione decriptação read-through para sistemas downstream que ainda precisam de texto claro; registre os pontos de chamada.
60 dias: inverta leituras e inicie a rotação
- Troque consultas para buscas baseadas em token; decripte apenas o que você retorna.
- Faça backfill das linhas existentes em lotes (por exemplo, 10k/minuto) em janelas de baixo tráfego. Meça crescimento de índice e latência p95.
- Introduza versionamento de DEK; rotacione 10% dos tenants para v2; observe regressões.
90 dias: descontinue texto claro, amplie cobertura
- Restrinja acesso a texto claro a uma allowlist curta e remova-o dos modelos do ORM.
- Expanda para telefone e CPF/CNPJ com canonicalização ciente de país.
- Decida entre comprar vs. construir para qualquer busca fuzzy restante. Se for comprar, integre agora o serviço de busca criptografada e aposente índices ad hoc.
Conformidade e residência: o que os reguladores realmente querem saber
HIPAA, GLBA e a LGPD do Brazil não vão prescrever algoritmos. Eles vão perguntar se partes não autorizadas (incluindo sua nuvem) podem ler PII em repouso. Criptografia em nível de campo com chaves detidas pela aplicação é uma resposta forte. Se você opera nos EUA e no Brazil, mantenha DEKs residentes onde os reguladores esperam (geralmente na mesma região do data store) e documente os fluxos. Quando chegar a discovery, você quer mostrar que snapshots do DB de produção são criptograficamente inertes sem a sua camada de aplicação.
O que dizer ao seu time de produto
Busca criptografada não é grátis. Deixe três restrições explícitas desde o início:
- Semântica de match exato é rápida; fuzzy não é: Prefixos limitados a N caracteres, nomes normalizados e sem acento no momento da tokenização.
- Intervalos são bucketizados: Buscas por data de nascimento são por mês ou trimestre, não por filtros arbitrários de dia da semana.
- O custo aparece no armazenamento e em um pequeno imposto de latência: Planeje 1,3–2,0x de crescimento de índice nos campos criptografados e +10–30 ms p95. Esse é o preço de não entregar suas chaves para a nuvem.
Onde Supabase + CipherStash se encaixam
Se você já está em Supabase ou Postgres gerenciado, uma integração de busca criptografada (como o trabalho recente de Supabase + CipherStash) pode eliminar muito yak shaving: bibliotecas cliente para tokenização, padrões sensatos para igualdade/prefixo/intervalo e rotação gerenciada. Seu modelo de vazamento não será zero — ordem e padrões de acesso ainda vazam — mas você terá um time de produto mantendo esses modelos e um caminho de migração que não exige um PhD em cripto. Avalie em três eixos: cobertura das consultas (suas consultas reais se encaixam?), SLOs de latência com o seu formato de dados e controle de chaves (você pode trazer seu próprio KMS?).
O ângulo brasileiro: não deixe a localização quebrar sua cripto
Para stacks US–Brazil, a normalização importa mais do que o usual:
- Nomes: Remova diacríticos para tokens de busca, mas preserve-os no ciphertext; construa comparadores sensíveis ao locale.
- Telefones: Imponha E.164 com tratamento de DDD; dados vindos de WhatsApp frequentemente chegam malformados. Normalize ou você perderá matches.
- CPF/CNPJ: Valide e normalize (remova pontuação) antes da tokenização. Considere exibição com preservação de formato apenas no momento do render após a decriptação.
Erre a normalização e você multiplicará ciphertexts para o mesmo usuário, inflando índices e detonando taxas de match.
Quando não fazer isso
Se sua proposta de valor central é busca fuzzy sobre texto inerentemente sensível (por exemplo, um mecanismo de busca de pessoas), você precisa de uma arquitetura pesada no cliente ou aceitar que sua equipe de operações pode ler dados. Meias-medidas vão trazer custo sem privacidade real. Para o resto — o SaaS mainstream que lida com registros de usuários, transações e fluxos de suporte — as técnicas acima são suficientes para sair do “teatro da criptografia” para controle substantivo.
Conclusão
A criptografia pesquisável deixou de ser um projeto de pesquisa. Consultas de igualdade e de intervalo prático em campos criptografados estão bem ao alcance com criptografia determinística, blind indexes e gerenciamento disciplinado de chaves. Adicione um serviço de busca criptografada para os 10–20% de consultas que precisam, e seu app finalmente consegue responder consultas de suporte, fraude e billing sem dar ao seu provedor de nuvem ou ao seu DBA texto claro. Isso é uma redução de risco material que você consegue explicar ao conselho — e uma postura que seus clientes vão notar na próxima vez que um concorrente vazar um snapshot.
Principais lições
- Decida primeiro contra o que você está se protegendo: insiders de nuvem/DB e vazamentos de snapshots são realistas; camadas de app totalmente comprometidas não são corrigíveis só com cripto.
- Use criptografia determinística ou blind indexes para igualdade; bucketize intervalos; empurre busca fuzzy para um cliente ou serviço de busca criptografada.
- Mantenha chaves fora do banco: DEKs por tenant, KEK apoiada por KMS, TTLs curtos em memória e versionamento explícito de chaves.
- Preveja 1,3–2,0x de armazenamento de índices nos campos criptografados e +10–30 ms p95 de latência para a maioria das consultas.
- Normalize agressivamente (e-mails, telefones, CPF/CNPJ, diacríticos) antes da tokenização ou você vai perder matches e inchar índices.
- Construa seu próprio vault se você só precisa de igualdade + intervalos grosseiros; compre uma camada de busca criptografada se precisar de busca textual fuzzy ou ranqueada.
- Migre em 90 dias com dual-writes, inversão de leituras e rotação gradual de chaves; não tente uma virada única em um fim de semana.