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

Version anglaise

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

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

17.9.1. Utiliser des certificats clients

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 31.18, « Support de SSL » 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é. (Voir les diagrammes montrant l'utilisation des certificats SSL.)

L'option clientcert de pg_hba.conf est disponible pour toutes les méthodes d'authentification, mais seulement pour les lignes spécifiées hostssl. Quand clientcert n'est pas précisé ou qu'il est configuré à 0, le serveur vérifiera toujours les certificats clients présentés avec sa liste CA si elle est configurée -- mais il ne forcera pas la présentation d'un certificat client.

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 19.3.10, « Authentification de certificat » pour les détails.

17.9.2. Utilisation des fichiers serveur SSL

Tableau 17.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 17.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

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

17.9.3. Créer des certificats

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.