Existe um padrão nos incidentes com banco de dados que atendemos ou acompanhamos. Quase nunca o ataque começa com uma técnica sofisticada. Começa com uma instância de PostgreSQL exposta na internet porque “era só para o teste”, com uma senha que virou permanente, com um usuário de aplicação que tem privilégio de superusuário, ou com um backup que ninguém restaurou desde a implantação.

O relatório Cost of a Data Breach da IBM (2024) mediu que o tempo médio para identificar e conter uma violação de dados chega a 258 dias. Ou seja, mais de oito meses. Nesse intervalo, a operação segue normal, os relatórios fecham e o incidente já aconteceu.

Na prática, saber como proteger um banco de dados é executar um conjunto pequeno de controles bem conhecidos e nunca implantados até o fim. Este é o checklist. Doze pontos, agrupados em quatro camadas, na ordem em que valem mais.

Cada item traz o que verificar e o que fazer. Vale dizer que, se você trabalha com PostgreSQL, MySQL/MariaDB ou SQL Server, os exemplos se aplicam com pequenas variações de sintaxe.

Camada 1: superfície de exposição (pontos 1 a 3)

A primeira camada elimina o acesso que não deveria existir. É também a que dá mais resultado por hora de trabalho: reduz o número de pessoas e máquinas capazes de sequer tentar uma conexão.

1. Tire o banco de dados da internet

Banco de dados não deve ter IP público. Ele fica em sub-rede privada, e o acesso chega por VPN, bastion host (uma máquina intermediária, endurecida, usada como único ponto de entrada) ou pela própria rede interna da aplicação.

O que fazer:

• Remova o IP público da instância. Se a aplicação está na mesma rede, ela não precisa dele.
• Configure o grupo de segurança / firewall para aceitar conexões apenas do IP ou do grupo da aplicação. Nunca 0.0.0.0/0.
• Se alguém da equipe precisa acessar de casa, a resposta é VPN, não liberação de IP.

Teste rápido: de uma rede externa, tente telnet seu-host 5432 (PostgreSQL) ou 3306 (MySQL). Se conecta, então você tem um problema hoje, não amanhã.

2. Feche a porta padrão e o acesso administrativo remoto

Trocar a porta padrão não é segurança de verdade, mas reduz ruído de varredura automatizada. O controle que importa, contudo, é impedir login administrativo remoto e restringir por origem no próprio banco.

O que fazer:

• PostgreSQL: revise o pg_hba.conf. Nenhuma linha com trust. Use scram-sha-256 como método de autenticação e restrinja por faixa de rede. Confirme que listen_addresses não é * sem necessidade.
• MySQL/MariaDB: ajuste bind-address para a interface interna. Remova usuários com host %: rode SELECT user, host FROM mysql.user; e trate qualquer % em conta administrativa como liberação global.
• SQL Server: desative o protocolo TCP para a instância se ela só atende localmente e restrinja o endpoint pelo firewall.
• Em todos: remova contas de demonstração, bancos de exemplo e o usuário anônimo.

3. Mantenha versão e patch em dia

Versão fora de suporte não recebe correção de segurança. Logo, rodar um banco em fim de vida é aceitar, por contrato, conviver com falhas conhecidas e publicadas.

O que fazer:

• Levante a versão de cada instância e a data de fim de suporte do fabricante.
• Defina janela mensal de manutenção. Patch de segurança não espera pelo próximo projeto.
• Assine o feed de vulnerabilidades do seu banco. CVEs de motores de banco costumam ter exploração pública em pouco tempo.
• Teste o patch em ambiente de homologação com uma cópia recente dos dados, que você tem, se o ponto 11 estiver feito.

Camada 2: identidade e privilégio (pontos 4 a 6)

A segunda camada trata de quem entra e do que consegue fazer depois de entrar. Credencial válida usada indevidamente é o vetor mais difícil de detectar, porque o sistema não distingue invasor de usuário.

4. Aplique privilégio mínimo, de verdade

Cada usuário e cada aplicação recebem apenas as permissões necessárias para a função. Por exemplo, aplicação que só lê recebe SELECT. Nenhuma aplicação, em hipótese alguma, precisa de superusuário.

O que fazer:

• Crie um usuário por aplicação, não um usuário compartilhado por todo o ambiente.
• Separe leitura de escrita. Relatórios, BI e integrações leem por uma conta somente-leitura.
• No PostgreSQL, bloqueie o schema público, que é aberto por padrão em versões mais antigas: REVOKE ALL ON SCHEMA public FROM PUBLIC;
• Revogue DROP, TRUNCATE e ALTER de contas de aplicação. Migração de schema roda com credencial própria, usada apenas no deploy.
• Rode um inventário: liste todas as roles e o que cada uma pode fazer. Quase sempre aparecem três ou quatro contas que ninguém sabe de onde vieram.

5. Exija acesso nominal e MFA para humanos

Pessoas acessam com contas individuais e autenticação multifator (MFA), nunca com credencial compartilhada. Afinal, sem identidade individual, o log de auditoria não serve para nada.

O que fazer:

• Elimine o uso direto de postgres, root ou sa por pessoas. Essas contas ficam para processo, com senha em cofre e uso registrado.
• Integre a autenticação ao diretório corporativo, quando houver, para que o desligamento de um funcionário revogue o acesso automaticamente.
• Exija MFA no bastion host e na VPN.
• Faça revisão trimestral de acessos. Uma hora de reunião, uma planilha, e a lista de ex-funcionários com credencial ativa deixa de existir.

6. Tire senha do código e rotacione segredos

Senha de banco não fica em repositório, em arquivo .env versionado, em variável de ambiente de imagem pública nem em planilha compartilhada. Ela fica em cofre de segredos, com rotação programada.

O que fazer:

• Migre as credenciais para um gerenciador de segredos. A aplicação busca a senha em tempo de execução.
• Varra o histórico do repositório: uma senha removida em um commit continua no histórico do Git. Portanto, se apareceu lá, considere-a comprometida e troque.
• Defina rotação: 90 dias para credenciais de aplicação é um ponto de partida razoável.
• Chaves de API e tokens de integração seguem a mesma regra, com prazo de expiração.

Camada 3: o dado em si (pontos 7 a 9)

A terceira camada assume que alguém vai passar pelas duas primeiras. Trata-se, então, de tornar o dado inútil, ilegível ou inalcançável para quem chegou até ele.

7. Criptografe em repouso e em trânsito

O dado é criptografado no disco (com TDE, transparent data encryption, ou criptografia no nível do volume) e durante o tráfego pela rede (TLS 1.2 ou superior, obrigatório e não opcional).

O que fazer:

• Ative a criptografia de volume ou o TDE do motor. Isso protege contra roubo de disco e descarte inadequado de hardware.
• Force TLS nas conexões. MySQL: require_secure_transport = ON. PostgreSQL: ssl = on e hostssl no pg_hba.conf, sem linha host equivalente. Conexão sem TLS deve ser recusada, não apenas desencorajada.
• Criptografe também o arquivo de backup. Cópia em claro num bucket é o mesmo dado, com menos vigilância.
• Defina quem guarda a chave. Chave gerenciada pelo cliente em um KMS (key management service, serviço que armazena e controla o uso de chaves) dá controle de revogação e rotação.

8. Trate dado sensível como dado sensível

Nem todo dado tem o mesmo peso. CPF, dados de saúde, dados financeiros e credenciais, por exemplo, exigem controles adicionais. Vale lembrar que a LGPD (Lei nº 13.709/2018) responsabiliza a empresa por essa distinção.

O que fazer:

• Classifique as tabelas e colunas que contêm dado pessoal e dado pessoal sensível. Sem inventário, não existe conformidade.
• Nunca use dump de produção em homologação sem mascarar. É a falha mais comum e a mais fácil de corrigir: um script de anonimização no pipeline de refresh resolve.
• Aplique minimização: se o sistema não precisa do CPF completo para funcionar, guarde o hash ou os últimos dígitos.
• Defina descarte. Dado retido além da finalidade é risco sem contrapartida.

9. Blinde a camada de aplicação contra injeção

A maior parte dos vazamentos de banco não passa pelo banco: passa pela aplicação. A injeção de SQL segue listada entre os principais riscos de aplicações web pelo OWASP Top 10 (2021, categoria A03).

O que fazer:

• Use prepared statements e consultas parametrizadas em todos os pontos. Concatenação de string com entrada de usuário é proibida, sem exceção de “esse é interno”.
• Valide entrada por lista de permissão, não por lista de bloqueio.
• Configure mensagens de erro genéricas em produção. Stack trace com nome de tabela é mapa entregue de graça.
• Considere um WAF (web application firewall, filtro de tráfego HTTP) como camada adicional, nunca como substituto do código correto.
• Limite o resultado: uma API que devolve 200 mil registros em uma chamada é um vazamento esperando pelo momento certo.

Camada 4: detecção e recuperação (pontos 10 a 12)

A quarta camada parte de uma premissa desconfortável: em algum momento, algo vai passar. Assim, o que define o tamanho do estrago é a velocidade com que você percebe e a qualidade da cópia que sobrou.

10. Ligue log, auditoria e alerta

Registro de conexões, de tentativas falhas e de comandos administrativos, enviado para fora do próprio servidor. Log que mora na máquina comprometida é apagado junto com ela.

O que fazer:

• PostgreSQL: log_connections = on, log_disconnections = on, log_statement = 'ddl' no mínimo. Para auditoria detalhada, a extensão pgaudit.
• MySQL: ative o audit log da sua distribuição e o general_log em janelas de investigação.
• Envie tudo para um coletor externo, com retenção definida.
• Configure alerta para o que importa: pico de falhas de autenticação, criação de usuário, alteração de privilégio, DROP ou TRUNCATE em tabela de produção, e volume atípico de leitura.

O último é o mais negligenciado. Afinal, exfiltração de dados aparece como consulta bem-sucedida: legítima em forma, anômala em volume.

11. Backup imutável, com regra 3-2-1 e recuperação pontual

O backup precisa ser inalcançável a partir da produção. Isso significa cópia imutável (que não pode ser alterada ou apagada durante um prazo definido, nem por administrador) e credencial separada.

O que fazer:

• Aplique a regra 3-2-1: três cópias do dado, em dois tipos de mídia diferentes, com uma delas fora do local principal (Peter Krogh, The DAM Book, 2005).
• Combine backup físico com dump lógico. O físico volta rápido; o lógico, por sua vez, permite recuperar objeto isolado.
• Ative a recuperação pontual (PITR, point-in-time recovery): no PostgreSQL, via arquivamento de WAL; no MySQL, via binlog. É o que permite voltar para as 14h07, e não só para a cópia da madrugada.
• Marque as cópias como imutáveis com prazo mínimo e mantenha o repositório em conta separada da produção. Isso se aproxima de um air gap, ou seja, a ausência de rota de rede direta entre o ambiente ativo e as cópias.

Isso deixou de ser preciosismo: no State of Ransomware da Sophos (2024), 94% das organizações atingidas por ransomware relataram que os criminosos tentaram comprometer os backups, e as tentativas tiveram sucesso em 57% dos casos.

12. Escreva o plano de resposta e teste a restauração

Um backup nunca restaurado é uma hipótese. O plano de resposta define quem faz o quê, em que ordem e em quanto tempo. Já o teste comprova que o número no contrato é real.

O que fazer:

• Defina RPO (recovery point objective: quanto dado a empresa aceita perder, em tempo) e RTO (recovery time objective: quanto tempo o sistema pode ficar fora do ar) para cada base. Em horas, por escrito.
• Escreva um runbook de uma página: contatos, ordem de restauração, comandos, critério para declarar incidente.
• Teste a restauração completa a cada seis meses, em ambiente isolado, cronometrando. O tempo real é o seu RTO verdadeiro.
• Inclua o prazo regulatório no plano: a Resolução CD/ANPD nº 15/2024 estabelece 3 dias úteis para comunicação de incidente de segurança com dados pessoais à Autoridade Nacional de Proteção de Dados. Descobrir esse prazo durante a crise, portanto, é tarde demais.

Tabela de priorização: por onde começar na segunda-feira

Se você não pode fazer tudo, faça nesta ordem. A coluna de esforço considera uma equipe pequena de TI.

Note que quatro dos oito primeiros controles da tabela levam de um a dois dias. Ou seja: proteger banco de dados é menos uma questão de orçamento e mais de decidir que a tarefa entra no calendário.

Para o desenho completo das camadas de defesa, incluindo governança e segregação de ambientes, vale ler segurança do banco de dados: as 8 camadas que a sua empresa precisa ter. E para avaliar o repositório onde as cópias vivem, os critérios estão em armazenamento em nuvem seguro.

Como a Prodb aplica esse checklist em ambientes de cliente

A Prodb Tecnologia opera infraestrutura em nuvem há 15 anos, atende mais de 550 clientes e trabalha a partir da região de Campinas, em São Paulo. Nos projetos de banco de dados, o checklist acima não é entregue como recomendação: é implantado e verificado.

• Arquitetura por ambiente. Os servidores cloud são dimensionados conforme a carga real do banco, com isolamento de rede, sub-rede privada e regras de acesso definidas no desenho, não improvisadas depois.
• Backup com separação real. Os planos de backup usam credenciais e políticas de retenção independentes da produção, com camada de imutabilidade e recuperação pontual quando o motor suporta. A escolha de retenção parte do RPO acordado com o cliente, não de um padrão de catálogo.
• Dado no Brasil. Servidores em território nacional, infraestrutura com certificações internacionais de cloud e faturamento em real. Isso simplifica a resposta a auditorias de LGPD e evita a discussão sobre jurisdição estrangeira.
• Suporte técnico dedicado. Quem atende conhece o ambiente. Em restauração de banco, sobretudo, esse detalhe é a diferença entre uma hora e um turno inteiro.

Uma ressalva necessária: migrar o banco para a nuvem não protege o banco. Um ambiente mal configurado na nuvem é tão vulnerável quanto no rack da sala dos fundos, com a diferença de estar mais perto da internet. O que protege, no fim das contas, é a disciplina dos doze pontos. A nuvem só torna vários deles mais fáceis de aplicar. E se o seu provedor atual promete backup diário, vale conferir o que essa promessa costuma esconder.

Perguntas frequentes

O post Como proteger um banco de dados: checklist técnico em 12 pontos apareceu primeiro em Prodb.