Wichtige Konfigurationseinstellungen zur Sicherung Ihrer PostgreSQL-Datenbank

Die Sicherung von PostgreSQL beginnt mit einer einfachen Frage: Wer darf sich verbinden, von wo und mit welcher Authentifizierungsmethode? Wenn pg_hba.conf zu weit gefasst ist oder der Server auf mehr Schnittstellen lauscht als nötig, hat Ihre Datenbank eine größere Angriffsfläche als notwendig.

Diese Anleitung behandelt die PostgreSQL-Sicherheitseinstellungen, die Sie zuerst überprüfen sollten: pg_hba.conf, SCRAM-Passwortauthentifizierung, TLS, Netzwerk-Listener, Rollenberechtigungen und Logs.

1. Härten der Client-Authentifizierung mit `pg_hba.conf`

Die Host-basierte Authentifizierungsdatei (pg_hba.conf) legt fest, welche Hosts sich verbinden können, als welche PostgreSQL-Benutzer sie sich verbinden können, auf welche Datenbanken sie zugreifen können und – am wichtigsten – welche Authentifizierungsmethode für diese Verbindung erforderlich ist.

Verstehen der `pg_hba.conf`-Struktur

Jede Zeile in pg_hba.conf folgt einem bestimmten Format:

TYP DATENBANK BENUTZER ADRESSE METHODE [OPTIONEN]

TYP: Verbindungstyp (z. B. local, host, hostnossl, hostssl).
DATENBANK: Ziel-Datenbankname(n).
BENUTZER: Ziel-Datenbankrolle(n).
ADRESSE: IP-Adressbereich des Clients.
METHODE: Authentifizierungsmechanismus (z. B. scram-sha-256, md5, reject, trust).

Best Practices für Authentifizierungsmethoden

Verwenden Sie die trust-Methode niemals in der Produktion, da sie jedem, der die Verbindungskriterien erfüllt, die Verbindung ohne Passwort erlaubt. Die empfohlenen modernen Authentifizierungsmethoden sind:

Empfohlen: `scram-sha-256`

SCRAM (Salted Challenge Response Authentication Mechanism) bietet erhebliche Verbesserungen gegenüber älteren Passwortmethoden wie md5, indem es stärkeres Hashing verwendet und Replay-Angriffe verhindert. Dies sollte Ihre Standardwahl für Remote-Verbindungen sein.

# Erzwingen von SCRAM für Remote-Verbindungen aus einem Anwendungs-Subnetz
host    appdb   app_user 10.20.30.0/24  scram-sha-256

Setzen Sie password_encryption = 'scram-sha-256' in postgresql.conf, bevor Sie Passwörter erstellen oder rotieren. Vorhandene Passwörter, die mit älteren Hashes gespeichert wurden, werden nicht automatisch konvertiert; setzen Sie sie zurück, nachdem Sie SCRAM aktiviert haben.

password_encryption = 'scram-sha-256'

Vermeiden Sie breite Regeln wie diese, es sei denn, eine andere Netzwerkkontrolle schränkt den Zugriff bereits ein:

host    all     all     0.0.0.0/0       scram-sha-256

Lokale Verbindungen

Verwenden Sie für Verbindungen, die vom Server selbst ausgehen (z. B. Anwendungen, die auf demselben Rechner laufen), lokale Sockets. Die sicherste Einstellung ist oft peer (für Unix-Domain-Sockets) oder scram-sha-256, wenn Sockets deaktiviert oder eingeschränkt sind.

# Verwenden Sie Peer-Authentifizierung für lokale Verbindungen über Unix-Socket
local   all     all             peer

Explizites Ablehnen von Verbindungen

Verwenden Sie die reject-Methode, um Verbindungen von gefährlichen oder nicht vertrauenswürdigen Netzwerken explizit zu blockieren.

# Blockieren aller Verbindungen aus einem bekannten unsicheren IP-Bereich
host    all     all     192.168.1.0/24  reject

Handlungsempfehlung: Laden Sie PostgreSQL nach Änderungen an pg_hba.conf neu, damit die Änderungen wirksam werden, z. B. mit sudo systemctl reload postgresql oder SELECT pg_reload_conf();.

2. Implementieren von SSL/TLS-Verschlüsselung

Um zu verhindern, dass sensible Daten (einschließlich Passwörter) über das Netzwerk abgefangen werden, ist die Erzwingung von SSL/TLS-Verschlüsselung für alle Remote-Verbindungen obligatorisch.

Konfiguration in `postgresql.conf`

Stellen Sie sicher, dass diese Parameter in Ihrer Hauptkonfigurationsdatei korrekt gesetzt sind:

ssl = on: Aktiviert SSL-Unterstützung global.
ssl_cert_file: Pfad zur Serverzertifikatsdatei (z. B. server.crt).
ssl_key_file: Pfad zur privaten Serverschlüsseldatei (z. B. server.key).

Erzwingen von SSL in `pg_hba.conf`

Um Clients zur Verwendung von SSL zu zwingen, ändern Sie den Verbindungstyp in pg_hba.conf von host zu hostssl:

# Nur Verbindungen über SSL/TLS zulassen
hostssl all     all     0.0.0.0/0       scram-sha-256

hostssl stimmt nur mit SSL-Verbindungen überein. Stellen Sie sicher, dass Sie nicht auch eine spätere oder frühere host-Regel haben, die denselben Benutzern ohne TLS erlaubt. Um die Richtlinie deutlich zu machen, fügen Sie eine Ablehnungsregel für Nicht-SSL-Verbindungen hinzu:

hostnossl all    all     0.0.0.0/0       reject

3. Minimieren der Angriffsfläche

Sicherheit beinhaltet die Reduzierung der Exposition des Datenbankservers gegenüber externen Bedrohungen. Dies wird hauptsächlich durch Netzwerkkonfiguration und Deaktivieren unnötiger Funktionen erreicht.

Einschränken der Netzwerk-Listener-Adresse

PostgreSQL lauscht standardmäßig oft auf localhost, aber gepackte Bereitstellungen und verwaltete Images können abweichen. Konfigurieren Sie es explizit so, dass es nur auf der spezifischen Schnittstelle lauscht, die Zugriff benötigt, oder belassen Sie es auf localhost, wenn nur lokale Anwendungen eine Verbindung herstellen.

In postgresql.conf:

# Nur auf localhost (127.0.0.1) lauschen, wenn möglich
listen_addresses = 'localhost'

# ODER, nur auf einer bestimmten privaten Netzwerkschnittstelle lauschen
# listen_addresses = '192.168.1.10'

Sicherheitswarnung: Wenn listen_addresses auf * gesetzt ist, werden alle Schnittstellen verwendet. Stellen Sie sicher, dass pg_hba.conf streng kontrolliert, welche IP-Bereiche sich verbinden können.

Deaktivieren unnötiger Erweiterungen und Funktionen

Jede aktivierte Erweiterung fügt potenzielle Komplexität und Angriffsvektoren hinzu. Überprüfen Sie regelmäßig installierte Erweiterungen und entfernen Sie alle, die nicht aktiv für Ihre Produktionslast verwendet werden. Dies minimiert die gesamte Angriffsfläche.

Passwortsicherheit und Rollen

Stellen Sie sicher, dass alle administrativen Rollen (wie der Standard-postgres-Benutzer) starke, komplexe Passwörter haben, die mit ALTER USER gesetzt werden:

ALTER USER postgres WITH PASSWORD 'YourStrongAndComplexPassword123!';

Wenden Sie das Prinzip der minimalen Berechtigungen an: Anwendungsbenutzer sollten nur SELECT-, INSERT-, UPDATE- und DELETE-Berechtigungen auf den spezifischen Tabellen haben, die sie benötigen, anstatt Superuser-Status.

4. Audit- und Logging-Konfiguration

Obwohl es sich nicht um einen Zugriffskontrollmechanismus handelt, ist ein robustes Logging entscheidend für die Erkennung und Untersuchung von Sicherheitsvorfällen. Konfigurieren Sie Logging-Parameter in postgresql.conf, um relevante Ereignisse zu erfassen.

Wichtige Einstellungen für Sicherheitsaudits:

log_statement = 'ddl' oder 'all': Protokolliert alle Data Definition Language (DDL)-Befehle, wie CREATE TABLE und ALTER USER. Verwenden Sie 'all' vorsichtig, da es ein hohes Log-Volumen erzeugen und sensible Abfragetexte erfassen kann.
log_connections = on: Protokolliert jeden erfolgreichen Verbindungsversuch.
log_disconnections = on: Protokolliert, wenn Clients die Verbindung trennen.
log_duration = on: Protokolliert die Ausführungszeit aller Anweisungen, was manchmal ungewöhnliche Aktivitätsmuster aufdecken kann.

Durch die Kombination strenger Zugriffsregeln in pg_hba.conf, erzwungener Verschlüsselung über SSL, einer eingeschränkten Listener-Adresse und umfassendem Logging schaffen Sie eine solide Grundlage für die Sicherung Ihrer PostgreSQL-Bereitstellung.

Wesentliche Sicherheitsschritte

Aktualisieren Sie pg_hba.conf: Verwenden Sie scram-sha-256 oder peer für Authentifizierungsmethoden.
Erzwingen Sie Verschlüsselung: Setzen Sie ssl = on in postgresql.conf und verwenden Sie hostssl-Einträge in pg_hba.conf.
Schränken Sie das Lauschen ein: Konfigurieren Sie listen_addresses nur auf notwendige Schnittstellen und vermeiden Sie wenn möglich den Standardwert *.
Erzwingen Sie minimale Berechtigungen: Beschränken Sie Datenbankrollen auf nur die Berechtigungen, die für ihre Funktion unbedingt erforderlich sind.
Laden Sie die Konfiguration neu: Laden Sie PostgreSQL nach Änderungen an Sicherheitsdateien immer neu oder starten Sie es neu, um die Änderungen anzuwenden.

Diese Einstellungen sind die Grundlage. Nachdem Sie sie angewendet haben, testen Sie von einem erlaubten Client, testen Sie von einem blockierten Client und überprüfen Sie, ob die Logs das erwartete Verbindungsverhalten zeigen.