Absicherung von PostgreSQL-Verbindungen mit SSL/TLS-Konfiguration: Ein umfassender Leitfaden

Absicherung von PostgreSQL-Verbindungen mit SSL/TLS-Konfiguration: Ein vollständiger Leitfaden

In der heutigen vernetzten digitalen Landschaft ist die Sicherung von Daten während der Übertragung von größter Bedeutung. PostgreSQL, eine leistungsstarke Open-Source-Relationale-Datenbank, bietet robuste Mechanismen zur Verschlüsselung von Verbindungen mithilfe von SSL/TLS. Dieser Leitfaden bietet eine umfassende Anleitung zur Konfiguration von PostgreSQL-Servern und -Clients, um die SSL/TLS-Verschlüsselung zu erzwingen und sensible Informationen vor Abhören und Man-in-the-Middle-Angriffen in nicht vertrauenswürdigen Netzwerken zu schützen. Die Implementierung dieser Sicherheitsmaßnahmen ist entscheidend für die Wahrung der Datenintegrität, die Einhaltung strenger Sicherheitsstandards und den Aufbau von Vertrauen bei Ihren Benutzern.

Dieser Artikel behandelt die wesentlichen Schritte, von der Erstellung oder Beschaffung von SSL-Zertifikaten über die Konfiguration von PostgreSQL zur Verwendung dieser Zertifikate bis hin zur Einrichtung von Clients für sichere Verbindungen. Wir werden uns mit den erforderlichen Konfigurationsparametern befassen und praktische Beispiele geben, um Sie bei der effektiven Implementierung dieser Sicherheitsverbesserungen zu unterstützen.

Verständnis von SSL/TLS in PostgreSQL

SSL/TLS (Secure Sockets Layer/Transport Layer Security) ist ein kryptografisches Protokoll, das zur Gewährleistung der Kommunikationssicherheit über ein Computernetzwerk entwickelt wurde. Wenn es auf PostgreSQL angewendet wird, verschlüsselt es die zwischen dem Datenbankserver und seinen Clients ausgetauschten Daten. Dies verhindert, dass unbefugte Parteien sensible Informationen wie Anmeldeinformationen, Finanzdaten oder persönliche Angaben abfangen und lesen.

PostgreSQL unterstützt zwei Hauptmodi für SSL/TLS:

ssl=on: Ermöglicht SSL-Verbindungen, erfordert diese aber nicht. Clients können sich entweder über SSL oder über Nicht-SSL-Verbindungen verbinden.
ssl=prefer: Versucht, eine SSL-Verbindung herzustellen, fällt aber auf eine Nicht-SSL-Verbindung zurück, falls dies fehlschlägt.
ssl=require: Erfordert SSL-Verbindungen. Wenn keine SSL-Verbindung hergestellt werden kann, wird die Client-Verbindung abgelehnt.

Die Erzwingung von ssl=require ist die sicherste Option zum Schutz von Daten während der Übertragung.

Voraussetzungen für die SSL/TLS-Konfiguration

Bevor Sie mit der Konfiguration von PostgreSQL für SSL/TLS beginnen, stellen Sie sicher, dass Sie Folgendes haben:

OpenSSL installiert: Das OpenSSL-Toolkit ist unerlässlich für die Erstellung und Verwaltung von SSL-Zertifikaten. Es ist normalerweise auf Linux- und macOS-Systemen vorinstalliert. Für Windows müssen Sie es möglicherweise separat herunterladen und installieren.
Zugriff auf PostgreSQL-Konfigurationsdateien: Sie benötigen administrative Berechtigungen, um die Dateien postgresql.conf und pg_hba.conf zu ändern.
Verständnis von Zertifizierungsstellen (CAs): Obwohl Sie selbstsignierte Zertifikate für Tests erstellen können, sollten Produktionsumgebungen idealerweise Zertifikate verwenden, die von einer vertrauenswürdigen Zertifizierungsstelle (CA) oder einer internen Unternehmens-CA signiert wurden.

Serverseitige SSL/TLS-Konfiguration

Die serverseitige Konfiguration umfasst die Aktivierung von SSL, die Angabe des Speicherorts der SSL-Zertifikate und Schlüssel sowie die Konfiguration der Client-Authentifizierung.

1. Erstellung oder Beschaffung von SSL-Zertifikaten und Schlüsseln

Es gibt zwei Hauptmethoden, um SSL-Zertifikate für Ihren PostgreSQL-Server zu erhalten:

Selbstsignierte Zertifikate (für Tests/Entwicklung): Diese werden mit OpenSSL erstellt und von externen Clients standardmäßig nicht als vertrauenswürdig eingestuft. Sie eignen sich für die erste Einrichtung und interne Tests.
Zertifikate einer Zertifizierungsstelle (CA) (für die Produktion): Besorgen Sie sich Zertifikate von einer vertrauenswürdigen öffentlichen CA (z. B. Let's Encrypt, DigiCert) oder einer internen Unternehmens-CA. Dies stellt sicher, dass Clients die Identität des Servers überprüfen können.

Erstellung selbstsignierter Zertifikate mit OpenSSL:

Dies ist ein gängiger Ansatz für Entwicklungs- und interne Umgebungen. Führen Sie die folgenden Befehle auf Ihrem PostgreSQL-Server oder einem Rechner mit OpenSSL aus:

Erstellen eines Verzeichnisses für Zertifikate: Es ist gute Praxis, Zertifikate organisiert aufzubewahren.
bash sudo mkdir -p /etc/postgresql/ssl sudo chown postgres:postgres /etc/postgresql/ssl cd /etc/postgresql/ssl
Generieren des privaten Server-Schlüssels: Dieser Schlüssel sollte geheim gehalten werden.
bash sudo openssl genrsa -des3 -out server.key 2048
Sie werden aufgefordert, eine Passphrase einzugeben. Merken Sie sich diese Passphrase, da Sie sie benötigen, wenn PostgreSQL startet.
Entfernen der Passphrase (optional, aber für automatische Neustarts empfohlen): Für den automatischen Start ohne manuelle Passphraseneingabe entfernen Sie die Passphrase. Seien Sie äußerst vorsichtig, da jeder, der Zugriff auf diese Datei hat, Ihren Server imitieren kann.
bash sudo openssl rsa -in server.key -out server.key
Erstellen einer Server-Zertifikatsanforderung (CSR): Diese enthält Informationen über Ihren Server.
bash sudo openssl req -new -key server.key -out server.csr
Sie werden nach Informationen wie Ländernamen, Bundesland, Ort, Organisationsname, Common Name (dies sollte der Hostname oder die IP-Adresse Ihres Servers sein) und einer E-Mail-Adresse gefragt.
Signieren des Zertifikats mit Ihrer eigenen CA (für den internen Gebrauch):
- Erstellen eines Root-CA-Privatschlüssels und -Zertifikats (falls Sie keines haben):
  bash # Generieren des CA-Privatschlüssels sudo openssl genrsa -des3 -out root.key 2048 # Erstellen des CA-Zertifikats (gültig für 3650 Tage) sudo openssl req -new -x509 -days 3650 -key root.key -out root.crt
- Signieren der Server-CSR mit der CA: Dies erstellt das vertrauenswürdige Serverzertifikat.
  bash sudo openssl x509 -req -days 365 -in server.csr -CA root.crt -CAkey root.key -set_serial 01 -out server.crt
Berechtigungen festlegen: Stellen Sie sicher, dass der PostgreSQL-Benutzer diese Dateien lesen kann.
bash sudo chown postgres:postgres server.key server.crt root.crt sudo chmod 600 server.key sudo chmod 644 server.crt root.crt

Verwendung von Zertifikaten einer öffentlichen/Unternehmens-CA:

Wenn Sie Zertifikate von einer CA beziehen, erhalten Sie typischerweise:

server.crt: Das öffentliche Zertifikat Ihres Servers.
server.key: Der private Schlüssel Ihres Servers.
root.crt (oder ähnlich): Das Stammzertifikat der CA (und möglicherweise Zwischenzertifikate).

Speichern Sie diese Dateien in einem sicheren Verzeichnis (z. B. /etc/postgresql/ssl/) und stellen Sie sicher, dass der PostgreSQL-Benutzer Leseberechtigungen hat.

2. Konfiguration von `postgresql.conf`

Bearbeiten Sie Ihre Datei postgresql.conf (normalerweise im Datenverzeichnis von PostgreSQL), um SSL zu aktivieren und die Pfade zu den Zertifikatsdateien anzugeben.

#------------------------------------------------------------------------------
# SSL
#------------------------------------------------------------------------------

ssl = on

# Diese sind alle im PEM-Format und werden ignoriert, wenn Server-Schlüssel/-Zertifikat
# nicht konfiguriert sind. Standardmäßig werden die Dateien im Datenverzeichnis des Servers erwartet.
# Alternativ können sie als vollständige Pfade angegeben werden.
ssl_cert_file = '/etc/postgresql/ssl/server.crt'     # (Dateiname bei Bedarf ändern)
ssl_key_file = '/etc/postgresql/ssl/server.key'      # (Dateiname bei Bedarf ändern)
ssl_ca_file = '/etc/postgresql/ssl/root.crt'         # (optional, für die Überprüfung von Client-Zertifikaten)

# Optional: Cipher-Liste bei Bedarf angeben
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL'

# Optional: Überprüfung von Client-Zertifikaten aktivieren
# ssl_ca_file muss auf eine Datei gesetzt werden, die das CA-Zertifikat(e) enthält, dem vertraut werden soll
#ssl_crl_file = ''
#ssl_crl_dir = ''

ssl = on: Aktiviert die SSL-Unterstützung auf dem Server.
ssl_cert_file: Pfad zum öffentlichen Zertifikat des Servers.
ssl_key_file: Pfad zum privaten Schlüssel des Servers.
ssl_ca_file: Pfad zum CA-Zertifikat (wenn Sie Client-Zertifikate überprüfen möchten oder wenn Ihr Serverzertifikat von einer benutzerdefinierten CA signiert wurde).

3. Konfiguration von `pg_hba.conf` zur Erzwingung von SSL

Die Datei pg_hba.conf steuert die Client-Authentifizierung. Sie müssen Einträge ändern, um SSL-Verbindungen zu erzwingen.

Standardmäßig sehen Einträge in pg_hba.conf wie folgt aus:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
# IPv4 lokale Verbindungen:
host    all             all             127.0.0.1/32            scram-sha-256
# IPv6 lokale Verbindungen:
host    all             all             ::1/128                 scram-sha-256

Um SSL zu erzwingen, ändern Sie die host-Einträge in hostssl:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
# IPv4 lokale Verbindungen:
hostssl all             all             127.0.0.1/32            scram-sha-256
# IPv6 lokale Verbindungen:
hostssl all             all             ::1/128                 scram-sha-256

# Beispiel für externen Netzwerkzugriff – erfordert SSL
hostssl all             all             0.0.0.0/0               scram-sha-256
hostssl all             all             ::/0                    scram-sha-256

hostssl: Dieser Eintragstyp erfordert SSL-Verbindungen. Jeder Verbindungsversuch ohne SSL wird abgelehnt.
hostnossl: Dieser Eintragstyp verbietet explizit SSL-Verbindungen.
host: Erlaubt sowohl SSL- als auch Nicht-SSL-Verbindungen (dies ist die Standardeinstellung und weniger sicher).

4. Neustart des PostgreSQL-Servers

Nach der Änderung von postgresql.conf und pg_hba.conf müssen Sie den PostgreSQL-Dienst neu starten, damit die Änderungen wirksam werden.

# Für Systeme, die systemd verwenden (die meisten modernen Linux-Distributionen)
sudo systemctl restart postgresql

# Für Systeme, die init.d verwenden
sudo service postgresql restart

Clientseitige SSL/TLS-Konfiguration

Clients müssen ebenfalls so konfiguriert werden, dass sie sich sicher verbinden. Dies beinhaltet die Angabe von Verbindungsparametern, die mögliche Bereitstellung von Client-Zertifikaten und die Überprüfung des Serverzertifikats.

1. Parameter der Verbindungszeichenfolge

Beim Verbinden über psql oder jede PostgreSQL-Clientbibliothek können Sie SSL-Parameter in der Verbindungszeichenfolge oder als einzelne Optionen angeben.

Grundlegende SSL-Verbindung (nur Serverauthentifizierung):

psql "sslmode=require host=Ihr_Server_Hostname dbname=Ihre_DB user=Ihr_Benutzer"

sslmode: Steuert das SSL-Verhalten des Clients.
- disable: Nur Nicht-SSL-Verbindungen zulassen.
- allow: Nicht-SSL zulassen, aber SSL bevorzugen, wenn der Server es unterstützt.
- prefer (Standard): SSL bevorzugen, aber Nicht-SSL zulassen, wenn SSL fehlschlägt.
- require: Nur SSL-Verbindungen zulassen. Wenn der Server kein SSL unterstützt, schlägt die Verbindung fehl.
- verify-ca: Nur SSL-Verbindungen zulassen und überprüfen, ob das Serverzertifikat von einer vertrauenswürdigen CA signiert wurde. Der Parameter sslrootcert muss gesetzt sein.
- verify-full: Nur SSL-Verbindungen zulassen, das Serverzertifikat gegen eine vertrauenswürdige CA überprüfen und überprüfen, ob der Serverhostname mit dem Common Name (CN) oder dem Subject Alternative Name (SAN) des Zertifikats übereinstimmt.

Überprüfung des Serverzertifikats (verify-ca oder verify-full):

Für erhöhte Sicherheit sollten Clients die Identität des Servers überprüfen. Dies erfordert, dass der Client der CA vertraut, die das Serverzertifikat signiert hat.

CA-Zertifikat beschaffen: Holen Sie die Datei root.crt (oder das entsprechende CA-Zertifikat) ab, die zum Signieren des Serverzertifikats verwendet wurde.
sslrootcert angeben: Teilen Sie dem Client mit, wo dieses CA-Zertifikat zu finden ist.

psql "sslmode=verify-full host=Ihr_Server_Hostname dbname=Ihre_DB user=Ihr_Benutzer sslrootcert=/pfad/zu/Ihrem/root.crt"

2. Client-Zertifikate (Gegenseitige Authentifizierung)

Für ein noch höheres Sicherheitsniveau können Sie eine gegenseitige Authentifizierung implementieren, bei der der Server auch die Identität des Clients mithilfe von Client-Zertifikaten überprüft.

Generieren von Client-Zertifikaten:

Ähnlich wie bei Serverzertifikaten benötigen Sie einen privaten Clientschlüssel und ein Clientsertifikat, das von einer von der Server vertrauten CA signiert wurde (oft dieselbe CA wie für das Serverzertifikat).

Generieren des privaten Clientschlüssels:
bash openssl genrsa -des3 -out client.key 2048
Erstellen der Client-CSR:
bash openssl req -new -key client.key -out client.csr
Geben Sie Details an und stellen Sie sicher, dass der Common Name für den Client eindeutig ist.
Signieren der Client-CSR mit CA:
bash sudo openssl x509 -req -days 365 -in client.csr -CA root.crt -CAkey root.key -set_serial <eindeutige_seriennummer> -out client.crt
Berechtigungen festlegen:
bash chmod 600 client.key chmod 644 client.crt

Konfiguration von `pg_hba.conf` für die Client-Zertifikatsauthentifizierung:

Auf dem Server müssen Sie pg_hba.conf so konfigurieren, dass die Client-Zertifikatsauthentifizierung akzeptiert wird. Hierfür wird häufig die Authentifizierungsmethode cert verwendet.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# SSL und Client-Zertifikatsauthentifizierung für spezifischen Benutzer/DB erfordern
hostssl all             Ihr_Benutzer       Ihre_Client_IP/32       cert map=Ihre_Zertifikat_Map

Möglicherweise müssen Sie auch eine Zertifikatszuordnungsdatei (cert_map-Option) definieren, wenn Sie bestimmte Client-Zertifikatsdetails (wie Subject oder SubjectAltName) PostgreSQL-Benutzern zuordnen möchten. Weitere Einzelheiten zur cert-Authentifizierung und zur Einrichtung der Zertifikatszuordnung finden Sie in der PostgreSQL-Dokumentation.

Konfigurieren des Clients zur Verwendung von Zertifikaten:

Aktualisieren Sie die Verbindungszeichenfolge des Clients, um Pfade zu seinem Zertifikat und Schlüssel einzuschließen:

psql "sslmode=verify-full host=Ihr_Server_Hostname dbname=Ihre_DB user=Ihr_Benutzer \nsslrootcert=/pfad/zu/Ihrem/root.crt sslcert=/pfad/zu/Ihrem/client.crt sslkey=/pfad/zu/Ihrem/client.key"

Best Practices und Tipps

Verwenden Sie verify-full für sslmode: Versuchen Sie auf der Clientseite immer, verify-full zu verwenden, um Man-in-the-Middle-Angriffe zu verhindern.
Schützen Sie private Schlüssel: Stellen Sie sicher, dass private Schlüssel (.key-Dateien) strenge Dateiberechtigungen (z. B. chmod 600) haben und nur vom PostgreSQL-Benutzer auf dem Server und dem verbindenden Benutzer auf dem Client gelesen werden können.
Zertifikate regelmäßig erneuern: Zertifikate haben Ablaufdaten. Implementieren Sie einen Prozess zur Erneuerung, bevor sie ablaufen, um Verbindungsunterbrechungen zu vermeiden.
Zentralisierte Zertifikatsverwaltung: Ziehen Sie bei größeren Bereitstellungen ein Zertifikatsverwaltungssystem in Betracht oder automatisieren Sie die Ausstellung und Erneuerung von Zertifikaten.
Protokolle überwachen: Überprüfen Sie die PostgreSQL-Protokolle auf SSL-bezogene Fehler beim Start oder bei Verbindungsversuchen.
Dokumentation: Schlagen Sie in der offiziellen PostgreSQL-Dokumentation die aktuellsten Parameter und erweiterten Konfigurationsoptionen für Ihre spezifische PostgreSQL-Version nach.

Fazit

Die Konfiguration von SSL/TLS für PostgreSQL-Verbindungen ist ein entscheidender Schritt zur Sicherung Ihrer Datenbankinfrastruktur. Durch das Aktivieren von SSL auf dem Server, das Erzwingen von ssl=require oder hostssl in pg_hba.conf und die Konfiguration der Clients mit geeigneten sslmode-Einstellungen (idealerweise verify-full) verbessern Sie die Sicherheit der über Ihr Netzwerk übertragenen Daten erheblich. Die Implementierung einer gegenseitigen Authentifizierung mit Client-Zertifikaten fügt eine weitere robuste Sicherheitsebene hinzu. Obwohl die anfängliche Einrichtung komplex erscheinen mag, machen die langfristigen Vorteile des Datenschutzes und der Compliance sie zu einer unverzichtbaren Praxis für jede PostgreSQL-Bereitstellung.