Criptografia de dados: o que é e como funciona

Criptografia de dados é o processo de transformar uma informação legível em um formato ilegível para quem não possui a chave correta, e reversível para quem possui. Na prática, ela existe em três variações que resolvem problemas diferentes: criptografia simétrica (uma chave para cifrar e decifrar), criptografia assimétrica (um par de chaves, pública e privada) e hashing (uma transformação de mão única, sem chave para reverter). Confundir os três é o erro mais comum de quem está começando — e é também a causa de boa parte das implementações inseguras que aparecem em auditorias.

Criptografia simétrica: uma chave para tudo

Na criptografia simétrica, a mesma chave cifra e decifra os dados. É rápida e eficiente para grandes volumes de informação, por isso é o tipo usado para proteger arquivos, bancos de dados e comunicações depois que a conexão já foi estabelecida. O padrão de fato hoje é o AES (Advanced Encryption Standard), definido pelo NIST no FIPS 197, com chaves de 128, 192 ou 256 bits — o NIST mantém a orientação de que aplicações atuais podem seguir usando qualquer um desses três tamanhos.

O ponto fraco da criptografia simétrica não é o algoritmo, é a distribuição da chave: se as duas partes precisam da mesma chave, como ela chega até a outra ponta sem ser interceptada? É esse problema que a criptografia assimétrica resolve.

Criptografia assimétrica: duas chaves, papéis diferentes

Na criptografia assimétrica, existe um par de chaves matematicamente relacionadas: uma pública, que pode ser distribuída livremente, e uma privada, que nunca sai de quem a gerou. O que uma chave cifra, só a outra decifra. É assim que um site consegue combinar uma chave de sessão com o seu navegador sem que vocês tenham se falado antes — e é a base de assinaturas digitais, onde a chave privada assina e a pública verifica.

O custo é o desempenho: operações assimétricas são ordens de grandeza mais lentas que as simétricas. Por isso, na prática, os dois tipos trabalham juntos — é o chamado esquema híbrido. O TLS 1.3 (RFC 8446), protocolo que cifra a comunicação entre navegador e servidor na internet, funciona assim: usa criptografia assimétrica só para negociar uma chave de sessão simétrica, e depois cifra todo o tráfego real com essa chave simétrica, muito mais rápida.

Hashing não é criptografia — mas anda junto

Hash é uma função de mão única: transforma qualquer entrada em uma saída de tamanho fixo, e não existe operação inversa que reconstrua a entrada original a partir da saída. Por isso hashing não serve para proteger dados que precisam ser recuperados depois (como o conteúdo de um arquivo), mas é exatamente o que se quer para senhas: o sistema nunca precisa 'ler de volta' a senha, só confirmar que a que foi digitada gera o mesmo hash que está guardado.

O erro clássico é usar hashes rápidos como SHA-256 ou MD5 para senhas. Eles foram desenhados para velocidade, o que é exatamente o oposto do que se quer aqui: um atacante com a base de hashes vazada consegue testar bilhões de combinações por segundo. O OWASP Password Storage Cheat Sheet recomenda algoritmos lentos e propositalmente caros de rodar, como Argon2id (o padrão hoje), com fallback para bcrypt ou scrypt em sistemas legados — sempre com um salt único por senha, para inutilizar ataques de rainbow table.

from argon2 import PasswordHasher

ph = PasswordHasher()  # Argon2id com parâmetros seguros por padrão

# Ao cadastrar o usuário
hash_armazenado = ph.hash("senha-do-usuario")

# Ao autenticar
try:
    ph.verify(hash_armazenado, "senha-digitada")
    print("Senha correta")
except Exception:
    print("Senha incorreta")

Em repouso e em trânsito: dois momentos, duas proteções

Criptografia "em repouso" protege dados armazenados — em disco, em banco de dados, em backup. Criptografia "em trânsito" protege dados enquanto trafegam pela rede, tipicamente via TLS. São proteções independentes: um banco de dados pode estar cifrado em repouso e ainda assim expor os dados em texto claro se a conexão da aplicação até ele não usar TLS, e vice-versa. Um pipeline de dados completo — inclusive os que alimentam sistemas de IA, como descrito no nosso guia de [segurança em RAG](/artigo/seguranca-em-rag-riscos-como-proteger) — precisa cobrir os dois momentos, não apenas um deles.

Onde a criptografia entra na LGPD

A LGPD não usa a palavra "criptografia" em nenhum momento do seu texto, mas ela aparece de forma indireta em dois pontos relevantes. O artigo 46 exige que agentes de tratamento adotem medidas de segurança técnicas e administrativas capazes de proteger dados pessoais de acessos não autorizados. E o artigo 48, §3º, prevê que a comprovação de medidas técnicas que tornem os dados pessoais afetados ininteligíveis — o que a criptografia faz na prática — pode ser considerada atenuante na aplicação de sanções pela ANPD em caso de incidente.

No plano prático, o Guia Orientativo sobre Segurança da Informação para Agentes de Tratamento de Pequeno Porte, publicado pela ANPD, lista criptografia, autenticação multifator, controle de acesso por função, backups regulares, pseudonimização e monitoramento de redes entre as medidas técnicas recomendadas para qualquer organização, independentemente do porte.

Boas práticas (e erros comuns)

• Nunca implemente seu próprio algoritmo de criptografia — use bibliotecas revisadas e mantidas (nas principais linguagens, isso normalmente já vem em módulos padrão ou em pacotes amplamente auditados).
• Separe dado cifrado de chave: guardar a chave no mesmo lugar que os dados cifrados anula boa parte da proteção.
• Use um gerenciador de chaves (KMS) em vez de variáveis de ambiente ou arquivos de configuração, sempre que a infraestrutura permitir.
• Prefira modos autenticados (AES-GCM) a modos que só garantem confidencialidade — sem autenticação, dados cifrados podem ser adulterados sem que ninguém perceba.
• Troque hash por criptografia (e vice-versa) apenas quando fizer sentido: senha é hash; número de cartão que precisa ser recuperado depois é criptografia.
• Tenha um plano de rotação de chaves — chave que nunca muda é chave que, se vazar uma vez, compromete tudo para sempre.

O que a criptografia não resolve

Criptografia protege dados contra quem não tem a chave — não contra quem tem acesso legítimo e abusa dele, nem contra um endpoint já comprometido por malware, que lê os dados depois que já foram decifrados para uso. Ela também não substitui controle de acesso: um banco de dados cifrado, mas com credenciais fracas ou permissões abertas demais, continua vulnerável. E criptografia mal implementada — chave fixa no código-fonte, modo de operação sem autenticação, ausência de rotação — costuma dar uma falsa sensação de segurança pior do que a ausência de criptografia, porque baixa a guarda de quem confia nela.