Restriction d'accès par IP et configuration de pg_hba.conf

pg_hba.conf — c'est le fichier de config de PostgreSQL qui sert à gérer les connexions et l'authentification. HBA, ça veut dire Host-Based Authentication (authentification basée sur l’hôte). Ce fichier, c'est un peu comme une barrière réseau qui décide :

• Qui a le droit de se connecter au serveur (adresses IP, rôle, base de données).
• Quelle méthode d’authentification est requise pour la connexion.

Si on compare ça à la vraie vie, pg_hba.conf c’est comme un vigile à l’entrée d’un immeuble. Il décide qui peut entrer ou pas, en vérifiant non seulement tes papiers (mot de passe), mais aussi ton adresse (IP).

Structure du fichier pg_hba.conf

Le fichier pg_hba.conf est composé de lignes, chaque ligne décrivant une règle d’accès. La structure d’une ligne ressemble à ça :

<type de connexion> <base de données> <utilisateur> <source> <méthode d’authentification>

Voyons les composants :

Type de connexion (connection type) : définit comment le client va se connecter.

• local : connexion via sockets Unix (pour les utilisateurs locaux sur un serveur Linux).
• host : connexion via TCP/IP.
• hostssl : connexion via TCP/IP, mais seulement avec SSL.
• hostnossl : connexion via TCP/IP sans SSL.

Base de données : liste les bases auxquelles l’accès est autorisé. Tu peux mettre une base précise, plusieurs séparées par des virgules, ou des mots-clés :

• all : Autoriser l’accès à toutes les bases de données.

Utilisateur : indique quels utilisateurs ont le droit de se connecter.

• Tu peux mettre un nom d’utilisateur précis ou utiliser all pour tout le monde.

Source (address) : indique l’adresse IP du client ou une plage d’adresses.

• Pour IPv4, c’est le format x.x.x.x ou x.x.x.x/y (où /y c’est le masque de sous-réseau, genre /24).
• Pour IPv6, c’est le format ::/y.
• Le mot-clé all veut dire autoriser toutes les adresses IP.

Méthode d’authentification : indique la méthode d’authentification utilisée.

Exemples :

• trust : autoriser la connexion sans mot de passe (pas safe, juste pour les tests).
• md5 : utiliser un mot de passe (hashé).
• scram-sha-256 : authentification plus secure avec SHA-256.
• reject : interdire l’accès.

Exemples de lignes dans pg_hba.conf

La config du fichier peut être super flexible. Voilà quelques exemples :

1. Autoriser les connexions locales via socket Unix

   local   all             all                                     trust
   

   Tous les utilisateurs peuvent se connecter à toutes les bases sur le serveur local sans mot de passe.

2. Autoriser les connexions depuis une seule adresse IP

   host    my_database     my_user        192.168.1.100/32         md5
   

   L’utilisateur my_user peut se connecter à la base my_database seulement depuis l’IP 192.168.1.100, avec mot de passe.

3. Autoriser l’accès à la base depuis tout un sous-réseau

   host    my_database     all            192.168.1.0/24           scram-sha-256
   

   N’importe quel utilisateur du sous-réseau 192.168.1.0/24 peut se connecter à la base my_database, mais seulement via authentification SHA-256.

4. Interdire les connexions depuis un sous-réseau précis

   host    all             all            192.168.2.0/24           reject
   

   Les connexions depuis le sous-réseau 192.168.2.0/24 sont totalement interdites.

Configurer l’accès par adresses IP

Maintenant qu’on a pigé la structure du fichier, voyons comment gérer les connexions.

Essayons de limiter l’accès au serveur à certaines adresses IP. Imaginons qu’on a un serveur PostgreSQL et qu’on veut autoriser l’accès seulement depuis le localhost (127.0.0.1) et le réseau du bureau (192.168.10.0/24). Pour ça, on ajoute ces lignes dans pg_hba.conf :

# Accès local
host    all             all            127.0.0.1/32             trust

# Accès depuis le bureau
host    all             all            192.168.10.0/24          md5

# Tout le reste interdit
host    all             all            0.0.0.0/0                reject

Ici, la règle 0.0.0.0/0 veut dire "toutes les adresses IP". On interdit explicitement tout accès sauf depuis les adresses listées.

Configurer l’accès pour des utilisateurs distants

Si ton serveur PostgreSQL tourne dans le cloud ou sur un serveur distant, tu voudras peut-être autoriser les connexions seulement pour certaines IP externes. Par exemple :

# Accès pour l’admin depuis la maison
host    all             admin_user     203.0.113.10/32          md5

Dans cet exemple, seul l’utilisateur admin_user depuis l’IP 203.0.113.10 pourra se connecter.

Recharger la configuration

Après avoir modifié pg_hba.conf, PostgreSQL doit appliquer les changements. Utilise la commande :

sudo systemctl reload postgresql

Le rechargement est safe et ne va pas faire planter le serveur.

Si jamais tu as oublié où se trouve pg_hba.conf, tu peux trouver son chemin via SQL :

SHOW hba_file;

Erreurs classiques avec pg_hba.conf

Travailler avec pg_hba.conf est plutôt simple, mais les admins débutants font parfois des boulettes. Par exemple :

1. Oubli de recharger le serveur. Tous les changements dans pg_hba.conf ne prennent effet qu’après rechargement de la config.
2. Règles en conflit. PostgreSQL lit les règles de haut en bas. Dès qu’une règle matche, les suivantes sont ignorées. Les règles plus générales doivent être en bas.
3. Mauvais masque de sous-réseau. Par exemple, si tu mets /0, tu ouvres l’accès à tout le monde, ce qui est une grosse faille de sécurité.

Exemples de scénarios réels

Tester une appli sur le serveur local.

Autoriser l’accès seulement depuis localhost :

local   all   all   trust

Travailler avec des clients distants.

Autoriser l’accès à un client depuis une IP précise :

host    all   client_user   203.0.113.42/32   scram-sha-256

Restreindre l’accès sur un réseau public.

Interdire les connexions depuis Internet (mais autoriser le bureau) :

host    all   all   0.0.0.0/0   reject
host    all   all   192.168.10.0/24   md5

À ce stade, tu devrais déjà avoir capté comment utiliser pg_hba.conf pour restreindre l’accès à PostgreSQL. Ce fichier, c’est un des outils clés pour sécuriser ta base. Fais en sorte que ta config soit logique, testée et adaptée aux besoins du business. On veut tous vivre dans un monde où les données sont protégées des hackers, non ? Enfin, sauf si le hacker, c’est toi :)