Partager via

Connectivité sécurisée avec les protocoles TLS et SSL dans Azure Database pour PostgreSQL – Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Azure Database pour PostgreSQL – Serveur flexible impose la connexion de vos applications clientes à Azure Database pour PostgreSQL – Serveur flexible à l’aide du protocole TLS (Transport Layer Security). TLS est un protocole standard du secteur qui garantit des connexions réseau chiffrées entre votre serveur de base de données et vos applications clientes. Il s’agit d’une mise à jour du protocole SSL (Secure Sockets Layer).

Qu’est-ce que TLS ?

TLS a été créé à partir du protocole SSL de Netscape, et l’a communément remplacé. Les termes SSL ou TLS/SSL sont toujours parfois utilisés de façon interchangeable. TLS est constitué de deux couches : la présentation de l’enregistrement TLS et la présentation de l’établissement de liaison TLS. La présentation de l’enregistrement fournit la sécurité de l’association. La présentation d’établissement de liaison permet au serveur et au client de s’affirmer l’un l’autre et de coordonner les évaluations de chiffrement et les clés de chiffrement avant tout échange d’informations.

Diagramme montrant une séquence d’établissement d’une liaison TLS 1.2 classique.

Le diagramme précédent montre une séquence d’établissement de liaison TLS 1.2 classique, qui se compose de ces étapes :

  1. Le client commence par envoyer un message appelé ClientHello qui exprime la volonté de communiquer via TLS 1.2 avec un ensemble de suites de chiffrement pris en charge par le client.
  2. Le serveur reçoit le message, répond avec ServerHello, et accepte de communiquer avec le client via TLS 1.2 à l’aide d’une suite de chiffrement particulière.
  3. Le serveur envoie également son partage de clé. Les spécificités de ce partage de clé changent en fonction de la suite de chiffrement sélectionnée. Pour que le client et le serveur acceptent une clé de chiffrement, ils doivent recevoir la partie (ou partage) de l’autre.
  4. Le serveur envoie le certificat (signé par l’autorité de certification) et une signature sur les parties de ClientHello et ServerHello. Il inclut également le partage de clé. Ainsi, le client sait qu’il est authentique.
  5. Une fois que le client a bien reçu les données et a généré son propre partage de clé, il le mélange avec le partage de clé du serveur afin de générer les clés de chiffrement pour la session.
  6. Le client envoie au serveur son partage de clé, active le chiffrement, et envoie un message Finished. Ce message est un hachage d’une transcription de ce qui s’est passé jusqu’à présent. Le serveur fait de même. Il mélange les partages de clé pour obtenir la clé, et envoie son propre message Finished.
  7. Maintenant, les données d’application peuvent être envoyées chiffrées sur la connexion.

Chaînes de certificats

Une chaîne de certificats est une liste ordonnée de certificats qui contiennent un certificat TLS/SSL et des certificats d’autorité de certification. Ils permettent au destinataire de vérifier que l’expéditeur et toutes les autorités de certification sont fiables. La chaîne ou le chemin commence par le certificat TLS/SSL. Chaque certificat de la chaîne est signé par l’entité identifiée par le certificat suivant dans la chaîne.

La chaîne se termine par un certificat d’autorité de certification racine. Ce certificat est toujours signé par l’autorité de certification elle-même. Les signatures de tous les certificats dans la chaîne doivent être vérifiées, jusqu’au certificat d’autorité de certification racine.

Tout certificat se trouvant entre le certificat TLS/SSL et le certificat d’autorité de certification racine dans la chaîne est appelé « certificat intermédiaire ».

Versions TLS

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.

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. Ils sont utilisés ensemble pour établir une connexion TLS sécurisée. La plupart des clients et serveurs TLS prennent en charge plusieurs alternatives. Ils doivent négocier lorsqu’ils établissent une connexion sécurisée afin de sélectionner une version TLS et une suite de chiffrement communes.

Azure Database pour PostgreSQL prend en charge TLS 1.2 et les versions ultérieures. Dans la norme RFC 8996, l’organisation Internet Engineering Task Force (IETF) stipule explicitement que les protocoles 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 antérieures du protocole TLS, comme TLS 1.0 et TLS 1.1, sont refusées par défaut.

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

Remarque

Les certificats SSL et TLS certifient que votre connexion est sécurisée à l’aide de protocoles de chiffrement de pointe. En chiffrant votre connexion sur le réseau, vous empêchez l’accès non autorisé à vos données pendant leur transit. Nous vous recommandons vivement d’utiliser les dernières versions de TLS pour chiffrer vos connexions à Azure Database pour PostgreSQL – Serveur flexible.

Bien que nous ne le recommandions pas, si nécessaire, vous pouvez désactiver TLS\SSL pour les connexions à Azure Database pour PostgreSQL – Serveur flexible. Vous pouvez mettre à jour le paramètre de serveur require_secure_transport sur OFF. Vous pouvez également définir la version de TLS en définissant les paramètres de serveur ssl_min_protocol_version et ssl_max_protocol_version.

L’authentification par certificat est effectuée en utilisant des certificats clients SSL pour l’authentification. Dans ce scénario, le serveur PostgreSQL compare l’attribut CN (nom commun) du certificat client présenté par rapport à l’utilisateur de la base de données demandée.

Actuellement, Azure Database pour PostgreSQL – Serveur flexible ne prend pas en charge :

Remarque

Microsoft a apporté des modifications à l’autorité de certification racine pour différents services Azure, notamment Azure Database pour PostgreSQL – Serveur flexible. Pour plus d’informations, consultez Modifications apportées aux certificats TLS Azure et la section Configurer SSL sur le client.

Pour déterminer l’état actuel de votre connexion TLS\SSL, vous pouvez charger l’extension sslinfo, puis appeler la fonction ssl_is_used() pour déterminer si SSL est utilisé. La fonction retourne t si la connexion utilise SSL. Sinon, fest retourné. Vous pouvez également collecter toutes les informations sur l’utilisation SSL de votre serveur flexible Azure Database pour PostgreSQL par processus, client et application à l’aide de la requête suivante :

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;

Pour les tests, vous pouvez également utiliser la commande openssl directement :

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

Cette commande imprime des informations de protocole de bas niveau, telles que la version de TLS et le chiffrement. Vous devez utiliser l'option -starttls postgres. Autrement, cette commande signale qu’aucun protocole SSL n’est utilisé. L’utilisation de cette commande nécessite au moins OpenSSL 1.1.1.

Pour appliquer la dernière version la plus sécurisée du protocole TLS pour la protection de la connectivité du client vers Azure Database pour PostgreSQL – Serveur flexible, affectez la valeur 1.3 à ssl_min_protocol_version. Ce paramètre oblige les clients qui se connectent à votre serveur flexible Azure Database pour PostgreSQL à utiliser cette version du protocole uniquement pour communiquer en toute sécurité. Les clients plus anciens peuvent ne pas être en mesure de communiquer avec le serveur, car ils ne prennent pas en charge cette version.

Configurer le protocole SSL sur le client

Par défaut, PostgreSQL n’effectue aucune vérification du certificat de serveur. Pour cette raison, il est possible d’usurper l’identité du serveur (par exemple, en modifiant un enregistrement DNS ou en prenant l’adresse IP du serveur) sans que le client le sache. Toutes les options SSL entraînent une surcharge en termes de chiffrement et d’échange de clés ; un compromis est donc trouvé entre niveau de performance et sécurité.

Pour empêcher l’usurpation d’identité, la vérification du certificat SSL sur le client doit être utilisée.

Il existe de nombreux paramètres de connexion pour configurer le client pour le protocole SSL. En voici quelques-uns qui sont importants :

  • ssl : se connecter à l’aide du protocole SSL. Cette propriété n’a pas besoin d’une valeur associée. La simple présence de celle-ci spécifie une connexion SSL. Pour la compatibilité avec les futures versions, la valeur true est préférable. Dans ce mode, lorsque vous établissez une connexion SSL, le pilote client valide l’identité du serveur afin de prévenir les attaques de l’intercepteur. Il vérifie que le certificat de serveur est signé par une autorité de confiance et que l’hôte auquel vous vous connectez est identique au nom d’hôte dans le certificat.

  • sslmode : si vous avez besoin d’un chiffrement et souhaitez que la connexion échoue si elle ne peut pas être chiffrée, définissez sslmode=require. Ce paramètre garantit que le serveur est configuré pour accepter les connexions SSL pour cet hôte/cette adresse IP et que le serveur reconnaît le certificat client. Si le serveur n’accepte pas les connexions SSL ou si le certificat client n’est pas reconnu, la connexion échoue. Le tableau suivant indique les valeurs de ce paramètre :

    Mode SSL Explication
    disable Le chiffrement n’est pas utilisé.
    allow Le chiffrement est utilisé si les paramètres du serveur l’exigent ou l’appliquent.
    prefer Le chiffrement est utilisé si les paramètres du serveur l’autorisent.
    require Le chiffrement est utilisé. Cela garantit que le serveur est configuré pour accepter les connexions SSL pour cet hôte/cette adresse IP et que le serveur reconnaît le certificat client.
    verify-ca Le chiffrement est utilisé. Vérifie la signature du certificat de serveur par rapport au certificat stocké sur le client.
    verify-full Le chiffrement est utilisé. Vérifie la signature du certificat de serveur et le nom d’hôte par rapport au certificat stocké sur le client.

    Le mode sslmode par défaut utilisé est différent entre les clients basés sur libpq (tels que psql) et JDBC. Les clients libpq utilisent par défaut prefer. Les clients JDBC utilisent par défaut verify-full.

  • sslcert, sslkey et sslrootcert : ces paramètres peuvent remplacer l’emplacement par défaut du certificat client, la clé client PKCS-8 et le certificat racine. Par défaut, il s’agit respectivement de /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 et /defaultdir/root.crt, où defaultdir est ${user.home}/.postgresql/ dans les systèmes nix et %appdata%/postgresql/ sur Windows.

Les autorités de certification sont les institutions responsables de l’émission de certificats. Une autorité de certification approuvée est une entité qui a le droit de vérifier qu’une personne est ce qu’elle prétend être. Pour que ce modèle fonctionne, tous les participants doivent s’entendre sur un ensemble d’autorités de certification approuvées. Tous les systèmes d’exploitation et la plupart des navigateurs web sont fournis avec un ensemble d’autorités de certification approuvées.

L’utilisation des paramètres de configuration sslmode verify-ca et verify-full est également connue sous le nom d’épinglage de certificat. Dans ce cas, les certificats d’autorité de certification racine sur le serveur PostgreSQL doivent correspondre à la signature de certificat et même au nom d’hôte par rapport au certificat sur le client.

Vous devrez peut-être régulièrement mettre à jour les certificats stockés des clients lorsque les autorités de certification changent ou expirent sur les certificats de serveur PostgreSQL. Pour déterminer si vous épinglez des autorités de certification, consultez Épinglage de certificat et services Azure.

Pour plus d’informations sur la configuration des paramètres SSL\TLS sur le client, consultez Documentation PostgreSQL.

Les clients qui utilisent les paramètres de configuration sslmode verify-ca et verify-full (autrement dit, épinglage de certificat) doivent déployer trois certificats d’autorité de certification racine dans les magasins de certificats clients :

Télécharger des certificats d’autorité de certification racine et mettre à jour des clients d’application dans des scénarios d’épinglage de certificats

Pour mettre à jour des applications clientes dans des scénarios d’épinglage de certificat, vous pouvez télécharger des certificats :

Pour importer des certificats dans des magasins de certificats clients, vous devrez peut-être convertir des fichiers de certificat .crt au format .pem après avoir téléchargé des fichiers de certificat à partir des URI précédents. Vous pouvez utiliser l’utilitaire OpenSSL pour effectuer ces conversions de fichiers :

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

Les informations sur la mise à jour des magasins de certificats d’applications clientes avec de nouveaux certificats d’autorité de certification racine sont documentées dans Mettre à jour des certificats TLS clients pour les clients d’application.

Important

Certaines des bibliothèques de client Postgres, lors de l’utilisation du paramètre sslmode=verify-full, peuvent rencontrer des échecs de connexion avec des certificats d’autorité de certification racine qui sont signés avec des certificats intermédiaires. Le résultat est la présence d’autres chemins d’accès d’approbation. Dans ce cas, nous vous recommandons de spécifier explicitement le paramètre sslrootcert. Ou alors, modifiez la valeur par défaut (%APPDATA%\postgresql\root.crt) de la variable d’environnement PGSSLROOTCERT et affectez-lui un chemin d’accès local où le certificat d’autorité de certification racine Microsoft RSA Root CA 2017 est placé.

Réplicas en lecture avec des scénarios d’épinglage de certificat

Avec la migration de l’autorité de certification racine vers Microsoft RSA Root CA 2017, il est possible que les réplicas nouvellement créés soient sur un certificat d’autorité de certification racine plus récent que le serveur principal créé précédemment. Par conséquent, pour les clients qui utilisent les paramètres de configuration sslmode verify-ca et verify-full (c’est-à-dire l’épinglage de certificat), il est impératif que la connectivité interrompue accepte trois certificats d’autorité de certification racine :

À ce stade, Azure Database pour PostgreSQL – Serveur flexible ne prend pas en charge l’authentification basée sur des certificats.

Tester les certificats clients en se connectant avec psql dans des scénarios d’épinglage de certificats

Vous pouvez utiliser la ligne de commande psql à partir de votre client pour tester la connectivité au serveur dans des scénarios d’épinglage de certificats :


$ 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"

Pour plus d’informations sur les paramètres SSL et de certificat, consultez la documentation psql.

Tester la connectivité TLS/SSL

Avant d’essayer d’accéder à votre serveur compatible SSL à partir d’une application cliente, assurez-vous de pouvoir y accéder via psql. Si vous avez établi une connexion SSL, vous devriez voir une sortie similaire à l’exemple suivant :

psql (14.5)connexion SSL (protocole : TLSv1.2, chiffrement : ECDHE-RSA-AES256-GCM-SHA384, bits : 256, compression : désactivé)Tapez « aide » pour obtenir de l’aide.

Vous pouvez également charger l’extension sslinfo, puis appeler la fonction ssl_is_used() pour déterminer si SSL est utilisé. La fonction retourne t si la connexion utilise SSL. Sinon, fest retourné.

Suites de chiffrement

Une suite de chiffrement est un ensemble d’algorithmes cryptographiques. Les protocoles TLS/SSL utilisent des algorithmes d’une suite de chiffrement pour créer des clés et chiffrer des informations.

Une suite de chiffrement est affichée sous la forme d’une longue chaîne d’informations apparemment aléatoires, mais chaque segment de cette chaîne contient des informations essentielles. En règle générale, cette chaîne de données comprend plusieurs composants clés :

  • Protocole (c’est-à-dire TLS 1.2 ou TLS 1.3)
  • Algorithme d’échange ou d’acceptation de clé
  • Algorithme de signature numérique (authentification)
  • Algorithme de chiffrement par lots
  • Algorithme de code d’authentification de message (MAC)

Différentes versions de TLS/SSL prennent en charge différentes suites de chiffrement. Les suites de chiffrement TLS 1.2 ne peuvent pas être négociées avec des connexions TLS 1.3, et inversement.

À ce stade, Azure Database pour PostgreSQL – Serveur flexible prend en charge de nombreuses suites de chiffrement avec la version du protocole TLS 1.2 qui entrent dans la catégorie HIGH:!aNULL.

Résoudre les erreurs de connectivité TLS/SSL

  1. Pour résoudre les problèmes de compatibilité de la version du protocole TLS/SSL, la première étape consiste à identifier les messages d’erreur que vos utilisateurs ou vous-même voyez quand vous essayez d’accéder à votre serveur flexible Azure Database pour PostgreSQL sous chiffrement TLS à partir du client. Les messages d’erreur peuvent être différents en fonction de l’application de et la plateforme. Dans de nombreux cas, ils pointent vers le problème sous-jacent.

  2. Pour être certain de la compatibilité des versions du protocole TLS/SSL, vérifiez la configuration TLS/SSL du serveur de base de données et du client d’application pour vous assurer qu’ils prennent en charge des versions et des suites de chiffrement compatibles.

  3. Analysez les différences ou les lacunes entre les versions TLS/SSL et les suites de chiffrement du client et du serveur de base de données. Essayez de les résoudre en activant ou en désactivant certaines options, en mettant à niveau ou en rétrogradant des logiciels, ou en modifiant des certificats ou des clés. Par exemple, vous devrez peut-être activer ou désactiver des versions TLS/SSL spécifiques sur le serveur ou le client, en fonction des exigences de sécurité et de compatibilité. Par exemple, vous devrez peut-être désactiver TLS 1.0 et TLS 1.1, qui sont considérés comme non sécurisés et déconseillés, et activer TLS 1.2 et TLS 1.3, qui sont plus sécurisés et modernes.

  4. Le certificat le plus récent émis avec Microsoft RSA Root CA 2017 a un intermédiaire dans la chaîne avec signature croisée par l’autorité de certification Global Root G2 CA. Certaines des bibliothèques de client Postgres, lors de l’utilisation du paramètre sslmode=verify-full ou sslmode=verify-ca, peuvent rencontrer des échecs de connexion avec des certificats d’autorité de certification racine qui sont signés avec des certificats intermédiaires. Le résultat est la présence d’autres chemins d’accès d’approbation.

    Pour contourner ces problèmes, ajoutez les trois certificats nécessaires au magasin de certificats client ou spécifiez explicitement le paramètre sslrootcert. Ou alors, modifiez la valeur par défaut (%APPDATA%\postgresql\root.crt) de la variable d’environnement PGSSLROOTCERT et affectez-lui le chemin d’accès local où le certificat d’autorité de certification racine Microsoft RSA Root CA 2017 est placé.

Contenu connexe

  • Découvrez comment créer un serveur flexible Azure Database pour PostgreSQL en utilisant l’option Accès privé (intégration au réseau virtuel) dans le portail Azure ou dans Azure CLI.
  • Découvrez comment créer un serveur flexible Azure Database pour PostgreSQL en utilisant l’option Accès public (adresses IP autorisées) dans le portail Azure ou l’interface Azure CLI.