Chaque fois qu'un client de base de données envoie une requête ou reçoit un ensemble de résultats, ces données transitent par un réseau. Sur un réseau privé et isolé, sans accès externe, cela peut représenter un risque acceptable. Cependant, dans la plupart des environnements réels, où le trafic traverse des infrastructures partagées, des réseaux cloud ou l'Internet, une connexion non chiffrée à une base de données représente une vulnérabilité importante. Le chiffrement SSL/TLS comble cette lacune, et sa configuration correcte est l'une des étapes les plus importantes, mais souvent négligées, de la sécurisation d'un environnement de base de données.
Pourquoi les connexions non chiffrées constituent un risque réel
Sans chiffrement, les données échangées entre un client et un serveur de base de données circulent en clair. Toute personne positionnée sur le même chemin réseau – que ce soit via un routeur compromis, un réseau virtuel cloud mal configuré ou une menace interne – peut potentiellement intercepter ces données. Cela inclut non seulement les résultats des requêtes, mais aussi les identifiants d’authentification. Un paquet de connexion capturé à partir d'une connexion à une base de données non chiffrée fournit à un attaquant un nom d'utilisateur et un mot de passe valides sans qu'il ait à fournir le moindre effort supplémentaire. Le risque n'est pas théorique ; l'interception au niveau du réseau est une technique d'attaque bien documentée, et son impact est considérablement plus grave lorsque le trafic intercepté provient d'une base de données.
Comprendre la chaîne de certificats
Le protocole TLS (Transport Layer Security) repose sur un système de certificats numériques. Avant toute communication chiffrée, le serveur présente au client un certificat attestant de son identité, déclarant en substance : « Je suis bien celui que je prétends être, et voici un document signé cryptographiquement par une autorité de confiance pour le prouver ». Cette autorité de confiance est une autorité de certification (CA), dont le rôle est de garantir l'identité des certificats qu'elle délivre.
En pratique, cela signifie que vous avez besoin de trois éléments pour établir une connexion TLS correctement vérifiée vers un serveur de base de données :
- Le serveur doit disposer d'un certificat valide émis par une autorité de certification (AC).
- Le client doit disposer d'une copie du certificat de l'autorité de certification afin de pouvoir vérifier l'identité du serveur.
- (facultatif) Pour le protocole TLS mutuel (mTLS), le client présente également son propre certificat au serveur, de sorte que l'authentification s'effectue dans les deux sens. Cette authentification facultative côté client est parfois appelée « authentification par certificat » ; elle offre une garantie nettement plus solide que l'authentification par mot de passe seule.
Principales options de configuration à comprendre
Lors de la configuration du protocole TLS pour une connexion à une base de données, plusieurs paramètres reviennent systématiquement, quel que soit le système de base de données ou le client utilisé
- Le fichier de certificat d'autorité de certification (CA) sert de référence de confiance. Il indique au client à quelle autorité de certification se fier pour vérifier l'identité du serveur.
- Le fichier de certificat client et le fichier de clé client sont utilisés lorsque le TLS mutuel est requis, ce qui permet au serveur de vérifier à son tour l'identité du client.
- La spécification de chiffrement détermine quels algorithmes de chiffrement sont acceptables pour la session ; il est recommandé de spécifier des chiffrements robustes et modernes plutôt que d'accepter les valeurs par défaut, car les suites de chiffrement plus anciennes présentent des failles connues.
Options SSL de PostgreSQL
PostgreSQL ajoute une dimension particulièrement utile à la gestion du protocole SSL, permettant de définir précisément le niveau de sécurité de la connexion. Les options vont de « allow » (tentative sans SSL en premier lieu, basculement vers SSL si nécessaire) et « prefer » (tentative avec SSL en premier lieu, basculement vers une connexion non chiffrée) à « require » (SSL uniquement, sans vérification du certificat), en passant par « verify-ca » (SSL et vérification de l'autorité de certification) et « verify-full » (SSL, autorité de certification vérifiée et correspondance du nom d'hôte du serveur avec le certificat). En environnement de production, les options « verify-ca » ou « verify-full » sont recommandées, car toute option moins permissive que « require » expose le système à une attaque de type « homme du milieu ».
Le tunneling SSH comme approche alternative
SSL/TLS chiffre le protocole de base de données en lui-même. Le tunneling Secure Shell (SSH) adopte une approche différente : il encapsule l’intégralité de la connexion à la base de données au sein d'une session SSH chiffrée. Le client de base de données se connecte à un port local, un tunnel SSH achemine ce trafic via une connexion chiffrée vers le serveur distant, et le serveur de base de données voit une connexion locale provenant du point de terminaison du tunnel. Le tunneling SSH est particulièrement utile dans les situations où le serveur de base de données n'a pas TLS configuré, ou lorsque les ports directs de la base de données ne sont pas exposés à l'extérieur pour des raisons de pare-feu, car il ne nécessite qu'un accès SSH plutôt qu'une configuration TLS au niveau de la base de données. C’est également un moyen simple de sécuriser l’accès distant pour les administrateurs qui doivent se connecter de manière interactive à une base de données située derrière un hôte bastion.
Comment Navicat prend en charge SSL/TLS et le tunneling SSH
Les produits de bureau Navicat, notamment Navicat Premium et les clients dédiés à chaque base de données, permettent de configurer SSL/TLS directement depuis l'interface des paramètres de connexion, accessible via un onglet SSL dédié lors de la création ou de la modification d'une connexion. Les utilisateurs peuvent alors activer SSL, fournir le certificat d'autorité de certification nécessaire à l'authentification du serveur et, éventuellement, un certificat client et une clé client pour l'authentification TLS mutuelle. Un champ de spécification du chiffrement permet aux administrateurs de restreindre les suites de chiffrement autorisées pour la connexion, au lieu de se fier aux valeurs par défaut négociées. Pour les connexions PostgreSQL, Navicat propose l'ensemble des options de mode SSL décrites ci-dessus, offrant ainsi aux administrateurs un contrôle précis sur le niveau de sécurité de la vérification de la connexion.
Le tunneling SSH est également pris en charge nativement dans toute la gamme de produits de Navicat. L'onglet SSH de la boîte de dialogue de connexion permet aux utilisateurs de configurer un tunnel via un serveur SSH intermédiaire, avec la prise en charge de l'authentification par mot de passe et par paire de clés publique/privée. Il est ainsi facile de se connecter en toute sécurité à des bases de données non exposées directement aux réseaux externes.
Navicat On-Prem Server étend également cette prise en charge SSL/TLS à la collaboration. Les connexions entre le serveur On-Prem et ses clients peuvent être chiffrées à l'aide de SSL/TLS, les administrateurs pouvant configurer les suites de chiffrement spécifiques utilisées pour ces sessions. SSL/TLS peut également être appliqué à la connexion entre Navicat On-Prem Server et sa base de données de référentiel sous-jacente, garantissant ainsi le chiffrement de bout en bout de l'infrastructure interne de la plateforme de collaboration, et pas seulement des connexions des utilisateurs finaux.
Conclusion
La configuration du protocole SSL/TLS pour les connexions aux bases de données n'est pas une tâche complexe, mais elle exige une attention particulière aux détails, tels que la gestion des certificats, le choix du mode ou la configuration des algorithmes de chiffrement, qui peuvent facilement être mal configurés ou laissés sur des paramètres par défaut peu sûrs. L'intérêt d'une configuration correcte est qu'il permet de réduire considérablement le risque d'interception au niveau du réseau, pouvant entraîner le vol d'identifiants ou la divulgation de données. Pour toute base de données traitant des données sensibles ou accessible via un réseau autre qu'un réseau totalement privé et isolé, une configuration TLS correcte est indispensable.
