Banco de dados não deve ficar exposto sem necessidade
Um erro comum em servidores é deixar MySQL, MariaDB ou PostgreSQL escutando publicamente na internet. Isso aumenta o risco de tentativa de senha, exploração de falhas, vazamento e acesso indevido. Na maioria dos sites, o banco só precisa ser acessado pela própria aplicação no servidor, não por qualquer IP externo.
Em uma VPS, você tem autonomia para configurar isso corretamente. O objetivo é permitir acesso apenas por caminhos controlados: aplicação local, túnel SSH, VPN ou IPs autorizados.
Use bind local quando possível
Se o banco roda no mesmo servidor da aplicação, configure para escutar apenas em 127.0.0.1. Assim, ele aceita conexões locais, mas não fica disponível na interface pública. Essa é uma das medidas mais simples e efetivas para reduzir exposição.
Depois de alterar, teste se a aplicação continua conectando. Se ela usa host localhost ou 127.0.0.1, normalmente funciona. Se há outro servidor acessando o banco, será preciso planejar uma rota segura.
Firewall como segunda camada
Mesmo com bind correto, use firewall. Se o banco precisa escutar em rede privada, limite a porta apenas aos IPs necessários. Não libere 3306, 5432 ou outras portas para 0.0.0.0/0 sem motivo muito bem justificado. Firewall reduz o impacto de configurações erradas e ajuda a manter regras claras.
Em servidores Linux, ferramentas como UFW, firewalld ou regras diretas de iptables/nftables podem ser usadas. O importante é documentar o que está liberado e por quê.
Acesso administrativo por túnel SSH
Para acessar o banco a partir do seu computador, prefira túnel SSH. Assim, a porta do banco continua fechada publicamente, mas você consegue conectar uma ferramenta local pela porta encaminhada. Um exemplo para MySQL seria encaminhar uma porta local para o banco dentro da VPS.
Esse modelo é simples para administradores e desenvolvedores. Combine com chaves SSH, usuários individuais e permissões limitadas no banco. Se várias pessoas precisam acessar com frequência, uma VPN pode ser mais organizada.
VPN para equipe
Quando há equipe acessando bancos, painéis e sistemas internos, WireGuard ou outra VPN pode ser uma solução melhor. O banco aceita conexões apenas da faixa da VPN. Cada colaborador recebe uma chave própria. Quando alguém sai, você revoga o acesso sem alterar toda a estrutura.
Para ambientes maiores, como Servidor Dedicado com vários serviços, VPN e rede privada ajudam a separar tráfego administrativo do tráfego público.
Usuários com menor privilégio
Não use o usuário root do banco na aplicação. Crie usuários específicos por sistema, com permissões necessárias. Se a aplicação precisa apenas de um banco, não dê acesso a todos. Se uma rotina só lê dados, use permissão de leitura. Isso reduz danos se uma credencial vazar.
Também use senhas fortes e rotacione credenciais quando alguém da equipe sai ou quando há suspeita de vazamento. Credencial antiga esquecida é risco real.
Backups e logs
Segurança não é apenas impedir acesso. Faça backups, teste restauração e acompanhe logs de conexão e erro. Tentativas repetidas de login podem indicar ataque ou aplicação mal configurada. Consultas lentas podem indicar problema de performance.
Consulte as documentações oficiais do MySQL e do PostgreSQL para opções específicas de configuração.
Conclusão
Para proteger banco de dados em VPS, reduza exposição: bind local, firewall, túnel SSH, VPN e permissões mínimas. Não abra portas sensíveis para a internet por comodidade. Com camadas simples e bem configuradas, você melhora segurança sem dificultar a administração diária.
Nenhum comentário ainda. Seja o primeiro a comentar!