Compartir a través de

Seguridad de la capa de transporte (TLS) en Azure Database for PostgreSQL

Azure Database for PostgreSQL requiere todas las conexiones de cliente para usar la seguridad de la capa de transporte (TLS), un protocolo estándar del sector que cifra las comunicaciones entre el servidor de bases de datos y las aplicaciones cliente. TLS reemplaza el protocolo SSL anterior, con solo las versiones 1.2 y 1.3 de TLS reconocidas como seguras. La integridad de la seguridad tls se basa en tres pilares:

  • Usar solo las versiones 1.2 o 1.3 de TLS.
  • El cliente valida el certificado TLS del servidor emitido por una entidad de certificación (CA) en una cadena de CA iniciadas por una CA raíz de confianza.
  • Negociación de un conjunto de cifrado seguro entre el servidor y el cliente.

Certificados raíz de confianza y rotaciones de certificados

Importante

Microsoft inició una rotación de certificados TLS para Azure Database for PostgreSQL para actualizar los certificados de entidad de certificación intermedios y la cadena de certificados resultante. Las CA raíz permanecen iguales.

Si la configuración de cliente usa las configuraciones recomendadas para TLS, no es necesario realizar ninguna acción.

Programación intermedia de rotación de certificados:

  • Se han completado las actualizaciones de las regiones de Azure Centro-oeste de EE. UU. y Este de Asia.
  • Las actualizaciones de las regiones del Sur de Reino Unido y del Gobierno de EE. UU. comienzan el 21 de enero de 2026.
  • Las actualizaciones en el Centro de Estados Unidos comienzan el 26 de enero de 2026.
  • Las actualizaciones de todas las demás regiones comienzan el 28 de enero de 2026.
  • Después del Festival de Primavera (año nuevo chino) 2026, las regiones de China también se someten a una rotación de certificados que incluye un cambio a una de las CA raíz.

Certificados raíz (Root CAs) utilizados por Azure Database para PostgreSQL

Las CA raíz son las entidades de nivel superior de la cadena de certificados. Azure Database for PostgreSQL usa actualmente certificados firmados duales emitidos por una CA intermedia (ICA) anclada por las siguientes CA raíz:

Actualmente, las regiones de China usan las siguientes CA:

Entidades de certificación intermedias

Azure Database for PostgreSQL usa entidades de certificación (ICA) intermedias para emitir certificados de servidor. Para mantener la seguridad, Microsoft rota periódicamente estos ICA y los certificados de servidor que emiten. Estas rotaciones son rutinarias y no se anuncian de antemano.

La rotación actual de las CA intermedias para DigiCert Global Root CA (consulte Rotación de certificados) comenzó en noviembre de 2025 y está programada para completarse en el primer trimestre de 2026. Si ha seguido los procedimientos recomendados, este cambio no requiere ningún cambio en el entorno.

Cadena de CA antigua

No utilice certificados de CA intermedias ni certificados de servidor en su almacén de certificados raíz de confianza.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Certificado de servidor

Nueva cadena de CA

No utilice certificados de CA intermedias ni certificados de servidor en su almacén de certificados raíz de confianza.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Certificado de servidor

Réplicas de lectura

La migración de la Autoridad de Certificación Raíz de DigiCert Global Root CA a DigiCert Global Root G2 no se ha completado en todas las regiones. Por lo tanto, es posible que las réplicas de lectura recién creadas utilicen un certificado raíz más reciente que el del servidor principal. Debe agregar el DigiCert Global Root CA al almacén de confianza de las réplicas de lectura.

Cadenas de certificados

Una cadena de certificados es una secuencia jerárquica de certificados emitidos por entidades de certificación (CA) de confianza. La cadena comienza en la ENTIDAD de certificación raíz, que emite certificados de CA intermedios (ICA). Las ICC (Autoridades de Certificación Intermedias) pueden emitir certificados para las ICC inferiores. El ICA más bajo de la cadena emite certificados de servidor individuales. Se establece la cadena de confianza verificando cada certificado de la cadena hasta el certificado raíz de la CA.

Reducción de errores de conexión

El uso de configuraciones tls recomendadas ayuda a reducir el riesgo de errores de conexión debido a rotaciones de certificados o cambios en entidades de certificación intermedias. En concreto, evite confiar en entidades de certificación intermedias o certificados de servidor individuales. Estas prácticas pueden provocar problemas de conexión inesperados cuando Microsoft actualiza la cadena de certificados.

Importante

Microsoft anuncia los cambios en las CA raíz con antelación para ayudarle a preparar las aplicaciones cliente. Sin embargo, las rotaciones de certificados de servidor y los cambios en las CA intermedias son rutinarios y no se anuncian.

Precaución

El uso de configuraciones no admitidas (cliente) provoca errores de conexión inesperados.

Mejor configuración

  • Aplique la versión de TLS más reciente y segura estableciendo el parámetro de servidor de ssl_min_protocol_version a TLSv1.3.
  • Use sslmode=verify-all para las conexiones de PostgreSQL para garantizar la comprobación completa del certificado y el nombre de host. Según la configuración de DNS con puntos de conexión privados o integración de red virtual, verify-all es posible que no sea posible. Por lo tanto, puede usar verify-ca en su lugar.
  • Mantenga siempre el conjunto completo de certificados raíz de Azure en el almacén raíz de confianza.

Buena configuración

  • Establezca el parámetro del servidor ssl_min_protocol_version en TLSv1.3. Si debe admitir TLS 1.2, no establezca la versión mínima.
  • Use sslmode=verify-all o sslmode=verify-ca para las conexiones de PostgreSQL para garantizar la comprobación completa o parcial del certificado.
  • Asegúrese de que el almacén raíz de confianza contiene el certificado de entidad de certificación raíz usado actualmente por Azure Database for PostgreSQL:

No use las siguientes configuraciones:

  • Deshabilite TLS estableciendo require_secure_transport a OFF y configurando el lado del cliente en sslmode=disable.
  • Utiliza configuraciones del lado del cliente como sslmode, disable, allow, o prefer que pueden hacer que tu aplicación sea vulnerable a ataques man-in-the-middle.

Configuraciones no admitidas; no usar

Azure PostgreSQL no anuncia cambios sobre cambios intermedios de entidad de certificación o rotaciones de certificados de servidor individuales. Por lo tanto, las siguientes configuraciones no son compatibles al usar las opciones de sslmodeverify-ca o verify-all:

  • Uso de certificados de CA intermedias en su almacén de certificados de confianza.
  • Uso de pinning de certificados, por ejemplo, utilizando certificados individuales del servidor en su almacén de certificados de confianza.

Precaución

Las aplicaciones no se pueden conectar a los servidores de bases de datos sin previo aviso cuando Microsoft cambia las CA intermedias de la cadena de certificados o gira el certificado de servidor.

Problemas de anclaje de certificados

Nota:

Las rotaciones de certificados no le afectan si no utiliza las configuraciones sslmode=verify-full o sslmode=verify-ca en la cadena de conexión de su aplicación cliente. Por lo tanto, no es necesario seguir los pasos descritos en esta sección.

Nunca utilice pinning de certificados en sus aplicaciones, ya que interfiere con la rotación de certificados, como el cambio actual de certificados de CA intermedias. Si no conoce qué es el anclaje de certificados, probablemente no lo esté utilizando. Para comprobar el pinning de certificados:

Si experimenta problemas debido al certificado intermedio incluso después de seguir estos pasos, póngase en contacto con el soporte técnico de Microsoft. Incluya ICA Rotation 2026 en el título.

Otras consideraciones para TLS

Además de la configuración principal de TLS y la administración de certificados, otros factores influyen en la seguridad y el comportamiento de las conexiones cifradas a Azure Database for PostgreSQL. Comprender estas consideraciones le ayuda a tomar decisiones fundamentadas sobre la implementación de TLS en su entorno.

Importante

Azure Database for PostgreSQL no admite la autenticación de certificados de cliente TLS (TLS mutuo). No incluya parámetros de certificado de cliente (sslcert, sslkey) en las cadenas de conexión, ya que no se admiten y puede causar problemas de conexión.

Versiones de TLS seguras e inseguras

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.

Azure Database for PostgreSQL admite las versiones 1.2 y 1.3 de TLS. En RFC 8996, el Grupo de tareas de ingeniería de Internet (IETF) indica explícitamente que no se debe usar TLS 1.0 y TLS 1.1. Ambos protocolos quedaron en desuso a finales de 2019. Todas las conexiones entrantes que usan versiones anteriores no seguras del protocolo TLS, como TLS 1.0 y TLS 1.1, se deniegan de forma predeterminada.

IETF lanzó la especificación TLS 1.3 en RFC 8446 en agosto de 2018 y TLS 1.3 es la versión recomendada, ya que es más rápida y segura que TLS 1.2.

Aunque no se recomienda, si es necesario, puede deshabilitar TLS para las conexiones a Azure Database for PostgreSQL. Puede actualizar el parámetro de servidor de require_secure_transport a OFF.

Importante

Use la versión más reciente de TLS 1.3 para cifrar las conexiones de base de datos. Puede especificar la versión mínima de TLS configurando el parámetro del servidor ssl_min_protocol_version a TLSv1.3. No establezca el ssl_max_protocol_version parámetro de servidor.

Conjuntos de cifrado

Un conjunto de cifrado es un conjunto de algoritmos que incluyen un cifrado, un algoritmo de intercambio de claves y un algoritmo hash. Úselos junto con el certificado TLS y la versión de TLS para establecer una conexión TLS segura. La mayoría de los clientes y servidores TLS admiten varios conjuntos de cifrado y, a veces, varias versiones de TLS. Durante el establecimiento de la conexión, el cliente y el servidor negocian la versión de TLS y el conjunto de cifrado que se utilizará mediante un intercambio de claves. Durante este apretón de manos, se producen los siguientes pasos:

  • El cliente envía una lista de conjuntos de cifrado aceptables.
  • El servidor selecciona el mejor conjunto de cifrado de la lista e informa al cliente de la elección.

Características de TLS no disponibles en Azure Database for PostgreSQL

En este momento, Azure Database for PostgreSQL no implementa las siguientes características TLS:

  • Autenticación de cliente basada en certificados TLS mediante TLS con autenticación mutua (mTLS).
  • Certificados de servidor personalizados (traiga sus propios certificados TLS).

Contenido relacionado

  • Last updated on