Melhores Práticas de Segurança MySQL para LGPD.

LGPD não cita MySQL. Mas qualquer banco que armazene dado pessoal — e MySQL armazena, em praticamente todo SaaS, e-commerce e fintech do Brasil — está dentro do escopo da lei. Em incidente, a ANPD não pergunta qual SGBD você usa: pergunta quais controles técnicos e administrativos estavam ativos quando o dado vazou.

Este artigo traduz os princípios da LGPD em controles concretos de MySQL — o que ligar, como configurar e o que registrar para que, em auditoria ou incidente, exista evidência defensável. Faz parte do mesmo cluster da nossa consultoria MySQL.

Quatro artigos da LGPD têm reflexo técnico direto no MySQL:

• Art. 6º (princípios): finalidade, necessidade, segurança, prevenção. Traduz em mínimo privilégio e auditoria.
• Art. 18 (direitos do titular): acesso, retificação, anonimização, eliminação. Traduz em rotinas operacionais e logs de execução.
• Art. 46 (segurança): medidas técnicas e administrativas. Traduz em criptografia, controle de acesso, audit.
• Art. 48 (incidente): comunicação à ANPD e ao titular. Traduz em capacidade de saber o que vazou, quando e por quem.

O primeiro pecado de produção: aplicação conectando como root. Segundo: usuários com GRANT ALL ON *.*. Em auditoria LGPD, ambos são achados imediatos.

Roles (MySQL 8.x)

Use roles para encapsular conjuntos de privilégios — não conceda grant diretamente a usuários. Roles permitem revogar acesso em escala, documentar perfis e auditar mudanças.

Restrinja host de conexão: usuário 'app'@'%' é convite a credencial vazada virar acesso de qualquer IP. Use sub-rede da VPC ou IP fixo do load balancer.

TLS em todas as conexões

require_secure_transport = ON obriga TLS em todo client. Combine com REQUIRE SSL ou REQUIRE X509 por usuário para validação adicional. Em RDS/Aurora, a CA é fornecida pela AWS — rotacione antes do vencimento ou conexões caem em massa.

Encryption at rest (InnoDB tablespace encryption)

MySQL 8 suporta encryption at rest via keyring. keyring_file serve para POC, mas para produção use keyring_okv (Oracle Key Vault), keyring_aws (KMS) ou solução compatível com KMIP. Tabela é criptografada com ENCRYPTION='Y', redo log via innodb_redo_log_encrypt=ON, undo via innodb_undo_log_encrypt=ON, binlog via binlog_encryption=ON.

"Criptografia sem gestão de chaves é teatro. KMS centralizado, rotacionado, com audit log próprio."

SHOW BINARY LOGS não é audit log. Binlog é replicação e PITR — não retém o suficiente nem registra acessos de leitura. Para LGPD você precisa de audit plugin de verdade.

Opções: MySQL Enterprise Audit (oficial, pago), Percona Audit Log Plugin (open source, robusto), McAfee MySQL Audit Plugin (open source, em desuso). Configure para capturar: connections, failed logins, statements em tabelas sensíveis, mudanças em privilégios.

Audit log precisa ser imutável: append-only, com hash periódico, armazenado fora do host MySQL (idealmente SIEM ou S3 com Object Lock). Audit log no mesmo disco da base é a primeira coisa que atacante apaga.

Ambiente de homologação ou desenvolvimento com dump cru de produção é violação direta de LGPD — mesmo "só para corrigir bug". Mascaramento é obrigatório.

MySQL Enterprise traz Data Masking nativo (mysql.data_masking functions). Em Community, combine views com funções de hash/embaralhamento + Percona pt-archiver para extração + scripts de masking. Mantenha integridade referencial: hash determinístico (SHA-256 com salt) preserva joins entre tabelas mascaradas.

Direito à eliminação (Art. 18) inclui backup. Se o titular pede exclusão e o dado fica em backup mensal pelos próximos 7 anos, a empresa segue em desconformidade. A regra prática: retenção curta para PITR (binlog 7 dias), retenção média para operacional (30 dias), retenção legal documentada e expurgo automatizado.

Backups devem ser criptografados (mysqlbackup --encrypt ou Percona XtraBackup com encryption), armazenados em storage com controle de acesso separado do banco, e ter restore testado periodicamente. Backup que ninguém testa é arquivo, não backup.

Em incidente, a ANPD pede resposta em até 2 dias úteis. O MySQL precisa entregar, em horas, não dias: quem acessou, quando, quais dados, como entrou. Sem audit log preparado, essas perguntas ficam sem resposta — e isso por si só agrava a sanção.

Tenha um runbook documentado: como isolar o nó comprometido, como rotacionar credenciais, como extrair audit log e binlog para análise forense, como comunicar internamente. Ensaiar isso uma vez por ano é mínimo defensável.

• Nenhuma aplicação conecta como root.
• Privilégios via roles, com host restrito.
• require_secure_transport = ON.
• Encryption at rest com keyring KMS/Vault (não keyring_file).
• Audit log plugin ativo, externalizado, com integridade verificada.
• Senhas em vault (HashiCorp Vault, AWS Secrets Manager), nunca em código.
• Mascaramento obrigatório em homologação/dev.
• Backup criptografado com retenção documentada e restore testado.
• Rotina de exclusão LGPD documentada e logada.
• Runbook de resposta a incidente ensaiado anualmente.
• Cobertura por DBA Remoto 24/7 ou time interno responsável.