Documentation PostgreSQL 15.15 » Administration du serveur » Configuration du serveur et mise en place » Connexions TCP/IP sécurisées avec SSL

Précédent | Niveau supérieur | Suivant
19.8. Options de chiffrement | Sommaire | 19.10. Connexions TCP/IP sécurisées avec le chiffrage GSSAPI

## 19.9. Connexions TCP/IP sécurisées avec SSL

PostgreSQL dispose d'un support natif pour l'utilisation de connexions SSL et le chiffrage des communications client/serveur pour améliorer la 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 17).

Les termes SSL et TLS sont souvent utilisés de façon interchangeable pour signifier une connexion chiffrée sécurisée en utilisant un protocole TLS. Les protocoles SSL sont les précurseurs des protocoles TLS, et le terme SSL est encore utilisée pour des connexions chiffrées même si les protocoles SSL ne sont plus acceptées. SSL est utilisé de façon interchangeable avec TLS dans PostgreSQL.

### 19.9.1. Configuration basique

Avec SSL intégré à la compilation, le serveur PostgreSQL peut être démarré avec le support des connexions chiffrées utilisant les protocoles TLS activé en positionnant le paramètre ssl à `on` dans `postgresql.conf`. Le serveur écoutera les deux types de connexion, normal et SSL, sur le même port TCP, et négociera l'utilisation de SSL avec chaque client. Par défaut, c'est au choix du client ; voir Section 21.1 pour la configuration du serveur pour exiger SSL pour tout ou partie des connexions.

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 le répertoire des données permet l'accès en lecture au groupe, alors les fichiers de certificat doivent être placés hors de ce répertoire pour se conformer aux exigences de sécurité décrites ci-dessus. Généralement, l'accès au groupe est autorisé pour permettre à un utilisateur non privilégié de sauvegarder la base, et dans ce cas le logiciel de sauvegarde sera incapable de lire les certificats et retournera probablement une erreur.

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 par défaut empêche également la possibilité de modifier la configuration SSL du serveur sans redémarrage. Voir ssl_passphrase_command_supports_reload. 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 de `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.

### 19.9.2. Configuration d'OpenSSL

PostgreSQL lit le fichier de configuration OpenSSL du système. Par défaut, ce fichier est nommé `openssl.cnf` et est situé dans le répertoire désigné par `openssl version -d`. Ce défaut peut être surchargé en remplissant la variable d'environnement `OPENSSL_CONF` avec le nom du fichier de configuration désiré.

OpenSSL supporte une large gamme d'algorithmes de chiffrement et d'authentification de forces variables. Bien qu'une liste des techniques de chiffrement soit spécifiée dans le fichier de configuration d'OpenSSL, vous pouvez préciser les chiffrements à utiliser par le serveur en modifiant ssl_ciphers dans `postgresql.conf`.

### Note

Il est possible d'avoir une authentification sans le coût du chiffrement en utilisant les chiffrements `NULL-SHA` ou `NULL-MD5` ciphers. Cependant, un « homme du milieu » (man-in-the-middle) pourrait lire et transmettre des communications entre client et serveur. Pour ces raisons, les chiffrements NULL ne sont pas recommandés.

### 19.9.3. 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=verify-ca` ou `clientcert=verify-full` 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 34.19 pour une description sur la configuration des certificats sur le client.)

Pour une entrée `hostssl` avec `clientcert=verify-ca` , le serveur vérifiera que le certificat du client est signé par l'une des autorités de certification de confiance. Si `clientcert=verify-full` est spécifié, le serveur ne vérifiera pas seulement la chaîne de certificats, mais il vérifiera également si l'utilisateur ou sa correspondance concorde au `cn` (Common Name) du certificat fourni. Notez que la validation de la chaîne de certificats est toujours assurée lorsque la méthode d'authentification `cert` est utilisée (voir Section 21.12).

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 ou ssl_crl_dir 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é, le serveur vérifie toujours avec son fichier CA le certificat client présenté, s'il est configuré.

Il y a deux approches pour forcer les utilisateurs à fournir un certificat à la connexion.

La première approche fait usage de la méthode d'authentification `cert` pour les entrées `hostssl` de `pg_hba.conf`, afin que le certificat lui-même soit utilisé pour l'authentification tout en fournissant la sécurité de la connexion SSL. Voir les détails dans Section 21.12. (Il n'est pas nécessaire de spécifier explicitement d'options `clientcert` avec la méthode d'authentification `cert`.) Dans ce cas, le `cn` (Common Name) dans le certificat est comparé au nom d'utilisateur ou au mappage applicable.

La seconde approche combine n'importe quelle méthode d'authentification pour les entrées `hostssl` avec la vérification des certificats des clients, en positionnant l'option d'authentification `clientcert` à `verify-ca` ou `verify-full`. La première option ne garantit que la validité du certificat, alors que la seconde vérifie aussi que le `cn` (Common Name) correspond au nom d'utilisateur ou au mappage applicable.

### 19.9.4. Utilisation des fichiers serveur SSL

Tableau 19.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. Les noms configurés localement peuvent être différents.)

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

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