LGPD e Storage: O Risco Oculto em Backups e Logs

A infraestrutura de armazenamento de dados não é mais apenas um repositório passivo de bits; tornou-se um campo minado de responsabilidade jurídica. Para auditores e gestores de TI, a Lei Geral de Proteção de Dados (LGPD) e o GDPR transformaram práticas operacionais padrão — como snapshots de longa retenção e logs de depuração — em vetores de risco crítico.

A mentalidade tradicional de "armazenar tudo para sempre" colide frontalmente com os princípios de minimização de dados e limitação de armazenamento. Quando um titular de dados exerce seu direito de exclusão (Art. 18 da LGPD), a conformidade não se encerra no banco de dados da aplicação. Se esse dado persiste em um array de discos, em uma fita LTO ou em um log de transação de storage, a organização permanece em violação.

Resumo em 30 segundos

• O Paradoxo do Backup: Sistemas de backup imutáveis (WORM) entram em conflito direto com o "Direito ao Esquecimento", criando passivos jurídicos ocultos.
• Vazamento em Metadados: Logs de acesso (SMB/NFS) e nomes de arquivos em snapshots frequentemente contêm PII (Informação Pessoal Identificável) não criptografada.
• A Solução Criptográfica: O crypto-shredding (destruição de chaves) é a única metodologia técnica viável para garantir a sanitização de dados em mídias modernas como SSDs e NVMes.

A proliferação silenciosa em snapshots e backups

A arquitetura de storage moderna prioriza a durabilidade e a recuperação de desastres. Tecnologias como ZFS, com seus snapshots de baixo custo, ou appliances de deduplicação, encorajam a retenção massiva de histórico. No entanto, sob a ótica da conformidade, cada snapshot é uma "cópia fantasma" do ambiente de produção.

O cenário de risco é claro: um titular solicita a exclusão de seus dados pessoais. O DBA executa o comando DELETE no banco de dados principal. O sistema confirma a exclusão. O ticket de conformidade é fechado. Contudo, os dados desse usuário residem em:

1. Snapshots locais do storage tirados nas últimas 48 horas.

2. Backups incrementais enviados para um repositório secundário.

3. Fitas ou buckets de arquivamento frio (Cold Storage) com retenção de 5 anos.

Se a organização precisar restaurar um backup de duas semanas atrás devido a um ataque de ransomware, os dados do titular "excluído" ressurgem no ambiente de produção. Sem um processo de re-sanitização pós-restore, a empresa volta a processar dados ilegalmente no momento em que o sistema sobe.

⚠️ Perigo: A restauração de backups antigos é a causa número um de "reincidência de dados" em auditorias de privacidade. O dado volta "zumbi", sem o consentimento atualizado e frequentemente violando a solicitação de exclusão prévia.

O conflito técnico: Imutabilidade vs. Direito ao Esquecimento

A indústria de segurança da informação advoga agressivamente pelo uso de armazenamento imutável (WORM - Write Once, Read Many) como defesa contra ransomware. Se o dado não pode ser alterado ou deletado, o atacante não pode criptografá-lo.

Aqui reside o impasse jurídico. A LGPD exige que a organização tenha a capacidade técnica de eliminar dados quando a finalidade do tratamento cessa ou mediante solicitação. Se o seu storage está configurado com Object Lock ou retenção imutável de 3 anos em nível de hardware, a exclusão física é impossível sem destruir a mídia ou formatar o pool inteiro.

Para auditores, a justificativa de "limitação técnica" não é uma defesa válida para a retenção perpétua de dados pessoais sensíveis. A arquitetura deve ser desenhada prevendo a exclusão (Privacy by Design).

Persistência inadvertida de PII em logs e metadados

Enquanto o foco da conformidade recai sobre as tabelas de bancos de dados, os administradores de storage frequentemente ignoram a camada de gerenciamento. Logs de protocolos de arquivo (SMB, NFS) e logs de auditoria do próprio array de armazenamento são notórios por capturar PII.

Considere um servidor de arquivos corporativo. Um usuário salva um arquivo nomeado Relatorio_Medico_Joao_Silva_CPF_123456.pdf. Mesmo que o arquivo esteja em uma pasta criptografada, o nome do arquivo (metadado) trafega em texto claro nos logs do protocolo SMB e é gravado nos logs de acesso do storage (ex: /var/log/samba/ ou logs de auditoria do TrueNAS/NetApp).

Esses logs são frequentemente retidos por meses para fins de troubleshooting e raramente são alvo de políticas de expurgo de dados pessoais. Em uma auditoria forense, a presença de nomes e CPFs em logs de texto simples constitui uma violação de segurança (falta de criptografia) e de privacidade.

💡 Dica Pro: Configure seus níveis de log de storage para anonimizar ou excluir nomes de arquivos e caminhos completos, registrando apenas Handles de Arquivo ou IDs numéricos, a menos que o debug detalhado seja temporariamente necessário.

Crypto-shredding: A resposta técnica para mídias modernas

Diante da impossibilidade de garantir a sobrescrita física de dados em SSDs e NVMes (devido ao wear leveling e overprovisioning que escondem blocos físicos do sistema operacional), a exclusão lógica tradicional é insuficiente. A única metodologia robusta aceita em auditorias de alto nível para garantir a exclusão em mídias complexas ou imutáveis é o Crypto-shredding.

O conceito é criptografar os dados (seja por arquivo, por objeto ou por volume) e gerenciar as chaves de criptografia separadamente. Para "apagar" o dado, não se toca nos bits armazenados no disco; destrói-se a chave de decriptografia.

Figura: Fluxo lógico de Crypto-shredding: a eliminação da chave torna os dados irrecuperáveis sem necessidade de sobrescrita física.

Como vemos na representação acima, o dado permanece fisicamente na mídia, mas torna-se matematicamente irrecuperável. Isso resolve o problema dos backups imutáveis: se o backup contém dados criptografados e a chave foi destruída no sistema de gerenciamento de chaves (KMS), o backup é inútil para aquele dado específico, mantendo a integridade do restante do arquivo.

Implementação em Discos SED (Self-Encrypting Drives)

Para infraestrutura física, o uso de discos SED (Self-Encrypting Drives) é mandatório para conformidade robusta. Diferente da criptografia por software, o SED realiza a encriptação no hardware do controlador do disco, sem impacto de performance na CPU do servidor.

O recurso crítico aqui é o Instant Secure Erase (ISE). Ao descomissionar um servidor ou substituir um disco falho em um array RAID, o administrador envia um comando para o disco regenerar sua chave de criptografia interna (Media Encryption Key). Em milissegundos, terabytes de dados tornam-se lixo digital irrecuperável.

Sem o uso de SEDs ou criptografia de volume total (FDE), o descarte de discos rígidos e SSDs exige processos físicos caros e propensos a falhas humanas, como desmagnetização (degaussing) ou trituração física.

Protocolos de sanitização: O padrão NIST 800-88

Para fins de auditoria, "formatar" um disco é irrelevante. A norma técnica que rege a sanitização de mídia é a NIST SP 800-88 Rev. 1. Ela define três níveis de sanitização que devem constar nos relatórios de conformidade da infraestrutura de storage:

1. Clear (Limpeza): Métodos lógicos simples para prevenir recuperação por ferramentas de software padrão (ex: sobrescrita de zeros). Aceitável apenas para dados internos não confidenciais.

2. Purge (Expurgo): Métodos que protegem contra recuperação laboratorial invasiva. Para SSDs e NVMes, isso exige comandos específicos de firmware (como o comando NVMe Format com Secure Erase ou Sanitize Block Erase) ou Crypto-shredding. É o padrão mínimo para dados protegidos pela LGPD.

3. Destroy (Destruição): A inutilização física da mídia (trituração, incineração). Necessária quando o disco está danificado e não aceita comandos lógicos.

Auditores exigirão certificados de sanitização que especifiquem o método utilizado (ex: "NIST 800-88 Purge via Crypto Erase") e o número de série de cada disco descartado. A falta desse documento em um inventário de hardware é uma não-conformidade grave.

Recomendação de Governança

A infraestrutura de storage não pode ser gerida em um vácuo técnico. A desconexão entre as políticas de retenção jurídica e as configurações de backup/snapshot é um risco latente que, estatisticamente, se manifestará durante uma solicitação de acesso de titular ou um incidente de segurança.

Recomenda-se a revisão imediata das políticas de Lifecycle Management dos arrays de armazenamento. A implementação de criptografia granular e a adoção de hardware com suporte nativo a sanitização criptográfica não são custos adicionais, mas seguros obrigatórios contra multas que podem atingir 2% do faturamento global da empresa. O dado mais seguro é aquele que não existe mais; garanta que, quando você diz que ele foi apagado, ele realmente tenha sido.

Referências & Leitura Complementar

• NIST Special Publication 800-88 Revision 1: Guidelines for Media Sanitization. (Padrão ouro para destruição de dados).

• ISO/IEC 27040:2015: Information technology — Security techniques — Storage security. (Normas específicas para segurança em Storage).

• SNIA (Storage Networking Industry Association): "Data Encryption and Key Management for Storage".

• Lei nº 13.709/2018 (LGPD): Artigos 18 (Direitos do titular) e 46 (Segurança e sigilo de dados).