SEGURANÇA EM
BANCO DE DADOS:
AS FALHAS
SILENCIOSAS QUE
CUSTAM R$ 7 MILHÕES.

Falha 1 — Usuários com privilégios excessivos

O cenário mais comum: o desenvolvedor precisou de acesso DBA temporário para resolver um problema. O acesso nunca foi revogado. Seis meses depois, aquela conta ainda tem permissão de DROP em tabelas de produção — e ninguém sabe.

Privilégios excessivos são a porta de entrada mais silenciosa. Não aparecem em nenhum alerta. Não geram log sem monitoramento específico. E quando explorados — seja por um atacante externo que comprometeu a credencial, seja por um insider — o dano é total.

Falha 2 — Configurações padrão nunca alteradas

MySQL, SQL Server, Oracle, PostgreSQL — todos saem de fábrica com configurações que priorizam facilidade de instalação, não segurança. Usuários padrão habilitados. Portas conhecidas abertas. Autenticação por senha simples. Features ativas que nunca serão usadas.

Um ambiente configurado há três anos e nunca revisado desde então provavelmente ainda carrega vulnerabilidades que o fabricante já corrigiu — mas que dependem de reconfiguração manual para serem fechadas.

Falha 3 — Ausência de log de auditoria

Sem log de auditoria, você não sabe quem acessou o banco, quando, o que leu, o que modificou. Em caso de incidente, não há trilha forense. Em caso de auditoria de LGPD, não há evidência de controle.

Mais grave: sem log ativo, uma exfiltração de dados pode acontecer durante semanas antes de qualquer alerta. A IBM aponta que o tempo médio até identificar uma violação supera 55 dias em ambientes sem monitoramento adequado.

Falha 4 — SQL Injection não tratado no código da aplicação

SQL Injection é a vulnerabilidade mais documentada da história da segurança de aplicações. O OWASP Top 10 a classifica como uma das mais recorrentes desde 2003. E continua sendo explorada em 2025.

O banco de dados em si não é vulnerável a SQL Injection — a vulnerabilidade está no código da aplicação que não valida entradas antes de passá-las ao banco. Mas é o banco que carrega as consequências: dados expostos, tabelas corrompidas, acesso administrativo não autorizado.

A correção técnica existe e é bem documentada: prepared statements, validação de entradas, princípio do menor privilégio na conta de conexão. O problema é que ambientes legados raramente recebem essa revisão de forma sistemática.

Falha 5 — Backups sem criptografia e sem teste de restore

Backup descriptografado em armazenamento acessível é um banco de dados completo esperando ser roubado. Não precisa invadir o servidor de produção — basta acessar o repositório de backup.

Pior: a maioria das empresas nunca testou o restore dos seus backups. Um backup corrompido silenciosamente há seis meses significa que, em caso de desastre, o plano de recuperação não existe — só existe a ilusão de que existe.

Falha 6 — Versões desatualizadas com vulnerabilidades conhecidas

Cada versão de RDBMS desatualizada tem uma lista pública de CVEs (Common Vulnerabilities and Exposures) — vulnerabilidades documentadas, com exploits conhecidos, disponíveis para qualquer pessoa pesquisar. Um atacante não precisa descobrir uma vulnerabilidade zero-day. Precisa apenas consultar a lista e verificar se o seu banco ainda está na versão afetada.

Em 2024, 60% das organizações relataram violações causadas por componentes com vulnerabilidades conhecidas que simplesmente não haviam sido atualizados.

Falha 7 — Dados sensíveis sem criptografia em repouso

CPF, número de cartão, dados de saúde, senhas — armazenados em texto puro em tabelas de produção. Quem tem acesso SELECT à tabela tem acesso aos dados reais. Sem criptografia em repouso, não há segunda camada de proteção se o controle de acesso falhar.

E sob a LGPD, a ausência de criptografia de dados pessoais não é apenas risco técnico — é evidência de negligência em um eventual processo sancionatório.

Controle de acesso com registro

Quem acessa quais dados, quando e com qual finalidade. Sem log de auditoria ativo, não há como demonstrar controle — e sem demonstrar, não há como se defender em caso de notificação da ANPD.

Criptografia de dados pessoais

Dados de identificação, saúde, financeiros e outros dados sensíveis armazenados em banco de dados precisam de proteção adicional além do controle de acesso. Criptografia em repouso é a medida técnica mais direta para isso.

Plano documentado de resposta a incidentes

Em caso de violação, a LGPD exige comunicação à ANPD em prazo razoável. Para isso, você precisa saber que aconteceu um incidente — o que requer monitoramento ativo — e ter um plano documentado de resposta.

Camada 1 — Acesso e identidade

Revisão completa de usuários, roles, privilégios e contas de serviço. Identificação de contas inativas, privilégios excessivos e contas com senhas padrão. Verificação de acesso externo ao banco.

Camada 2 — Configuração e hardening

Comparação das configurações do banco com as best-practices de segurança do fabricante. Identificação de features ativas desnecessárias, portas expostas e parâmetros inseguros.

Camada 3 — Dados e criptografia

Mapeamento de tabelas com dados pessoais ou sensíveis. Verificação de criptografia em repouso e em trânsito. Identificação de dados sensíveis sem proteção adicional.

Camada 4 — Monitoramento e auditoria

Verificação de logs ativos, cobertura do monitoramento e capacidade de detectar acessos anômalos. Avaliação do plano de resposta a incidentes.