Paramètres de configuration essentiels pour sécuriser votre base de données PostgreSQL

La sécurisation de PostgreSQL commence par une question simple : qui est autorisé à se connecter, d'où et avec quelle méthode d'authentification ? Si pg_hba.conf est trop large ou si le serveur écoute sur plus d'interfaces que nécessaire, votre base de données a une surface d'attaque plus grande que nécessaire.

Ce guide couvre les paramètres de sécurité PostgreSQL que vous devez examiner en premier : pg_hba.conf, l'authentification par mot de passe SCRAM, TLS, les écouteurs réseau, les permissions des rôles et les journaux.

1. Renforcement de l'authentification client avec `pg_hba.conf`

Le fichier d'authentification basé sur l'hôte (pg_hba.conf) dicte quels hôtes peuvent se connecter, à quels utilisateurs PostgreSQL ils peuvent se connecter, à quelles bases de données ils peuvent accéder et, surtout, la méthode d'authentification requise pour cette connexion.

Comprendre la structure de `pg_hba.conf`

Chaque ligne dans pg_hba.conf suit un format spécifique :

TYPE DATABASE USER ADDRESS METHOD [OPTIONS]

TYPE : Type de connexion (par exemple, local, host, hostnossl, hostssl).
DATABASE : Nom(s) de la base de données cible.
USER : Rôle(s) de la base de données cible.
ADDRESS : Plage d'adresses IP du client.
METHOD : Mécanisme d'authentification (par exemple, scram-sha-256, md5, reject, trust).

Meilleures pratiques pour les méthodes d'authentification

N'utilisez jamais la méthode trust en production, car elle permet à quiconque correspondant aux critères de connexion de se connecter sans mot de passe. Les méthodes d'authentification modernes recommandées sont :

Recommandé : `scram-sha-256`

SCRAM (Salted Challenge Response Authentication Mechanism) offre des améliorations significatives par rapport aux méthodes de mot de passe plus anciennes comme md5 en utilisant un hachage plus fort et en empêchant les attaques par rejeu. Cela devrait être votre choix par défaut pour les connexions à distance.

# Appliquer SCRAM pour les connexions à distance depuis un sous-réseau d'application
host    appdb   app_user 10.20.30.0/24  scram-sha-256

Définissez password_encryption = 'scram-sha-256' dans postgresql.conf avant de créer ou de faire pivoter les mots de passe. Les mots de passe existants stockés avec des hachages plus anciens ne sont pas automatiquement convertis ; réinitialisez-les après avoir activé SCRAM.

password_encryption = 'scram-sha-256'

Évitez les règles larges comme celle-ci à moins qu'un autre contrôle réseau ne restreigne déjà l'accès :

host    all     all     0.0.0.0/0       scram-sha-256

Connexions locales

Pour les connexions provenant du serveur lui-même (par exemple, les applications s'exécutant sur la même machine), utilisez les sockets locaux. Le paramètre le plus sécurisé est souvent peer (pour les sockets de domaine Unix) ou scram-sha-256 si les sockets sont désactivés ou restreints.

# Utiliser l'authentification peer pour les connexions locales via socket Unix
local   all     all             peer

Rejeter explicitement les connexions

Utilisez la méthode reject pour bloquer explicitement les connexions provenant de réseaux dangereux ou non fiables.

# Bloquer toutes les connexions depuis une plage IP connue comme non sécurisée
host    all     all     192.168.1.0/24  reject

Conseil pratique : Après avoir modifié pg_hba.conf, rechargez PostgreSQL pour que les modifications prennent effet, par exemple avec sudo systemctl reload postgresql ou SELECT pg_reload_conf();.

2. Mise en œuvre du chiffrement SSL/TLS

Pour empêcher l'interception de données sensibles (y compris les mots de passe) sur le réseau, l'application du chiffrement SSL/TLS pour toutes les connexions à distance est obligatoire.

Configuration dans `postgresql.conf`

Assurez-vous que ces paramètres sont correctement définis dans votre fichier de configuration principal :

ssl = on : Active le support SSL globalement.
ssl_cert_file : Chemin vers le fichier de certificat du serveur (par exemple, server.crt).
ssl_key_file : Chemin vers le fichier de clé privée du serveur (par exemple, server.key).

Application de SSL dans `pg_hba.conf`

Pour forcer les clients à utiliser SSL, changez le type de connexion dans pg_hba.conf de host à hostssl :

# Autoriser uniquement les connexions via SSL/TLS
hostssl all     all     0.0.0.0/0       scram-sha-256

hostssl ne correspond qu'aux connexions SSL. Assurez-vous de ne pas avoir également une règle host ultérieure ou antérieure qui autorise les mêmes utilisateurs sans TLS. Pour rendre la politique évidente, ajoutez une règle de rejet pour les connexions non SSL :

hostnossl all    all     0.0.0.0/0       reject

3. Minimiser la surface d'attaque

La sécurité implique de réduire l'exposition du serveur de base de données aux menaces externes. Cela est principalement géré via la configuration réseau et la désactivation des fonctionnalités inutiles.

Limiter l'adresse d'écoute réseau

PostgreSQL par défaut écoute sur localhost, mais les déploiements packagés et les images gérées peuvent différer. Configurez-le explicitement pour écouter uniquement sur l'interface spécifique qui nécessite un accès, ou maintenez-le sur localhost si seules des applications locales se connectent.

Dans postgresql.conf :

# Écouter uniquement sur localhost (127.0.0.1) si possible
listen_addresses = 'localhost'

# OU, écouter uniquement sur une interface réseau privée spécifique
# listen_addresses = '192.168.1.10'

Avertissement de sécurité : Si listen_addresses est défini sur *, toutes les interfaces seront utilisées. Assurez-vous que pg_hba.conf contrôle strictement les plages IP pouvant se connecter.

Désactiver les extensions et fonctionnalités inutiles

Chaque extension activée ajoute une complexité potentielle et des vecteurs d'attaque. Auditez régulièrement les extensions installées et supprimez celles qui ne sont pas activement utilisées pour votre charge de travail de production. Cela minimise la surface d'attaque globale.

Sécurité des mots de passe et des rôles

Assurez-vous que tous les rôles administratifs (comme l'utilisateur postgres par défaut) ont des mots de passe forts et complexes définis à l'aide de ALTER USER :

ALTER USER postgres WITH PASSWORD 'YourStrongAndComplexPassword123!';

Utilisez le principe du moindre privilège : les utilisateurs d'application ne doivent avoir que les permissions SELECT, INSERT, UPDATE et DELETE sur les tables spécifiques dont ils ont besoin, plutôt qu'un statut de superutilisateur.

4. Configuration de l'audit et de la journalisation

Bien qu'il ne s'agisse pas strictement d'un mécanisme de contrôle d'accès, une journalisation robuste est cruciale pour détecter et enquêter sur les incidents de sécurité. Configurez les paramètres de journalisation dans postgresql.conf pour capturer les événements pertinents.

Paramètres clés pour l'audit de sécurité :

log_statement = 'ddl' ou 'all' : Enregistre toutes les commandes DDL (Data Definition Language), telles que CREATE TABLE et ALTER USER. Utilisez 'all' avec précaution car cela peut créer un volume de journal élevé et peut capturer du texte de requête sensible.
log_connections = on : Enregistre chaque tentative de connexion réussie.
log_disconnections = on : Enregistre lorsque les clients se déconnectent.
log_duration = on : Enregistre le temps d'exécution de toutes les instructions, ce qui peut parfois révéler des modèles d'activité inhabituels.

En combinant des règles d'accès strictes dans pg_hba.conf, un chiffrement appliqué via SSL, une adresse d'écoute restreinte et une journalisation complète, vous établissez une base solide pour sécuriser votre déploiement PostgreSQL.

Étapes de sécurité essentielles

Mettez à jour pg_hba.conf : Utilisez scram-sha-256 ou peer pour les méthodes d'authentification.
Appliquez le chiffrement : Définissez ssl = on dans postgresql.conf et utilisez les entrées hostssl dans pg_hba.conf.
Restreignez l'écoute : Configurez listen_addresses uniquement sur les interfaces nécessaires, en évitant le * par défaut si possible.
Appliquez le moindre privilège : Limitez les rôles de base de données aux seules permissions absolument nécessaires à leur fonction.
Rechargez la configuration : Rechargez ou redémarrez toujours PostgreSQL après avoir modifié les fichiers de sécurité pour appliquer les modifications.

Ces paramètres sont la base. Après les avoir appliqués, testez à partir d'un client autorisé, testez à partir d'un client bloqué et vérifiez que les journaux montrent le comportement de connexion attendu.