PostgreSQL™ dispose d'un support natif pour l'utilisation de connexions ssl, cryptant ainsi les communications clients/serveurs pour une sécurité améliorée. Ceci requiert l'installation d'openssl™ à la fois sur le système client et sur le système serveur et que ce support soit activé au moment de la construction de PostgreSQL™ (voir le Chapitre 16, Procédure d'installation de PostgreSQL™ du code source).
Avec le support ssl compilé, le serveur PostgreSQL™ peut être lancé avec ssl activé en activant ssl dans PostgreSQL.conf. Le serveur écoutera les deux connexions, standard et SSL sur le même port TCP, et négociera avec tout client l'utilisation de SSL. Par défaut, le client peut choisir cette option ; voir Section 20.1, « Le fichier pg_hba.conf » sur la façon de configurer le serveur pour réclamer l'utilisation de SSL pour certaines, voire toutes les connexions.
PostgreSQL™ lit le fichier de configuration d'OpenSSL™ pour le serveur. Par défaut, ce fichier est nommé openssl.cnf et est situé dans le répertoire indiqué par openssl version -d. Cette valeur par défaut peut être surchargée en configurant la variable d'environnement OPENSSL_CONF avec le nom du fichier de configuration désiré.
OpenSSL™ accepte une gamme étendue d'algorithmes de chiffrement et d'authentification, de différentes forces. Bien qu'une liste d'algorithmes de chiffrement peut être indiquée dans le fichier de configuration d'OpenSSL™, vous pouvez spécifier des algorithmes spécifiques à utiliser par le serveur de la base de données en modifiant le paramètre ssl_ciphers dans postgresql.conf.
![[Note]](images/note.png)
Il est possible d'avoir une authentification sans le chiffrement en utilisant les algorithmes NULL-SHA ou NULL-MD5. Néanmoins, une attaque du type man-in-the-middle pourrait lire et passer les communications entre client et serveur. De plus, le temps pris par le chiffrement est minimal comparé à celui pris par l'authentification. Pour ces raisons, les algorithmes NULL ne sont pas recommandés.
Pour démarrer dans le mode SSL, les fichiers contenant le certificat du serveur et la clé privée doivent exister. Par défaut, ces fichiers sont nommés respectivement server.crt et server.key, et sont placés dans le répertoire des données du serveur. D'autres noms et emplacements peuvent être spécifiés en utilisant les paramètres ssl_cert_file et ssl_key_file.
Sur les systèmes Unix, les droits de server.key doivent interdire l'accès au groupe et au reste du monde ; cela se fait avec la commande chmod 0600 server.key. Il est aussi possible de faire en sorte que le fichier ait root comme propriétaire et des droits de lecture pour le groupe (autrement dit, des droits 0640). Cette configuration cible les installations où les fichiers certificat et clé sont gérés par le système d'exploitation. L'utilisateur qui exécute le serveur PostgreSQL™ doit être un membre du groupe qui a accès aux fichiers certificat et clé.
Si la clé privée est protégée par une phrase de passe, le serveur la demandera et ne se lancera pas tant qu'elle n'aura pas été saisie. Utiliser une phrase de passe empêche également la possibilité de modifier la configuration SSL du serveur sans redémarrage. De plus, les clés privées protégées par phrases de passe ne peuvent être utilisées sur Windows.
Dans certains cas, le certificat du serveur peut être signé par une autorité « intermédiaire » de certificats, plutôt que par un qui soit directement de confiance par les clients. Pour utiliser un tel certificat, ajoutez le certificat de l'autorité signataire au fichier server.crt, puis le certificat de l'autorité parente, et ainsi de suite jusqu'à l'autorité « racine » ou « intermédiaire » qui est acceptée par les clients, autrement dit signé par le fichier root.crt du client.
Pour réclamer l'envoi d'un certificat de confiance par le client, placez les certificats des autorités (CA) de confiance dans le fichier root.crt du répertoire des données, configurez le paramètre ssl_ca_file du postgresql.conf à root.crt, et ajoutez l'option d'authentification clientcert=1 sur la ligne hostssl appropriée dans le fichier pg_hba.conf. Un certificat pourra ensuite être réclamé lors du lancement de la connexion SSL. (Voir Section 33.18, « Support de SSL » pour une description de la configuration de certificats sur le client.) Le serveur vérifiera que le certificat du client est signé par une des autorités de confiance.
Si des CA intermédiaires apparaissent dans le fichier root.crt, le fichier doit aussi contenir les chaînes de certificat jusqu'au CA racine. Les entrées de la liste de révocation des certificats sont aussi vérifiées si le paramètre ssl_crl_file est configuré. (Voir les diagrammes montrant l'utilisation des certificats SSL.)
L'option d'authentification clientcert est disponible pour toutes les méthodes d'authentification, mais seulement pour les lignes du fichier pg_hba.conf indiquées avec hostssl. Quand clientcert n'est pas configuré ou qu'il est configuré à 0, le serveur vérifiera toujours tout certificat client présenté avec le fichier CA, s'il est configuré -- mais il n'insistera pas sur le fait qu'un certificat client doit être présenté.
Notez que root.crt du serveur liste les autorités de certificats de haut-niveau, ceux suffisamment de confiance pour signer les certificats des clients. En principe, il n'a pas besoin de lister l'autorité de certificats qui a signé le certificat du serveur bien que dans la plupart des cas, cette autorité sera aussi de confiance pour les certificats de clients.
Si vous configurez les certificats de clients, vous pouvez utiliser la méthode d'authentification cert, de façon à ce que les certificats soient aussi utilisés pour contrôler l'authentification de l'utilisateur, tout en fournissant une sécurité de connexion. Voir Section 20.3.9, « Authentification de certificat » pour les détails. (Il n'est pas nécessaire de spécifier explicitement clientcert=1 lors de l'utilisation de la méthode d'authentification cert.)
Tableau 18.2, « Utilisation des fichiers serveur SSL » résume les fichiers qui ont un lien avec la configuration de SSL sur le serveur. (Les noms de fichiers indiqués sont les noms par défaut ou typiques. Les noms configurés localement peuvent être différents.)
Tableau 18.2. Utilisation des fichiers serveur SSL
| Fichier | Contenu | Effet |
|---|---|---|
| ssl_cert_file ($PGDATA/server.crt) | certificat du serveur | envoyé au client pour indiquer l'identité du serveur |
| ssl_key_file ($PGDATA/server.key) | clé privée du serveur | prouve que le certificat serveur est envoyé par son propriétaire n'indique pas que le propriétaire du certificat est de confiance |
| ssl_ca_file ($PGDATA/root.crt) | autorités de confiance pour les certificats | vérifie le certificat du client ; vérifie que le certificat du client est signé par une autorité de confiance |
| ssl_crl_file ($PGDATA/root.crl) | certificats révoqués par les autorités de confiance | le certificat du client ne doit pas être sur cette liste |
Le serveur lit ces fichiers lors de son démarrage et à chaque rechargement de la configuration serveur. Sur les systèmes Windows, ils sont également relus chaque fois qu'un nouveau processus est démarré pour une nouvelle connexion client.
Si une erreur est détectée dans ces fichiers lors du démarrage du serveur, celui-ci refusera de démarrer. Par contre, si une erreur est détectée lors d'un rechargement de configuration, ces fichiers seront ignorés et l'ancienne configuration SSL continuera d'être utilisée. Sur les systèmes Windows, si une erreur est détectée dans ces fichiers au démarrage d'un processus backend, celui-ci ne pourra établir une connexion SSL. Dans tous les cas, l'erreur sera rapportée dans les journaux du serveur.
Pour créér rapidement un certificat signé soi-même pour un serveur, valide pour 365 jours, utilisez la commande OpenSSL™ suivante, en remplacant yourdomain.com par le nom de l'hôte local :
openssl req -new -x509 -days 365 -nodes -text -out server.crt \ -keyout server.key -subj "/CN=yourdomain.com"
Faire ensuite :
chmod og-rwx server.key
car le serveur rejetera le fichier si ses droits sont plus importants. Pour plus de détails sur la façon de créer la clé privée et le certificat de votre serveur, référez-vous à la documentation d'OpenSSL™.
Un certificat auto-signé peut être utilisé pour tester, mais un certificat signé par une autorité (CA) (un des CAs global ou un local) devra être utilisé lorsque le serveur sera en production pour que le client puisse vérifier l'identité du serveur. Si tous les clients sont locaux à l'organisation, utiliser un CA local est recommandé.
Options de chiffrement
