BANCO DE DADOS · MYSQL · LGPD

    Segurança MySQL e LGPD: Checklist Completo 2026.

    HTI Tecnologia · Equipe TécnicaPublicado em junho de 20269–11 min de leitura

    MySQL nunca foi projetado para ser seguro por padrão — foi projetado para subir rápido e aceitar conexão. Em produção, isso vira problema na primeira auditoria, e vira incidente na primeira credencial vazada. Este checklist condensa a metodologia que a HTI aplica em consultoria MySQL especializada em segurança: os quatro pilares de hardening que cobrem 90% do risco real, conectados explicitamente ao que a LGPD (Lei 13.709/2018) exige como evidência.

    Atuamos com banco de dados desde 1990, somos AMEC Oracle e mantemos engenheiros que já resolveram mais de 596 incidentes críticos em produção. Tudo aqui é calibrado contra recorrência real — não contra documentação genérica.

    POR QUE MYSQL NÃO É SEGURO 'DE FÁBRICA'

    A instalação padrão do MySQL otimiza para que o banco "ligue". bind-address em 0.0.0.0 em vários pacotes Linux, root com host % em ambientes mal provisionados, criptografia em trânsito opcional, encryption at rest desligado, audit log inexistente. Em auditoria LGPD, cada um desses pontos vira achado — e, em incidente, vira a explicação para a ANPD.

    Em ambientes que auditamos via Health Check, 38% dos servidores MySQL têm a porta 3306 exposta à internet. O número mais alarmante é o segundo: quase todos esses servidores acreditavam estar atrás de firewall. Hardening não é opcional — é o piso da operação.

    01

    PRINCÍPIO DO MENOR PRIVILÉGIO

    O primeiro pecado de produção: aplicação conectando como root. O segundo: usuários com GRANT ALL ON *.*. Em qualquer auditoria de privilégios, esses dois pontos viram achado imediato — e a LGPD (Art. 6º, princípios de necessidade e segurança) exige que cada acesso seja proporcional à finalidade.

    Diagnóstico: quem pode o quê

    -- Listar usuários e hosts permitidos
    SELECT user, host, plugin, account_locked, password_expired
    FROM mysql.user
    ORDER BY user, host;
    -- Para cada usuário suspeito:
    SHOW GRANTS FOR 'app'@'%';

    Usuário com host % é convite a credencial vazada virar acesso de qualquer IP. Use sub-rede da VPC ou IP fixo do load balancer.

    Correção via roles (MySQL 8.x)

    -- Padrão: role por perfil, usuário herda role
    CREATE ROLE 'app_read', 'app_write';
    GRANT SELECT ON loja.* TO 'app_read';
    GRANT SELECT, INSERT, UPDATE ON loja.* TO 'app_write';
    -- Atribui ao usuário com host restrito:
    CREATE USER 'app_pedidos'@'10.0.%' IDENTIFIED BY '...';
    GRANT 'app_write' TO 'app_pedidos'@'10.0.%';
    SET DEFAULT ROLE ALL TO 'app_pedidos'@'10.0.%';
    -- Revoga acessos legados:
    REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'legacy_app'@'%';
    DROP USER 'legacy_app'@'%';

    Erro comum: conceder SUPER, PROCESS ou RELOAD a usuários de aplicação "para resolver um caso pontual" e esquecer de revogar. Cada um desses privilégios é vetor de evasão de audit log.

    02

    EXPOSIÇÃO DE REDE

    Em auditoria, a porta 3306 exposta a 0.0.0.0 é o achado mais frequente — e o mais corrigível. O parâmetro bind-address controla em qual interface o MySQL escuta. Em servidor que atende apenas aplicação interna, ele nunca deveria estar em 0.0.0.0.

    # /etc/mysql/mysql.conf.d/mysqld.cnf
    [mysqld]
    bind-address = 10.0.1.15  # IP privado da instância
    port = 3306
    # Em ambientes multi-tenant, considere ainda:
    skip-name-resolve = ON

    Combine com regras de Security Group / firewall que permitam ingress 3306 apenas das sub-redes de aplicação. RDS e Aurora seguem o mesmo princípio — publicly_accessible = false e Security Group restrito.

    Validação rápida

    # Do host MySQL — confirmar em qual interface escuta
    ss -tlnp | grep 3306
    # De fora da VPC — não deve responder:
    nmap -p 3306 -Pn meu-servidor-publico.com

    Esse tipo de validação faz parte de qualquer auditoria de segurança MySQL séria — e é um dos primeiros itens que ANPD examina em incidente envolvendo dado pessoal.

    MYSQL SECURITY AUDIT

    🛡 Diagnóstico de segurança em 30 minutos.

    Auditoria dos quatro pilares — privilégios, exposição de rede, criptografia e audit log — com plano de remediação priorizado por severidade.

    Solicitar MySQL Security Audit →

    03

    CRIPTOGRAFIA EM REPOUSO E EM TRÂNSITO

    TLS obrigatório em todas as conexões

    require_secure_transport = ON obriga TLS em todo client. Aplicações que ainda conectam em texto plano falham com mensagem clara — melhor do que descobrir o vazamento depois.

    -- Forçar TLS no servidor inteiro
    SET PERSIST require_secure_transport = ON;
    -- Ou no my.cnf:
    require_secure_transport = ON
    -- Por usuário (validação adicional):
    ALTER USER 'app'@'10.0.%' REQUIRE SSL;
    ALTER USER 'app_critico'@'10.0.%' REQUIRE X509;

    Encryption at rest (InnoDB tablespace encryption)

    MySQL 8 suporta encryption at rest via keyring. keyring_file serve para POC, mas em produção use keyring_okv (Oracle Key Vault), keyring_aws (KMS) ou solução compatível com KMIP.

    -- Criar tabela criptografada e ligar encryption nos logs
    CREATE TABLE clientes (
      id BIGINT PRIMARY KEY,
      cpf VARCHAR(14) NOT NULL,
      email VARCHAR(255) NOT NULL
    ) ENGINE=InnoDB ENCRYPTION='Y';
    -- Redo / Undo / Binlog encryption:
    SET PERSIST innodb_redo_log_encrypt = ON;
    SET PERSIST innodb_undo_log_encrypt = ON;
    SET PERSIST binlog_encryption = ON;
    "Criptografia sem gestão de chaves é teatro. KMS centralizado, rotacionado, com audit log próprio — separado do banco que ele protege."

    Para LGPD: criptografia de dados pessoais é a mitigação de risco mais defensável em caso de incidente (Art. 46). Ausência dela em base com CPF, e-mail ou dado financeiro é difícil de justificar perante a ANPD.

    04

    AUDIT LOG E MONITORAMENTO DE ACESSO

    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, capturando conexões, falhas de login, statements em tabelas sensíveis e mudanças em privilégios.

    Opções práticas: MySQL Enterprise Audit (oficial, pago), Percona Audit Log Plugin (open source, robusto). Em ambos, o destino do log deve ser fora do host MySQL — SIEM, S3 com Object Lock, ou storage WORM. Audit log no mesmo disco da base é a primeira coisa que atacante apaga.

    -- Exemplo: Percona Audit Plugin com filtros úteis
    INSTALL PLUGIN audit_log SONAME 'audit_log.so';
    SET GLOBAL audit_log_policy = 'ALL';
    SET GLOBAL audit_log_format = 'JSON';
    SET GLOBAL audit_log_rotate_on_size = 104857600;
    -- Monitorar tentativas falhas em tempo real:
    SELECT event_time, user, host, status
    FROM mysql.general_log
    WHERE command_type = 'Connect' AND status <> 0
    ORDER BY event_time DESC LIMIT 50;

    Erro comum: ativar audit log, gerar 50 GB por dia e nunca olhar. Audit log só vale o I/O extra se entra em dashboards, alertas e revisão semanal. Esse é o tipo de operação contínua coberta por um serviço de DBA Remoto com NOC 24/7.

    COMO A LGPD SE CONECTA A CADA PILAR

    A LGPD não cita MySQL — ela exige evidência de controle. Cada pilar acima responde a um dispositivo legal específico:

    • Privilégios (Art. 6º, princípios de necessidade e segurança): acessos proporcionais à finalidade, com revisão documentada. SHOW GRANTS exportado periodicamente é evidência defensável.
    • Exposição de rede (Art. 46, medidas técnicas): banco com porta pública é "controle inadequado" por definição. Em incidente, agrava a sanção (Art. 52, §1º, III).
    • Criptografia (Art. 46 + Art. 48, §3º): dado pessoal criptografado pode dispensar comunicação ao titular em caso de incidente, dependendo do caso concreto avaliado pela ANPD. Sem criptografia, a comunicação é obrigatória.
    • Audit log (Art. 37 e Art. 48): obrigação de manter registro do tratamento e capacidade de informar à ANPD o que foi acessado, por quem, quando, em até 2 dias úteis após a tomada de conhecimento.

    Em caso de incidente envolvendo backup, retenção e direito à exclusão (Art. 18), o ecossistema de banco entra inteiro no escopo — inclui também Disaster Recovery e LGPD.

    05

    CHECKLIST MARCÁVEL DE CONFORMIDADE

    Use isto em revisão trimestral ou em pré-auditoria:

    • ☐ Nenhuma aplicação conecta como root.
    • ☐ Nenhum usuário com GRANT ALL ON *.* exceto contas administrativas controladas.
    • ☐ Privilégios concedidos via roles, com host restrito (sub-rede privada).
    • ☐ SHOW GRANTS exportado e revisado a cada trimestre.
    • ☐ bind-address em IP privado; porta 3306 fechada para internet.
    • ☐ Security Group / firewall permite ingress apenas das sub-redes de aplicação.
    • ☐ require_secure_transport = ON.
    • ☐ Tabelas com dado pessoal criadas com ENCRYPTION='Y'.
    • ☐ Encryption ligado em redo log, undo log e binlog.
    • ☐ Keyring em KMS centralizado (não keyring_file).
    • ☐ Audit plugin instalado, com destino externo ao host.
    • ☐ Log de falhas de login monitorado em SIEM, com alerta.
    • ☐ Backups criptografados, com restore testado nos últimos 90 dias.
    • ☐ Runbook de resposta a incidente documentado e ensaiado em 12 meses.

    PRÓXIMO PASSO

    Quer saber se seu MySQL está exposto a riscos de LGPD?

    Cada item do checklist acima é simples isoladamente — mas validar todos, em produção, sem janela de risco, exige método. Comece pelo diagnóstico:

    Fale com um especialista em Consultoria MySQL→💬 WhatsApp — Resposta imediata: Fale com um especialista em MySQL agora↗🛡 MySQL Remoto DBA — Operação contínua com NOC 24/7 e SLA contratual↗

    06

    PERGUNTAS FREQUENTES

    MySQL Community Edition é suficiente para atender LGPD?

    Atende, com ressalvas. TLS, encryption at rest via keyring, roles e controle de privilégios estão no Community. Audit log nativo e data masking, porém, são exclusivos do Enterprise — ou exigem Percona Audit Plugin / ProxySQL no Community. Para LGPD, o que importa é o controle estar implementado, documentado e auditável; o fornecedor é detalhe.

    Preciso criptografar tudo? Mesmo dados que não são pessoais?

    A LGPD obriga proteger dados pessoais (Art. 46). Mas separar tablespaces criptografados e não criptografados aumenta complexidade operacional sem ganho real. Em produção, a recomendação é criptografar tudo: encryption at rest com KMS centralizado e TLS obrigatório em todo client. O custo de CPU é marginal em hardware moderno; o custo de auditar 'o que está e o que não está' é alto.

    O que a ANPD pede em caso de incidente envolvendo MySQL?

    Evidência de que controles estavam ativos antes do incidente, escopo do dado vazado (quais titulares, quais campos), prazo entre detecção e contenção, e medidas para mitigar reincidência. Sem audit log íntegro, responder essas perguntas é especulação — o que agrava a sanção. Audit trail preparado é o que separa multa proporcional de multa máxima.

    Quem é responsável: a empresa ou o provedor de cloud?

    Responsabilidade compartilhada, mas a LGPD recai sobre o controlador — sua empresa. AWS, GCP ou Azure cuidam da segurança física e do hypervisor. Configurar usuários, privilégios, bind-address, encryption, audit, retenção de backup e resposta a incidente é seu. RDS gerenciado não significa LGPD gerenciado.

    Continue lendo