Segurança de dados em repouso e em trânsito com criptografia e gestão de chaves

Segurança de dados em repouso e em trânsito: o papel da criptografia

Criptografia é um conjunto de técnicas que transforma dados legíveis (texto claro) em dados ilegíveis (texto cifrado) para qualquer pessoa que não possua a chave correta. Em segurança da informação aplicada à LGPD, a criptografia é um controle técnico central para reduzir o risco de acesso indevido, vazamento e exposição acidental, tanto quando os dados estão armazenados (em repouso) quanto quando estão sendo transmitidos (em trânsito). O objetivo prático não é “esconder tudo”, mas garantir confidencialidade e, em muitos casos, integridade e autenticidade, com decisões proporcionais ao risco e ao contexto do tratamento.

Do ponto de vista operacional, a criptografia só é eficaz quando acompanhada de gestão de chaves: geração, armazenamento, rotação, revogação, backup e controle de acesso às chaves. Sem isso, a criptografia vira um “cadeado com a chave pendurada ao lado”.

Dados em repouso: o que são e onde aparecem

Dados em repouso são aqueles armazenados em algum meio persistente: bancos de dados, arquivos em servidores, objetos em storage, backups, snapshots, discos de máquinas virtuais, notebooks, celulares corporativos, pendrives, mídias de backup e até logs exportados para análise. O risco típico é o acesso não autorizado ao meio de armazenamento (roubo de equipamento, credenciais comprometidas, falha de configuração, exposição de bucket, cópia indevida de backup).

Criptografar dados em repouso reduz o impacto de incidentes em que o atacante obtém o arquivo, o disco ou o dump do banco, mas não obtém a chave. Isso não substitui controles de acesso, segmentação e hardening, mas adiciona uma camada de proteção importante.

Dados em trânsito: o que são e onde aparecem

Dados em trânsito são aqueles que trafegam entre componentes: navegador e servidor, aplicativo móvel e API, microserviço e banco de dados, integrações com terceiros, replicação entre data centers, envio de arquivos para parceiros, mensageria, e-mails e até chamadas internas em rede corporativa. O risco típico é interceptação (sniffing), ataque man-in-the-middle, downgrade de protocolo, roteamento malicioso, proxies comprometidos ou dispositivos de rede inseguros.

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

Criptografia em trânsito normalmente é implementada com TLS (Transport Layer Security), que fornece confidencialidade e integridade do canal e permite autenticar o servidor (e, quando necessário, o cliente). O foco é impedir que alguém no caminho leia ou altere os dados.

Tipos de criptografia e quando usar

Criptografia simétrica

Usa a mesma chave para cifrar e decifrar. É rápida e adequada para grandes volumes de dados (arquivos, discos, colunas de banco, backups). Exemplos de algoritmos: AES (Advanced Encryption Standard). Na prática, recomenda-se AES-256 ou AES-128 em modos seguros (ex.: GCM) conforme a biblioteca e o padrão adotado.

Criptografia assimétrica

Usa um par de chaves: pública (para cifrar/verificar) e privada (para decifrar/assinar). É mais lenta e costuma ser usada para troca segura de chaves, assinatura digital e autenticação. Exemplos: RSA, ECC (curvas elípticas). Em TLS, a criptografia assimétrica é usada para estabelecer a sessão e negociar chaves simétricas.

Hash e HMAC (não é criptografia reversível)

Hash é uma função unidirecional: transforma um dado em um resumo (digest) e não permite recuperar o original. É útil para integridade, comparação e armazenamento seguro de senhas (com salt e algoritmos apropriados). HMAC combina hash com uma chave secreta para garantir integridade e autenticidade de mensagens entre sistemas.

Importante: hash não substitui criptografia quando você precisa recuperar o dado original (por exemplo, para processar um CPF). Para esse caso, usa-se criptografia; para senhas, usa-se hash com algoritmo de derivação de chave (ex.: Argon2, bcrypt, scrypt) e parâmetros fortes.

Estratégias de criptografia em repouso

Criptografia de disco/volume (full-disk encryption)

Protege o armazenamento como um todo (disco, volume, partição). É útil para laptops e servidores, reduzindo risco em caso de roubo físico ou acesso ao disco fora do sistema operacional. Limitação: se o sistema estiver ligado e desbloqueado, um atacante com acesso lógico pode ler os dados; por isso, é uma camada, não a única.

Criptografia no nível de banco de dados

Inclui recursos como TDE (Transparent Data Encryption) ou criptografia nativa do mecanismo. Protege arquivos de dados e backups gerados pelo banco. Vantagem: implementação relativamente simples. Limitação: geralmente não protege contra consultas indevidas feitas por uma aplicação comprometida com acesso ao banco, porque o banco descriptografa ao servir a consulta.

Criptografia no nível de aplicação (campo/coluna)

Criptografa atributos específicos (por exemplo, documento, dados financeiros, endereço) antes de persistir. Vantagens: reduz exposição mesmo para administradores de banco e para dumps; permite segmentar chaves por tipo de dado ou por tenant. Desafios: impacto em buscas e indexação, necessidade de padronizar bibliotecas, gestão de chaves mais cuidadosa e risco de erros de implementação.

Criptografia de backups e exportações

Backups e exportações (CSV, relatórios, dumps) são fontes frequentes de incidentes. A regra prática é: se contém dado pessoal, deve ser criptografado e ter controle de acesso e rastreabilidade operacional. Também é importante separar chaves de criptografia do local onde o backup é armazenado.

Estratégias de criptografia em trânsito

TLS em interfaces externas (usuário, parceiros, APIs públicas)

Use TLS 1.2+ (preferencialmente TLS 1.3 quando disponível), desabilite protocolos e cifras fracas, e configure corretamente certificados. Para aplicações web, habilite HSTS para reduzir risco de downgrade para HTTP. Para APIs, exija HTTPS e recuse conexões inseguras.

TLS em tráfego interno (leste-oeste)

Tráfego interno entre serviços e bancos também pode carregar dados pessoais e credenciais. Criptografar apenas “na borda” deixa um trecho interno exposto. Em arquiteturas distribuídas, adote TLS interno, preferencialmente com autenticação mútua (mTLS) entre serviços críticos, reduzindo risco de movimentação lateral e interceptação em redes internas.

Integrações e transferência de arquivos

Para troca de arquivos com terceiros, prefira canais seguros (SFTP, HTTPS com autenticação forte, ou criptografia do arquivo + canal seguro). Em alguns cenários, criptografar o arquivo (por exemplo, com uma chave compartilhada via canal separado) adiciona proteção caso o arquivo seja encaminhado indevidamente.

Gestão de chaves: o que torna a criptografia realmente segura

Chaves criptográficas são ativos de alta criticidade. Quem controla a chave controla o acesso ao dado. Uma gestão de chaves madura define processos e controles para todo o ciclo de vida da chave, reduzindo risco de vazamento, uso indevido e indisponibilidade.

Conceitos essenciais

• Chave mestra (master key): chave usada para proteger outras chaves (key encryption key, KEK). Idealmente armazenada em módulo seguro (HSM) ou serviço gerenciado equivalente.
• Chave de dados (data encryption key, DEK): chave usada para criptografar o dado em si. Pode ser gerada por objeto/arquivo/registro, e então protegida (embrulhada) por uma KEK.
• Envelope encryption: padrão em que o dado é criptografado com uma DEK, e a DEK é criptografada com uma KEK. Facilita rotação e segmentação.
• Rotação: troca periódica de chaves para reduzir impacto de comprometimento e atender políticas internas. Pode ser rotação de KEK, de DEK ou de ambas.
• Revogação e desativação: impedir uso futuro de uma chave comprometida, mantendo rastreabilidade e plano de recuperação.
• Segregação de funções: quem administra infraestrutura não deve, por padrão, ter acesso às chaves e aos dados ao mesmo tempo.

Onde armazenar chaves

Evite armazenar chaves em código-fonte, variáveis de ambiente expostas, arquivos de configuração em repositórios, ou em planilhas. Opções mais seguras incluem:

• KMS/HSM: serviços ou módulos dedicados para geração e proteção de chaves, com controle de acesso, auditoria e políticas.
• Secret manager: para segredos de aplicação (tokens, senhas, chaves de API), com rotação e controle de acesso. Para chaves de criptografia, prefira KMS/HSM, mas secret manager pode armazenar referências e material auxiliar conforme arquitetura.
• Hardware seguro em endpoints: em dispositivos, use enclaves/TPM/keystore do sistema operacional para proteger chaves locais.

Políticas mínimas de gestão de chaves

• Geração: use geradores criptograficamente seguros; proíba chaves “caseiras” e reutilização indevida.
• Controle de acesso: restrinja por função e por serviço; aplique o princípio de menor privilégio especificamente para operações de criptografia (encrypt/decrypt/wrap/unwrap).
• Rotação: defina periodicidade e gatilhos (ex.: suspeita de incidente, troca de fornecedor, mudança de equipe, alteração de risco).
• Backup e recuperação: planeje como recuperar chaves sem criar cópias descontroladas. Para HSM/KMS, use mecanismos nativos e procedimentos aprovados.
• Ambientes separados: chaves de produção não devem ser usadas em homologação/desenvolvimento. Dados de produção não devem ser descriptografados fora de produção.
• Auditoria: registre uso de chaves (quem, quando, qual operação, qual serviço), e alerte para padrões anômalos (ex.: volume incomum de decrypt).

Passo a passo prático: criptografia em repouso com envelope encryption

O passo a passo abaixo descreve uma abordagem comum para criptografar campos sensíveis no nível de aplicação, usando envelope encryption. Ele é aplicável quando você precisa reduzir exposição mesmo em dumps e acessos administrativos ao banco.

1) Defina o escopo do que será criptografado

• Liste campos que, se expostos, geram maior impacto (ex.: documento, dados financeiros, saúde, biometria, endereço completo).
• Decida se a criptografia será por coluna, por documento (JSON) ou por arquivo.
• Defina requisitos de busca: se precisa pesquisar por igualdade, considere técnicas complementares (ex.: índices por hash/HMAC do valor normalizado) sem armazenar o valor em claro.

2) Escolha algoritmos e bibliotecas aprovadas

• Use algoritmos padrão (ex.: AES-GCM para confidencialidade + integridade).
• Padronize bibliotecas criptográficas mantidas e revisadas; evite implementar criptografia manualmente.
• Defina tamanho de chave e formato de armazenamento (ex.: base64 do ciphertext + nonce/IV + tag).

3) Estruture o modelo de chaves (KEK e DEK)

• Crie uma KEK no KMS/HSM (ou serviço equivalente) com política de acesso restrita ao serviço de criptografia.
• Defina como gerar DEKs: por registro, por usuário, por tenant ou por objeto, conforme necessidade de segmentação.
• Defina metadados: versão da chave, algoritmo, data de criação, identificador da KEK.

4) Implemente o fluxo de criptografia (write path)

Fluxo típico ao salvar um dado sensível:

• Gere uma DEK aleatória (simétrica) para o objeto/registro.
• Criptografe o dado sensível com a DEK usando AES-GCM, gerando ciphertext + nonce + tag.
• Envie a DEK para o KMS/HSM para ser “embrulhada” (wrap) com a KEK, obtendo a DEK protegida (wrapped key).
• Armazene no banco: ciphertext, nonce, tag, wrapped key e metadados (versão/algoritmo).

// Pseudocódigo ilustrativo (não específico de linguagem)  dek = SecureRandomBytes(32) // 256-bit  nonce = SecureRandomBytes(12)  (ciphertext, tag) = AES_GCM_Encrypt(dek, nonce, plaintext, aad=record_id)  wrapped_dek = KMS_WrapKey(kek_id, dek)  store({ciphertext, nonce, tag, wrapped_dek, kek_id, alg="AES-256-GCM", v=1})

Observação prática: usar AAD (Additional Authenticated Data), como um identificador do registro, ajuda a detectar troca indevida de ciphertext entre registros.

5) Implemente o fluxo de descriptografia (read path)

• Recupere ciphertext, nonce, tag e wrapped key.
• Solicite ao KMS/HSM o unwrap da DEK (apenas o serviço autorizado deve poder fazer isso).
• Descriptografe com AES-GCM e valide a tag (integridade).
• Entregue o dado em memória apenas pelo tempo necessário; evite logs e dumps com o valor em claro.

// Pseudocódigo ilustrativo  record = load(id)  dek = KMS_UnwrapKey(record.kek_id, record.wrapped_dek)  plaintext = AES_GCM_Decrypt(dek, record.nonce, record.ciphertext, record.tag, aad=id)  return plaintext

6) Planeje rotação de chaves sem indisponibilidade

• Rotação de KEK: em geral, reembrulhe (rewrap) as DEKs com a nova KEK sem precisar descriptografar os dados.
• Rotação de DEK: recriptografe os dados com uma nova DEK quando necessário (mais custoso).
• Mantenha versão de chave nos metadados para permitir leitura de registros antigos durante migração.

7) Teste e valide

• Teste falhas: nonce repetido, tag inválida, wrapped key corrompida, indisponibilidade do KMS.
• Valide desempenho: latência adicional por operação de unwrap; use cache controlado quando apropriado (com cuidado para não expor chaves).
• Valide observabilidade: métricas de erro de decrypt, taxa de chamadas ao KMS, alertas de anomalia.

Passo a passo prático: TLS seguro para dados em trânsito

1) Inventarie os fluxos de comunicação

• Liste endpoints externos (sites, APIs) e internos (serviço-serviço, serviço-banco, filas, mensageria).
• Identifique onde trafegam dados pessoais e credenciais.
• Defina prioridade: primeiro fluxos com dados sensíveis e integrações com terceiros.

2) Padronize configurações mínimas de TLS

• Habilite TLS 1.2+ e, quando possível, TLS 1.3.
• Desabilite SSL/TLS legados e cifras fracas.
• Use certificados com cadeia válida e algoritmos atuais.
• Habilite redirecionamento HTTP->HTTPS e HSTS em aplicações web.

3) Gerencie certificados como ativos

• Defina responsáveis e processo de renovação antes do vencimento.
• Automatize emissão/renovação quando possível para reduzir risco de expiração.
• Proteja chaves privadas de certificados (principalmente em servidores e gateways).

4) Considere mTLS para tráfego interno crítico

• Em mTLS, cliente e servidor se autenticam com certificados.
• Defina uma autoridade certificadora interna (ou serviço equivalente) e políticas de emissão.
• Implemente rotação e revogação de certificados de serviços.

5) Teste com ferramentas e cenários reais

• Valide se endpoints recusam HTTP e protocolos antigos.
• Teste renegociação, cadeias de certificado e comportamento com proxies.
• Simule interceptação em ambiente controlado para verificar se o cliente valida corretamente o certificado (evitar “aceitar qualquer certificado”).

Armadilhas comuns e como evitar

Chaves e segredos expostos em repositórios

Um erro recorrente é colocar chaves em arquivos de configuração versionados. Mitigação: varredura de segredos em repositórios, uso de secret manager/KMS, e revisão de código com foco em vazamento de credenciais.

Criptografia sem integridade

Usar modos de cifra que não autenticam (ou não validar MAC/tag) permite adulteração silenciosa. Mitigação: use AEAD (ex.: AES-GCM, ChaCha20-Poly1305) e valide tags sempre.

Reutilização de nonce/IV

Em algoritmos como AES-GCM, reutilizar nonce com a mesma chave pode comprometer a segurança. Mitigação: nonce aleatório com tamanho recomendado e controle para evitar repetição; em alguns casos, nonce determinístico com contador seguro.

Criptografar tudo e perder capacidade operacional

Criptografia no nível de aplicação pode dificultar buscas, relatórios e detecção de fraude. Mitigação: criptografe campos de maior risco e use técnicas auxiliares (ex.: HMAC para busca por igualdade, tokenização, ou separação de dados) com avaliação cuidadosa de risco.

Dependência crítica do KMS sem plano de contingência

Se o KMS ficar indisponível, operações de decrypt podem parar. Mitigação: arquitetura resiliente, cache de curto prazo com proteção, filas para reprocessamento, e definição clara de comportamento degradado (por exemplo, bloquear operações sensíveis em vez de “falhar aberto”).

Tokenização e pseudonimização como complementos

Em alguns cenários, tokenização pode ser mais adequada do que criptografia direta: você substitui um identificador sensível por um token e mantém o valor real em um cofre (vault) com controles rígidos. Isso reduz a exposição em sistemas que não precisam do dado original. Já a pseudonimização pode envolver técnicas como substituição por identificadores internos e separação lógica de tabelas, reduzindo o vínculo direto com o titular. Essas abordagens não eliminam a necessidade de segurança, mas podem reduzir superfície de ataque e facilitar o princípio de necessidade no uso diário.

Checklist operacional para implementar e sustentar

• Definir quais dados exigem criptografia em repouso e em trânsito, com critérios de risco.
• Padronizar algoritmos e bibliotecas; proibir implementações ad hoc.
• Adotar KMS/HSM para KEKs e aplicar envelope encryption para dados sensíveis.
• Separar chaves por ambiente (dev/homolog/prod) e por contexto quando necessário.
• Implementar rotação e versionamento de chaves com compatibilidade retroativa durante migração.
• Garantir TLS 1.2+ em todos os endpoints e considerar mTLS em comunicações internas críticas.
• Gerenciar certificados e chaves privadas com inventário, renovação e proteção.
• Testar falhas e indisponibilidades (KMS, certificados expirados, validação de tag) antes de ir a produção.
• Monitorar uso de chaves e erros de criptografia para detectar anomalias e regressões.