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

Le serveur flexible Azure Database pour PostgreSQL impose la connexion de vos applications clientes à un serveur flexible Azure Database pour PostgreSQL à 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 fabriqué à partir de Netscape Communications Corp’s. Le show SSL (Secure Sockets Layer) l’a régulièrement supplanté, mais les termes SSL ou SSL/TLS sont toujours parfois utilisés de manière interchangeable. TLS est constitué de deux couches : le show d’enregistrement TLS et le show d’établissement d’une liaison TLS. Le show d’enregistrement fournit la sécurité d’association, tandis que le show d’établissement d’une liaison permet au serveur et au client d’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 ci-dessus montre une séquence d’établissement d’une liaison TLS 1.2 classique, composée des éléments suivants :

  1. Le client commence par envoyer un message appelé ClientHello, qui exprime essentiellement la volonté de communiquer via TLS 1.2 avec un ensemble de suites de chiffrement pris en charge par le client
  2. Le serveur le reçoit et répond avec un ServerHello qui accepte la communication avec le client via TLS 1.2 à l’aide d’une suite de chiffrement particulière
  3. En plus de cela, le serveur envoie son partage de clés. Les spécificités de ce partage de clé changent en fonction de la suite de chiffrement sélectionnée. Le détail important à noter est que pour que le client et le serveur acceptent une clé de chiffrement, ils doivent recevoir la partie ou le partage de l’autre.
  4. Le serveur envoie le certificat (signé par l’autorité de certification) et une signature sur des parties de ClientHello et ServerHello, y compris le partage de clés, afin que le client sache que ceux-ci sont authentiques.
  5. Une fois que le client reçoit correctement les données mentionnées ci-dessus, il génère alors son propre partage de clés, le mélange avec le partage de clés du serveur, et génère ainsi les clés de chiffrement pour la session.
  6. Enfin, le client envoie au serveur son partage de clés, active le chiffrement et envoie un message Terminé (qui 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és pour obtenir la clé et envoie son propre message Terminé.
  7. À ce stade, 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 triée de certificats, contenant un certificat SSL/TLS et des certificats d’autorité de certification (CA), qui permet au récepteur de vérifier que l’expéditeur et toutes les autorités de certification sont dignes de confiance. La chaîne ou le chemin d’accès commence par le certificat SSL/TLS, et 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. Le certificat d’autorité de certification racine est toujours signé par l’autorité de certification. 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 SSL/TLS 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 maintiennent des lignes directrices relatives au protocole TLS en ce qui concerne la sécurité réseau, notamment le HHS (Department of Health and Human Services) ou le NIST (National Institute of Standards and Technology) aux États-Unis. 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, incluant un chiffrement, un algorithme d’échange de clés et un algorithme de hachage, qui 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 donc négocier lors de l’établissement d’une connexion sécurisée pour sélectionner une version TLS commune et une suite de chiffrement.

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.

IETF (Internet Engineering Task Force) a publié la spécification TLS 1.3 dans RFC 8446 en août 2018, qui 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. C’est pourquoi nous vous recommandons vivement d’utiliser les dernières versions du protocole TLS pour chiffrer vos connexions à un serveur flexible Azure Database pour PostgreSQL.
Même si cela n’est pas recommandé, vous pouvez au besoin désactiver le protocole TLS\SSL pour les connexions à un serveur flexible Azure Database pour PostgreSQL en configurant le paramètre de serveur require_secure_transport sur OFF. Vous pouvez également définir la version TLS en configurant les paramètres de serveur ssl_min_protocol_version et ssl_max_protocol_version.

L’authentification par certificat est effectuée à l’aide de 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. Le serveur flexible Azure Database pour PostgreSQL ne prend pas en charge l’authentification par certificat SSL pour l’instant.

Remarque

Le serveur flexible Azure Database pour PostgreSQL ne prend pas en charge les certificats personnalisés SSL/TLS pour l’instant.

Remarque

Microsoft a procédé à des modifications de l’autorité de certification racine pour différents services Azure, notamment Azure Database pour PostgreSQL – Serveur flexible, comme détaillé dans ce document et dans Configuration de SSL dans la section Client ci-dessous.

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, elle retourne f. Vous pouvez également collecter toutes les informations sur l’utilisation SSL de votre instance de 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 directement la commande openssl, par exemple :

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

Cette commande imprime de nombreuses informations de bas niveau sur le protocole, y compris la version du protocole TLS, le chiffrement, et ainsi de suite. Vous devez utiliser l’option -starttls postgres. Dans le cas contraire, cette commande signale qu’aucun protocole SSL n’est utilisé. L’utilisation de cette commande nécessite au moins OpenSSL 1.1.1.

Remarque

Pour appliquer la dernière version la plus sécurisée du protocole TLS pour la protection de la connectivité du client vers un serveur flexible Azure Database pour PostgreSQL, définissez ssl_min_protocol_version sur 1.3. Cela obligera les clients qui se connectent à votre instance de serveur flexible Azure Database pour PostgreSQL à utiliser cette version du protocole uniquement pour communiquer en toute sécurité. Toutefois, les clients plus anciens, étant donné qu’ils ne prennent pas en charge cette version, peuvent ne pas être en mesure de communiquer avec le serveur.

Configuration du protocole SSL sur le client

Par défaut, PostgreSQL n’effectue aucune vérification du certificat de serveur. Cela signifie qu’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 matière de chiffrement et d’échange de clés, ce qui oblige à trouver un compromis entre niveau de performance et sécurité. Pour empêcher l’usurpation d’identité, il est nécessaire d’utiliser la vérification du certificat SSL sur le client. Il existe de nombreux paramètres de connexion pour configurer le client pour le protocole SSL. Parmi ceux qui sont importants pour nous, citons notamment :

  1. ssl. Connexion à 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. Toutefois, pour la compatibilité avec les futures versions, la valeur « true » est préférée. Dans ce mode, lors de l’établissement d’une connexion SSL, le pilote client valide l’identité du serveur empêchant les attaques de l’intercepteur. Il vérifie pour cela 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.
  2. 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. 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. En d’autres termes, si le serveur n’accepte pas les connexions SSL ou si le certificat client n’est pas reconnu, la connexion échoue. Le tableau ci-dessous indique les valeurs pour 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\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 cette adresse IP hôte et que le serveur reconnaît le certificat client.
verify-ca Le chiffrement est utilisé. Cela vérifie par ailleurs la signature du certificat de serveur par rapport au certificat stocké sur le client
verify-full Le chiffrement est utilisé. Cela vérifie par ailleurs 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 sont par défaut préférer, et les clients JDBC sont par défaut de vérification complète.

  1. 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. Ces paramètres sont définis respectivement sur /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 et /defaultdir/root.crt, où la valeur defaultdir est ${user.home}/.postgresql/ dans les systèmes *nix et %appdata%/postgresql/ sur Windows.

Les Autorités de certification (CA) 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.

Remarque

L’utilisation des paramètres de configuration verify-ca et verify-full pour sslmode 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. Il est important de noter que 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, reportez-vous à Épinglage de certificat et aux services Azure.

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

Remarque

Les clients qui utilisent les paramètres de configuration de sslmode verify-ca et verify-full, c’est-à-dire l’épinglage de certificat, doivent déployer trois certificats d’autorité de certification racine dans les magasins de certificats clients : les certificats d’autorité de certification racine DigiCert Global Root G2 et Microsoft RSA Root Certificate Authority 2017, car les services migrent de Digicert vers l’autorité de certification Microsoft. Pour la compatibilité héritée, Digicert Global Root CA.

Téléchargement des certificats d’autorité de certification racine et mise à 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 à partir des URI suivants :

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

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

Vous trouverez des informations détaillées sur la mise à jour des magasins de certificats d’applications clientes avec de nouveaux certificats d’autorité de certification racine dans ce document de procédure.

Important

Certaines des bibliothèques clientes 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, ce qui entraîne d’autres chemins d’accès d’approbation. Dans ce cas, il est recommandé de spécifier explicitement le paramètre sslrootcert, expliqué ci-dessus, ou de définir la variable d’environnement PGSSLROOTCERT sur le chemin local où le certificat d’autorité de certification racine Microsoft RSA Root Certificate Authority 2017 est placé, en changeant sa valeur par défaut %APPDATA%\postgresql\root.crt.

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 Certificate Authority 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 :

Remarque

Le serveur flexible Azure Database pour PostgreSQL ne prend pas en charge l’authentification par certificat pour l’instant.

Test des 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 les scénarios d’épinglage de certificats, comme le montre l’exemple ci-dessous :


$ 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, vous pouvez suivre documentation psql.

Test de la connectivité SSL/TLS

Avant d’essayer d’accéder à votre serveur compatible SSL à partir de l’application cliente, assurez-vous que vous pouvez y accéder via psql. Vous devriez apercevoir une sortie similaire à ce qui suit si vous avez établi une connexion SSL.

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, elle retourne f.

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 est constituée de 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 SSL/TLS 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, le serveur flexible Azure Database pour PostgreSQL prend en charge de nombreuses suites de chiffrement avec la version du protocole TLS 1.2 qui se situent dans la catégorie HIGH:!aNULL.

Résolution des erreurs de connectivité SSL\TLS

  1. Pour résoudre les problèmes de compatibilité de la version du protocole SSL/TLS, la première étape consiste à identifier les messages d’erreur que vous ou vos utilisateurs voyez quand vous essayez d’accéder à votre serveur flexible Azure Database pour PostgreSQL sous chiffrement TLS à partir du client. Selon l’application et la plateforme, les messages d’erreur peuvent être différents, mais ils pointent dans de nombreux cas vers un problème sous-jacent.
  2. Pour être certain de la compatibilité des versions du protocole SSL/TLS, vous devez vérifier la configuration des paramètres SSL/TLS du serveur de base de données et du client d’application pour vous assurer qu’ils prennent en charge les versions compatibles et les suites de chiffrement.
  3. Analysez les différences ou les lacunes entre le serveur de base de données et les versions SSL/TLS du client et les suites de chiffrement, puis essayez de les résoudre en activant ou en désactivant certaines options, en mettant à niveau les logiciels ou en revenant à une version antérieure, ou en modifiant des certificats ou des clés. Par exemple, vous devrez peut-être activer ou désactiver des versions SSL/TLS spécifiques sur le serveur ou le client en fonction des exigences de sécurité et de compatibilité, telles que la désactivation des versions TLS 1.0 et TLS 1.1, considérées comme non sécurisées et déconseillées, et l’activation des versions TLS 1.2 et TLS 1.3, qui sont plus sécurisées et modernes.
  4. Le certificat le plus récent émis avec Microsoft RSA Root Certificate Authority 2017 a un intermédiaire dans la chaîne avec signature croisée par l’autorité de certification Digicert Global Root G2. 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, ce qui aboutit à des chemins d’approbation alternatifs. Pour contourner ces problèmes, ajoutez les trois certificats nécessaires au magasin de certificats du client ou spécifiez explicitement le paramètre sslrootcert expliqué ci-dessus, ou définissez la variable d’environnement PGSSLROOTCERT sur le chemin d’accès local où le certificat de l’autorité de certification racine Microsoft RSA Root Certificate Authority 2017 est placé et dont la valeur par défaut est %APPDATA%\postgresql\root.crt.

Contenu connexe