Como proteger dados em repouso com criptografia de disco e campos

1. Introdução à proteção de dados em repouso

Dados em repouso referem-se a informações armazenadas em dispositivos físicos ou virtuais que não estão sendo transmitidas ativamente pela rede. Isso inclui arquivos em discos rígidos, bancos de dados, backups em fita, snapshots em nuvem e qualquer outra forma de armazenamento persistente. A proteção desses dados é fundamental porque, ao contrário de dados em trânsito, que podem ser interceptados durante a comunicação, dados em repouso são alvos frequentes de roubo físico de hardware, acesso não autorizado a servidores descartados e violações de backups mal configurados.

Existem duas abordagens principais para proteger dados em repouso: criptografia de disco completo (Full Disk Encryption — FDE) e criptografia de campos (column-level encryption). A FDE oferece proteção transparente em nível de bloco, enquanto a criptografia de campos permite granularidade, protegendo apenas colunas específicas de um banco de dados. A escolha entre elas depende dos requisitos de compliance (LGPD, PCI-DSS, HIPAA), do modelo de ameaça e das necessidades de desempenho.

2. Criptografia de disco completo (FDE)

A criptografia de disco completo opera em nível de bloco, criptografando todo o volume de armazenamento — setor por setor — antes que os dados sejam escritos no disco. Ferramentas como LUKS (Linux Unified Key Setup) no Linux e BitLocker no Windows implementam essa técnica. A principal vantagem é a transparência: aplicações e sistemas operacionais interagem com o disco como se ele não estivesse criptografado, pois a descriptografia ocorre automaticamente na camada do kernel.

No entanto, a FDE possui limitações significativas. Ela não protege dados quando o sistema está em execução e a chave está carregada na memória. Um invasor com acesso ao sistema operacional pode ler todos os dados, independentemente da criptografia do disco. Além disso, não oferece proteção por campo — se um backup for exposto, todo o volume estará vulnerável, não apenas campos específicos.

3. Criptografia de campos em banco de dados

A criptografia de campos atua em nível granular, permitindo que colunas específicas de uma tabela sejam criptografadas com algoritmos como AES-256-GCM. Diferentemente da FDE, essa abordagem protege os dados mesmo quando o sistema está em execução, pois a descriptografia só ocorre mediante acesso à chave correta. Implementações nativas de SGBDs, como o módulo pgcrypto do PostgreSQL ou as funções AES_ENCRYPT/AES_DECRYPT do MySQL, facilitam essa integração.

O gerenciamento de chaves é um ponto crítico: as chaves de criptografia de campo devem ser armazenadas separadamente dos dados (em um cofre de chaves ou HSM) e submetidas a rotação periódica. Sem esse cuidado, a criptografia de campo perde sua eficácia.

4. Escolhendo entre criptografia de disco e de campos

A decisão entre FDE e criptografia de campos deve considerar:

  • Compliance: regulamentações como PCI-DSS exigem criptografia de dados de cartão de crédito, o que favorece a abordagem granular. A LGPD, por sua vez, recomenda proteção de dados pessoais, podendo ser atendida por ambas as técnicas.
  • Desempenho: a FDE tem impacto mínimo sobre consultas, pois opera em nível de bloco. Já a criptografia de campo pode degradar consultas com índices e filtros, exigindo otimizações como índices em hashes.
  • Modelo de ameaça: se o principal risco é roubo físico de hardware, a FDE é suficiente. Se o risco inclui acesso não autorizado a backups ou consultas internas, a criptografia de campo é necessária.

A combinação de ambas as camadas — FDE para proteção do volume inteiro e criptografia de campo para dados sensíveis — constitui uma defesa em profundidade robusta.

5. Implementação prática com exemplos de código

Exemplo 1: Configuração de criptografia de disco com LUKS no Linux

# 1. Instalar o pacote cryptsetup
sudo apt-get install cryptsetup

# 2. Particionar o disco (exemplo: /dev/sdb)
sudo fdisk /dev/sdb  # criar partição /dev/sdb1

# 3. Inicializar o volume LUKS
sudo cryptsetup luksFormat /dev/sdb1

# 4. Abrir o volume e mapear para /dev/mapper/volume_cripto
sudo cryptsetup open /dev/sdb1 volume_cripto

# 5. Criar sistema de arquivos e montar
sudo mkfs.ext4 /dev/mapper/volume_cripto
sudo mount /dev/mapper/volume_cripto /mnt/dados_cripto

Exemplo 2: Criptografia de campo em PostgreSQL usando pgcrypto

-- 1. Habilitar a extensão pgcrypto
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- 2. Criar tabela com coluna criptografada
CREATE TABLE usuarios (
    id SERIAL PRIMARY KEY,
    nome TEXT,
    email TEXT,
    cpf_cifrado BYTEA
);

-- 3. Inserir dados com criptografia AES-256-GCM
INSERT INTO usuarios (nome, email, cpf_cifrado)
VALUES (
    'João Silva',
    'joao@exemplo.com',
    pgp_sym_encrypt('123.456.789-00', 'chave_super_secreta')
);

-- 4. Consultar dados descriptografados
SELECT nome,
       pgp_sym_decrypt(cpf_cifrado, 'chave_super_secreta') AS cpf
FROM usuarios;

Exemplo 3: Envelope encryption com AWS KMS para chaves de campo

# 1. Criar chave mestra no AWS KMS (via CLI)
aws kms create-key --description "Chave mestra para criptografia de campos"

# 2. Gerar chave de dados (Data Key) usando a chave mestra
aws kms generate-data-key \
    --key-id alias/minha-chave-mestra \
    --key-spec AES_256 \
    --output json

# Resposta:
# {
#   "CiphertextBlob": "AQIDAH...",  # chave criptografada (para armazenar)
#   "Plaintext": "uNqS8..."        # chave em texto claro (usar e descartar)
# }

# 3. Usar a chave em texto claro para criptografar campo no PostgreSQL
# (armazenar o CiphertextBlob junto com os dados)

6. Gerenciamento de chaves e boas práticas

O ciclo de vida da chave inclui geração segura (usando fontes de entropia confiáveis), armazenamento em cofres de chaves (HashiCorp Vault, AWS KMS, Azure Key Vault), rotação periódica (a cada 90 dias ou conforme política de compliance) e revogação imediata em caso de comprometimento. Logs de auditoria devem registrar todas as operações de descriptografia, permitindo rastrear acessos suspeitos. Para ambientes críticos, o uso de HSMs (Hardware Security Modules) adiciona uma camada física de proteção.

7. Considerações de desempenho e manutenção

A criptografia de campo impacta consultas porque impede o uso de índices B-tree tradicionais em colunas criptografadas. Estratégias para mitigar esse problema incluem:

  • Índices em hashes: criar índices sobre hashes determinísticos do dado original (ex.: MD5 do CPF) para buscas exatas.
  • Cache de chaves: manter chaves em cache local (com tempo de expiração curto) para evitar chamadas frequentes ao cofre de chaves.
  • Criptografia seletiva: criptografar apenas campos realmente sensíveis, não todo o banco.

Testes de integridade devem verificar periodicamente se os dados criptografados podem ser descriptografados corretamente, simulando cenários de recuperação após falhas.

8. Conclusão e próximos passos

Proteger dados em repouso exige uma abordagem em camadas: a criptografia de disco completo protege contra roubo físico, enquanto a criptografia de campos protege dados sensíveis mesmo durante a execução do sistema. A combinação dessas técnicas, aliada a um gerenciamento rigoroso de chaves e monitoramento contínuo, forma a base de uma estratégia de segurança da informação sólida.

Para aprofundar, explore temas vizinhos como criptografia básica, segurança em pipelines CI/CD e rate limiting para APIs. Um checklist de auditoria deve incluir: verificação de que todos os volumes críticos estão criptografados, rotação de chaves em dia, logs de acesso às chaves ativos e testes de recuperação realizados trimestralmente.

Referências