Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Asegurando Conexiones PostgreSQL con Configuración SSL/TLS: Una Guía Completa

Aprenda cómo asegurar las conexiones de PostgreSQL con cifrado SSL/TLS. Esta guía completa cubre la configuración del lado del servidor y del cliente, incluyendo la generación de certificados, la modificación de `postgresql.conf` y `pg_hba.conf`, y la configuración de clientes para una comunicación segura y cifrada. Proteja sus datos sensibles en tránsito y asegure el cumplimiento con los estándares de seguridad modernos.

101 vistas

Configuración de SSL/TLS para asegurar las conexiones de PostgreSQL: Una guía completa

En el panorama digital interconectado actual, asegurar los datos en tránsito es primordial. PostgreSQL, una potente base de datos relacional de código abierto, ofrece mecanismos robustos para cifrar las conexiones mediante SSL/TLS. Esta guía proporciona un recorrido completo sobre cómo configurar tanto los servidores como los clientes de PostgreSQL para forzar el cifrado SSL/TLS, protegiendo la información sensible contra escuchas (eavesdropping) y ataques de intermediario (man-in-the-middle) en redes no confiables. La implementación de estas medidas de seguridad es crucial para mantener la integridad de los datos, garantizar el cumplimiento de estrictos estándares de seguridad y generar confianza con sus usuarios.

Este artículo cubrirá los pasos esenciales, desde la generación u obtención de certificados SSL hasta la configuración de PostgreSQL para utilizarlos, y finalmente, la configuración de los clientes para conexiones seguras. Profundizaremos en los parámetros de configuración necesarios y proporcionaremos ejemplos prácticos para ayudarle a implementar estas mejoras de seguridad de manera efectiva.

Entendiendo SSL/TLS en PostgreSQL

SSL/TLS (Secure Sockets Layer/Transport Layer Security) es un protocolo criptográfico diseñado para proporcionar seguridad en la comunicación a través de una red informática. Cuando se aplica a PostgreSQL, cifra los datos intercambiados entre el servidor de la base de datos y sus clientes. Esto impide que partes no autorizadas intercepten y lean información sensible como credenciales, datos financieros o detalles personales.

PostgreSQL admite dos modos principales para SSL/TLS:

  • ssl=on: Permite conexiones SSL pero no las requiere. Los clientes pueden conectarse usando conexiones SSL o no SSL.
  • ssl=prefer: Intenta establecer una conexión SSL pero recurre a una conexión no SSL si falla.
  • ssl=require: Requiere conexiones SSL. Si no se puede establecer una conexión SSL, la conexión del cliente será rechazada.

Forzar ssl=require es la opción más segura para proteger los datos en tránsito.

Requisitos previos para la configuración de SSL/TLS

Antes de comenzar a configurar PostgreSQL para SSL/TLS, asegúrese de tener lo siguiente:

  1. OpenSSL instalado: El kit de herramientas OpenSSL es esencial para generar y administrar certificados SSL. Generalmente viene preinstalado en sistemas Linux y macOS. Para Windows, es posible que deba descargarlo e instalarlo por separado.
  2. Acceso a los archivos de configuración de PostgreSQL: Necesitará privilegios administrativos para modificar los archivos postgresql.conf y pg_hba.conf.
  3. Comprensión de las Autoridades de Certificación (CA): Aunque puede crear certificados autofirmados para pruebas, los entornos de producción idealmente deben utilizar certificados firmados por una Autoridad de Certificación (CA) confiable o una CA empresarial interna.

Configuración SSL/TLS del lado del servidor

La configuración del lado del servidor implica habilitar SSL, especificar la ubicación de los certificados y claves SSL, y configurar la autenticación del cliente.

1. Generación u obtención de certificados y claves SSL

Hay dos formas principales de obtener certificados SSL para su servidor PostgreSQL:

  • Certificados autofirmados (para pruebas/desarrollo): Estos se crean usando OpenSSL y no son confiables por defecto por clientes externos. Son útiles para la configuración inicial y las pruebas internas.
  • Certificados de una Autoridad de Certificación (CA) (para producción): Obtenga certificados de una CA pública confiable (ej. Let's Encrypt, DigiCert) o una CA empresarial interna. Esto asegura que los clientes puedan verificar la identidad del servidor.

Creación de certificados autofirmados usando OpenSSL:

Este es un enfoque común para entornos de desarrollo e internos. Ejecute los siguientes comandos en su servidor PostgreSQL o en una máquina con OpenSSL:

  1. Crear un directorio para los certificados: Es una buena práctica mantener los certificados organizados.
    bash sudo mkdir -p /etc/postgresql/ssl sudo chown postgres:postgres /etc/postgresql/ssl cd /etc/postgresql/ssl

  2. Generar la Clave Privada del Servidor: Esta clave debe mantenerse en secreto.
    bash sudo openssl genrsa -des3 -out server.key 2048
    Se le pedirá que ingrese una frase de contraseña (passphrase). Recuerde esta frase, ya que la necesitará cuando PostgreSQL se inicie.

  3. Eliminar la Frase de Contraseña (opcional pero recomendado para reinicios automáticos): Para el inicio automático sin ingresar la frase de contraseña manualmente, elimine la frase. Tenga mucho cuidado, ya que cualquiera con acceso a este archivo puede hacerse pasar por su servidor.
    bash sudo openssl rsa -in server.key -out server.key

  4. Crear una Solicitud de Firma de Certificado de Servidor (CSR): Esto contiene información sobre su servidor.
    bash sudo openssl req -new -key server.key -out server.csr
    Se le pedirá información como Nombre del País, Estado, Nombre de Localidad, Nombre de la Organización, Nombre Común (este debe ser el nombre de host o la dirección IP de su servidor) y una dirección de correo electrónico.

  5. Firmar el Certificado con su propia CA (para uso interno):

    • Crear una clave privada y un certificado de CA raíz (si no tiene uno):
      bash # Generar clave privada de CA sudo openssl genrsa -des3 -out root.key 2048 # Crear certificado de CA (válido por 3650 días) sudo openssl req -new -x509 -days 3650 -key root.key -out root.crt
    • Firmar el CSR del servidor con la CA: Esto crea el certificado de servidor confiable.
      bash sudo openssl x509 -req -days 365 -in server.csr -CA root.crt -CAkey root.key -set_serial 01 -out server.crt

  6. Establecer permisos: Asegúrese de que el usuario PostgreSQL pueda leer estos archivos.
    bash sudo chown postgres:postgres server.key server.crt root.crt sudo chmod 600 server.key sudo chmod 644 server.crt root.crt

Uso de certificados de una CA pública/empresarial:

Si obtiene certificados de una CA, normalmente recibirá:

  • server.crt: El certificado público de su servidor.
  • server.key: La clave privada de su servidor.
  • root.crt (o similar): El certificado raíz de la CA (y potencialmente certificados intermedios).

Ponga estos archivos en un directorio seguro (ej. /etc/postgresql/ssl/) y asegúrese de que el usuario PostgreSQL tenga permisos de lectura.

2. Configuración de postgresql.conf

Edite su archivo postgresql.conf (generalmente ubicado en el directorio de datos de PostgreSQL) para habilitar SSL y especificar los archivos de certificado.

#------------------------------------------------------------------------------
# SSL
#------------------------------------------------------------------------------

ssl = on

# Todos estos están en formato PEM, y se ignoran si la clave/certificado del servidor no están configurados. Por defecto, se espera que los archivos estén en el directorio de datos del servidor. Alternativamente, se pueden especificar como rutas completas.
ssl_cert_file = '/etc/postgresql/ssl/server.crt'     # (cambie el nombre del archivo si es necesario)
ssl_key_file = '/etc/postgresql/ssl/server.key'      # (cambie el nombre del archivo si es necesario)
ssl_ca_file = '/etc/postgresql/ssl/root.crt'         # (opcional, para verificación de certificado de cliente)

# Opcional: especifique la lista de cifrados si es necesario
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL'

# Opcional: habilite la verificación de certificado de cliente
# ssl_ca_file debe configurarse con un archivo que contenga los certificados CA en los que confiar
#ssl_crl_file = ''
#ssl_crl_dir = ''
  • ssl = on: Habilita el soporte SSL en el servidor.
  • ssl_cert_file: Ruta al certificado público del servidor.
  • ssl_key_file: Ruta a la clave privada del servidor.
  • ssl_ca_file: Ruta al certificado de la CA (si desea verificar los certificados de cliente o si el certificado de su servidor está firmado por una CA personalizada).

3. Configuración de pg_hba.conf para forzar SSL

El archivo pg_hba.conf controla la autenticación del cliente. Debe modificar las entradas para forzar las conexiones SSL.

Por defecto, las entradas en pg_hba.conf se ven así:

# TIPO  BASE_DATOS      USUARIO         DIRECCION                 METODO
local   all             all                                     peer
# Conexiones locales IPv4:
host    all             all             127.0.0.1/32            scram-sha-256
# Conexiones locales IPv6:
host    all             all             ::1/128                 scram-sha-256

Para forzar SSL, cambie las entradas host a hostssl:

# TIPO  BASE_DATOS      USUARIO         DIRECCION                 METODO
local   all             all                                     peer
# Conexiones locales IPv4:
hostssl all             all             127.0.0.1/32            scram-sha-256
# Conexiones locales IPv6:
hostssl all             all             ::1/128                 scram-sha-256

# Ejemplo para acceso a red externa - requiere SSL
hostssl all             all             0.0.0.0/0               scram-sha-256
hostssl all             all             ::/0                    scram-sha-256
  • hostssl: Este tipo de registro requiere conexiones SSL. Cualquier intento de conexión sin SSL será rechazado.
  • hostnossl: Este tipo de registro prohíbe explícitamente las conexiones SSL.
  • host: Permite conexiones SSL y no SSL (este es el predeterminado y menos seguro).

4. Reinicio del servidor PostgreSQL

Después de modificar postgresql.conf y pg_hba.conf, debe reiniciar el servicio PostgreSQL para que los cambios surtan efecto.

# Para sistemas que usan systemd (la mayoría de las distribuciones Linux modernas)
sudo systemctl restart postgresql

# Para sistemas que usan init.d
sudo service postgresql restart

Configuración SSL/TLS del lado del cliente

Los clientes también deben configurarse para conectarse de forma segura. Esto implica especificar parámetros de conexión, potencialmente proporcionar certificados de cliente y verificar el certificado del servidor.

1. Parámetros de la cadena de conexión

Al conectarse a través de psql o cualquier biblioteca de cliente PostgreSQL, puede especificar parámetros SSL en la cadena de conexión o como opciones individuales.

Conexión SSL básica (solo autenticación del servidor):

psql "sslmode=require host=su_nombre_host_servidor dbname=su_bd user=su_usuario"
  • sslmode: Controla el comportamiento SSL del cliente.
    • disable: Solo permite conexiones no SSL.
    • allow: Permite no SSL, pero prefiere SSL si el servidor lo admite.
    • prefer (predeterminado): Prefiere SSL, pero permite no SSL si SSL falla.
    • require: Solo permite conexiones SSL. Si el servidor no admite SSL, la conexión falla.
    • verify-ca: Solo permite conexiones SSL y verifica que el certificado del servidor esté firmado por una CA confiable. El parámetro sslrootcert debe estar configurado.
    • verify-full: Solo permite conexiones SSL, verifica el certificado del servidor contra una CA confiable y verifica que el nombre de host del servidor coincida con el nombre común (CN) o el nombre alternativo del sujeto (SAN) del certificado.

Verificación del certificado del servidor (verify-ca o verify-full):

Para una seguridad mejorada, los clientes deben verificar la identidad del servidor. Esto requiere que el cliente confíe en la CA que firmó el certificado del servidor.

  1. Obtener el certificado de la CA: Obtenga el archivo root.crt (o el certificado de CA apropiado) que se utilizó para firmar el certificado del servidor.
  2. Especificar sslrootcert: Indique al cliente dónde encontrar este certificado de CA.
psql "sslmode=verify-full host=su_nombre_host_servidor dbname=su_bd user=su_usuario sslrootcert=/ruta/a/su/root.crt"

2. Certificados de cliente (Autenticación mutua)

Para un nivel de seguridad aún mayor, puede implementar la autenticación mutua, donde el servidor también verifica la identidad del cliente mediante certificados de cliente.

Generación de certificados de cliente:

De manera similar a los certificados de servidor, necesitará una clave privada de cliente y un certificado de cliente firmado por una CA en la que confíe el servidor (a menudo la misma CA que el certificado del servidor).

  1. Generar clave privada del cliente:
    bash openssl genrsa -des3 -out client.key 2048

  2. Crear CSR de cliente:
    bash openssl req -new -key client.key -out client.csr
    Proporcione detalles, asegurándose de que el Nombre Común sea único para el cliente.

  3. Firmar CSR de cliente con CA:
    bash sudo openssl x509 -req -days 365 -in client.csr -CA root.crt -CAkey root.key -set_serial <serial_unico> -out client.crt

  4. Establecer permisos:
    bash chmod 600 client.key chmod 644 client.crt

Configuración de pg_hba.conf para la autenticación de certificado de cliente:

En el servidor, debe configurar pg_hba.conf para aceptar la autenticación de certificado de cliente. Esto a menudo utiliza el método de autenticación cert.

# TIPO  BASE_DATOS      USUARIO         DIRECCION                 METODO
# Requerir SSL y autenticación de certificado de cliente para usuario/bd específico
hostssl all             su_usuario       su_ip_cliente/32       cert map=su_mapa_cert

Es posible que también deba definir un archivo de mapa de certificados (opción cert_map) si desea mapear detalles específicos del certificado de cliente (como Subject o SubjectAltName) a usuarios de PostgreSQL. Consulte la documentación de PostgreSQL para obtener detalles sobre la autenticación cert y la configuración del mapa de certificados.

Configuración del cliente para usar certificados:

Actualice la cadena de conexión del cliente para incluir las rutas a su certificado y clave:

psql "sslmode=verify-full host=su_nombre_host_servidor dbname=su_bd user=su_usuario \nsslrootcert=/ruta/a/su/root.crt sslcert=/ruta/a/su/client.crt sslkey=/ruta/a/su/client.key"

Mejores prácticas y consejos

  • Use sslmode=verify-full: Siempre intente usar verify-full en el lado del cliente para prevenir ataques de intermediario.
  • Proteja las claves privadas: Asegúrese de que las claves privadas (archivos .key) tengan permisos de archivo estrictos (ej. chmod 600) y que solo sean legibles por el usuario PostgreSQL en el servidor y el usuario que se conecta en el cliente.
  • Renueve los certificados regularmente: Los certificados tienen fechas de vencimiento. Implemente un proceso para renovarlos antes de que expiren para evitar interrupciones en la conexión.
  • Administración centralizada de certificados: Para implementaciones más grandes, considere usar un sistema de administración de certificados o automatizar la emisión y renovación de certificados.
  • Monitoree los registros: Verifique los registros de PostgreSQL en busca de errores relacionados con SSL durante el inicio o los intentos de conexión.
  • Documentación: Consulte la documentación oficial de PostgreSQL para conocer los parámetros más actualizados y las opciones de configuración avanzada específicas de su versión de PostgreSQL.

Conclusión

Configurar SSL/TLS para las conexiones de PostgreSQL es un paso crítico para asegurar su infraestructura de base de datos. Al habilitar SSL en el servidor, forzar ssl=require o hostssl en pg_hba.conf, y configurar los clientes con los ajustes apropiados de sslmode (idealmente verify-full), mejora significativamente la seguridad de los datos transmitidos a través de su red. La implementación de la autenticación mutua con certificados de cliente añade otra capa robusta de seguridad. Si bien la configuración inicial puede parecer compleja, los beneficios a largo plazo de la protección de datos y el cumplimiento normativo la convierten en una práctica indispensable para cualquier implementación de PostgreSQL.