DBAtlas · Atlas für Datenbankbetrieb

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) …
Schritt-für-Schritt-Plan für Ihre Umgebung öffnen →