Cómo publicar y conectarte a Postgres sin dejarlo expuesto

Publicado el 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.

Llega el momento en que necesitás conectar un cliente de base de datos a tu Postgres en producción, o que una aplicación en otro servidor lo consulte. Hay cuatro formas, y la diferencia entre ellas es enorme.

Opción 1: abrir el puerto a Internet

Es la más rápida y casi siempre la peor.

Modificás la configuración para que escuche en todas las interfaces, abrís el 5432 en el firewall, y listo.

Lo que pasa después: en cuestión de minutos tu servidor aparece en las listas de los escáneres automáticos. A partir de ahí, lo único que protege tus datos es la contraseña de la base y que ninguna versión de Postgres tenga una vulnerabilidad sin parchear. Para siempre.

Hay bases de datos expuestas en Internet con datos reales de clientes. Prácticamente ninguna se abrió a propósito: quedaron así después de una prueba.

Opción 2: abrir el puerto pero limitar por origen

Mejor. Si sólo entra desde la oficina, permitís únicamente esa dirección en el firewall.

El problema es práctico: las direcciones domésticas cambian, la gente trabaja desde otros lados, y al final alguien amplía la regla "por un rato".

Opción 3: el túnel SSH

Esta es la que resuelve el caso "yo necesito conectarme" de forma limpia:

ssh -L 5432:localhost:5432 prod

Eso hace que el puerto 5432 del servidor aparezca como local en tu máquina. Tu cliente se conecta a localhost, el tráfico viaja cifrado dentro de SSH, y la base no tiene ningún puerto abierto al mundo.

El acceso queda atado a tu clave SSH, que es mucho más fuerte que una contraseña de base de datos. Y si la conexión se corta al cambiar de red, autossh la reconecta sola.

Opción 4: red privada entre servidores

Para el caso "mi aplicación está en otro servidor", el túnel también aplica, pero permanente: un túnel entre los dos VPS, iniciado desde el lado de la aplicación.

Desde el punto de vista de la app, la base está en localhost. Desde Internet, el servidor de la base no tiene puerto abierto. Y como el túnel lo inicia el que necesita conectarse, el que guarda los datos no tiene que aceptar conexiones entrantes de nadie.

Es lo que hacemos entre los VPS de ArduMaker.

Las cuatro cosas que conviene revisar

Dónde escucha. El parámetro listen_addresses. Si dice localhost, sólo acepta conexiones de la propia máquina. Ese debería ser el valor salvo que tengas una razón concreta.

Quién puede conectarse. El archivo pg_hba.conf define, línea por línea, qué usuario puede entrar a qué base desde qué origen y con qué método. Dos avisos: el método debe ser scram-sha-256, no md5 (viejo) ni trust (que significa "sin contraseña"), y las reglas se evalúan en orden, así que la primera que coincide gana.

Con qué usuario se conecta tu aplicación. No con el superusuario. Creá un usuario con permisos sólo sobre lo que necesita. El día que aparezca una inyección SQL, la diferencia entre leer una tabla y borrar la base es exactamente ese detalle.

Si tus copias restauran. Tener backups no alcanza: hay que haber probado al menos una restauración completa. La primera vez siempre falta algo.