PostgreSQL-Sicherheitshärtung (Statusprüfung, Netzwerk, TLS, Authentifizierung, Berechtigungen, Audit, Verschlüsselung)
PostgreSQLStufe: MittelDauer: 5 Min. (Prüfung) – 3 Stunden (vollständige Härtung)Kein Installationsleitfaden: Er findet und schließt die Sicherheitslücken eines laufenden PostgreSQL-Servers. Zuerst listet die schreibgeschützte Statusprüfung die Befunde nach Schweregrad auf und nennt für jeden Befund die zuständige Karte; danach schließt du die Bereiche einzeln oder alle der Reihe nach: Listen-Adresse, Firewall und pg_hba; TLS und sslmode=verify-full auf dem Client; scram-sha-256 und das Sperren von Netzwerk-Logins für postgres; Rollendesign und PUBLIC-Berechtigungen; pgaudit und zentrales Logging; LUKS / pgcrypto; verschlüsselte Backups; Betriebssystem; Versionsverfolgung. Am Ende läuft die Prüfung erneut, und die geschlossenen Befunde fallen aus der Liste.
Topologie: Einzelner PostgreSQL-Server + Anwendungsserver (Client-Prüfung); Umgebungen mit Replica/Patroni in den Hinweisen
Szenarien
- Statusprüfung: Welche Lücken habe ich? (schreibgeschützt) — Der erste Scan: pg_hba, Listen-Adresse, TLS, md5-Passwörter, Superuser, PUBLIC-Berechtigungen, Audit, Dateiberechtigungen und Firewall; er ändert nichts.
- Vollständige Härtung (alle Bereiche der Reihe nach) — Neu installierter oder nie gehärteter Server: Alle Bereiche werden in sicherer Reihenfolge umgesetzt; PostgreSQL wird ein- bis zweimal neu gestartet (Wartungsfenster erforderlich).
- Netzwerk und Verbindungen: Wer darf sich von wo verbinden? (listen, firewall, pg_hba) — PostgreSQL lauscht auf allen Schnittstellen, pg_hba enthält 0.0.0.0/0 oder trust, der Port ist für alle offen. Eine Änderung von listen_addresses erfordert einen Neustart.
- Verbindungen verschlüsseln (TLS, sslmode=verify-full) — ssl = off oder Clients prüfen das Zertifikat nicht; Serverzertifikat, hostssl und verify-full auf dem Client. Nur ein Reload nötig, keine Downtime.
- Authentifizierung und Passwörter (scram-sha-256, Remote-Login für postgres) — Methode md5/password, md5-gehashte Passwörter, der Benutzer postgres kann sich über das Netzwerk anmelden; Umstellung auf scram-sha-256 und persönliches DBA-Konto. Keine Downtime, Passwörter werden neu gesetzt.
- Minimale Rechte: Rollen, PUBLIC und das Anwendungskonto — Das Anwendungskonto ist Eigentümer der Tabellen oder Superuser, jeder kann ins public-Schema schreiben; Lese-/Schreib-/Eigentümerrollen und ein Berechtigungsbericht. Keine Downtime.
- Audit: Wer hat was getan? (pgaudit, zentrales Logging) — Der Prüfer oder das Sicherheitsteam verlangt eine Aufzeichnung von DDL- und Rollenänderungen; Installation von pgaudit und Weiterleitung des Logs an einen zentralen Server. Ein Neustart ist erforderlich.
- Daten auf dem Datenträger verschlüsseln (LUKS / pgcrypto) — Gefordert ist Schutz gegen einen gestohlenen Datenträger oder ein gestohlenes Backup. PostgreSQL hat kein eingebautes TDE: LUKS auf Datenträgerebene (Downtime für den Umzug) oder pgcrypto auf Spaltenebene.
- Sicherheit der Backups (verschlüsselte Backups, Berechtigungen) — Backup-Dateien sind unverschlüsselt oder liegen in einem für alle lesbaren Verzeichnis; Repository-Verschlüsselung von pgBackRest oder pg_dump + GPG, .pgpass und Verzeichnisberechtigungen. Keine Downtime.
- Betriebssystemseite (Dienstkonto, Berechtigungen, Core Dumps, SELinux) — Das Konto postgres hat ein nutzbares Passwort, die Berechtigungen des Datenverzeichnisses sind zu offen, SELinux steht auf Permissive/Disabled. Die Core-Dump-Einstellung greift beim nächsten Neustart.
- Patches und Version: Bin ich auf einer unterstützten Version? — Prüft Version, Supportende und ausstehende Minor-Updates; zum Einspielen verweist er auf den Patch-Leitfaden. Schreibgeschützt.
Vor dem Start
- PostgreSQL … läuft, und du kannst dich als postgres vom Server selbst (sudo -iu postgres psql) ohne Passwort verbinden (local all postgres peer in pg_hba). Wurde mit dem PostgreSQL-Installationsleitfaden installiert, ist das bereits gegeben.
- Datenverzeichnis …, Konfigurationsverzeichnis …; psql und pg_dump liegen unter …. Sie stehen im PATH der Login-Shell des Benutzers postgres; beim Aufruf als root den vollständigen Pfad angeben.
- Zum Server sind zwei getrennte SSH-Sitzungen offen: In der einen setzt du die Schritte um, die andere (mit offenem sudo -iu postgres psql) dient zum Zurückdrehen, falls dich eine falsche Regel aussperrt. Teste nach jedem Schritt, der den Zugriff einschränkt, die neue Verbindung in einer dritten Sitzung; schließe die alten Sitzungen erst, wenn sie erfolgreich ist.
- Wartungsfenster: Für die gewählten Bereiche wird PostgreSQL neu gestartet (listen_addresses, shared_preload_libraries, Core-Dump-Limit, Datenträgerumzug). Das Anwendungsteam ist informiert.
- Du hast die Liste aller Anwendungen, die sich mit der Datenbank verbinden, samt Verbindungsdaten (Server-IPs, Benutzer, Treiberversionen). Bevor etwas eingeschränkt wird, beantwortet der Prüfschritt die Frage wer verbindet sich von wo; ein Client, der nicht auf der Liste steht, kann sich nach der Einschränkung nicht mehr verbinden.
- Es gibt ein aktuelles Backup mit getesteter Wiederherstellung (pgBackRest oder pg_dump). Die Härtung berührt keine Daten, aber Rollen-/Berechtigungsänderungen und der Datenträgerumzug sind anfällig für Fehler, die sich nicht rückgängig machen lassen.
Phasen der Anleitung
- Statusprüfung (schreibgeschützt) — Befunde innerhalb der Datenbank auflisten · Schema- und Funktionsbefunde in jeder Datenbank auflisten · Betriebssystemseite prüfen
- Vor dem Start: Rückfallpunkt — Kopie der aktuellen Konfiguration und der Rollen erstellen · Zusätzliches Konfigurationsverzeichnis (conf.d) aktivieren
- Berechtigungen — 1. Diagnose — Rollen, Eigentümerschaften und PUBLIC-Berechtigungen anzeigen
- Berechtigungen — 2. Sicherheitsnetz — Aktuelle Berechtigungen sichern
- Berechtigungen — 3. Umsetzung — Gruppenrollen und Login-Konten anlegen · Passwörter für die neuen Login-Konten setzen · Datenbank- und Schemaberechtigungen einrichten · Objekte des Anwendungskontos an die Eigentümerrolle übertragen · Berechtigungsbericht
- Berechtigungen — 4. Verifikation — Prüfen, dass das Anwendungskonto kein DDL ausführen, aber Daten schreiben kann
- Berechtigungen — 5. Nacharbeit — Migrationstool auf die Eigentümerrolle umstellen
- Authentifizierung — 1. Diagnose — Passwort-Hashes, Methoden und Konten anzeigen
- Authentifizierung — 2. Sicherheitsnetz — Treiberkompatibilität prüfen
- Authentifizierung — 3. Umsetzung — Neue Passwörter mit scram-sha-256 speichern · Einstellung laden und Passwörter der md5-Konten neu setzen · md5/password-Methode in pg_hba auf scram-sha-256 umstellen · Netzwerk-Logins für den Superuser postgres sperren · Persönliches DBA-Konto anlegen
- Authentifizierung — 4. Verifikation — Hashes und Abweisung von Superuser-Netzwerk-Logins prüfen · scram-Login vom Anwendungsserver und Abweisung von postgres
- Authentifizierung — 5. Nacharbeit — Ungenutzte und abgelaufene Konten überprüfen
- TLS — 1. Diagnose — Aktuellen SSL-Status und unverschlüsselte Clients anzeigen
- TLS — 2. Sicherheitsnetz — Zertifikatsverzeichnis vorbereiten
- TLS — 3. Umsetzung — Test-CA und Serverzertifikat erstellen · Schlüssel und Zertifikatsanforderung (CSR) erstellen · Signiertes Zertifikat und CA-Kette einspielen · Zertifikat, Schlüssel und Kette prüfen · TLS auf dem Server aktivieren · Einstellungen laden und prüfen, dass TLS aktiv ist …
- TLS — 4. Verifikation — Prüfen, dass unverschlüsselte Verbindungen abgelehnt werden
- TLS — 5. Nacharbeit: Zertifikatserneuerung — Verfahren zur Zertifikatserneuerung
- Netzwerk — 1. Diagnose: Wer verbindet sich von wo? — Listen-Adresse, pg_hba-Regeln und aktive Clients anzeigen
- Netzwerk — 2. Sicherheitsnetz — Rückfallsitzung offen halten
- Netzwerk — 3. Umsetzung — Listen-Adresse einschränken · pg_hba.conf mit minimalem Zugriff neu schreiben · Regeln prüfen und laden · Port in der Firewall nur für erlaubte Netze öffnen · PostgreSQL für die Listen-Adresse neu starten
- Netzwerk — 4. Verifikation — Erlaubte und abgewiesene Verbindung vom Anwendungsserver testen
- Netzwerk — 5. Nacharbeit — Abgewiesene Verbindungen überwachen
- Audit — 1. Diagnose — Audit- und Log-Einstellungen anzeigen
- Audit — 2. Sicherheitsnetz — Ort und freien Platz der Log-Platte prüfen
- Audit — 3. Umsetzung — pgaudit-Paket installieren · pgaudit zu den vorgeladenen Bibliotheken hinzufügen und Einstellungen schreiben · Neu starten, um pgaudit zu aktivieren · pgaudit-Erweiterung anlegen · Log an den zentralen Server weiterleiten (rsyslog) · Aufbewahrung der lokalen Audit-Datei (logrotate) …
- Audit — 4. Verifikation — Eine DDL- und eine Rollenänderung ausführen und im Log sehen
- Audit — 5. Nacharbeit — Abschalten des Audits überwachen
- Backup — 1. Diagnose — Verschlüsselungsstatus und Berechtigungen der Backups anzeigen
- Backup — 2. Sicherheitsnetz — Ablageort für den Verschlüsselungsschlüssel vorbereiten
- Backup — 3. Umsetzung — Neues verschlüsseltes Repository definieren · Verschlüsseltes Repository anlegen und erstes Vollbackup erstellen · Öffentlichen GPG-Schlüssel auf dem Server importieren · Skript für verschlüsselte Backups · Backup-Verzeichnis, Berechtigungen und manueller Test · Verschlüsseltes Backup zeitlich planen (cron) …