Fichiers de configuration (postgresql.conf et pg_hba.conf)
PostgreSQL.conf
Ce paragraphe concerne l'administrateur système et peut donc être sauté par les autres profils (voir acteurs et rôles dans le module d'introduction).
PostgreSQL attend des connexions depuis des logiciels clients (nous en verrons prochainement, mais QGIS en est un exemple).
Le fichier de configuration propre à chaque instance PostgreSQL se nomme postgresql.conf.
Ce fichier rassemble les directives de configurations permettant d'adapter le comportement du serveur au matériel. Nous ne les détaillerons pas ici, mais notons qu'il est possible en particulier de définir les adresses TCP/IP que le serveur écoute ainsi que les ports d'écoute (défaut 5432). Ce fichier est géré par l'administrateur système.
Dans le cas d'une ouverture vers le Web il est conseillé de changer le port d'écoute par défaut.
pg_hba.conf
Les droits de connexion aux bases sont définies dans le fichier pg_hba.conf (type de connexion, ex : host, nom de la base de données, nom de l'utilisateur, paramètres réseaux, méthode d'authentification exemple : md5 pour demander un mot de passe).
Ce fichier est présent dans le répertoire initialisé avec l'instance, par exemple dans les systèmes Debian sous etc/postgresql/12/main/pg_hba.conf.
Une connexion ne concerne qu'une seule base de données et doit être réalisée avec un compte utilisateur.
Ce fichier est décrit dans la documentation de PostgreSQL. Il y a beaucoup d'options réglables,par exemple le processus d'autovacuum est activé (ou non) par le paramètre -autovacuum.
Il faut redémarrer PostgreSQL pour prendre en compte les modifications (commande restart).
(en fait il est possible de faire un simple reload du fichier de conf si on a modifié des paramètres qui ne nécessitent pas un redémarrage complet, voir pg_ctl -reload)
Retenons qu'il permet un filtrage des utilisateurs par adresse IP de leur poste.
Exemple : Filtrage des utilisateurs par adresse IP
exemple : host all all 172.26.0.0/24 md5
Autorise tous les utilisateurs (2ème all) à se connecter à toutes les bases (1er all) depuis n'importe quelle hôte d'un réseau local en fournissant un mot de passe (md5) pour les adresses de 172.26.0.0 à 172.26.0.255 (l'option /24 est le masque CIDR). On peut trouver sur Internet des calculateurs de masque CIDR.
Il aurait été possible de préciser plusieurs bases de données en les séparant par des virgules à la place du premier all.
Exemple : host postgres, service_test all 172.26.0.0 /24 md5
Ci-dessous un extrait du fichier pg_hba.conf proposé par défaut lors d'une installation qui montre que les droits d'accès aux bases sont possible localement (localhost : 127.0.0.1) :
Les droits d'accès aux contenus des bases sont définis dans la base de données à plusieurs niveaux (base, schéma, table, colonne). Nous les examinons un peu plus loin.
Conseil : Astuce
Il est possible d'ouvrir assez largement les droits de connexion aux utilisateurs du service dans le fichier pg_hba.conf et de contrôler plus finement la gestion des droits d'accès par base dans la gestion des droits et rôles de PostgreSQL, ce qui évite de solliciter trop souvent l'administrateur système et permet de reporter la gestion des droits courants, autre que le filtrage IP et éventuelles bases stratégiques (ex : base de sauvegarde), sur l'administrateur des bases.
Cependant il faut être conscient que même s'il ne peut accéder aux bases pour lesquels il n'a pas les droits, l'utilisateur peut dans ce cas parcourir l'arborescence des bases, ce qui n'est pas toujours souhaitable.
Ceci est valable sur un réseau interne (Intranet) qui n'est pas ouvert sur l'extérieur (Internet).
Pour des raisons de sécurité (éviter l'injection de requêtes SQL), sur une base de données en production ouverte sur le Web, la configuration des serveurs (base sur le même serveur que l'application ou non ...) impliquera une réflexion sur l'ouverture ou non des connexions.