Segurança do banco de dados: as 8 camadas que a sua empresa precisa ter

Firewall na borda e senha forte no administrador resolvem uma parte pequena do problema. Este é um guia técnico das oito camadas de proteção do banco em si: o que cada uma controla, qual é o mínimo aceitável e como testar se funciona.

Na prática, a maioria dos incidentes graves com banco de dados não começa com uma técnica sofisticada.

Em geral, começa com uma porta 3306 ou 5432 exposta à internet. Com um usuário de aplicação que tem permissão de administrador porque, na migração de 2021, era mais rápido assim. Com uma cópia do banco de produção restaurada em homologação, com os dados reais dos clientes, acessível ao time de desenvolvimento inteiro.

Nenhuma dessas três coisas é um ataque. São aberturas. O ataque é só o que passa por elas.

A Gartner projetou que, até 2025, mais de 99% das falhas de segurança em nuvem seriam causadas por erro de configuração do próprio cliente, e não por falha do provedor (Gartner). Nesse sentido, a leitura prática dessa projeção é desconfortável: a maior parte do trabalho de segurança do banco de dados não está em comprar proteção; está, em vez disso, em configurar corretamente o que já existe.

Este artigo trata, sobretudo, das camadas de proteção do banco em si. Se você procura o quadro mais amplo (modelo de responsabilidade compartilhada, panorama de ameaças e estratégia de backup), ele está detalhado em segurança e backup de banco de dados na nuvem. Aqui, descemos um nível.

Por que segurança do banco de dados se organiza em camadas

Camadas existem porque nenhum controle isolado sobrevive a um erro. A lógica é que o atacante que vence a rede ainda precise vencer a autenticação; quem vence a autenticação ainda esbarre na autorização; e quem chega aos dados encontre criptografia e trilha de auditoria. Em resumo, é defesa em profundidade aplicada ao dado.

O modelo tem uma consequência prática importante: cada camada deve ser avaliada assumindo que a anterior falhou. Portanto, a pergunta correta não é “estamos protegidos?”. É “se alguém já estiver dentro da rede, o que ele consegue ler?”.

As oito camadas, na ordem em que um invasor as encontraria:

1. Superfície de rede
2. Autenticação e identidade
3. Autorização e privilégio mínimo
4. Criptografia e gestão de chaves
5. Camada de aplicação e injeção de SQL
6. Auditoria e trilha de log
7. Detecção e resposta
8. Hardening e ciclo de vida

Camada 1: Superfície de rede (onde o banco escuta)

O banco de dados nunca deve ser acessível diretamente da internet. Por isso, ele deve escutar apenas em rede privada, com acesso administrativo mediado por VPN ou host de salto (bastion), e com regras de firewall que liberem por origem específica, não por faixa aberta.

Controles mínimos:

• Bind em interface privada. O serviço escuta em endereço interno, não em 0.0.0.0.
• Sub-rede privada sem rota para a internet. Se o banco precisa sair para baixar atualização, isso passa por gateway controlado, não por IP público atribuído a ele.
• Grupo de segurança por origem. Libere a porta do banco apenas para os endereços dos servidores de aplicação. Nunca para 0.0.0.0/0.
• Acesso administrativo por VPN ou bastion. O DBA entra na rede antes de entrar no banco.
• Porta padrão alterada, quando não houver impacto operacional. Não é segurança de verdade, mas reduz ruído de varredura automatizada.

Como testar: faça uma varredura de portas a partir de um endereço externo à sua rede. Se a porta do banco responder, então essa camada não existe.

Camada 2: Autenticação e identidade

Autenticação responde a uma pergunta: quem está se conectando? A regra é eliminar credencial compartilhada, exigir segundo fator para acesso humano administrativo e guardar segredos em cofre, nunca em código ou arquivo de configuração versionado.

Controles mínimos:

• Uma identidade por pessoa. O usuário admin compartilhado por quatro pessoas torna impossível qualquer investigação posterior. Em outras palavras, se todos são admin, ninguém é responsável.
• Contas de serviço separadas das contas humanas. A aplicação usa uma credencial; a pessoa usa outra. Além disso, elas têm permissões diferentes e ciclos de vida diferentes.
• Autenticação multifator (MFA) para acesso administrativo. MFA é a exigência de um segundo elemento além da senha (token, aplicativo ou chave física).
• Cofre de segredos. Ferramenta que armazena senhas e chaves de forma criptografada e as entrega à aplicação em tempo de execução, com registro de quem pediu o quê. Credencial em .env no repositório é vazamento adiado.
• Rotação de credenciais. Senha de conta de serviço com prazo de validade e processo de troca sem parada.
• Bloqueio após tentativas. Limite de tentativas de autenticação com atraso progressivo.

O peso dessa camada é alto. Não por acaso, o relatório de investigação de violações da Verizon aponta que 68% das violações analisadas envolveram um elemento humano não malicioso, como erro, engano ou credencial cedida (Verizon, Data Breach Investigations Report, 2024). De fato, credencial é a porta mais usada porque é a mais barata de atravessar.

Como testar: liste todos os usuários do banco e, em seguida, identifique o dono de cada um. Se houver algum sem dono nomeado, você encontrou o problema.

Camada 3: Autorização e privilégio mínimo

Privilégio mínimo significa que cada conta recebe exatamente as permissões necessárias para a sua função e nada além disso. Ou seja, é a camada que determina o tamanho do estrago quando uma credencial vaza.

Controles mínimos:

• Nenhuma conta de aplicação com perfil de administrador. A aplicação que só lê e grava em cinco tabelas não precisa de DROP, não precisa criar usuário e não precisa acessar outros bancos da mesma instância.
• Permissão por papel (role), não por usuário. Crie papéis (leitura, escrita operacional, relatórios, administração) e associe pessoas a papéis. Na prática, isso torna a revisão viável.
• Separação entre leitura e escrita. Ferramentas de BI e relatórios conectam com credencial exclusivamente de leitura, preferencialmente em réplica.
• Views e colunas restritas. Em vez de dar acesso à tabela inteira, exponha uma view sem os campos sensíveis.
• Segurança em nível de linha (row-level security). Recurso que filtra automaticamente quais linhas cada usuário enxerga, útil em bancos multiempresa, onde um cliente jamais pode ver o registro de outro.
• Revisão trimestral de acessos. Lista de quem tem o quê, assinada pelo gestor da área.

Como testar: conecte-se com a credencial da aplicação e tente executar DROP TABLE em uma tabela de teste, ou consultar uma tabela fora do escopo dela. Se funcionar, o privilégio não é mínimo.

Camada 4: Criptografia e gestão de chaves

Criptografia protege o dado quando as camadas anteriores falham. São três frentes: em trânsito, em repouso e em nível de campo. A pergunta decisiva em todas elas, no entanto, é quem controla a chave.

• Criptografia em trânsito. Todo tráfego entre aplicação e banco passa por TLS, o protocolo que cifra a comunicação na rede. Não basta suportar: o banco deve recusar conexão não cifrada.
• Criptografia em repouso. Os arquivos de dados no disco ficam cifrados, de modo que uma cópia física do volume ou um snapshot vazado não seja legível. Nos bancos comerciais, isso costuma aparecer com o nome de TDE (Transparent Data Encryption).
• Criptografia em nível de coluna ou campo. Aplicada a dados especialmente sensíveis, como CPF, cartão e dados de saúde. O campo é cifrado individualmente, e nem quem tem acesso à tabela lê o conteúdo sem a chave.

Gestão de chaves é o ponto que quase todo mundo trata por último e que define se a criptografia vale alguma coisa:

• A chave nunca fica no mesmo lugar que o dado cifrado.
• Existe cofre de chaves (KMS) com controle de acesso e log próprio.
• Existe rotação periódica de chave.
• Existe procedimento documentado de recuperação. Chave perdida é dado perdido. Ou seja, criptografia sem plano de recuperação é ransomware que você aplicou em si mesmo.

Um cuidado adicional: criptografia em repouso não protege contra credencial comprometida. Isto é, quem se conecta legitimamente ao banco recebe o dado já decifrado. Ela protege contra roubo de mídia, snapshot vazado e acesso ao armazenamento por fora do banco, o que é relevante, mas é um cenário específico. O tema aparece também em armazenamento em nuvem seguro.

Como testar: tente abrir uma conexão sem TLS. Deve ser recusada. Depois, verifique se a chave de criptografia está armazenada em cofre separado e quem tem permissão para lê-la.

Camada 5: Aplicação, injeção de SQL e proxy

A maior parte dos vazamentos de banco não acontece por invasão do banco: acontece por abuso da aplicação que tem acesso legítimo a ele. Injeção de SQL é a técnica de inserir comando malicioso em um campo de entrada para que o banco o execute como se fosse parte da consulta.

Controles mínimos:

• Consultas parametrizadas (prepared statements). O comando e os dados trafegam separados, o que impede que o conteúdo digitado por um usuário vire instrução executável. De fato, é o controle mais eficaz e o mais barato.
• Validação de entrada no servidor. Validação apenas no navegador não vale nada, porque ela pode ser contornada.
• Mensagens de erro genéricas. Erro de banco exibido na tela entrega estrutura de tabela, nome de coluna e versão do servidor.
• WAF (firewall de aplicação web). Filtro que inspeciona requisições HTTP e bloqueia padrões conhecidos de ataque. Contudo, é complemento, não substituto de código correto.
• Proxy de banco de dados. Camada intermediária que centraliza conexões, aplica limites e registra consultas. Útil em ambientes com muitas aplicações acessando o mesmo banco.
• Limite de volume por consulta. Uma conta de relatório que normalmente lê 500 linhas não precisa poder extrair 4 milhões.

Como testar: rode uma varredura automatizada de injeção de SQL em ambiente de homologação e, em seguida, revise o código dos pontos onde a consulta é montada por concatenação de texto.

Camada 6: Auditoria e trilha de log

Auditoria responde a três perguntas depois do incidente: quem acessou, o que leu ou alterou e quando. Sem ela, uma investigação vira reconstituição por memória, e o prazo legal de notificação continua correndo.

Controles mínimos:

• Log de autenticação. Toda tentativa de conexão, bem-sucedida ou não, com origem e horário.
• Log de alteração de estrutura e permissão. Criação de usuário, mudança de privilégio, alteração de tabela.
• Log de acesso a dados sensíveis. Nem todo SELECT precisa ser registrado, mas consultas às tabelas com dado pessoal precisam.
• Log fora do banco. O registro deve ser enviado para um destino separado e, idealmente, imutável, isto é, armazenamento que não permite alteração nem exclusão dentro do período de retenção. Log que mora no servidor invadido é log que o invasor apaga.
• Retenção definida. Prazo escrito, alinhado com jurídico e com as obrigações do seu setor.
• Sincronização de relógio. Sem NTP, correlacionar eventos entre sistemas é impossível.

O tempo importa. O ciclo médio global entre a ocorrência e a contenção de uma violação foi de 258 dias (IBM, Cost of a Data Breach Report, 2024). Além disso, uma parte relevante desse tempo é gasta justamente descobrindo o que aconteceu, trabalho que só é possível com trilha de auditoria confiável.

Vale lembrar que a LGPD (Lei 13.709/2018) prevê sanções administrativas de até 2% do faturamento no Brasil, limitadas a R$ 50 milhões por infração, e exige que o controlador demonstre a adoção de medidas de segurança. Demonstrar exige registro.

Como testar: peça ao time uma resposta documentada para “quem consultou a tabela de clientes na terça-feira passada”. Cronometre.

Camada 7: Detecção e resposta

Detecção é o que transforma um log arquivado em alerta acionável. Ela funciona a partir de uma linha de base: você define o comportamento normal do banco e é avisado quando algo foge dele.

Sinais que valem um alerta:

• Autenticação bem-sucedida fora do horário habitual ou de origem geográfica atípica.
• Volume de leitura muito acima do padrão da conta, indício clássico de exfiltração.
• Sequência de falhas de autenticação seguida de sucesso.
• Execução de comandos de estrutura (DROP, TRUNCATE, ALTER) em produção.
• Criação de usuário ou concessão de privilégio fora de janela de mudança.
• Queda abrupta no tempo de resposta acompanhada de consultas atípicas.

Além do alerta, é preciso ter o plano. Quem é acionado, em quanto tempo, com que autoridade para desconectar sessões, isolar a instância ou revogar credenciais. Portanto, um plano de resposta que precisa de aprovação de diretoria às 3h da manhã não é um plano.

Como testar: faça um exercício controlado. Extraia um volume anormal de dados de uma tabela de teste com uma conta de relatório e cronometre quanto tempo leva até alguém ser avisado.

Camada 8: Hardening e ciclo de vida

Hardening é reduzir a superfície do próprio banco: remover o que não é usado, corrigir o que está vulnerável e impedir que dado de produção circule onde não deveria. É a camada mais rotineira e a mais adiada.

Controles mínimos:

• Remover contas e bancos de exemplo criados pela instalação padrão.
• Desativar funções e extensões não utilizadas, especialmente as que permitem execução de comando no sistema operacional.
• Ciclo de correção definido. Prazo máximo para aplicar correção crítica, com janela de manutenção acordada.
• Configuração revisada. Parâmetros de conexão, limite de sessões, tempo de espera, tamanho de log.
• Mascaramento de dados em ambientes não produtivos. Restaurar produção em homologação sem anonimizar é copiar o risco para um ambiente com menos controle. Inclusive, é um dos erros mais comuns e mais fáceis de corrigir.
• Descomissionamento com destruição de dado. Instância desligada com volume preservado continua sendo um banco de dados exposto.

Como testar: liste os ambientes que contêm dados pessoais reais. Se homologação, desenvolvimento ou a máquina de um analista estiverem na lista, comece por aí.

Tabela-resumo das 8 camadas

#	Camada	Falha típica	Controle mínimo	Teste de validação
1	Rede	Porta do banco exposta à internet	Sub-rede privada + firewall por origem	Varredura de portas externa
2	Autenticação	Conta admin compartilhada	Identidade individual + MFA + cofre de segredos	Listar usuários e apontar o dono de cada um
3	Autorização	Aplicação com perfil de administrador	Papéis + privilégio mínimo + revisão trimestral	Tentar DROP com a credencial da aplicação
4	Criptografia	Chave guardada junto com o dado	TLS obrigatório + repouso cifrado + cofre de chaves	Conectar sem TLS e verificar recusa
5	Aplicação	Consulta montada por concatenação	Consultas parametrizadas + WAF	Varredura de injeção em homologação
6	Auditoria	Log no próprio servidor do banco	Log externo e imutável + retenção definida	Reconstituir um acesso específico
7	Detecção	Alerta só para indisponibilidade	Linha de base + alerta de volume anômalo	Simular extração fora do padrão
8	Hardening	Produção restaurada em homologação	Mascaramento + patch com prazo + limpeza	Mapear onde há dado real

Se você só puder fazer três coisas este mês

Em ambientes de PME, com equipe reduzida, a ordem que produz mais redução de risco por hora investida é esta:

1. Tirar o banco da internet. Camada 1. É a correção com maior efeito e menor custo.
2. Retirar o perfil de administrador da conta da aplicação. Camada 3. Limita o estrago de qualquer credencial vazada.
3. Ativar log de autenticação e mandar para fora do servidor. Camada 6. Sem isso, você não saberá se algo aconteceu.

Depois disso, siga pelo checklist técnico de proteção de banco de dados e trate as camadas restantes em ciclos mensais.

Como a Prodb ajuda na segurança do banco de dados

A Prodb Tecnologia opera infraestrutura em nuvem no Brasil há 15 anos, com mais de 550 clientes. Vale dizer que segurança de banco de dados, no nosso trabalho, não é um produto separado. É como o ambiente é montado.

Na prática, isso significa:

• Rede desenhada com o banco em sub-rede privada por padrão. Acesso administrativo por caminho controlado, não por IP público.
• Monitoramento contínuo do ambiente, com acompanhamento de comportamento e não apenas de disponibilidade.
• Arquitetura sob medida por ambiente. Segregação entre produção, homologação e desenvolvimento definida junto com o cliente, e não herdada de um template.
• Infraestrutura no Brasil com certificações internacionais de nuvem, o que simplifica o tratamento de dado pessoal sob a LGPD e reduz latência. Conheça os servidores cloud.
• Suporte técnico dedicado. Quando um alerta dispara às 2h, você fala com alguém que conhece a topologia do seu ambiente.

Não existe banco de dados invulnerável, e desconfie de quem disser o contrário. Por outro lado, existe banco de dados em que o atacante precisa vencer oito obstáculos em vez de um, e em que você percebe a tentativa antes do terceiro.

Perguntas frequentes

O que é segurança do banco de dados?

É o conjunto de controles que protege o banco e os dados que ele guarda contra acesso indevido, vazamento, alteração e perda. Na prática, funciona em camadas: rede, autenticação, autorização, criptografia, aplicação, auditoria, detecção e hardening, de forma que a falha de uma não exponha os dados.

Quais são as camadas de segurança de um banco de dados?

São oito: superfície de rede, autenticação e identidade, autorização e privilégio mínimo, criptografia e gestão de chaves, aplicação e injeção de SQL, auditoria e trilha de log, detecção e resposta, e hardening e ciclo de vida. Cada uma deve ser avaliada assumindo que a anterior já falhou.

Qual a causa mais comum de incidentes com banco de dados?

Erro de configuração, e não técnica sofisticada. Os casos mais frequentes são porta do banco exposta à internet, conta de aplicação com permissão de administrador, credenciais compartilhadas e cópias de produção com dados reais em ambientes de homologação ou desenvolvimento.

Criptografia em repouso protege contra vazamento de dados?

Só em parte. Ela protege contra roubo de mídia, snapshot vazado e acesso ao armazenamento por fora do banco. Não protege contra credencial comprometida, porque quem se conecta legitimamente recebe o dado já decifrado. Por isso precisa ser combinada com autenticação forte e privilégio mínimo.

Como prevenir injeção de SQL?

O controle mais eficaz e barato é usar consultas parametrizadas, que separam o comando dos dados digitados pelo usuário. Complementam a proteção a validação de entrada no servidor, mensagens de erro genéricas, WAF e limite de volume por consulta.

O que a LGPD exige sobre segurança do banco de dados?

A LGPD (Lei 13.709/2018) exige que o controlador adote e consiga demonstrar medidas de segurança para proteger dados pessoais, e prevê sanções de até 2% do faturamento no Brasil, limitadas a R$ 50 milhões por infração. Demonstrar essas medidas depende de trilha de auditoria confiável.

Por onde começar a proteger o banco de dados?

Em equipes pequenas, três ações entregam mais redução de risco por hora: tirar o banco da internet, retirar o perfil de administrador da conta da aplicação e ativar o log de autenticação enviando-o para fora do servidor do banco.