Cada vez que un cliente de base de datos envía una consulta (query) o recibe un conjunto de resultados (result set), esos datos viajan a través de una red. En una red privada y aislada sin acceso externo, esto puede ser un riesgo aceptable. Sin embargo, en la mayoría de los entornos del mundo real, donde el tráfico atraviesa infraestructura compartida, redes en cloud o en internet público, una conexión de base de datos sin cifrar supone una exposición significativa. El cifrado SSL/TLS cierra esa brecha, y configurarlo correctamente es uno de los pasos más importantes y frecuentemente pasados por alto en la protección de un entorno de base de datos.
Por qué las conexiones sin cifrar son un riesgo real
Sin cifrado, los datos intercambiados entre un cliente y un servidor de base de datos viajan en formato de texto plano (.txt). Cualquiera posicionado en la misma ruta de la red (ya sea a través de un enrutador comprometido, una red virtual en el cloud mal configurada o una amenaza interna) puede potencialmente leer ese tráfico. Esto incluye no solo los resultados de las consultas, sino también las credenciales de autenticación (user y password). Un paquete de inicio de sesión (login) capturado de una conexión de base de datos sin cifrar entrega al atacante el nombre de usuario y una contraseña válidos sin requerir de ningún esfuerzo adicional por su parte. El riesgo no es teórico; la interceptación a nivel de red es una técnica de ataque bien documentada, y su impacto es considerablemente peor cuando el tráfico interceptado proviene de una base de datos.
Comprendiendo la cadena de certificados
Transport Layer Security (TLS) se basa en un sistema de certificados digitales. Antes de que pueda comenzar la comunicación cifrada, el servidor presenta un certificado al cliente que prueba su identidad, diciendo claramente: "Soy quien digo ser, y aquí hay un documento firmado criptográficamente por una autoridad de confianza para demostrarlo". Esa autoridad de confianza es una Autoridad de Certificación (CA, por sus siglas en inglés), y su función es avalar las identidades de los certificados que emite.
En la práctica, esto significa que necesita tres cosas para establecer una conexión TLS debidamente verificada con un servidor de base de datos:
- El servidor debe tener un certificado válido emitido por una CA.
- El cliente debe tener una copia del certificado de la CA para poder verificar la identidad del servidor.
- (Opcionalmente) Para TLS mutuo (mTLS), el cliente también presenta su propio certificado al servidor, por lo que la autenticación se ejecuta en ambas direcciones. Esta autenticación opcional del lado del cliente se denomina a veces autenticación basada en certificados, y proporciona una garantía significativamente más fuerte que la autenticación basada únicamente en contraseñas.
Opciones clave de configuración que uno debe comprender
Al configurar TLS para una conexión de base de datos, varios parámetros aparecen consistentemente en diferentes sistemas de bases de datos y clientes:
- El archivo del certificado de la CA es el ancla de confianza (trust anchor). Le indica al cliente en qué autoridad de certificación confiar al verificar la identidad del servidor.
- El archivo del certificado del cliente y el archivo de la clave del cliente (client key file) se utilizan cuando se requiere TLS mutuo, permitiendo al servidor verificar la identidad del cliente a su vez.
- La especificación del algoritmo de cifrado (cipher specification) controla qué algoritmos de cifrado son aceptables para la sesión; especificar algoritmos de cifrado modernos y robustos en lugar de aceptar los predeterminados es una buena práctica, ya que las suites de cifrado más antiguas tienen debilidades conocidas.
Opciones SSL de PostgreSQL
PostgreSQL añade una dimensión particularmente útil a esto con su configuración de modo SSL, que le permite definir exactamente cuán estricta debe ser la conexión. Las opciones van desde allow (intentar primero sin SSL, recurrir a SSL si es necesario) y prefer (intentar primero con SSL, recurrir a sin cifrar) pasando por require (solo SSL, pero no verifica el certificado) hasta verify-ca (SSL y verifica que el certificado proviene de una CA de confianza) y verify-full (SSL, CA verificada, y el nombre de host del servidor debe coincidir con el certificado). Para entornos de producción, verify-ca o verify-full son las opciones apropiadas, ya que cualquier opción menos permisiva deja margen para un ataque del intermediario (man-in-the-middle).
Los túneles SSH como enfoque alternativo
SSL/TLS cifra el propio protocolo de la base de datos. Los túneles Secure Shell (SSH) adoptan un enfoque diferente: envuelven toda la conexión de la base de datos dentro de una sesión SSH cifrada. El cliente de base de datos se conecta a un puerto local, un túnel SSH reenvía ese tráfico a través de una conexión cifrada al servidor remoto, y el servidor de base de datos ve una conexión local desde el extremo del túnel (tunnel endpoint). El uso de túneles SSH es particularmente útil en situaciones donde el servidor de base de datos no tiene TLS configurado, o donde los puertos directos de la base de datos no están expuestos externamente por razones del firewall, ya que requiere únicamente acceso SSH en lugar de configuración TLS a nivel de base de datos. También es una forma sencilla de asegurar el acceso remoto para los administradores que necesitan conectarse de forma interactiva a una base de datos que se encuentra detrás de un host bastión (bastion host).
Cómo Navicat da soporte a SSL/TLS y a los túneles SSH
Los productos de escritorio de Navicat (incluyendo Navicat Premium y los clientes individuales específicos para cada base de datos) proporcionan la configuración de SSL/TLS directamente dentro de la interfaz de configuración de la conexión, accesible a través de una pestaña SSL dedicada al crear o editar una conexión. Desde allí, los usuarios pueden habilitar SSL, proporcionar el archivo del certificado de la CA necesario para verificar la identidad del servidor, y opcionalmente proporcionar un certificado de cliente y un archivo de clave de cliente para TLS mutuo. Un campo de especificación de cifrado permite a los administradores restringir qué suites de cifrado son aceptables para la conexión, en lugar de depender de valores predeterminados negociados. Específicamente para las conexiones de PostgreSQL, Navicat expone la gama completa de opciones del modo SSL descritas anteriormente, dando a los administradores un control preciso sobre cuán estrictamente se verifica la conexión.
Los túneles SSH también están soportados de forma nativa en toda la familia de productos Navicat. La pestaña SSH en el cuadro de diálogo de conexión permite a los usuarios configurar un túnel a través de un servidor SSH intermedio, con soporte tanto para autenticación basada en contraseñas como en pares de claves pública/privada. Esto hace que sea sencillo conectarse de forma segura a bases de datos que no están expuestas directamente a redes externas.
Navicat On-Prem Server amplía este soporte SSL/TLS también a la colaboración. Las conexiones entre el On-Prem Server y sus clientes se pueden cifrar utilizando SSL/TLS, permitiendo a los administradores configurar las suites de cifrado específicas utilizadas para esas sesiones. SSL/TLS también se puede aplicar a la conexión entre Navicat On-Prem Server y su base de datos de repositorio subyacente, asegurando que la infraestructura interna de la plataforma de colaboración esté cifrada de extremo a extremo (end-to-end), no solo las conexiones de los usuarios finales.
Conclusión
Configurar SSL/TLS para las conexiones de bases de datos no es una empresa compleja, pero requiere prestar atención a los detalles (como la gestión de certificados, la selección del modo y la configuración del cifrado) que son fáciles de hacer mal o dejar en valores predeterminados inseguros. La recompensa por hacerlo correctamente es una reducción significativa del riesgo de que la interceptación a nivel de red resulte en el robo de credenciales o la exposición de datos. Para cualquier base de datos que maneje datos sensibles o a la que se acceda a través de cualquier red que no sea totalmente privada y aislada, TLS configurado correctamente no es opcional: es un requisito base fundamental.
