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).
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 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.
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.
Le premier certificat dans server.crt doit être le
certificat du serveur car il doit correspondre à la clé privée du serveur. Les
certificats des autorités « intermédiaires » d'autorité peuvent
aussi être ajoutés au fichier. Le faire permet d'éviter la nécessité
d'enregistrer les certificats intermédiaires des clients, en supposant que le
certificat racine et les certificats intermédiaires ont été créés avec les
extensions v3_ca. (Ceci configure la contrainte basique du
certificat CA à true.)
Ceci permet une expiration plus simple des certificats intermédiaires.
Il n'est pas nécessaire d'ajouter le certificat racine dans le fichier
server.crt. À la place, les clients doivent avoir le
certificat racine de la chaîne de certificats du serveur.
Pour réclamer au client de fournir un certificat de confiance, placez les
certificats des autorités certificats racines (CA) dont
vous avez confiance dans un fichier du répertoire des données, configurez le
paramètre ssl_ca_file dans
postgresql.conf au nouveau nom du fichier, et ajoutez
l'option d'authentification clientcert=1 sur la ligne
hostssl approprié dans pg_hba.conf. Un
certificat sera alors réclamé du client lors du démarrage de la connexion SSL.
(Voir Section 33.18 pour une description sur la configuration
des certificats sur le client.) Le serveur vérifiera que le certificat client
est signé par une des autorités de certificat de confiance.
Les certificats intermédiaires chaînés jusqu'aux certificats racines existants
peuvent aussi apparaître dans le fichier root.crt si vous
souhaitez éviter d'avoir à les stocker sur les clients (en supposant que les
certificats racine et intermédiaires ont été créés avec les extensions
v3_ca). Les entrées dans la liste de révocation de
certificats (CRL) sont aussi vérifiées si le paramètre ssl_crl_file est configuré.
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é.
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 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 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éer un certificat simple auto-signé pour le serveur, valide pour 365
jours, utilisez la commande OpenSSL suivante, en
remplaçant dbhost.yourdomain.com avec le nom d'hôte
du serveur
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
Puis, exécutez :
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.
Bien qu'un certificat auto-signé puisse être utilisé pour des tests, un certificat signé par une autorité de certificats (CA) (habituellement un CA racine entreprise) devrait être utilisé en production.
Pour créer un certificat serveur dont l'identité peut être validé par des clients, créez tout d'abord une demande de signature de certificat (CSR) et un fichier clés public/privé :
openssl req -new -nodes -text -out root.csr \
-keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
Puis, signez la demande avec la clé pour créer une autorité de certificat racine (en utilisant l'emplacement du fichier de configuration OpenSSL par défaut sur Linux) :
openssl x509 -req -in root.csr -text -days 3650 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -signkey root.key -out root.crt
Enfin, créez un certificat serveur signé par la nouvelle autorité de certificat racine :
openssl req -new -nodes -text -out server.csr \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
-CA root.crt -CAkey root.key -CAcreateserial \
-out server.crt
server.crt et server.key doivent
être stockés sur le serveur, et root.crt doit être stocké
sur le client pour que le client puisse vérifier que le certificat feuille du
serveur a été signé par son propre certificat racine de confiance.
root.key doit être enregistré hors ligne pour l'utiliser
pour créer les prochains certificats.
Il est aussi possible de créer une chaîne de confiance qui inclut les certificats intermédiaires :
# root openssl req -new -nodes -text -out root.csr \ -keyout root.key -subj "/CN=root.yourdomain.com" chmod og-rwx root.key openssl x509 -req -in root.csr -text -days 3650 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -signkey root.key -out root.crt # intermediate openssl req -new -nodes -text -out intermediate.csr \ -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com" chmod og-rwx intermediate.key openssl x509 -req -in intermediate.csr -text -days 1825 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -CA root.crt -CAkey root.key -CAcreateserial \ -out intermediate.crt # leaf openssl req -new -nodes -text -out server.csr \ -keyout server.key -subj "/CN=dbhost.yourdomain.com" chmod og-rwx server.key openssl x509 -req -in server.csr -text -days 365 \ -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \ -out server.crt
server.crt et intermediate.crt
doivent être concaténés dans un fichier certificat et stocké sur le serveur.
server.key doit aussi être stocké sur le serveur.
root.crt doit être stocké sur le client pour que le
client puisse vérifier que le certificat feuille du serveur a été signé par
une chaîne de certificats liés au certificat racine de confiance.
root.key et intermediate.key doivent
être stockées hors ligne pour être utilisé dans la création des certificats
futurs.