Seguridad de la capa de transporte (TLS) en Azure HorizonDB (versión preliminar)

Azure HorizonDB requiere que todas las conexiones de cliente usen la seguridad de la capa de transporte (TLS), un protocolo estándar del sector que cifra las comunicaciones entre el clúster de base 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 clúster emitido por una entidad de certificación (CA) en una cadena de CA iniciadas por una entidad de certificación raíz de confianza.
  • Negociación de un conjunto de cifrado seguro entre el clúster y el cliente.

Certificados raíz de confianza y rotación de certificados

Entidades de certificación raíz usadas por Azure HorizonDB

Las entidades de certificación raíz (CA) son las autoridades de nivel superior de la cadena de certificados. Azure HorizonDB usa actualmente certificados firmados duales emitidos por una entidad de certificación intermedia (ICA) anclada por las siguientes CA raíz:

Actualmente, las regiones de China usan las siguientes CA:

Entidades de certificación intermedias

Azure HorizonDB usa entidades de certificación intermedias (ICA) para emitir certificados de clúster. Para mantener la seguridad, Microsoft rota periódicamente estas ENTIDADES de certificación y los certificados de clúster que emiten. Estas rotaciones son rutinarias y no se anuncian de antemano.

La rotación actual de las ICA 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 entidad de certificación antigua

No utilices autoridades de certificación intermedias ni certificados de clúster en tu almacén raíz de confianza.

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

Nueva cadena de CA

No utilices autoridades de certificación intermedias ni certificados de clúster en tu almacén 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 clúster

Réplicas de lectura

La migración de la entidad 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 usen un certificado de entidad de certificación raíz más reciente que el 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 entidades de certificación intermedias (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 clúster 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 clúster 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, los cambios y rotaciones de certificados de clúster en entidades de certificación intermedias son rutinarios y no se anuncian.

Caution

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

Mejor configuración

  • Aplique la versión más reciente y más segura de TLS estableciendo el parámetro ssl_min_protocol_version en 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 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 que usa actualmente Azure HorizonDB:

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 notifica los cambios en la CA intermedia ni las rotaciones de certificados de clúster concretos. 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 la fijación de certificados, como, por ejemplo, el uso de certificados de clúster individuales en tu almacén de confianza.

Caution

Las aplicaciones no se pueden conectar al clúster de base de datos sin previo aviso cuando Microsoft cambia las CA intermedias de la cadena de certificados o gira el certificado de clúster.

Problemas de anclaje de certificados

Note

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 HorizonDB. Comprender estas consideraciones le ayuda a tomar decisiones fundamentadas sobre la implementación de TLS en su entorno.

Importante

Azure HorizonDB 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 podría 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 HorizonDB 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 debería, si es necesario, puede deshabilitar TLS para las conexiones a su Azure HorizonDB. Puede actualizar el require_secure_transport parámetro 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 estableciendo el parámetro ssl_min_protocol_version en TLSv1.3. No establezca el ssl_max_protocol_version parámetro .

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 clústeres tls admiten varios conjuntos de cifrado y, a veces, varias versiones de TLS. Durante el establecimiento de la conexión, el cliente y el clúster negocian la versión de TLS y el conjunto de cifrado que se utilizarán mediante un intercambio inicial. 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 HorizonDB

En este momento, Azure HorizonDB no implementa las siguientes características de TLS:

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

Contenido relacionado

  • Last updated on