Durcissement de PostgreSQL en production : gestion des rôles, TLS, pg_hba.conf et chiffrement des supports de données

Durcissement de PostgreSQL en production commence par un état des lieux réaliste : quels clients se connectent, depuis quels réseaux, quelles méthodes d’authentification utilisent-ils et quels droits supplémentaires ou de moindre privilège sont réellement nécessaires au quotidien ? Le mot-clé est volontairement placé tôt – le durcissement n’est pas une fonctionnalité, mais un processus ancré dans l’exploitation, qui fédère des mesures au niveau des rôles, du réseau et du stockage, tout en prenant en compte la migration, la sauvegarde et la RESTauration.

Modèle de menace, objectifs et priorisation

Le durcissement consiste à adresser des risques concrets. Les vecteurs d’attaque typiques sont : accès réseau ouverts, identifiants divulgués (p. ex. dans des variables CI/CD), sauvegardes non chiffrées, supports de stockage volés ou attaquants disposant d’un accès root local. Priorisez les mesures selon l’impact (perte de données, interruption de service) et la probabilité d’occurrence.

• Principe du moindre privilège: rôles et droits aussi RESTrictifs que possible
• Chiffrement des transports fiable: TLS avec vérification de l’hôte
• pg_hba.conf RESTrictive comme première couche de pare-feu
• Chiffrement des données au repos combiné à une gestion des clés contrôlée

Gestion des rôles: structure, responsabilités et processus de changement

Dans PostgreSQL, les rôles sont des identités techniques dotées de droits ; ils peuvent avoir le droit de se connecter (LOGIN) ou exister en tant que rôles de groupe sans LOGIN. Utilisez ce concept comme base d’un modèle d’autorisations maintenable : des rôles de connexion pour des services ou des personnes spécifiques, des rôles de groupe comme conteneurs de politiques.

Concept: séparation de l’identité et des droits

Les rôles de groupe regroupent des droits (p. ex. read-only, read-write). Les rôles de connexion reçoivent uniquement les appartenances dont ils ont besoin. Avantage : en cas de compromission ou de modification du déploiement, on ajuste les appartenances, pas les droits sur tous les objets. Des risques apparaissent lorsque les processus de déploiement modifient le propriétaire (owner) d’objets — dans ce cas, les Default-Privileges peuvent ne plus s’appliquer.

Opérations concrètes et commandes de vérification

-- Gruppenrollen anlegen
CREATE ROLE app_ro NOLOGIN;
CREATE ROLE app_rw NOLOGIN;

-- Service-Login-Rolle
CREATE ROLE svc_app_prod LOGIN;
GRANT app_rw TO svc_app_prod;

-- Basis-Grants
GRANT CONNECT ON DATABASE mydb TO app_ro, app_rw;
GRANT USAGE ON SCHEMA public TO app_ro, app_rw;

-- Objekt-Rechte
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;

-- Default-Privileges für neue Objekte
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO app_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;

Pour l’inventaire, utilisez des requêtes pour recenser les rôles de connexion, les groupes et les relations de propriétaire (owner) :

-- Login-fähige Rollen prüfen
SELECT rolname, rolcanlogin, rolsuper FROM pg_roles ORDER BY rolname;

-- Rollenmitgliedschaften
SELECT r.rolname AS role, m.rolname AS member
FROM pg_auth_members am
JOIN pg_roles r ON r.oid = am.roleid
JOIN pg_roles m ON m.oid = am.member
ORDER BY r.rolname, m.rolname;

-- Tabellen-Owner und Rechte prüfen
SELECT n.nspname, c.relname, r.rolname AS owner
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_roles r ON r.oid = c.relowner
WHERE c.relkind = 'r' -- nur Tabellen
ORDER BY n.nspname, c.relname;

Stratégie de modification et de repli

Effectuez les modifications de droits dans un ticket, exportez des rapports avant/après et générez des scripts de restauration (p. ex. des scripts automatiques GRANT/REVOKE). Si un changement affecte des connexions, restaurez d’abord les grants avant de supprimer les memberships.

Durcissement de PostgreSQL en production : déployer TLS et en apporter la preuve

TLS protège les données en transit ; l’essentiel est que les clients vérifient l’identité du serveur. En bref : ssl = on n’est que la base. Sans concept PKI, distribution des CA et SANs corrects, on n’obtient pas une protection réelle contre les attaques Man‑in‑the‑Middle.

Conditions pratiques

Vous avez besoin d’un certificat serveur (server.crt) et de la clé privée (server.key). Les SANs (Subject Alternative Names) du certificat doivent couvrir tous les noms d’hôte/alias DNS utilisés. Les permissions du fichier de clé sont critiques : PostgreSQL refusera de démarrer si les permissions sont trop permissives.

# Beispielrechte für den privaten Schlüssel
chown postgres:postgres /var/lib/postgresql/server.key
chmod 0600 /var/lib/postgresql/server.key

postgresql.conf : paramètres recommandés

ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file  = 'server.key'
# CA-Datei für clientseitige Zertifikatprüfung (optional bei mTLS)
# ssl_ca_file = 'root.crt'
# Erzwingen starker TLS-Versionen/Cipher basierend auf OS-Paket
log_connections = on
log_disconnections = on

Modes client et stratégie de transition

Les clients libpq prennent en charge des sslmodes tels que disable, require, verify-ca et verify-full. L’objectif à long terme est verify-full (vérifie la CA et le nom d’hôte). Pour le déploiement, privilégiez une approche par étapes : déployer d’abord le serveur avec TLS, tester les clients puis basculer progressivement vers verify-full. Documentez les clients legacy qui ne supportent pas verify-full.

Vérification et dépannage

-- TLS-Status pro Session sehen
SELECT a.pid, a.usename, a.client_addr, s.ssl, s.version, s.cipher
FROM pg_stat_activity a
LEFT JOIN pg_stat_ssl s ON a.pid = s.pid
ORDER BY a.client_addr;

Erreurs typiques : Certificate verify failed (CA non distribuée ou SANs incorrects), Permission denied pour server.key, ou dégradations de performance dues à un manque d’entropie sur de vieilles VM. En cas de problèmes OCSP/CRL, vérifiez que les pare-feu permettent l’accès aux serveurs CRL/OCSP.

pg_hba.conf : règles, ordre et tests

Le fichier pg_hba.conf est la première barrière logique d’accès. PostgreSQL évalue les entrées séquentiellement ; la première règle correspondante s’applique. Donc : placer les règles spécifiques en haut, les règles larges en fin de fichier ou ne pas les utiliser.

Principes recommandés

• Pas de règles de type « catch‑all »
• Privilégier hostssl pour les connexions host
• Authentification forte : scram-sha-256 plutôt que md5
• Accès administrateur uniquement via des bastion hosts avec une ligne HBA séparée

Exemple de configuration et procédure de vérification

# Wartung lokal
local   all             postgres                                peer
# Tools lokal
local   all             all                                     scram-sha-256
# Adminzugang - nur Bastion-Netz, TLS
hostssl all             dba_admin         10.10.10.0/24          scram-sha-256
# App-Zugriff
hostssl mydb            svc_app_prod      10.20.0.0/16           scram-sha-256
# Replikation
hostssl replication     repl_user         10.40.0.0/24           scram-sha-256

Testen Sie Änderungen mit einer offenen Admin-Session. Nach Änderungen reichen meist SELECT pg_reload_conf(); um HBA neu zu laden. Prüfen Sie zudem IPv6-Regeln — das Fehlen kann zu scheinbar random Verbindungsproblemen führen.

SELECT pg_reload_conf();

Planifier correctement le chiffrement des supports (FDE)

FDE (Full Disk Encryption) schützt gegen Datenträgerdiebstahl oder unautorisierte Images. Es schützt nicht gegen Angreifer mit Root auf laufendem System, weil Schlüssel dann verfügbar sind. Daher ist FDE Teil einer Verteidigungsstrategie, nicht die einzige Maßnahme.

Décisions d’architecture : PGDATA, WAL, Temp et Backups

Verschlüsseln Sie alle datensensitiven Speicherbereiche: PGDATA (Datenfiles), WAL-Volume (Write-Ahead Logs), Temp-Verzeichnisse und Backup-Staging. Ein unverschlüsseltes Backup auf einem unverschlüsselten Volume kann die ganze Strategie unterlaufen.

Pratique LUKS et vérifications de performance

# Beispielablauf (nicht blind in Prod)
lsblk
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb pgdata_crypt
mkfs.xfs /dev/mapper/pgdata_crypt
mount /dev/mapper/pgdata_crypt /var/lib/postgresql/data
# /etc/crypttab und /etc/fstab persistieren
# Test: I/O-Messung
fio --name=seqwrite --filename=/var/lib/postgresql/data/testfile --size=1G --bs=1M --rw=write

Testen Sie fsync-Verhalten, Checkpoint-Latenzen und WAL‑Durchsatz nach Migrationen. LUKS-Overhead ist meist moderat auf moderner CPU, aber auf I/O‑sensitiven Systemen müssen Sie Messungen machen und ggf. CPU‑Offload/Kernels mit AES‑NI sicherstellen.

Gestion des clés : TPM, KMS et récupération

Gute Praxis: Automatisiertes Unlocking per KMS-Connector (z. B. Vault, Cloud KMS) oder TPM-bindung mit klar definierten Break-Glass-Prozessen. Testen Sie Recovery-Prozesse regelmäßig. Ohne getestetes Recovery ist FDE ein erhebliches Betriebsrisiko.

Intégration des sauvegardes et PITR dans des environnements durcis

Backup-Strategie und PITR (Point-in-Time Recovery) müssen mit Verschlüsselung und TLS zusammenspielen. Backups sollten verschlüsselt transportiert und im Ziel verschlüsselt ruhen. WAL-Archive müssen dieselben Sicherheitsvorgaben erfüllen wie Live‑WALs.

Sauvegardes chiffrées et vérification

# Beispiel: verschlüsselte Archivierung mit GPG (Key-Management vorausgesetzt)
pg_basebackup -D - -Ft | gpg --encrypt --recipient backup@domain > /mnt/backup/mydb_$(date +%F).tar.gpg

Validieren Sie Backups regelmäßig: RESTore‑Tests in einer isolierten Umgebung, WAL‑Anwendung prüfen, und Wiederherstellungszeit messen. Prüfen Sie zudem, ob Backup-User notwendige Rechte haben, aber kein Superuser ist.

Monitoring, audit et tests automatisés

Härtung ist kein einmaliges Projekt. Automatisierte Checks geben Sicherheit im Betrieb:

• Monitoring: pg_stat_ssl, pg_stat_activity, Verbindungsraten
• Journaux d’audit: connexions/déconnexions, tentatives d’authentification échouées, événements DDL via pgaudit
• Tests automatisés: Verbindungstests aus den Client-Netzen, HBA-Testmatrix, Backup‑RESTore‑Jobs

-- Überwachen, ob TLS verwendet wird
SELECT count(*) FILTER (WHERE s.ssl) AS ssl_conn,
       count(*) FILTER (WHERE s.ssl IS NULL OR s.ssl = false) AS nonssl_conn
FROM pg_stat_activity a
LEFT JOIN pg_stat_ssl s ON a.pid = s.pid;

Rotation des clés, mise à niveau des mots de passe et stratégie de compatibilité

Planifiez la rotation des clés et des mots de passe : pour les certificats TLS, les en-têtes LUKS et les mots de passe PostgreSQL. Pour la migration SCRAM, définissez password_encryption = scram-sha-256 dans postgresql.conf et procédez à une mise à jour graduelle des mots de passe des rôles de connexion.

-- Setzen und erneuern von Passwörtern (nach Einstellen password_encryption)
ALTER ROLE svc_app_prod PASSWORD 'neues_starkes_passwort';
-- Prüfen ob SCRAM verwendet wird
SELECT rolname, rolpassword IS NOT NULL AS has_password FROM pg_authid WHERE rolcanlogin; -- Zugriff erfordert superuser

Pour la rotation de clés LUKS, créez de nouveaux keyslots, testez le déverrouillage/verrouillage sur un hôte et documentez la procédure de retour en arrière.

Pièges prévisibles et contre-mesures rapides

• SANs manquants : le certificat serveur ne couvre pas les noms d’hôte → Rollback : exception HBA temporaire et échange du certificat
• Clients hérités échouent avec SCRAM → Compensation : segmentation réseau ou règle transitoire dans HBA
• Zone de staging de sauvegarde non chiffrée → Mesure immédiate : arrêter les transferts de sauvegarde, provisionner des volumes cibles chiffrés
• Permissions de fichier incorrectes pour server.key → PostgreSQL refuse le SSL‑Handshake ; correctif : appliquer chown/chmod corrects

Conclusion

Le durcissement de PostgreSQL en production est un processus pragmatique à conduire par itérations : structurer proprement les rôles, introduire TLS avec une vérification réelle des certificats, maintenir pg_hba.conf de manière RESTrictive et traçable, et gérer le chiffrement des supports de stockage avec une stratégie de récupération et de gestion des clés testée. Des contrôles automatisés, des rollback documentés et l’alignement avec les processus de déploiement sont déterminants pour rendre la sécurité opérable, reproductible et auditable.

Perspectives opérationnelles : Rolling Changes, réplication et environnements conteneurisés

Outre la configuration et le chiffrement, la stratégie de changement et d’exploitation détermine si les mesures de durcissement RESTent viables au quotidien. Trois domaines sont particulièrement critiques : les rollouts ordonnés (Canary/Phased), la réplication sécurisée et le comportement dans les environnements conteneurisés / d’orchestration.

Modifications Canary et rollback rapide

Les modifications de pg_hba.conf, des certificats TLS ou de password_encryption ne doivent jamais être déployées « à l’aveugle » sur tous les nœuds. Procédez en étapes courtes et vérifiables :

• Générez une configuration modifiée comme fichier séparé (p.ex. pg_hba.conf.new).
• Activez le nouveau fichier sur un hôte canari, testez les connexions depuis tous les sous-réseaux pertinents.
• En cas de problème : RESTauration atomique de l’ancien fichier et SELECT pg_reload_conf();.

# Beispiel: sicherer Swap und Test
cp /etc/postgresql/12/main/pg_hba.conf /tmp/pg_hba.conf.bak
cp /etc/postgresql/12/main/pg_hba.conf.new /etc/postgresql/12/main/pg_hba.conf
psql -h 127.0.0.1 -U svc_test -d mydb -c 'conninfo' || { cp /tmp/pg_hba.conf.bak /etc/postgresql/12/main/pg_hba.conf; psql -c "SELECT pg_reload_conf();"; echo "Rollback ausgeführt"; }
psql -c "SELECT pg_reload_conf();"

Réplication sécurisée : rôles, limites et supervision

Les accès de réplication nécessitent des rôles dédiés avec des droits minimaux, des RESTrictions IP claires et des limites de connexions. Attribuez l’attribut REPLICATION de manière ciblée, définissez connection_limit, et surveillez les slots et la latence.

-- Replikationsrolle anlegen
CREATE ROLE repl_user WITH REPLICATION LOGIN PASSWORD 'starkes_passwort' CONNECTION LIMIT 3;
-- Überwachung: repl slot & lag
SELECT slot_name, active, RESTart_lsn FROM pg_replication_slots;
SELECT application_name, state, sync_state, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS bytes_lag
FROM pg_stat_replication;

Risiken: unbegrenzte Replication‑Slots können WAL‑Retention erzwingen und Speicher füllen. Planen Sie Slot‑Lifecycles und automatisierte Cleanup‑Jobs.

Container & Kubernetes: Geheimnisse und Volumes

In Containers/StatefulSets dürfen private Schlüssel und LUKS‑Keys nicht in Images liegen. Nutzen Sie Secrets (Kubernetes) oder verschlüsselte Volumes mit CSI‑KMS. Beachten Sie: Zertifikats‑Rotation erfordert meist Pod‑RESTart, weil Postgres das Serverzertifikat beim Start lädt.

• Mounten Sie Secrets mit RESTricted filemode (0600) und prüfen Sie SELinux/AppArmor‑Kontext auf Hostsystemen.
• Für Rolling RESTarts planen Sie PodDisruptionBudgets und Health‑Checks, damit Clients nicht alle Verbindungen verlieren.

Schnelle Diagnose‑Checks

• Fehler nach TLS/Key‑Änderungen: journalctl -u postgresql prüfen (Permission/SSL‑Fehler).
• Verbindungsprobleme nach HBA‑Anpassungen: aus verschiedenen Subnetzen mit psql -h testen.
• Bei Performance‑Änderungen nach LUKS‑Migration: I/O‑Benchmarks (fio) und WAL‑Durchsatz vergleichen.

Kurz: Operationalisierung macht Härtung belastbar. Automatisierte Canary‑Tests, dedizierte Replikationsrollen und gut verwaltete Secrets minimieren Ausfallrisiko und machen Rückrollen planbar — unerlässlich für produktive Umgebungen, in denen individuelle Unternehmenssoftware und Integrationen auf stabile Datenbankzugriffe angewiesen sind.

Für dieses Thema sind auch PostgreSQL Rollenmanagement und Pg_Hba.conf Best Practices wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.