Como publicar e conectar ao Postgres sem deixá-lo exposto

Publicado em 2026-09-12 por frfrand

Las cuatro formas de llegar a tu base de datos, ordenadas de peor a mejor, y por qué abrir el puerto 5432 a Internet es casi siempre la respuesta equivocada.

Chega o momento em que você precisa conectar um cliente de banco de dados ao seu Postgres em produção, ou que um aplicativo em outro servidor o consulte. Há quatro formas, e a diferença entre elas é enorme.

Opção 1: abrir a porta para a Internet

É a mais rápida e quase sempre a pior.

Você modifica a configuração para que escute em todas as interfaces, abre a 5432 no firewall, e pronto.

O que acontece depois: em questão de minutos seu servidor aparece nas listas dos scanners automáticos. A partir daí, o único que protege seus dados é a senha do banco e que nenhuma versão do Postgres tenha uma vulnerabilidade sem corrigir. Para sempre.

Há bancos de dados expostos na Internet com dados reais de clientes. Praticamente nenhum se abriu de propósito: ficaram assim depois de um teste.

Opção 2: abrir a porta mas limitar por origem

Melhor. Se só entra do escritório, você permite apenas esse endereço no firewall.

O problema é prático: os endereços residenciais mudam, as pessoas trabalham de outros lugares, e no final alguém amplia a regra "por um tempo".

Opção 3: o túnel SSH

Esta é a que resolve o caso "eu preciso me conectar" de forma limpa:

ssh -L 5432:localhost:5432 prod

Isso faz com que a porta 5432 do servidor apareça como local na sua máquina. Seu cliente se conecta ao localhost, o tráfego viaja criptografado dentro do SSH, e o banco não tem nenhuma porta aberta para o mundo.

O acesso fica atrelado à sua chave SSH, que é muito mais forte do que uma senha de banco de dados. E se a conexão cair ao mudar de rede, o autossh reconecta sozinho.

Opção 4: rede privada entre servidores

Para o caso "meu aplicativo está em outro servidor", o túnel também se aplica, mas de forma permanente: um túnel entre os dois VPS, iniciado do lado do aplicativo.

Do ponto de vista do app, o banco está no localhost. Da Internet, o servidor do banco não tem porta aberta. E como o túnel é iniciado por quem precisa se conectar, quem armazena os dados não precisa aceitar conexões entrantes de ninguém.

É o que fazemos entre os VPS da ArduMaker.

As quatro coisas que vale a pena revisar

Onde escuta. O parâmetro listen_addresses. Se disser localhost, aceita apenas conexões da própria máquina. Esse deve ser o valor, a menos que você tenha um motivo concreto.

Quem pode se conectar. O arquivo pg_hba.conf define, linha por linha, qual usuário pode entrar em qual banco de qual origem e com qual método. Dois avisos: o método deve ser scram-sha-256, não md5 (antigo) nem trust (que significa "sem senha"), e as regras são avaliadas em ordem, então a primeira que coincidir vence.

Com qual usuário seu aplicativo se conecta. Não com o superusuário. Crie um usuário com permissões apenas sobre o que precisa. No dia em que aparecer uma injeção SQL, a diferença entre ler uma tabela e excluir o banco é exatamente esse detalhe.

Se suas cópias restaurarem. Ter backups não basta: é preciso ter testado pelo menos uma restauração completa. Na primeira vez, sempre falta algo.