Como se compromete una base de datos (y cómo se evita)
Publicado em 2026-09-12 por frfrand
Los cinco caminos reales por los que se filtran datos, en orden de frecuencia. Ninguno implica romper el cifrado, y casi todos se cierran con decisiones que ya conocés.
Quando se fala de "hackear um banco de dados" a imagem mental costuma ser alguém quebrando uma criptografia. Na realidade, quase nenhum vazamento ocorre assim.
Estes são os caminhos reais, em ordem de frequência.
1. Estava aberta
O mais comum, e o menos glamoroso.
Uma porta de banco de dados exposta à Internet, com uma senha fraca ou diretamente sem autenticação. Redes inteiras escaneiam o espaço de endereços procurando exatamente isso, o dia todo.
Quase nunca foi aberta propositalmente: ficou assim após um teste, uma migração ou um "vou abrir por cinco minutos".
É fechada assim: fazendo com que o banco escute apenas no localhost, e que o acesso remoto seja por túnel ou rede privada. Se algo não precisa estar aberto, não se abre.
2. Injeção SQL
Continua vigente após vinte e cinco anos.
Ocorre quando a entrada do usuário é colada dentro de uma consulta como texto. Se alguém escreve algo que inclui aspas e mais SQL, esse SQL é executado.
A solução não é escapar aspas manualmente, nem filtrar palavras suspeitas. É usar consultas parametrizadas: o valor viaja separado da consulta e nunca se torna parte do SQL.
# vulnerável q = "SELECT * FROM usuarios WHERE mail = '" + mail + "'"
# correto cur.execute("SELECT * FROM usuarios WHERE mail = %s", [mail])
Todo ORM moderno faz isso por padrão. O risco aparece quando alguém monta uma consulta manualmente "porque o ORM não suportava".
3. Uma credencial vazada
A senha do banco terminou em um commit, em um log, em uma captura de tela, em um bate-papo.
Isso se reduz a: credenciais fora do código, .env ignorado desde o primeiro commit, e — o mais importante — rotá-las assim que houver suspeita. Lembre-se de que excluir uma chave de um commit não a remove do histórico.
4. Demasiados privilégios
Este não abre a porta, mas decide quanto se perde.
Se sua aplicação se conecta com o usuário administrador, qualquer um dos três caminhos anteriores dá acesso total: ler tudo, modificar tudo, excluir tudo.
Se se conecta com um usuário que só pode ler e escrever nas tabelas que usa, o mesmo erro tem um alcance muito menor.
É a medida mais barata de todas e a que mais se ignora, porque no início "é mais cômodo assim".
5. A cópia de segurança
O banco pode estar perfeitamente protegido e o despejo noturno estar em uma pasta acessível, ou em um armazenamento em nuvem mal configurado, ou no laptop de alguém.
Um backup é uma cópia completa dos seus dados sem nenhuma das proteções do banco. Merece o mesmo cuidado: criptografia, permissões rigorosas e acesso limitado.
O que deve ser verificado hoje
Cinco perguntas concretas:
- O banco escuta em todas as interfaces ou apenas no localhost?
- Sua aplicação se conecta com o superusuário?
- Há alguma consulta montada com concatenação de texto?
- Onde estão os backups e quem pode lê-los?
- Quando foi a última atualização do motor?
Nenhuma dessas perguntas requer conhecimentos avançados de segurança. É exatamente o ponto: a maioria das vazamentos poderia ser evitada com decisões que a equipe já sabia tomar.
