Criptografia de dados em repouso

1. Introdução à Criptografia de Dados em Repouso

Dados em repouso referem-se a qualquer informação armazenada persistentemente em dispositivos físicos ou virtuais: bancos de dados, discos rígidos, backups em nuvem, sistemas de arquivos e mídias removíveis. A criptografia de dados em repouso é a prática de transformar esses dados em formato ilegível para qualquer pessoa ou sistema que não possua a chave de descriptografia adequada.

A importância dessa proteção é crítica. Enquanto a criptografia de dados em trânsito (TLS/HTTPS) protege informações durante a transmissão entre sistemas, e a criptografia de dados em uso protege informações durante o processamento em memória, a criptografia em repouso é a última linha de defesa contra acessos não autorizados a armazenamentos físicos, violações de segurança em datacenters, roubo de dispositivos ou falhas de configuração em ambientes cloud.

Cenários comuns incluem:
- Senhas armazenadas em bancos de dados de autenticação
- Dados financeiros como números de cartão de crédito (PCI-DSS)
- Registros médicos protegidos por regulamentações como HIPAA
- Documentos confidenciais em sistemas de arquivos corporativos

2. Conceitos Fundamentais de Criptografia

Criptografia Simétrica vs. Assimétrica

A criptografia simétrica utiliza uma única chave tanto para cifrar quanto para decifrar dados. É ideal para dados em repouso porque oferece alto desempenho e é adequada para grandes volumes de informação. A criptografia assimétrica usa um par de chaves (pública e privada) e é mais lenta, sendo mais indicada para troca de chaves e assinaturas digitais.

Para dados em repouso, a abordagem mais comum é usar criptografia simétrica para o conteúdo, com a chave simétrica protegida por criptografia assimétrica ou armazenada em um cofre de chaves.

Algoritmos Recomendados

Os algoritmos atualmente recomendados são:

  • AES-256-GCM: Algoritmo simétrico com chave de 256 bits no modo Galois/Counter, que fornece autenticação integrada (proteção contra adulteração)
  • ChaCha20-Poly1305: Alternativa moderna ao AES, especialmente eficiente em dispositivos sem aceleração de hardware AES

O modo ECB (Electronic Codebook) deve ser sempre evitado por não esconder padrões nos dados. Prefira modos autenticados como GCM ou ChaCha20-Poly1305.

Gerenciamento de Chaves

O gerenciamento de chaves é o aspecto mais crítico e frequentemente negligenciado. Envolve:
- Geração: Usar geradores de números aleatórios seguros (CSPRNG)
- Armazenamento: Nunca em código-fonte ou variáveis de ambiente inseguras
- Rotação: Trocar chaves periodicamente (ex.: a cada 90 dias)

3. Criptografia em Nível de Aplicação

A criptografia em nível de aplicação oferece controle granular sobre quais dados são protegidos. Exemplo de criptografia de campo sensível usando libsodium em Python:

import sodium

# Geração de chave (deve ser armazenada em cofre seguro)
chave = sodium.utils.randombytes(32)  # Chave AES-256

# Criptografia de um campo sensível
dado_original = b"1234-5678-9012-3456"
nonce = sodium.utils.randombytes(12)  # Nonce único para cada operação
dado_cifrado = sodium.crypto_aead_aes256gcm_encrypt(
    dado_original, None, nonce, chave
)

# Armazenamento: nonce + ciphertext
armazenar_no_banco(nonce + dado_cifrado)

# Descriptografia
nonce, ciphertext = recuperar_do_banco()
dado_decifrado = sodium.crypto_aead_aes256gcm_decrypt(
    ciphertext, None, nonce, chave
)

Cuidados essenciais:
- Nunca reutilizar nonces: cada operação de criptografia deve ter um nonce único
- Sempre usar modos autenticados (GCM, ChaCha20-Poly1305) para detectar adulteração
- Armazenar metadados como nonce e salt junto com o ciphertext

4. Criptografia em Nível de Banco de Dados

Transparent Data Encryption (TDE) é uma funcionalidade oferecida por bancos de dados como SQL Server, Oracle e MySQL. Ela criptografa automaticamente arquivos de dados e logs de transação no nível do sistema operacional.

Vantagens:
- Transparente para a aplicação: nenhuma alteração de código necessária
- Protege backups físicos e arquivos MDF/LDF
- Criptografa logs de transação

Limitações:
- Não protege contra acesso de administradores do banco de dados
- Dados são descriptografados na memória do servidor
- Impacto no desempenho: 3-5% de overhead típico
- Índices e colunas de busca não são criptografados (a menos que use Always Encrypted)

-- SQL Server: Habilitar TDE
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MinhaCertificado;
GO

ALTER DATABASE MeuBanco
SET ENCRYPTION ON;
GO

Para proteção em nível de coluna com índices, considere usar Always Encrypted (SQL Server) ou criptografia determinística com HMAC para buscas exatas.

5. Gerenciamento de Chaves e Segredos

O uso de cofres de chaves (key vaults) é essencial para um gerenciamento seguro:

# Exemplo com HashiCorp Vault
vault write -address=https://vault.exemplo.com \
    -tls-skip-verify \
    transit/encrypt/minha-chave \
    plaintext=$(base64 <<< "dado_sensivel")

Ciclo de vida da chave:

  1. Criação: Gerar chaves dentro do cofre, nunca fora dele
  2. Distribuição: Aplicações obtêm chaves via API autenticada, nunca via arquivos
  3. Rotação: Automatizar com políticas (ex.: rotação a cada 30 dias)
  4. Revogação: Desabilitar chaves comprometidas imediatamente

Práticas recomendadas:
- Usar chaves mestras (Master Keys) para proteger chaves de dados (Data Encryption Keys - DEK)
- Implementar hierarquia de chaves: chave mestra → chave de criptografia de dados → chaves derivadas por contexto
- Nunca armazenar chaves em variáveis de ambiente ou arquivos de configuração

6. Criptografia de Backups e Arquivos

Backups são alvos frequentes de ataques. Criptografar backups completos e incrementais é obrigatório:

# Criptografia de backup com GPG (OpenPGP)
gpg --symmetric --cipher-algo AES256 \
    --output backup-2024-01-01.tar.gz.gpg \
    backup-2024-01-01.tar.gz

# Criptografia com age (ferramenta moderna)
age -p -o backup-2024-01-01.tar.gz.age \
    backup-2024-01-01.tar.gz

Verificação de integridade:
Após a descriptografia, verifique hashes SHA-256 ou assinaturas digitais para garantir que o backup não foi adulterado:

sha256sum backup-2024-01-01.tar.gz
# Compare com o hash armazenado em local seguro

7. Boas Práticas e Armadilhas Comuns

Nunca fazer:
- Armazenar chaves no código-fonte (nem mesmo em repositórios privados)
- Usar algoritmos caseiros (cryptography is hard)
- Ignorar tratamento de erros: mensagens de erro podem vazar informações sobre chaves

Sempre fazer:
- Usar bibliotecas auditadas (libsodium, OpenSSL, cryptography.io)
- Implementar rotação automática de chaves
- Validar nonces e tags de autenticação antes de processar dados

Exemplo de erro comum:

# ERRADO: Nonce fixo e sem autenticação
dado_cifrado = AES.new(chave, AES.MODE_ECB).encrypt(dado)

# CORRETO: Nonce aleatório e modo autenticado
nonce = os.urandom(12)
cipher = AES.new(chave, AES.MODE_GCM, nonce=nonce)
dado_cifrado, tag = cipher.encrypt_and_digest(dado)

8. Testes e Monitoramento de Segurança

Testes de penetração:
- Verificar se campos sensíveis estão realmente criptografados no disco
- Tentar acessar arquivos de dados diretamente (fora do banco)
- Validar que chaves não estão expostas em logs ou dumps de memória

Logging seguro:
- Registrar eventos de criptografia/descriptografia sem expor dados ou chaves
- Exemplo: "Campo [documento] criptografado com sucesso" (nunca "Chave X usada para criptografar dado Y")

Auditoria de acesso:
- Monitorar quem acessa chaves no cofre
- Configurar alertas para acessos incomuns
- Revisar periodicamente permissões de acesso a chaves

Referências