Compartir a través de

Conectividad segura mediante TLS y SSL en Azure Database for PostgreSQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

El servidor flexible de Azure Database for PostgreSQL exige la conexión de las aplicaciones cliente al servidor flexible de Azure Database for PostgreSQL mediante Seguridad de la capa de transporte (TLS). TLS es un protocolo estándar del sector que garantiza conexiones de red cifradas entre el servidor de bases de datos y las aplicaciones cliente. TLS es un protocolo actualizado de Capa de sockets seguros (SSL).

¿Qué es TLS?

TLS se desarrolló a partir del protocolo SSL de Netscape y lo ha reemplazado con regularidad. Los términos SSL o TLS/SSL todavía se usan indistintamente. TLS se compone de dos capas: el protocolo de registro y el protocolo de enlace. El protocolo de registro proporciona seguridad de asociación. El protocolo de enlace permite al servidor y al cliente afirmarse entre sí y coordinar las evaluaciones de cifrado y las claves criptográficas antes de que se intercambie cualquier información.

Diagrama que muestra la secuencia típica de protocolo de enlace TLS 1.2.

En el diagrama anterior se muestra una secuencia típica de protocolo de enlace TLS 1.2, que consta de estos pasos:

  1. El cliente comienza enviando un mensaje denominado ClientHello que expresa la voluntad de comunicarse a través de TLS 1.2 con un conjunto de cifrado que el cliente admite.
  2. El servidor recibe el mensaje, las respuestas con ServerHello y acepta comunicarse con el cliente a través de TLS 1.2 mediante un conjunto de cifrado determinado.
  3. El servidor también envía su recurso compartido de claves. Los detalles de este recurso compartido de claves cambian en función del conjunto de cifrado seleccionado. Para que el cliente y el servidor acepten una clave criptográfica, deben recibir la parte o recurso compartido del otro.
  4. El servidor envía el certificado (firmado por la entidad de certificación [CA]) y una firma en partes de ClientHello y ServerHello. También incluye el recurso compartido de claves. De este modo, el cliente sabe que son auténticas.
  5. Después de que el cliente reciba correctamente los datos y, luego, genere su propio recurso compartido de claves, lo mezcla con el recurso compartido de claves del servidor para generar claves de cifrado para la sesión.
  6. El cliente envía al servidor su recurso compartido de claves, habilita el cifrado y envía un mensaje de Finished. Este mensaje es un hash de una transcripción de lo que ha ocurrido hasta ahora. El servidor hace lo mismo. Combina los recursos compartidos de claves para obtener la clave y envía su propio mensaje de Finished.
  7. Ahora, los datos de la aplicación se pueden enviar cifrados en la conexión.

Cadenas de certificados

Una cadena de certificados es una lista ordenada de certificados que contienen un certificado TLS/SSL y certificados de entidad de certificación. Permiten al receptor comprobar que el remitente y todas las entidades de certificación son de confianza. La cadena o ruta de acceso comienza con el certificado de TLS/SSL. Cada certificado de la cadena está firmado por la entidad identificada por el siguiente certificado de la cadena.

La cadena finaliza con un certificado de entidad de certificación raíz. Este certificado siempre está firmado por la propia entidad de certificación. Las firmas de todos los certificados de la cadena deben comprobarse hasta el certificado de entidad de certificación raíz.

Cualquier certificado que se encuentra entre el certificado TLS/SSL y el certificado de entidad de certificación raíz de la cadena se denomina certificado intermedio.

Versiones de TLS

Varias entidades gubernamentales en todo el mundo mantienen directrices para TLS con respecto a la seguridad de red. En los Estados Unidos, estas organizaciones incluyen el Departamento de salud y servicios humanos y el National Institute of Standards and Technology. El nivel de seguridad que proporciona TLS se ve más afectado por la versión del protocolo TLS y los conjuntos de cifrado admitidos.

Un conjunto de cifrado es un grupo de algoritmos que incluyen un cifrado, un algoritmo de intercambio de claves y un algoritmo hash. Se usan juntos para establecer una conexión TLS segura. La mayoría de los clientes y servidores TLS admiten varias alternativas. Tienen que negociar cuando establecen una conexión segura para seleccionar una versión común de TLS y un conjunto de cifrado.

Azure Database for PostgreSQL admite TLS versión 1.2 y versiones posteriores. En RFC 8996, el Grupo de tareas de ingeniería de Internet (IETF) indica explícitamente que no se deben usar TLS 1.0 ni TLS 1.1. Ambos protocolos quedaron en desuso a finales de 2019.

Se denegarán de manera predeterminada todas las conexiones entrantes que usen versiones anteriores del protocolo TLS, como TLS 1.0 y TLS 1.1.

El IETF publicó la especificación TLS 1.3 en el RFC 8446 de agosto de 2018, y TLS 1.3 ahora es la versión de TLS más común y recomendada en uso. TLS 1.3 es más rápido y seguro que TLS 1.2.

Nota:

Los certificados SSL y TLS certifican que la conexión está protegida con protocolos de cifrado de última generación. Al cifrar la conexión en la red, se evita el acceso no autorizado a los datos mientras están en tránsito. Se recomienda encarecidamente usar las versiones más recientes de TLS para cifrar las conexiones a Azure Database for PostgreSQL (servidor flexible).

Aunque no se recomienda, si fuera necesario, puede deshabilitar TLS\SSL para las conexiones a Azure Database for PostgreSQL (servidor flexible). Puede actualizar el parámetro de servidor de require_secure_transport a OFF. También puede establecer la versión del TLS estableciendo los parámetros de servidor ssl_min_protocol_version y ssl_max_protocol_version.

La autenticación de certificados se realiza mediante certificados de cliente SSL para la autenticación. En este escenario, el servidor PostgreSQL compara el atributo de nombre común (CN) del certificado de cliente presentado con el usuario de base de datos solicitado.

En este momento, Azure Database for PostgreSQL (servidor flexible) no admite lo siguiente:

Nota:

Microsoft realizó cambios de entidad de certificación raíz para varios servicios de Azure, incluido Azure Database for PostgreSQL (servidor flexible). Para obtener más información, consulte Cambios en los certificados TLS de Azure y la sección Configuración de SSL en el cliente.

Para determinar el estado actual de la conexión TLS/SSL, puede cargar la extensión sslinfo y, después, llamar a la función ssl_is_used() para determinar si se usa SSL. La función devuelve t si la conexión usa SSL. De lo contrario, devuelve f. También puede recopilar toda la información sobre el uso de SSL por parte del servidor flexible de Azure Database for PostgreSQL por proceso, cliente y aplicación mediante la consulta siguiente:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Para realizar pruebas, también puede usar el comando openssl directamente:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Este comando muestra información de protocolo de bajo nivel, como la versión de TLS y el cifrado. Debe usar la opción -starttls postgres. De lo contrario, este comando informa de que no hay ningún SSL en uso. El uso de este comando requiere al menos OpenSSL 1.1.1.

Para aplicar la versión más reciente y segura de TLS para la protección de conectividad desde el cliente a Azure Database for PostgreSQL (servidor flexible), establezca ssl_min_protocol_version en 1.3. Esa configuración requiere clientes que se conecten al servidor flexible de Azure Database for PostgreSQL para usar solo esta versión del protocolo para comunicarse de forma segura. Es posible que los clientes más antiguos no puedan comunicarse con el servidor porque no admiten esta versión.

Configuración de SSL en el cliente

De forma predeterminada, PostgreSQL no realiza ninguna comprobación del certificado de servidor. Por este motivo, es posible suplantar la identidad (spoofing) del servidor (por ejemplo, modificando un registro DNS o tomando el control de la dirección IP del servidor) sin que el cliente lo sepa. Todas las opciones SSL tienen sobrecarga en forma de cifrado e intercambio de claves, por lo que se produce una compensación entre el rendimiento y la seguridad.

Para evitar cualquier la suplantación de identidad, se debe usar la comprobación de certificados SSL en el cliente.

Hay muchos parámetros de conexión para configurar el cliente para SSL. Estos son algunos de los importantes:

  • ssl: conexión mediante SSL. Esta propiedad no necesita un valor asociado. Su mera presencia especifica una conexión SSL. Para la compatibilidad con versiones futuras, se prefiere el valor true. En este modo, cuando establece una conexión SSL, el controlador cliente valida la identidad del servidor para prevenir ataques de intermediario. Comprueba que el certificado de servidor esté firmado por una entidad de confianza y que el host al que se conecta es el mismo que el nombre de host del certificado.

  • sslmode: si necesita cifrado y quiere que se produzca un error en la conexión si no se puede cifrar, establezca sslmode=require. Este ajuste garantiza que el servidor esté configurado para aceptar conexiones SSL para esta dirección IP o host y que el servidor reconozca el certificado de cliente. Si el servidor no acepta conexiones SSL o el certificado de cliente no se reconoce, se produce un error en la conexión. En la tabla siguiente, se detallan los valores de esta configuración:

    SSL Mode Explicación
    disable No se usa cifrado.
    allow El cifrado se usa si la configuración del servidor la requiere o la aplica.
    prefer Se usa cifrado si la configuración del servidor lo permite.
    require Se usa cifrado. Esto garantiza que el servidor esté configurado para aceptar conexiones SSL para esta dirección IP de host y que el servidor reconozca el certificado de cliente.
    verify-ca Se usa cifrado. Compruebe la firma del certificado de servidor en comparación con el certificado almacenado en el cliente.
    verify-full Se usa cifrado. Compruebe la firma del certificado de servidor y el nombre de host en comparación con el certificado almacenado en el cliente.

    El modo predeterminado sslmode usado es diferente entre los clientes basados en libpq (como psql) y JDBC. Los clientes basados en libpq tienen prefer como valor predeterminado. Los clientes JDBC tienen verify-full como valor predeterminado.

  • sslcert, sslkey y sslrootcert: estos parámetros pueden invalidar la ubicación predeterminada del certificado de cliente, la clave de cliente de PKCS-8 y el certificado raíz. El valor predeterminado es /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8y /defaultdir/root.crt, respectivamente, donde defaultdir es ${user.home}/.postgresql/ en sistemas Nix y %appdata%/postgresql/ en Windows.

Las entidades de certificación (CA) son las instituciones responsables de emitir certificados. Una entidad de certificación de confianza es una entidad autorizada para verificar que alguien es quien dice ser. Para que este modelo funcione, todos los participantes deben aceptar un conjunto de CA de confianza. Todos los sistemas operativos y la mayoría de los exploradores web se envían con un conjunto de CA de confianza.

El uso de verify-ca y los valores de configuración verify-full sslmode también se puede conocer como asignación de certificados. En este caso, los certificados de entidad de certificación raíz en el servidor de PostgreSQL tienen que coincidir con la firma del certificado e, incluso, el nombre de host con el certificado en el cliente.

Es posible que tenga que actualizar periódicamente los certificados almacenados por el cliente cuando las CA cambien o expiren en los certificados de servidor de PostgreSQL. Para determinar si va a asignar CA, consulte Asignación de certificados y servicios de Azure.

Para más información sobre la configuración de SSL\TLS en el cliente, consulte la documentación de PostgreSQL.

Para los clientes que usan los valores de configuración verify-ca y verify-full sslmode (es decir, asignación de certificados), deben implementar tres certificados de entidad de certificación raíz en los almacenes de certificados de cliente:

Descarga de certificados de CA raíz y actualización de clientes de aplicaciones en escenarios de asignación de certificados

Para actualizar las aplicaciones cliente en escenarios de asignación de certificados, puede descargar los certificados:

Para importar certificados a almacenes de certificados de cliente, es posible que tenga que convertir archivos de certificado .crt al formato .pem después de descargar los archivos de certificado de los URI anteriores. Puede usar la utilidad de OpenSSL para realizar estas conversiones de archivos:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

La información sobre la actualización de almacenes de certificados de aplicaciones cliente con nuevos certificados de entidad de certificación raíz se documenta en Actualización de certificados TLS de cliente para clientes de aplicaciones.

Importante

Algunas de las bibliotecas cliente de Postgres, al usar la configuración sslmode=verify-full, pueden experimentar errores de conexión con certificados de entidad de certificación raíz que estén firmados entre sí con certificados intermedios. El resultado son rutas de acceso de confianza alternativas. En este caso, se recomienda especificar explícitamente el parámetro sslrootcert. O bien, establezca la variable de entorno PGSSLROOTCERT en una ruta de acceso local en la que se coloque el CA raíz Microsoft RSA Root CA 2017, desde el valor predeterminado de %APPDATA%\postgresql\root.crt.

Réplicas de lectura con escenarios de asignación de certificados

Con la migración de CA raíz a Microsoft RSA Root CA 2017, es factible que las réplicas recién creadas estén en un certificado de CA raíz más reciente que el del servidor principal que se creó anteriormente. Para los clientes que usan los valores de configuración verify-ca y verify-full sslmode (es decir, asignación de certificados), es imperativo que la conectividad interrumpida acepte tres certificados de CA raíz:

En este momento, el servidor flexible de Azure Database for PostgreSQL no admite la autenticación basada en certificados.

Prueba de certificados de cliente mediante la conexión con psql en escenarios de asignación de certificados

Puede usar la línea de comandos psql desde el cliente para probar la conectividad con el servidor en escenarios de asignación de certificados:


$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Para obtener más información sobre los parámetros de certificado y SSL, consulte la documentación de psql.

Prueba de la conectividad TLS/SSL

Antes de intentar acceder al servidor habilitado para SSL desde una aplicación cliente, asegúrese de que puede acceder a él a través de psql. Si estableció una conexión SSL, debería ver una salida similar al ejemplo siguiente:

psql (14.5)SSL connection (protocolo: TLSv1.2, cifrado: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compresión: desactivada)Escriba "ayuda" para obtener ayuda.

También puede cargar la extensión sslinfo y, luego, llamar a la función ssl_is_used() para determinar si se usa SSL. La función devuelve t si la conexión usa SSL. De lo contrario, devuelve f.

Conjuntos de cifrado

Un conjunto de aplicaciones de cifrado es un conjunto de algoritmos criptográficos. Los protocolos TLS/SSL usan algoritmos de un conjunto de cifrado para crear claves y cifrar la información.

Un conjunto de cifrado se muestra como una cadena larga de información aparentemente aleatoria, pero cada segmento de esa cadena contiene información esencial. Por lo general, esta cadena de datos incluye varios componentes clave:

  • Protocolo (es decir, TLS 1.2 o TLS 1.3)
  • Algoritmo de intercambio de claves o contrato
  • Algoritmo de firma digital (autenticación)
  • Algoritmo de cifrado masivo
  • Algoritmo de código de autenticación de mensajes (MAC)

Diferentes versiones de TLS/SSL admiten diferentes conjuntos de cifrado. Los conjuntos de cifrado TLS 1.2 no se pueden negociar con conexiones TLS 1.3 y viceversa.

En este momento, el servidor flexible de Azure Database for PostgreSQL admite muchos conjuntos de cifrado con la versión del protocolo TLS 1.2 que se encuentra en la categoría HIGH:!aNULL.

Solución de errores de conectividad de TLS/SSL

  1. El primer paso para solucionar problemas de compatibilidad con la versión del protocolo de TLS/SSL es identificar los mensajes de error que usted o los usuarios ven al intentar acceder al servidor flexible de Azure Database for PostgreSQL con el cifrado TLS del cliente. Dependiendo de la aplicación y la plataforma, los mensajes de error pueden ser diferentes. En muchos casos, apuntan al problema subyacente.

  2. Para asegurarse de la compatibilidad de versiones del protocolo TLS/SSL, compruebe la configuración TLS/SSL del servidor de bases de datos y el cliente de la aplicación para comprobar que admiten versiones compatibles y conjuntos de cifrado.

  3. Analice las discrepancias o brechas entre el servidor de bases de datos y las versiones TLS/SSL del cliente y los conjuntos de cifrado. Intente resolverlos habilitando o deshabilitando determinadas opciones, actualizando o degradando software, o cambiando certificados o claves. Por ejemplo, es posible que tenga que habilitar o deshabilitar versiones específicas de TLS/SSL en el servidor o el cliente, en función de los requisitos de seguridad y compatibilidad. Por ejemplo, es posible que tenga que deshabilitar TLS 1.0 y TLS 1.1, que se consideran no seguros y en desuso, y habilitar TLS 1.2 y TLS 1.3, que son más seguros y modernos.

  4. El certificado más reciente emitido con Microsoft RSA Root CA 2017 tiene un nivel intermedio en la cadena firmado por Digicert Global Root G2 CA. Algunas de las bibliotecas cliente de Postgres, al usar sslmode=verify-full o sslmode=verify-ca configuración, pueden experimentar errores de conexión con certificados de entidad de certificación raíz firmados con certificados intermedios. El resultado son rutas de acceso de confianza alternativas.

    Para solucionar estos problemas, agregue los tres certificados necesarios al almacén de certificados de cliente o especifique explícitamente el parámetro sslrootcert. O bien, establezca la variable de entorno PGSSLROOTCERT en la ruta de acceso local en la que se coloque el CA raíz Microsoft RSA Root CA 2017, desde el valor predeterminado de %APPDATA%\postgresql\root.crt.

Contenido relacionado

  • Aprenda a crear una instancia del servidor flexible de Azure Database for PostgreSQL mediante la opción Acceso privado (integración con red virtual) en Azure Portal o la CLI de Azure.
  • Aprenda a crear un servidor flexible de Azure Database for PostgreSQL mediante la opción Acceso público (direcciones IP permitidas) en Azure Portal o la CLI de Azure.