PostgreSQLLa base de données la plus sophistiquée au monde.

17.8. Connexions tcp/ip sécurisées avec ssl

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 15, 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 19.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]

Note

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 le mode SSL, les fichiers server.crt et server.key doivent exister dans le répertoire de données du serveur. Ces fichiers doivent contenir, respectivement, le certificat et la clé privée du serveur. 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. 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.

17.8.1. Utiliser des certificats clients

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, et configurez le paramètre clientcert à 1 sur la ligne appropriée dans le fichier pg_hba.conf. Un certificat pourra ensuite être réclamé lors du lancement de la connexion SSL. (Voir Section 30.17, « 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. Les entrées de la liste de révocation des certificats sont aussi vérifiées si le fichier root.crl existe. (Voir les diagrammes montrant l'utilisation des certificats SSL.)

L'option clientcert dans pg_hba.conf est disponible pour toutes les méthodes d'authentification, mais seulement pour les lignes hostssl. Sauf cas contraire précisé, la valeur par défaut est de ne pas vérifier le certificat client.

Vous pouvez utiliser la méthode d'authentification cert dans le but d'utiliser le certificat client comme authentification des utilisateurs. Voir Section 19.3.8, « Authentification de certificat » pour les détails.

17.8.2. Utilisation des fichiers serveur SSL

Les fichiers server.key, server.crt, root.crt et root.crl sont seulement examinés au démarrage du serveur ; donc vous devez démarrer le serveur pour que les changements prennent effet.

Tableau 17.3. Utilisation des fichiers serveur SSL

Fichier Contenu Effet
server.crt certificat du serveur réclamé par le client
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
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
root.crl certificats révoqués par les autorités de confiance le certificat du client ne doit pas être sur cette liste

17.8.3. Créer un certificat auto-signé

Pour créer rapidement un certificat signé soi-même pour le serveur, utilisez la commande OpenSSL™ suivante :

openssl req -new -text -out server.req

Remplissez l'information que openssl demande. Assurez-vous de saisir le nom de l'hôte local dans « Common Name » ; le mot de passe peut ne pas être saisi. Le programme générera une clé qui est protégée par une phrase de passe ; il n'acceptera pas une phrase de passe qui fait moins de quatre caractères de long. Pour la supprimer (vous le devez si vous voulez un démarrage automatique du serveur), exécutez les commandes suivantes :

openssl rsa -in privkey.pem -out server.key
rm privkey.pem

Saisissez l'ancienne phrase de passe pour déverrouiller la clé existante. Maintenant, lancez :

openssl req -x509 -in server.req -text -key server.key -out server.crt

pour transformer le certificat en un certificat auto-signé et pour copier la clé et le certificat là où le serveur les cherchera. Enfin, faites :

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é.