PostgreSQL Produktionshärten: Rollenmanagement, TLS, pg_hba.conf und Datenträgerverschlüsselung

PostgreSQL Produktionshärten beginnt mit einer realistischen Bestandsaufnahme: Welche Clients verbinden sich, aus welchen Netzen, welche Auth‑Methoden nutzen sie und welche Plus/Minus-Rechte sind im Alltag wirklich nötig? Das Fokus-Keyword steht bewusst früh – Härtung ist kein Feature, sondern ein betrieblich verankerter Prozess, der Rollen-, Netzwerk- und Storage‑Maßnahmen zusammenführt und zugleich Migration, Backup und Wiederherstellung berücksichtigt.

Bedrohungsmodell, Ziele und Priorisierung

Härten heißt, konkrete Risiken zu adressieren. Typische Angriffspfade sind: offene Netzwerkzugriffe, geleakte Credentials (z. B. in CI/CD-Variablen), unverschlüsselte Backups, gestohlene Datenträger oder Angreifer mit lokalem Root. Priorisieren Sie Maßnahmen nach Impact (Datenverlust, Betriebsunterbrechung) und Eintrittswahrscheinlichkeit.

• Least Privilege: Rollen und Rechte so restriktiv wie möglich
• Zuverlässige Transportverschlüsselung: TLS mit Hostprüfung
• Restriktive pg_hba.conf als erste Firewall-Ebene
• Verschlüsselung ruhender Daten kombiniert mit kontrolliertem Key-Management

Rollenmanagement: Struktur, Verantwortung und Änderungsprozesse

In PostgreSQL sind Rollen technische Identitäten mit Rechten; sie können Login-Rechte haben (LOGIN) oder als Gruppenrollen ohne Login existieren. Setzen Sie dieses Konzept als Grundlage für ein wartbares Berechtigungsmodell um: Login‑Rollen für konkrete Services oder Personen, Gruppenrollen als Policy‑Container.

Konzept: Trennung von Identität und Rechte

Gruppenrollen bündeln Rechte (z. B. read-only, read-write). Login-Rollen bekommen nur die Mitgliedschaften, die sie brauchen. Vorteil: Bei Kompromittierung oder Deployment-Änderung passt man Memberships an, nicht Rechte über alle Objekte. Risiken entstehen, wenn Deployment-Prozesse Owner von Objekten ändern — dann greifen Default-Privileges unter Umständen nicht mehr.

Konkrete Operationen und Prüfbefehle

-- 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;

Zur Inventarisierung nutzen Sie Queries, um Login-Rollen, Gruppen und Owner-Verhältnisse zu erfassen:

-- 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;

Änderungs- und Rückfallstrategie

Führen Sie Rechteänderungen in einem Ticket durch, exportieren Sie Vorher-/Nachher-Reports und erzeugen Sie Revert-Scripts (z. B. automatische GRANT/REVOKE-Skripte). Wenn ein Change Verbindungen beeinträchtigt, stellen Sie zuerst Grants wieder her, bevor Sie Memberships entfernen.

PostgreSQL Produktionshärten: TLS einführen und nachweisen

TLS schützt Transportdaten; wichtig ist, dass Clients die Server-Identität prüfen. Kurz: ssl = on ist nur die Basis. Ohne PKI‑Konzept, CA‑Distribution und richtige SANs erreicht man keinen echten Schutz gegen Man‑in‑the‑Middle.

Praktische Voraussetzungen

Sie brauchen ein Serverzertifikat (server.crt) und den privaten Schlüssel (server.key). SANs (Subject Alternative Names) im Zertifikat müssen alle verwendeten Hostnamen/DNS‑Aliase abdecken. File‑Permissions für den Schlüssel sind kritisch: PostgreSQL verweigert den Start, wenn die Berechtigungen zu offen sind.

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

postgresql.conf: empfohlene Einstellungen

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

Client-Modi und Übergangsstrategie

libpq-Clients unterstützen sslmodes wie disable, require, verify-ca und verify-full. Langfristiges Ziel ist verify-full (prüft CA und Hostname). Beim Rollout empfiehlt sich ein gestaffeltes Vorgehen: zuerst Server mit TLS bereitstellen, dann Clients testen und schrittweise auf verify-full umstellen. Dokumentieren Sie Legacy-Clients, die verify-full nicht unterstützen.

Nachweis und Troubleshooting

-- 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;

Typische Fehler: Certificate verify failed (CA nicht verteilt oder falsche SANs), Permission denied für server.key, oder Performance-Einbrüche durch Entropy‑Engpässe auf älteren VMs. Bei OCSP/CRL-Problemen prüfen Sie, ob Firewalls die CRL/OCSP-Server erreichen.

pg_hba.conf: Regeln, Reihenfolge und Tests

Die pg_hba.conf ist die erste logische Zugriffsschranke. PostgreSQL wertet Einträge sequentiell; die erste passende Regel entscheidet. Daher: spezifische Regeln weit oben, breite Regeln ans Ende oder gar nicht verwenden.

Empfohlene Prinzipien

• Keine catch-all-Regeln
• Hostverbindungen bevorzugt über hostssl
• Starke Authentifizierung: scram-sha-256 statt md5
• Adminzugänge nur über Bastion-Hosts mit separater HBA-Zeile

Beispielkonfiguration und Prüfablauf

# 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();

Datenträgerverschlüsselung (FDE) richtig planen

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.

Architekturentscheidungen: PGDATA, WAL, Temp und 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.

LUKS‑Praxis und Performance‑Checks

# 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.

Key-Management: TPM, KMS und Recovery

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.

Backup-Integration und PITR in gehärteten Umgebungen

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.

Verschlüsselte Backups und Prüfung

# 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, Auditing und Automatisierte Tests

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

• Monitoring: pg_stat_ssl, pg_stat_activity, Verbindungsraten
• Audit-Logs: connection/disconnection, failed auths, DDL‑Events über pgaudit
• Automatisierte Tests: 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;

Key Rotation, Passwort-Upgrade und Kompatibilitätsstrategie

Planen Sie Key- und Passwortrotation: für TLS‑Zertifikate, LUKS-Header, und PostgreSQL-Passwörter. Für SCRAM‑Migration setzen Sie password_encryption = scram-sha-256 in postgresql.conf und führen ein gestaffeltes Update der Login-Rollenpasswörter durch.

-- 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

Bei Key-Rotation für LUKS erzeugen Sie neue Keyslots, testen Ent- und Verriegelung auf einem Host und dokumentieren das Rückrollverfahren.

Vorhersehbare Stolperfallen und schnelle Gegenmaßnahmen

• Fehlende SANs: Serverzertifikat deckt Hostnamen nicht ab → Rollback: temporäre HBA-Ausnahme und Zertifikatsaustausch
• Legacy-Clients brechen bei SCRAM → Kompensation: Netzwerksegmentierung oder Übergangsregel in HBA
• Unverschlüsselte Backup-Staging → Sofortmaßnahme: Backup-Transfers anhalten, verschlüsselte Ziel-Volumes einrichten
• Falsche file permissions für server.key → PostgreSQL verweigert SSL-Handshake; fix: chown/chmod korrekt setzen

Schlussfazit

PostgreSQL Produktionshärten ist ein pragmatischer, in Iterationen durchzuführender Prozess: Rollen sauber strukturieren, TLS mit echter Zertifikatsprüfung einführen, pg_hba.conf restriktiv und nachvollziehbar pflegen sowie Datenträgerverschlüsselung mit getesteter Recovery- und Key-Management-Strategie betreiben. Automatisierte Prüfungen, dokumentierte Rollbacks und Abstimmung mit Deployment‑Prozessen sind entscheidend, damit Sicherheit betriebbar, reproduzierbar und auditfähig bleibt.

Betriebsperspektiven: Rolling Changes, Replikation und Container-Umgebungen

Neben Konfiguration und Verschlüsselung entscheidet die Änderungs‑ und Betriebsstrategie darüber, ob Härtungsmaßnahmen im Alltag tragbar bleiben. Drei Bereiche sind dabei besonders kritisch: geordnete Rollouts (Canary/Phased), sichere Replikation und das Verhalten in Container‑/Orchestrierungsumgebungen.

Canary‑Änderungen und schnelles Rollback

Änderungen an pg_hba.conf, TLS‑Zertifikaten oder password_encryption sollten nie „blind“ auf alle Knoten ausgerollt werden. Vorgehen in kurzen, überprüfbaren Schritten:

• Erzeuge eine geänderte Konfiguration als separate Datei (z. B. pg_hba.conf.new).
• Aktiviere die neue Datei auf einem Canari‑Host, teste Verbindungen aus allen relevanten Subnetzen.
• Bei Problemen: atomare Wiederherstellung der alten Datei und 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();"

Sichere Replikation: Rollen, Limits und Monitoring

Replikationszugänge brauchen eigene Rollen mit minimalen Rechten, klaren IP‑Einschränkungen und Verbindungsgrenzen. Vergeben Sie das REPLICATION‑Attribut gezielt, setzen Sie connection_limit, und überwachen Sie Slots und Latenz.

-- 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.