Partager via

Tls (Transport Layer Security) dans Azure Database pour PostgreSQL

Azure Database pour PostgreSQL nécessite toutes les connexions clientes pour utiliser le protocole TLS (Transport Layer Security), un protocole standard qui chiffre les communications entre votre serveur de base de données et les applications clientes. TLS remplace l’ancien protocole SSL, avec uniquement les versions TLS 1.2 et 1.3 reconnues comme sécurisées. L’intégrité de la sécurité TLS repose sur trois piliers :

  • Utilisation uniquement de TLS versions 1.2 ou 1.3.
  • Le client valide le certificat TLS du serveur émis par une autorité de certification dans une chaîne d’autorités de certification démarrée par une autorité de certification racine approuvée.
  • Négociation d’une suite de chiffrement sécurisée entre le serveur et le client.

Certificats racine de confiance et rotation des certificats

Important

Microsoft a démarré une rotation des certificats TLS pour Azure Database pour PostgreSQL afin de mettre à jour les certificats d’autorité de certification intermédiaires et la chaîne de certificats résultante. Les autorités de certification racines restent identiques.

Si votre configuration client utilise les configurations recommandées pour TLS, vous n’avez pas besoin d’effectuer d’action.

Planification de la rotation des certificats

  • Les régions Azure USA Centre Ouest, Asie Est et Royaume-Uni Sud ont démarré leur rotation des certificats TLS le 11 novembre 2025.
  • À compter du 19 janvier 2026, cette rotation des certificats est prévue pour s’étendre aux régions restantes (à l’exception de la Chine), y compris Azure Government.
  • Après le Festival de printemps (Nouvel an chinois) 2026, les régions chinoises effectueront également une rotation de certificats qui inclut une modification de l’une des autorités de certification racine.

Autorités de certification racines utilisées par Azure Database pour PostgreSQL

Les autorités de certification racines sont les autorités de niveau supérieur dans la chaîne de certificats. Azure Database pour PostgreSQL utilise actuellement des certificats double signés émis par une autorité de certification intermédiaire (ICA) ancrée par les autorités de certification racine suivantes :

Les régions de Chine utilisent actuellement les autorités de certification suivantes :

Autorités de certification intermédiaires

Azure Database pour PostgreSQL utilise des autorités de certification intermédiaires (ICA) pour émettre des certificats de serveur. Pour maintenir la sécurité, Microsoft effectue régulièrement la rotation de ces icAs et des certificats serveur qu’ils émettent. Ces rotations sont courantes et ne sont pas annoncées à l’avance.

La rotation actuelle des autorités de certification intermédiaires pour DigiCert Global Root CA (voir rotation des certificats) a commencé en novembre 2023 et devrait être terminée au premier trimestre de 2024. Si vous avez suivi les pratiques recommandées, cette modification ne nécessite aucune modification dans votre environnement.

Ancienne chaîne d’autorité de certification

N’utilisez pas d’autorités de certification intermédiaires ou de certificats de serveur dans votre magasin racine approuvé.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Certificat serveur

Nouvelle chaîne d’autorité de certification

N’utilisez pas d’autorités de certification intermédiaires ou de certificats de serveur dans votre magasin racine approuvé.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Certificat serveur

Réplicas en lecture

La migration de l'autorité de certification Racine DigiCert Global de DigiCert Global Root CA vers DigiCert Global Root G2 n'est pas terminée dans toutes les régions. Par conséquent, il est possible que les réplicas en lecture nouvellement créés utilisent un certificat racine de l'autorité de certification plus récent que celui du serveur principal. Vous devez ajouter l’autorité de certification racine globale DigiCert au magasin approuvé de réplicas en lecture.

Chaînes de certificats

Une chaîne de certificats est une séquence hiérarchique de certificats émis par les autorités de certification approuvées. La chaîne commence à l'autorité de certification racine, qui émet des certificats d’autorité de certification intermédiaire (ACI). Les ICAs peuvent émettre des certificats pour les ICAs inférieures. L’ICA la plus basse dans la chaîne émet des certificats de serveur individuels. Vous établissez la chaîne de confiance en vérifiant chaque certificat de la chaîne jusqu’au certificat d’autorité de certification racine.

Réduction des échecs de connexion

L’utilisation de configurations TLS recommandées permet de réduire le risque d’échecs de connexion en raison de rotations de certificats ou de modifications apportées aux autorités de certification intermédiaires. Plus précisément, évitez de faire confiance aux autorités de certification intermédiaires ou aux certificats de serveur individuels. Ces pratiques peuvent entraîner des problèmes de connexion inattendus lorsque Microsoft met à jour la chaîne de certificats.

Important

Microsoft annonce à l'avance les changements concernant les autorités de certification racines pour vous aider à préparer vos applications clientes. Toutefois, les rotations de certificats de serveur et les modifications apportées aux autorités de certification intermédiaires sont courantes et ne sont pas annoncées.

Caution

L’utilisation de configurations non prises en charge (client) provoque des échecs de connexion inattendus.

Meilleure configuration

  • Appliquez la version TLS la plus récente et la plus sécurisée en définissant le paramètre du serveur ssl_min_protocol_version sur TLSv1.3.
  • Utilisez sslmode=verify-all les connexions PostgreSQL pour garantir la vérification complète du certificat et du nom d’hôte. Selon votre configuration DNS avec des points de terminaison privés ou une intégration de réseau virtuel, verify-all il se peut que cela ne soit pas possible. Par conséquent, vous pouvez utiliser verify-ca à la place.
  • Conservez toujours l’ensemble complet de certificats racines Azure dans votre magasin racine approuvé.

Bonne configuration

  • Définissez le paramètre de ssl_min_protocol_version serveur sur TLSv1.3. Si vous devez prendre en charge TLS 1.2, ne définissez pas la version minimale.
  • Utilisez sslmode=verify-all ou sslmode=verify-ca pour les connexions PostgreSQL pour garantir une vérification complète ou partielle des certificats.
  • Vérifiez que le magasin racine approuvé contient le certificat d’autorité de certification racine actuellement utilisé par Azure Database pour PostgreSQL :

N’utilisez pas les configurations suivantes :

  • Désactivez TLS en définissant require_secure_transportOFF et en définissant le côté client sur sslmode=disable.
  • Utilisez les paramètres sslmode côté client disable, allow ou preferrequire qui peuvent rendre votre application vulnérable aux attaques man-in-the-middle.

Configurations non prises en charge ; ne pas utiliser

Azure PostgreSQL n’annonce pas les modifications relatives aux modifications de l’autorité de certification intermédiaire ou aux rotations de certificats de serveur individuelles. Par conséquent, les configurations suivantes ne sont pas prises en charge lors de l’utilisation des sslmode paramètres verify-ca ou verify-all:

  • Utilisation de certificats d’autorité de certification intermédiaires dans votre magasin approuvé.
  • Utiliser l'épinglage des certificats, par exemple en employant des certificats de serveur individuels dans votre magasin de confiance.

Caution

Vos applications ne parviennent pas à se connecter aux serveurs de base de données sans avertissement chaque fois que Microsoft modifie les autorités de certification intermédiaires de la chaîne de certificats ou fait pivoter le certificat de serveur.

Problèmes d’épinglage de certificat

Note

Les rotations de certificat ne vous affectent pas si vous n’utilisez ni les paramètres sslmode=verify-full ni les paramètres sslmode=verify-ca dans la chaîne de connexion de votre application cliente. Par conséquent, vous n’avez pas besoin de suivre les étapes décrites dans cette section.

N’utilisez jamais le verrouillage de certificat dans vos applications, car cela empêche la rotation des certificats, comme c'est le cas actuellement avec les modifications de certificat des autorités de certification intermédiaires. Si vous ne savez pas ce qu'est le pinning des certificats, il est peu probable que vous l'utilisiez. Pour vérifier l’épinglage de certificat :

Si vous rencontrez des problèmes en raison du certificat intermédiaire, même après avoir suivi ces étapes, contactez le support Microsoft. Incluez la rotation ICA 2026 dans le titre.

Autres considérations relatives au protocole TLS

Au-delà de la configuration TLS principale et de la gestion des certificats, plusieurs autres facteurs influencent la sécurité et le comportement des connexions chiffrées à Azure Database pour PostgreSQL. La compréhension de ces considérations vous aide à prendre des décisions éclairées sur l’implémentation tls dans votre environnement.

Versions TLS non sécurisées et sécurisées

Plusieurs entités gouvernementales dans le monde tiennent à jour des instructions pour TLS concernant la sécurité réseau. Aux États-Unis, ces organisations incluent le Department of Health and Human Services ainsi que le National Institute of Standards and Technology. Le niveau de sécurité fourni par TLS est le plus affecté par la version du protocole TLS et les suites de chiffrement prises en charge.

Azure Database pour PostgreSQL prend en charge TLS versions 1.2 et 1.3. Dans RFC 8996, internet Engineering Task Force (IETF) indique explicitement que TLS 1.0 et TLS 1.1 ne doivent pas être utilisés. Ces deux protocoles sont déconseillés depuis la fin de l’année 2019. Toutes les connexions entrantes qui utilisent des versions non sécurisées antérieures du protocole TLS, telles que TLS 1.0 et TLS 1.1, sont refusées par défaut.

L’IETF a publié la spécification TLS 1.3 dans RFC 8446 en août 2018 et TLS 1.3 est la version recommandée, car elle est plus rapide et plus sécurisée que TLS 1.2.

Bien que nous ne le recommandons pas, si nécessaire, vous pouvez désactiver TLS pour les connexions à votre instance Azure Database pour PostgreSQL. Vous pouvez mettre à jour le paramètre de serveur require_secure_transport sur OFF.

Important

Utilisez la dernière version de TLS 1.3 pour chiffrer vos connexions de base de données. Vous pouvez spécifier la version TLS minimale en définissant le paramètre du serveur sur ssl_min_protocol_versionTLSv1.3. Ne définissez pas le paramètre serveur de ssl_max_protocol_version.

Suites de chiffrement

Une suite de chiffrement est un ensemble d’algorithmes qui incluent un chiffrement, un algorithme d’échange de clés et un algorithme de hachage. Utilisez-les conjointement avec le certificat TLS et la version TLS pour établir une connexion TLS sécurisée. La plupart des clients et serveurs TLS prennent en charge plusieurs suites de chiffrement et parfois plusieurs versions TLS. Pendant l’établissement de la connexion, le client et le serveur négocient la version TLS et la suite de chiffrement à utiliser via une négociation. Pendant ce handshake, les étapes suivantes se produisent :

  • Le client envoie une liste de suites de chiffrement acceptables.
  • Le serveur sélectionne la meilleure suite de chiffrement dans la liste et informe le client du choix.

Fonctionnalités TLS non disponibles dans Azure Database pour PostgreSQL

À ce stade, Azure Database pour PostgreSQL n’implémente pas les fonctionnalités TLS suivantes :

  • Authentification client basée sur un certificat TLS via TLS avec authentification mutuelle (mTLS).
  • Certificats de serveur personnalisés (apportez vos propres certificats TLS).

Contenu connexe

  • Last updated on