Cómo exponer bases de datos públicamente usando NLB en Data Center

Introducción

Conectar a bases de datos gestionadas desde entornos externos es un requisito común en arquitecturas modernas, especialmente cuando se integran aplicaciones web, móviles o servicios en la nube. Sin embargo, exponer una base de datos directamente a internet plantea riesgos significativos de seguridad. Tradicionalmente, técnicas como el túnel SSH se han utilizado para acceder a bases de datos internas, pero presentan limitaciones notables para entornos productivos.

En este artículo técnico, exploraremos en detalle una alternativa segura, eficiente y escalable para exponer bases de datos gestionadas públicamente usando un Network Load Balancer (NLB) en un centro de datos virtualizado. Médiante un paso a paso exhaustivo y consejos prácticos, entenderás cómo esta solución permite balancear tráfico TCP hacia bases de datos sin comprometer la seguridad ni la operatividad.

Las limitaciones del acceso mediante túnel SSH a bases de datos

Una práctica común para acceder a bases de datos internas es la creación de túneles SSH, que cifran y redirigen el tráfico vía un servidor intermedio con acceso SSH. A pesar de su popularidad, esta técnica presenta varios inconvenientes:

• Dependencia de una conexión permanente: El túnel requiere que la sesión SSH esté abierta continuamente; si se cierra, la conexión se interrumpe.
• Requisito de un servidor SSH expuesto: Es necesario que exista un servidor intermedio con puerto SSH abierto y accesible desde internet, lo que puede implicar riesgos de seguridad.
• Complejidad operativa en ambientes de producción: No es práctico ni escalable para conexiones automatizadas o desde aplicaciones web.

Por estas razones, el uso de túneles SSH se limita generalmente a entornos de desarrollo o pruebas, y no resulta recomendable para producción.

¿Por qué necesitamos una alternativa para exponer bases de datos?

Imagina tener una aplicación web alojada en internet que necesita leer y escribir información en una base de datos gestionada ubicada dentro de un centro de datos virtual. La aplicación debe conectarse directamente a la base de datos usando protocolos TCP específicos (por ejemplo, PostgreSQL utiliza el puerto 5432).

Sin embargo, esta base de datos se encuentra en una red privada y no está accesible desde internet, ni tiene servicios HTTP/HTTPS expuestos, sino un puerto TCP para su motor de base de datos. Por ende, necesitamos un método para:

• Exponer este recurso TCP hacia internet de manera segura.
• Evitar mantener conexiones complejas como túneles SSH.
• Garantizar alta disponibilidad y escalabilidad en el acceso.

Conceptos clave: Protocolos TCP y redes privadas

Las bases de datos manejan protocolos propios basados en TCP, no HTTP ni HTTPS, por lo que no pueden exponerse simplemente a través de un proxy HTTP convencional.

Además, el recurso perteneciente a la base de datos está en una red privada aislada (subred LAN) dentro del centro de datos virtual, lo que impide el acceso directo desde internet. Por tanto, necesitamos un intermediario que redirija tráfico TCP de internet hacia ese recurso privado.

Introducción al Network Load Balancer (NLB)

El Network Load Balancer (NLB) es un componente esencial en infraestructuras de redes que permite distribuir tráfico TCP y UDP entrante hacia uno o múltiples destinos internos (targets), manteniendo su transparencia y alta disponibilidad.

A diferencia de un balanceador de carga HTTP, un NLB trabaja a nivel de transporte (capa 4 OSI), permitiendo balancear tráfico TCP puro, muy adecuado para protocolos de bases de datos.

Ventajas del servicio PaaS y bases de datos gestionadas DBaaS

Beneficios clave del NLB para exponer bases de datos

• Exposición controlada: Permite asociar una IP pública a la capa de balanceo para reenviar tráfico TCP a recursos privados.
• Alta disponibilidad: Distribuye conexiones a varios servidores o instancias redundantes.
• Escalabilidad: Facilita agregar o eliminar targets sin interrumpir el acceso.
• Mejora de la seguridad: Reduce la superficie de exposición al evitar abrir múltiples puertos o servicios directamente.

Arquitectura de ejemplo para explicar el proceso

En este artículo usaremos como referencia práctica una configuración basada en el Data Center Designer (DCD) de Arsys, con los siguientes elementos:

• Una base de datos gestionada PostgreSQL (pgsql) en una red privada LAN 2.
• Un Network Load Balancer conectado a internet con IP pública asignada.
• Una regla de reenvío (forwarding rule) configurada para redirigir tráfico al puerto 5432 del servidor pgsql.

Esta arquitectura simula un entorno real donde la base de datos no está accesible directamente ni mediante túneles SSH, sino a través del NLB.

Configurando el Network Load Balancer para bases de datos gestionadas

A continuación explicamos paso a paso los elementos claves para la configuración correcta.

1. Asignación de la IP pública al NLB

El primer paso es asociar una IP pública al Network Load Balancer, asegurándonos que esta IP esté reservada y disponible en nuestro espacio de direcciones públicas.

Esta IP será la puerta de entrada desde internet hacia nuestra base de datos.

2. Definición de la regla de reenvío

Creamos una forwarding rule que indique que las conexiones que lleguen a la IP pública y al puerto 5432 (puerto típico de PostgreSQL) serán redirigidas hacia el target.

Este target será la IP privada del servidor de base de datos gestionada, en este caso la dirección 107.226.3, aunque normalmente pertenezca a una red privada.

3. Configuración del target en el NLB

Al agregar el target, es importante ignorar la advertencia del portal de administración que indica que esa IP no se encuentra dentro de los servidores reconocidos. Esto ocurre porque las bases de datos gestionadas no forman parte del pool clásico de servidores virtualizados, aunque sí están accesibles por IP.

Por tanto, introducimos manualmente la IP privada de la base de datos como target y confirmamos que el puerto es el 5432.

4. Validar los puertos y tráfico permitido

En nuestras reglas de firewall internas y externas debemos asegurar que el puerto 5432 está abierto para tráfico TCP en la IP pública del NLB.

Monitorización y métricas clave para bases de datos gestionadas DBaaS

También se recomienda validar que la base de datos acepta conexiones desde la IP pública del NLB para evitar bloqueos.

Ejemplo detallado de configuración

Verificando la conexión desde un cliente externo

Una vez configurado el NLB y la regla de reenvío, podemos probar la conexión con herramientas de administración de bases de datos como Azure Data Studio o pgAdmin.

Desde una máquina cliente externa, se configurará la conexión apuntando a la IP pública del NLB (ej. 85.215.148.59) y al puerto 5432.

El proceso es sencillo:

• Abrir Azure Data Studio.
• Crear una nueva conexión con la IP pública del NLB como servidor.
• Ingresar las credenciales adecuadas.
• Conectar y verificar que los datos se muestran correctamente.

Esta conexión confirma que el NLB está redirigiendo correctamente el tráfico TCP hacia la base de datos gestionada.

Buenas prácticas y consideraciones de seguridad

Exponer una base de datos a internet siempre implica riesgos, por lo tanto es crucial aplicar medidas de seguridad:

• Limitar el acceso por IP: Configurar listas blancas para permitir conexiones sólo desde hosts o redes específicas confiables.
• Uso de autenticación segura: Emplear credenciales robustas y métodos de autenticación avanzados en la base de datos.
• Monitoreo y logging: Registrar toda conexión entrante para detectar actividad sospechosa.
• Actualizaciones y parches: Mantener la base de datos y el nivel de red actualizados frente a vulnerabilidades.
• Evitar puertos comunes abiertos sin protección: En la medida de lo posible, utilizar VPN o mecanismos adicionales de protección.

Comparativa entre acceso por túnel SSH y NLB

Paso a paso para implementar el acceso a base de datos mediante NLB

1. Reservar una IP pública en el centro de datos virtual.
2. Configurar el Network Load Balancer y asociar dicha IP pública.
3. Crear una regla de reenvío que escuche en el puerto del motor de base de datos (5432 para PostgreSQL).
4. Agregar como target la IP privada de la base de datos gestionada y puerto correspondiente.
5. Asegurar que en el firewall y políticas de red se permite el tráfico hacia la IP pública en el puerto indicado.
6. Probar la conexión desde una máquina cliente externa mediante una herramienta compatible.
7. Aplicar medidas de seguridad recomendadas para minimizar riesgos.

Ejemplo práctico con PostgreSQL

El ejemplo ilustra cómo exponer un servidor PostgreSQL gestionado con la IP privada 107.226.3:

• La IP pública asociada al NLB es 85.215.148.59.
• Se configura el NLB para recibir conexiones TCP en el puerto 5432.
• El NLB reenvía el tráfico a la IP 107.226.3, puerto 5432 dentro de la red privada.
• Desde Azure Data Studio, se conecta usando la IP pública y las credenciales del usuario PostgreSQL.
• Se comprueba la conexión y la visualización de datos.

¿Querés profundizar visualmente en este proceso? Te invitamos a ver el video explicativo que acompaña este artículo donde se demuestra paso a paso la configuración y conexión efectiva a la base de datos gestionada usando un NLB.

Palabras clave relacionadas y su importancia

DBaaS (Database as a Service)

Se refiere a la provisión de bases de datos gestionadas como servicios en la nube, que abstraen la administración del hardware y software. Es fundamental entender cómo exponer estos servicios de forma segura desde redes privadas al mundo exterior.

Bases de Datos Gestionadas

Son instancias de bases de datos que el proveedor administra integralmente, incluyendo actualizaciones, backups y escalabilidad. La exposición debe ser cuidadosa para no comprometer la integridad ni disponibilidad.

Cómo combinar ALB y NLB en redes privadas y balanceadores

Acceso Externo

Hacer que recursos internos puedan ser consumidos fuera de la red privada, en este caso, una base de datos. Es clave asegurar una conexión controlada y protegida.

Seguridad

Aspecto central cuando se expone bases de datos, requieren mecanismos de autenticación, autorización, control de acceso, cifrado y monitorización.

PostgreSQL

Uno de los motores de base de datos open source más populares y el ejemplo usado para ilustrar la configuración con NLB. Manipula conexiones tcp sobre el puerto 5432 por defecto.

MongoDB

Base de datos NoSQL que también usa conexiones TCP. El método presentado es adaptable para otros motores similares.

Centro de Datos Virtual

Infraestructura virtualizada que permite desplegar servidores, bases de datos y servicios interconectados. La configuración de red es vital para extender servicios dentro y fuera del centro.

Data Center Designer (DCD)

Herramienta para diseñar y administrar infraestructuras de centros de datos virtuales. Facilita la configuración del NLB y recursos vinculados.

Cloud y PaaS

Plataformas que ofrecen recursos escalables, como bases de datos gestionadas, que pueden ser integradas con soluciones como NLB para una exposición controlada y robusta.

Software Defined Data Center (SDDC)

Enfoque que abstrae la infraestructura física mediante software, permitiendo gestionar recursos de red, computación y almacenamiento de forma programable, clave para implementar balanceadores y acceso seguro.

Preguntas frecuentes (FAQ)

¿Qué riesgos implica exponer una base de datos gestionada directamente a internet?

Exponer la base de datos a internet puede abrir la puerta a ataques como intentos de acceso no autorizado, inyección de comandos, ataques de denegación de servicio (DDoS) y fuga de información. Sin medidas adecuadas de seguridad, la base de datos puede ser comprometida, afectando integridad, confidencialidad y disponibilidad.

¿Por qué no es recomendable usar túneles SSH para producción?

El túnel SSH depende de mantener una conexión activa, lo que dificulta la escalabilidad y automatización. Además, requiere que el servidor SSH esté accesible públicamente, aumentando los riesgos de seguridad. Para entornos productivos, no es práctico ni seguro a gran escala.

Bastión en cloud qué es y cómo crear redes y balanceadores

¿Cómo protege un NLB una base de datos cuando la expone a internet?

El NLB actúa como primer punto de contacto, permitiendo controlar qué tráfico TCP se redirige hacia el recurso interno. Se pueden implementar reglas de acceso, limitar puertos y realizar monitoreo, reduciendo la superficie de ataque si se configura correctamente.

¿Qué sucede si la IP del target no está registrada como servidor en el portal del centro de datos?

El portal puede mostrar una advertencia porque no reconoce esa IP como parte integral del pool de servidores. Sin embargo, mientras la IP pertenezca a la red privada y el recurso esté activo, el NLB podrá redirigir el tráfico sin problemas.

¿Es posible balancear múltiples bases de datos gestionadas con un solo NLB?

Sí, configurando múltiples reglas de reenvío para diferentes puertos o diferentes IPs virtuales, se puede balancear tráfico para múltiples bases de datos o instancias.

¿Qué herramientas permiten verificar la conexión a base de datos a través del NLB?

Herramientas como Azure Data Studio, pgAdmin para PostgreSQL, o clientes específicos de cada motor permiten probar la conexión enviando consultas y verificando respuesta.

¿Se puede usar el NLB con base de datos NoSQL como MongoDB?

Sí, el NLB es agnóstico al tipo de base datos y protocolo TCP, puede usarse con MongoDB o cualquier otro siempre que el puerto y protocolo TCP sean compatibles.

¿Qué configuraciones de firewall son necesarias para que funcione el NLB?

Se debe permitir el tráfico entrante TCP en la IP pública del NLB en el puerto asignado a la base de datos. Además, la comunicación interna debe permitir que el NLB acceda a la IP privada del servidor base de datos en el mismo puerto.

¿Qué hacer si la conexión a la base de datos a través del NLB no funciona?

Primero verificar la configuración de la regla de reenvío, IP pública y target. Asegurarse de que firewalls y listas de control no bloqueen el tráfico. Confirmar que el servicio de base de datos está activo y escuchando el puerto correcto. Usar herramientas de diagnóstico de red como telnet o nc para probar conectividad.

¿Cómo garantizar la seguridad en conexiones abiertas mediante NLB?

Implementar listas blancas de IP, usar autenticación fuerte, cifrar datos en tránsito mediante SSL/TLS si el motor lo soporta, realizar monitoreo continuo y limitar las exposiciones a sólo lo estrictamente necesario.

Conclusión

Exponer bases de datos gestionadas directamente a internet es una tarea que debe abordarse con precaución y profesionalismo. El uso de un Network Load Balancer (NLB) representa una solución avanzada que combina accesibilidad, escalabilidad y seguridad cuando se configura adecuadamente.

Este enfoque supera las limitaciones del túnel SSH y facilita la integración de bases de datos en arquitecturas modernas, especialmente en entornos cloud y centros de datos virtualizados.

Cómo crear healthchecks efectivos en redes privadas y balanceadores

¿Buscás implementar este tipo de soluciones en tu empresa? En Código6 podemos ayudarte. Somos especialistas en automatización, inteligencia artificial y transformación digital. Contactanos para comenzar tu proyecto hoy.