Durcissement de la sécurité PostgreSQL (audit d'état, réseau, TLS, authentification, privilèges, audit, chiffrement)

Ce n'est pas un guide d'installation : il trouve et corrige les failles de sécurité d'un serveur PostgreSQL en service. D'abord, l'Audit d'état en lecture seule liste les failles par gravité et indique vers quelle carte mène chaque constat ; vous corrigez ensuite les domaines un par un, ou tous dans l'ordre : adresse d'écoute, firewall et pg_hba ; TLS et sslmode=verify-full côté client ; scram-sha-256 et blocage des connexions réseau de postgres ; conception des rôles et privilèges PUBLIC ; pgaudit et journalisation centralisée ; LUKS / pgcrypto ; sauvegardes chiffrées ; système d'exploitation ; suivi des versions. À la fin, l'audit est relancé et les constats corrigés disparaissent de la liste.

Topologie: Un serveur PostgreSQL + serveur applicatif (vérification côté client) ; environnements avec replica/Patroni traités dans les notes

Scénarios

• Audit d'état : quelles sont mes failles ? (lecture seule) — Le premier contrôle à lancer : pg_hba, adresse d'écoute, TLS, mots de passe md5, superutilisateurs, privilèges PUBLIC, audit, permissions des fichiers et firewall ; il ne modifie rien.
• Durcissement complet (tous les domaines dans l'ordre) — Serveur fraîchement installé ou jamais durci : tous les domaines sont appliqués dans un ordre sûr ; PostgreSQL est redémarré une ou deux fois (une fenêtre de maintenance est nécessaire).
• Réseau et connexions : qui peut se connecter d'où ? (listen, firewall, pg_hba) — PostgreSQL écoute sur toutes les interfaces, pg_hba contient 0.0.0.0/0 ou trust, le port est ouvert à tous. Une modification de listen_addresses exige un redémarrage.
• Chiffrer les connexions (TLS, sslmode=verify-full) — ssl = off ou les clients ne vérifient pas le certificat ; certificat serveur, hostssl et verify-full côté client. Un simple reload suffit, sans interruption.
• Authentification et mots de passe (scram-sha-256, connexion distante de postgres) — Méthode md5/password, mots de passe hachés en md5, l'utilisateur postgres peut se connecter par le réseau ; migration vers scram-sha-256 et compte DBA nominatif. Sans interruption ; les mots de passe sont redéfinis.
• Moindre privilège : rôles, PUBLIC et compte applicatif — Le compte applicatif est propriétaire des tables ou superutilisateur, tout le monde peut écrire dans le schéma public ; rôles lecture/écriture/propriétaire et rapport des privilèges. Sans interruption.
• Audit : qui a fait quoi ? (pgaudit, journalisation centralisée) — L'auditeur ou l'équipe sécurité demande une trace des modifications DDL et des rôles ; installation de pgaudit et envoi des journaux vers un serveur central. Un redémarrage est nécessaire.
• Chiffrer les données au repos (LUKS / pgcrypto) — Une protection contre le vol d'un disque ou d'une sauvegarde est exigée. PostgreSQL n'a pas de TDE intégré : LUKS au niveau disque (interruption pour le déplacement) ou pgcrypto au niveau colonne.
• Sécurité des sauvegardes (sauvegardes chiffrées, permissions) — Les fichiers de sauvegarde ne sont pas chiffrés ou se trouvent dans un répertoire lisible par tous ; chiffrement du dépôt pgBackRest ou pg_dump + GPG, .pgpass et permissions des répertoires. Sans interruption.
• Côté système d'exploitation (compte de service, permissions, core dump, SELinux) — Le compte postgres a un mot de passe utilisable, les permissions du répertoire de données sont trop larges, SELinux est en Permissive/Disabled. Le réglage des core dumps prend effet au prochain redémarrage.
• Correctifs et version : suis-je sur une version supportée ? — Contrôle de la version, de la date de fin de support et des mises à jour mineures en attente ; renvoie au guide de patch pour les appliquer. Lecture seule.

Avant de commencer

• PostgreSQL … est démarré et vous pouvez vous connecter en postgres depuis le serveur lui-même (sudo -iu postgres psql) sans mot de passe (local all postgres peer dans pg_hba). Si l'installation a suivi le guide d'installation de PostgreSQL, c'est déjà le cas.
• Répertoire de données …, répertoire de configuration … ; psql et pg_dump sont sous …. Ils sont dans le PATH du login shell de l'utilisateur postgres ; depuis root, utilisez le chemin complet.
• Deux sessions SSH distinctes sont ouvertes sur le serveur : l'une pour appliquer les étapes, l'autre (avec sudo -iu postgres psql ouvert) pour revenir en arrière si une règle erronée vous bloque. Après chaque étape qui restreint l'accès, testez la nouvelle connexion dans une troisième session ; ne fermez pas les anciennes sessions avant d'avoir constaté le succès.
• Fenêtre de maintenance : PostgreSQL sera redémarré pour les domaines choisis (listen_addresses, shared_preload_libraries, limite des core dumps, déplacement du disque). L'équipe applicative a été prévenue.
• Vous disposez de la liste de toutes les applications qui se connectent à la base et de leurs paramètres de connexion (IP des serveurs, utilisateurs, versions des pilotes). Avant toute restriction, l'étape d'audit répond à la question qui se connecte d'où ; un client absent de la liste ne pourra plus se connecter après la restriction.
• Une sauvegarde récente dont la restauration a été testée existe (pgBackRest ou pg_dump). Le durcissement ne touche pas aux données, mais les modifications de rôles/privilèges et le déplacement du disque sont exposés à des erreurs irréversibles.

Phases du guide

• Audit d'état (lecture seule) — Lister les constats internes à la base · Lister les constats de schémas et de fonctions dans chaque base · Auditer le côté système d'exploitation
• Avant de commencer : point de retour — Copier la configuration actuelle et les rôles · Activer le répertoire de configuration supplémentaire (conf.d)
• Privilèges — 1. Diagnostic — Afficher les rôles, les propriétaires et les privilèges PUBLIC
• Privilèges — 2. Filet de sécurité — Faire un dump des privilèges actuels
• Privilèges — 3. Application — Créer les rôles de groupe et les comptes de connexion · Définir les mots de passe des nouveaux comptes de connexion · Mettre en place les privilèges de base et de schéma · Transférer au rôle propriétaire les objets appartenant au compte applicatif · Rapport des privilèges
• Privilèges — 4. Vérification — Vérifier que le compte applicatif ne peut pas exécuter de DDL et peut écrire des données
• Privilèges — 5. Suivi — Faire passer l'outil de migration par le rôle propriétaire
• Authentification — 1. Diagnostic — Afficher les hachages de mots de passe, les méthodes et les comptes
• Authentification — 2. Filet de sécurité — Vérifier la compatibilité des pilotes
• Authentification — 3. Application — Stocker les nouveaux mots de passe en scram-sha-256 · Charger le paramètre et redéfinir les mots de passe des comptes md5 · Remplacer la méthode md5/password par scram-sha-256 dans pg_hba · Bloquer les connexions réseau du superutilisateur postgres · Créer le compte DBA nominatif
• Authentification — 4. Vérification — Vérifier les hachages et le refus des connexions réseau du superutilisateur · Connexion scram depuis le serveur applicatif et refus de postgres
• Authentification — 5. Suivi — Passer en revue les comptes inutilisés et expirés
• TLS — 1. Diagnostic — Afficher l'état SSL actuel et les clients non chiffrés
• TLS — 2. Filet de sécurité — Préparer le répertoire des certificats
• TLS — 3. Application — Créer une CA de test et le certificat serveur · Créer la clé et la demande de signature de certificat (CSR) · Mettre en place le certificat signé et la chaîne de la CA · Vérifier le certificat, la clé et la chaîne · Activer TLS sur le serveur · Charger les paramètres et vérifier que TLS est activé …
• TLS — 4. Vérification — Vérifier que les connexions non chiffrées sont refusées
• TLS — 5. Suivi : renouvellement du certificat — Procédure de renouvellement du certificat
• Réseau — 1. Diagnostic : qui se connecte d'où ? — Afficher l'adresse d'écoute, les règles pg_hba et les clients actifs
• Réseau — 2. Filet de sécurité — Garder la session de secours ouverte
• Réseau — 3. Application — Restreindre l'adresse d'écoute · Réécrire pg_hba.conf avec un accès minimal · Contrôler et charger les règles · N'ouvrir le port dans le firewall qu'aux réseaux autorisés · Redémarrer PostgreSQL pour l'adresse d'écoute
• Réseau — 4. Vérification — Tester depuis le serveur applicatif une connexion autorisée et une connexion refusée
• Réseau — 5. Suivi — Surveiller les connexions refusées
• Audit — 1. Diagnostic — Afficher les paramètres d'audit et de journalisation
• Audit — 2. Filet de sécurité — Vérifier l'emplacement et l'espace libre du disque des journaux
• Audit — 3. Application — Installer le paquet pgaudit · Ajouter pgaudit aux bibliothèques préchargées et écrire les paramètres · Redémarrer pour activer pgaudit · Créer l'extension pgaudit · Transférer les journaux vers le serveur central (rsyslog) · Durée de conservation du fichier d'audit local (logrotate) …
• Audit — 4. Vérification — Faire une modification DDL et une modification de rôle, puis les voir dans le journal
• Audit — 5. Suivi — Surveiller la désactivation de l'audit
• Sauvegarde — 1. Diagnostic — Afficher l'état de chiffrement et les permissions des sauvegardes
• Sauvegarde — 2. Filet de sécurité — Préparer l'emplacement de stockage de la clé de chiffrement
• Sauvegarde — 3. Application — Déclarer le nouveau dépôt chiffré · Créer le dépôt chiffré et faire la première sauvegarde complète · Importer la clé publique GPG sur le serveur · Script de sauvegarde chiffrée · Répertoire de sauvegarde, permissions et test manuel · Planifier la sauvegarde chiffrée (cron) …