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

La sécurisation d'une base de données PostgreSQL est primordiale pour protéger les données sensibles et garantir la conformité. En tant que base de données relationnelle open-source avancée, PostgreSQL offre des mécanismes de configuration robustes pour contrôler l'accès, chiffrer les communications et minimiser les vulnérabilités potentielles. Ce guide explore les fichiers de configuration et les paramètres critiques nécessaires pour établir une posture de sécurité renforcée pour les environnements de production.

La sécurité efficace de PostgreSQL repose sur deux piliers principaux : contrôler qui peut se connecter et comment ils se connectent. Nous examinerons les paramètres vitaux dans postgresql.conf et le fichier crucial d'authentification client, pg_hba.conf, tout en mettant en œuvre le chiffrement obligatoire à l'aide de SSL/TLS.

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, en tant que quels utilisateurs PostgreSQL ils peuvent se connecter, à quelles bases de données ils peuvent accéder, et surtout, quelle méthode d'authentification est 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 (exemples : local, host, hostnossl, hostssl).
DATABASE : Nom(s) de la base de données cible.
USER : Rôle(s) de base de données cible.
ADDRESS : Plage d'adresses IP du client.
METHOD : Mécanisme d'authentification (exemples : 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 à toute personne 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 anciennes méthodes de mot de passe comme md5 en utilisant un hachage plus fort et en empêchant les attaques par rejeu. Ce devrait être votre choix par défaut pour les connexions à distance.

# Imposer SCRAM pour toutes les connexions à distance sur le port 5432
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 provenant d'une plage IP connue comme non sécurisée
host    all     all     192.168.1.0/24  reject

Astuce pratique : Après avoir modifié pg_hba.conf, vous devez recharger la configuration pour que les changements prennent effet (par exemple, pg_ctl reload ou envoyer un signal SIGHUP au processus postmaster).

2. Mise en œuvre du chiffrement SSL/TLS

Pour empêcher l'interception des 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).

Imposer SSL dans `pg_hba.conf`

Pour forcer les clients à utiliser SSL, modifiez 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

Si vous avez des clients existants qui ne prennent pas en charge SSL, vous pouvez autoriser explicitement les connexions non-SSL mais les restreindre uniquement aux opérations non sensibles, bien que le rejet total soit préférable.

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. Ceci est principalement géré par la configuration réseau et la désactivation des fonctionnalités inutiles.

Limiter l'adresse d'écoute réseau

Par défaut, PostgreSQL peut écouter sur toutes les interfaces réseau (listen_addresses = '*'). Pour une sécurité accrue, configurez-le explicitement pour qu'il n'écoute que sur l'interface (ou les interfaces) spécifique(s) qui nécessite(nt) un accès externe, ou sur localhost si seules les 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 quelles plages IP peuvent 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 rôles

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

ALTER USER postgres WITH PASSWORD 'YourStrongAndComplexPassword123!';

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

4. Configuration de l'audit et de la journalisation

Bien que n'étant pas strictement 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' : Journalise toutes les commandes de langage de définition de données (DDL) (comme CREATE TABLE, ALTER USER). Définissez sur 'all' temporairement lors des examens de sécurité, mais soyez conscient de l'impact sur les performances.
log_connections = on : Journalise chaque tentative de connexion réussie.
log_disconnections = on : Journalise la déconnexion des clients.
log_duration = on : Journalise le temps d'exécution de toutes les instructions, ce qui peut parfois révéler des schémas d'activité inhabituels.

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

Résumé des étapes de sécurité essentielles

Mettre à jour pg_hba.conf : Utiliser scram-sha-256 ou peer pour les méthodes d'authentification.
Imposer le chiffrement : Définir ssl = on dans postgresql.conf et utiliser des entrées hostssl dans pg_hba.conf.
Restreindre l'écoute : Configurer listen_addresses uniquement sur les interfaces nécessaires, en évitant le * par défaut si possible.
Imposer le moindre privilège : Limiter les rôles de base de données aux seules permissions absolument requises pour leur fonction.
Recharger la configuration : Toujours recharger ou redémarrer PostgreSQL après avoir modifié les fichiers de sécurité pour appliquer les changements.