Criptografia em repouso: do que protege e do que não protege

O que é

"Criptografia em repouso" designa várias camadas distintas. A documentação do PostgreSQL lista as seguintes entre as opções para um servidor de banco de dados: criptografia da partição de dados em nível de bloco ou de sistema de arquivos (no Linux, tipicamente dm-crypt com LUKS, gerenciado pelo cryptsetup), criptografia de colunas específicas com pgcrypto, em que o cliente fornece a chave e o servidor descriptografa, e criptografia no cliente, em que o servidor nunca vê o texto em claro. As plataformas de nuvem acrescentam a criptografia de volume gerenciada pelo provedor, com chaves em um serviço de gerenciamento de chaves. A documentação afirma sem rodeios o limite da criptografia de partição: ela impede que dados sem criptografia sejam lidos dos discos caso os discos ou o computador sejam roubados, mas não protege contra ataques enquanto o sistema de arquivos está montado, pois o sistema operacional então oferece uma visão não criptografada dos dados; além disso, para montá-lo é preciso entregar a chave ao host, o que às vezes significa que a chave fica armazenada nesse próprio host.

Por que importa

Os questionários perguntam "os dados são criptografados em repouso?" e um sim costuma ser interpretado como proteção contra vazamentos. Um ataque que passa pela aplicação ou por suas credenciais atinge um sistema em execução, no qual a criptografia de volume é transparente. Saber qual camada barra qual ameaça evita tanto a falsa sensação de segurança quanto complexidade desnecessária.

Como aplicar

• Ameaça: discos roubados ou desativados, mídias de backup perdidas, snapshots copiados para a conta errada. Controle: criptografia de volume completo, backups criptografados e uma chave guardada em outro lugar que não o disco criptografado.
• Ameaça: um administrador de banco de dados ou um invasor do host lendo determinados campos sensíveis. Controle: criptografia de colunas com chaves mantidas pela aplicação, aceitando que o texto em claro e a chave estejam presentes por um breve período no servidor (o modelo do pgcrypto), ou criptografia no cliente, que abre mão de busca e indexação no servidor sobre esses campos.
• Chaves: o cheat sheet Cryptographic Storage da OWASP recomenda armazenar as chaves separadamente dos dados, proteger a chave de criptografia de dados (DEK) com uma chave de criptografia de chaves (KEK) mantida em outro lugar, e conservar chaves aposentadas pelo tempo em que backups antigos puderem precisar delas.
• Registre por escrito, para cada classe de dados, qual camada a protege contra o quê; inclua backups, exportações e logs, que muitas vezes são a cópia sem criptografia.

Armadilhas

Criptografar uma coluna e depois indexar, pesquisar ou registrar em log o seu texto em claro. Perder a KEK, o que equivale a perder os dados. Tratar a criptografia gerenciada pelo provedor, em que o provedor detém a chave, como proteção contra o próprio provedor ou contra quem tenha as credenciais da sua conta. Supor que um volume criptografado torna os dumps criptografados: a saída do pg_dump, arquivos CSV exportados e arquivos de log ficam em texto claro, a menos que sejam criptografados separadamente.

Chaves em logs de comandos

Uma chave passada ao pgcrypto dentro de um comando SQL é gravada em todo lugar em que o texto do comando é gravado: o log do servidor com log_statement = 'all' ou log_min_duration_statement, pg_stat_activity.query, arquivos de histórico do cliente e qualquer proxy que faça log. Desde o PostgreSQL 13, os parâmetros de bind também são registrados por padrão, a menos que log_parameter_max_length seja 0. A descriptografia de colunas no servidor exige, portanto, que o log de comandos e de parâmetros seja desativado para o role que fornece as chaves e que o acesso aos logs seja tratado como acesso às chaves; se isso não puder ser garantido, use criptografia no cliente, em que a chave nunca chega ao servidor.