dozent.net
Projekt anfragen
Info

PostgreSQL Security und Härtung — Seminar für DBAs und Sicherheitsverantwortliche

PostgreSQL zu härten heißt, jede Schicht einer Instanz so einzustellen, dass nur vorgesehene Verbindungen, Personen und Abfragen an die Daten kommen — vom Netzwerk über Anmeldung und Rechte bis zu Protokoll, Verschlüsselung und Sicherung. Im Seminar nimmst du den Ist-Stand einer Instanz auf, sicherst sie Schicht für Schicht ab und dokumentierst die Maßnahmen für Audit und Betrieb. Dauer: 2 Tage, optional 3 Tage mit Praxistag.

Die Schichten, an denen eine PostgreSQL-Instanz gehärtet wird Sechs Schichten von außen nach innen: Netzwerk und TLS, Anmeldung, Rollen und Rechte, Code in der Datenbank, Daten mit Row-Level Security und Verschlüsselung, und darunter Betriebssystem, Sicherungen und Protokolle. Jede Schicht ist eine eigene Hürde; wer eine auslässt, etwa über eine Sicherung im Klartext, umgeht die Schichten darüber. Das Seminar behandelt die Schichten von außen nach innen. Netzwerk und TLS — wer kommt überhaupt an Anmeldung — SCRAM, Zertifikat, OAuth, Kerberos Rollen und Rechte — Least Privilege Code in der Datenbank — Funktionen, Extensions Daten — Row-Level Security, Verschlüsselung Betriebssystem, Sicherungen, Protokolle von außen nach innen
Abbildung 1: Das Seminar behandelt die Schichten von außen nach innen. Die unterste wird oft übersehen, dabei umgeht eine unverschlüsselte Sicherung alle Schichten darüber.

Für wen ist dieses Seminar

Für PostgreSQL-Administratoren, die eine Instanz für einen Audit oder nach einem Sicherheitsvorfall belastbar absichern müssen. Für Security Engineers und Informationssicherheitsbeauftragte, die wissen wollen, welche Stellschrauben PostgreSQL bietet und wie man ihren Zustand prüft. Für Datenschutzbeauftragte und Compliance-Verantwortliche, die Zugriffsprotokolle, Verschlüsselung und Mandantentrennung beurteilen müssen. Und für Entwickler mit DBA-Verantwortung, deren Anwendung Rollen, Row-Level Security oder Funktionen mit erweiterten Rechten nutzt.

Das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.

Was du mitbringen solltest

Du solltest PostgreSQL schon administriert haben: Installation, Konfigurationsdateien, Benutzer anlegen, pg_hba.conf mindestens einmal geändert. Dazu kommt ein Grundverständnis von Netzwerk und TLS — Zertifikat, Zertifizierungsstelle, Port, Firewall. Wer die Grundlagen des Betriebs erst aufbauen will, beginnt mit PostgreSQL Administration.

Geschult wird auf der jeweils aktuellen Version; bei Inhouse-Seminaren gern auch auf der Version, die ihr im Einsatz habt.

Inhalte im Überblick

Jeder Themenblock beginnt mit einer Prüfabfrage oder einem Werkzeug, das den Ist-Stand zeigt. Danach folgen die Einstellungen mit Begründung und Nebenwirkungen, am Ende läuft dieselbe Prüfung noch einmal. Geübt wird an einer Übungsinstanz mit typischen Schwachstellen gewachsener Installationen, die im Lauf des Seminars nacheinander behoben werden.

Ablauf eines Themenblocks: Ist-Stand, Absichern, Kontrolle Zuerst zeigt eine Abfrage oder ein Werkzeug den Ist-Stand als Befundliste. Dann folgt die Änderung mit Begründung und Nebenwirkungen. Zum Schluss läuft dieselbe Prüfung erneut, das Ergebnis geht in den Härtungsplan. Danach folgt die nächste Schicht. Ist-Stand Abfrage, Benchmark, Befundliste Absichern Änderung mit Begründung und Nebenwirkung Kontrolle gleiche Prüfung erneut, Eintrag im Härtungsplan nächste Schicht
Abbildung 2: Am Ende jedes Themenblocks steht dieselbe Prüfung wie am Anfang. Ihr Ergebnis geht in den Härtungsplan und dient im Audit als Beleg.

Bestandsaufnahme und Bedrohungsmodell

  • Angriffsflächen einer Instanz: Netz, Anmeldung, Rechte, Code in der Datenbank, Betriebssystem, Sicherungen
  • Bedrohungsmodell für die eigene Umgebung: wer greift von wo mit welchem Ziel zu
  • Ist-Stand automatisiert erheben: CIS PostgreSQL Benchmark, DISA STIG, Security Assessment mit pgdsat
  • Die Konfiguration als Prüfquelle: pg_settings, pg_file_settings, pg_hba_file_rules, pg_ident_file_mappings
  • Patch-Stand: Minor Releases, Support-Ende einer Hauptversion, Sicherheitsmeldungen (CVE) verfolgen

Netzwerk, Verbindungen und TLS

  • listen_addresses, Unix-Domain-Sockets (unix_socket_permissions, unix_socket_group) und Firewall
  • TLS erzwingen: hostssl, ssl_min_protocol_version auf TLS 1.3, ssl_ciphers, ssl_tls13_ciphers, ssl_groups
  • Zertifikate verwalten: eigene CA, Sperrlisten (CRL), Rotation per Reload ohne Neustart, Schlüssel mit ssl_passphrase_command
  • Client-Seite: sslmode=verify-full, sslrootcert=system, sslnegotiation=direct, require_auth gegen Downgrade
  • Verbindungsgrenzen: max_connections, reserved_connections, superuser_reserved_connections, CONNECTION LIMIT je Rolle
  • Brute Force und hängende Sitzungen: authentication_timeout, auth_delay, idle_session_timeout, idle_in_transaction_session_timeout
  • Pooler und Hochverfügbarkeit in der Kette: PgBouncer mit TLS und SCRAM, REST-Schnittstelle von Patroni absichern

Authentifizierung

  • pg_hba.conf lesen wie eine Firewall: Reihenfolge, Include-Dateien, reguläre Ausdrücke, reject-Regeln
  • SCRAM-SHA-256 statt MD5: password_encryption, Umstellung im laufenden Betrieb, Abkündigung von MD5
  • Zertifikatsbasierte Anmeldung: cert, clientcert=verify-full, Benutzer-Mapping in pg_ident.conf
  • Single Sign-on mit OAuth 2.0 / OpenID Connect (OIDC) über ein Validator-Modul — etwa an Entra ID oder Keycloak
  • Kerberos/GSSAPI gegen Active Directory, verschlüsselt per hostgssenc
  • LDAP und RADIUS als Altlast: Risiken, Ablösewege
  • Passwortrichtlinien: passwordcheck, credcheck, VALID UNTIL, Ablaufwarnung
  • Kurzlebige Zugangsdaten statt gespeicherter Passwörter: HashiCorp Vault bzw. OpenBao (Database Secrets Engine), IAM-Token bei Cloud-Diensten
  • Server-zu-Server ohne hinterlegtes Passwort: SCRAM-Passthrough für postgres_fdw und dblink

Rollen und Rechte nach Least Privilege

  • Login- und Gruppenrollen, GRANT … WITH INHERIT / WITH SET, NOINHERIT
  • Ohne Superuser arbeiten: vordefinierte Rollen wie pg_read_all_data, pg_monitor, pg_read_all_stats, pg_signal_backend, pg_maintain, pg_checkpoint, pg_use_reserved_connections
  • CREATEROLE entschärft: createrole_self_grant und wer wen verwalten darf
  • Rollentrennung in der Anwendung: Eigentümer, Migration, Anwendung, Nur-Lesen, Monitoring
  • Schema-Isolation: public-Schema, REVOKE … FROM PUBLIC, sichere search_path-Muster
  • Default Privileges, Column-Level Privileges
  • Rechte inventarisieren und gegen das Soll prüfen: pg_permissions, Katalogabfragen
  • ALTER SYSTEM sperren mit allow_alter_system und Konfiguration als Code

Code in der Datenbank als Angriffsfläche

  • SECURITY DEFINER mit fixiertem search_path — und wann SECURITY INVOKER reicht
  • Views mit security_barrier und security_invoker, Funktionen mit LEAKPROOF
  • Hochrisiko-Funktionen: COPY … PROGRAM, pg_read_server_files, lo_import/lo_export, untrusted Languages (plpython3u, plperlu)
  • Extensions als Lieferkette: Paketquelle, trusted-Flag, shared_preload_libraries prüfen
  • SQL-Injection im dynamischen SQL: format() mit %I und %L, EXECUTE … USING
  • Kontrollierte Rechteausweitung mit set_user, Sitzungsregeln über Login-Event-Trigger

Row-Level Security

  • ENABLE und FORCE ROW LEVEL SECURITY, PERMISSIVE und RESTRICTIVE Policies
  • USING und WITH CHECK: Regeln für Lesen und Schreiben getrennt festlegen
  • Mandantentrennung (Multi-Tenancy) über Sitzungsvariablen — und was ein Transaction-Pooler daran ändert
  • Wer RLS umgeht: BYPASSRLS, Tabelleneigentümer, Superuser
  • Seitenkanäle und Performance: Fehlermeldungen, LEAKPROOF, Indexe auf der Mandantenspalte

Audit-Logging und Protokollierung

  • Bordmittel gezielt einsetzen: log_connections mit Einzelstufen, log_disconnections, log_line_prefix, log_statement, log_parameter_max_length
  • Was ungewollt im Log landet: Passwörter in ALTER ROLE, Parameterwerte, Abfragetexte in pg_stat_activity und pg_stat_statements
  • pgAudit: Session- und Object-Audit, rollenbasiertes Objekt-Audit, Filter gegen Protokollflut
  • Strukturierte Logs (jsonlog) an ein SIEM übergeben: syslog, Fluent Bit, Vector; Auswertung mit pgBadger
  • Aufbewahrung, Manipulationsschutz und Datenminimierung im Audit-Log

Verschlüsselung und Schutz der Daten

  • Encryption at Rest mit Volume-Verschlüsselung (LUKS, Cloud-KMS): wogegen sie schützt und wogegen nicht
  • Ausblick Transparent Data Encryption (TDE): bisher nur mit angepasstem Server, etwa pg_tde in der Percona-Distribution
  • Spaltenverschlüsselung mit pgcrypto gegen Verschlüsselung in der Anwendung; Schlüsselverwaltung als eigentliche Aufgabe
  • Passwörter in Anwendungstabellen richtig speichern: crypt() mit gen_salt('bf')
  • Pseudonymisierung und Anonymisierung von Test- und Analysedaten mit PostgreSQL Anonymizer
  • Datenprüfsummen (data_checksums) gegen stille Beschädigung
  • Sicherungen als Datenabflussweg: verschlüsseltes pgBackRest-Repository, WAL-Archiv, pg_dump-Dateien, restrict_nonsystem_relation_kind
  • Replikation absichern: eigene Replikationsrolle, replication-Einträge in pg_hba.conf, Slots
Welche Verschlüsselung gegen welchen Angriff hilft Vier Angriffe gegen drei Verfahren. Ein ausgebauter Datenträger: Volume-Verschlüsselung schützt, Spaltenverschlüsselung schützt nur die verschlüsselten Spalten, das verschlüsselte Backup ist nicht betroffen. Eine kopierte Sicherungsdatei: Volume-Verschlüsselung schützt nicht, Spaltenverschlüsselung nur die verschlüsselten Spalten, ein verschlüsseltes Backup schützt. Zugriff mit Datenbankrechten: nur die Spaltenverschlüsselung mit Schlüssel außerhalb der Datenbank schützt. Eine kompromittierte Anwendung: keines der drei Verfahren schützt; hier begrenzen Rechte und Row-Level Security den Schaden, Audit macht ihn sichtbar. Angriff Volume- Verschlüsselung Spalten (Schlüssel außerhalb der DB) verschlüsseltes Backup Datenträger ausgebaut schützt nur diese Spalten nicht betroffen Sicherungsdatei kopiert schützt nicht nur diese Spalten schützt Zugriff mit DB-Rechten schützt nicht schützt schützt nicht Anwendung kompromittiert schützt nicht schützt nicht schützt nicht Kompromittierte Anwendung: Rechte und Row-Level Security begrenzen den Schaden, Audit macht ihn sichtbar.
Abbildung 3: Jedes Verfahren schützt gegen bestimmte Angriffe. Welches ihr braucht, hängt davon ab, wovor die Daten geschützt werden sollen.

Betrieb, Container und Cloud

  • Betriebssystem: Dienstbenutzer, Rechte auf PGDATA, data_directory_mode, SELinux
  • Container und Kubernetes: CloudNativePG, Betrieb ohne root, Secrets, Network Policies
  • Managed PostgreSQL: was der Anbieter übernimmt und was bei dir bleibt (Shared Responsibility)
  • Härtung automatisieren: Konfiguration als Code, Abweichungen erkennen, Benchmark als wiederkehrender Lauf

Workshop: euer Härtungsplan

  • Bestandsaufnahme einer Instanz mit Prüfskript und Benchmark
  • Befunde priorisieren: Quick Wins, mittelfristige und strategische Maßnahmen
  • Nachweise für Prüfungen: ISO 27001, BSI IT-Grundschutz (Baustein Relationale Datenbanken), Anforderungen aus der DSGVO
  • Peer-Review des Plans mit Angriffsfragen

Praxistag (optional)

  • Single Sign-on mit OAuth 2.0 / OIDC an einem Identity-Provider durchspielen, Anmeldung per psql
  • Dynamische Zugangsdaten mit Vault bzw. OpenBao: Rollen, Ablauf, Widerruf
  • Einen gehärteten Cluster mit CloudNativePG aufsetzen
  • Inhouse: eure eigene Instanz gegen den Benchmark prüfen und den Härtungsplan daran ausrichten

Dauer: 2 Tage, optional 3 Tage mit Praxistag

Was du danach kannst

  • den Sicherheitszustand einer PostgreSQL-Instanz mit Benchmark und Katalogabfragen reproduzierbar erheben und als Befundliste festhalten
  • pg_hba.conf und TLS so einstellen, dass nur verschlüsselte, vorgesehene Verbindungen ankommen, und das über pg_stat_ssl nachweisen
  • MD5-Passwörter aufspüren, auf SCRAM-SHA-256 umstellen und eine zertifikatsbasierte Anmeldung einrichten (Single Sign-on mit OAuth/OIDC praktisch im Praxistag)
  • eine Anwendung vom Superuser auf ein Rollenmodell nach Least Privilege umbauen und Soll und Ist der Rechte per Abfrage vergleichen
  • Funktionen mit SECURITY DEFINER auf Schwachstellen prüfen und Mandanten mit Row-Level Security so trennen, dass Lesen und Schreiben getrennt geregelt sind
  • begründen, welche Verschlüsselung gegen welchen Angriff hilft, und ein Objekt-Audit mit pgAudit für Tabellen mit personenbezogenen Daten aufsetzen

Formate und Ablauf

Du arbeitest an einer Übungsinstanz mit vorbereiteten Schwachstellen und einem Prüfskript, das am Anfang und am Ende jedes Abschnitts läuft. Die Unterlagen bestehen aus einem Teilnehmerskript mit Parameter-Checkliste, der Übungsumgebung und einer Vorlage für den Härtungsplan.

Format Ablauf Passend wenn
Inhouse vor Ort Zwei Tage bei euch — von Leverkusen aus im Raum Köln und bundesweit; Beispiele auf eure Umgebung abgestimmt ihr eine konkrete Instanz oder einen anstehenden Audit im Blick habt
Remote / Online Zwei Tage im virtuellen Klassenraum, Übungsinstanz für jede Person Teilnehmende an mehreren Standorten sitzen
Mit Praxistag (3 Tage) Standardprogramm plus Single Sign-on, Vault, Container — inhouse auf Wunsch an eurer eigenen Instanz ihr direkt in die Umsetzung gehen wollt

Verwandte Seminare und Vertiefung

Die Grundlagen des Betriebs — Installation, Rollen, pg_hba.conf, TLS, Sicherung und einen ersten Blick auf Row-Level Security und pgaudit — vermittelt PostgreSQL Administration. Diese Themen kommen hier wieder vor und werden vertieft: mit Bedrohungsmodell, Prüfabfragen und Dokumentation der Maßnahmen. Wer beide Seminare gemeinsam bucht, hört sie nicht doppelt: wir stimmen Themenschnitt und Dauer vorab ab und legen die Überschneidungen zusammen. SECURITY DEFINER, search_path und dynamisches SQL behandelt PL/pgSQL-Programmierung als Sprachthema; hier geht es um die Angriffsfläche, die sie öffnen. Wie Sicherheitsparameter mit der Last zusammenspielen — Verbindungsgrenzen, Pooler, Protokollmenge —, vertieft PostgreSQL Performance-Tuning.

Die Konfigurationsdatei, in der auch die Sicherheitsparameter stehen, erklärt der Referenzartikel PostgreSQL Performance-Settings. Dienstbenutzer, Dateirechte und Kernel-Einstellungen der Schicht darunter beschreibt Das Betriebssystem unter PostgreSQL, und PostgreSQL Wartung zeigt die Wartungsarbeiten, für die eine Betriebsrolle heute keinen Superuser mehr braucht. Alle PostgreSQL-Seminare stehen in der Kategorie PostgreSQL.

Dein Dozent

Frank Glück schult seit mehr als 30 Jahren und programmiert seit 1986. Seit 1999 ist er auch als Dozent für die GFU tätig. Seit 1999 hat er Dutzende Datenbankmigrationen nach PostgreSQL begleitet, gecoacht oder durchgeführt — bei Konzernen und Behörden — und mit pg-clusterbackup ein eigenes Open-Source-Werkzeug für die Sicherung mehrerer PostgreSQL-Cluster geschrieben.

Häufige Fragen (FAQ)

Wie lange dauert das Seminar?

Das Seminar dauert 2 Tage. Optional kommt ein dritter Praxistag dazu: Single Sign-on mit OAuth 2.0 / OIDC, dynamische Zugangsdaten mit Vault oder OpenBao, ein gehärteter Cluster unter Kubernetes und inhouse die Prüfung eurer eigenen Instanz.

Worin unterscheidet es sich vom Seminar PostgreSQL Administration?

Das Administrationsseminar richtet eine Instanz ein und betreibt sie; Rollen, pg_hba.conf, TLS und Row-Level Security kommen dort als Grundlage vor. Dieses Seminar geht von einem Bedrohungsmodell aus, nimmt den Ist-Stand auf, sichert jede Schicht ab und dokumentiert die Maßnahmen. Dazu kommen Themen, die dort fehlen: Single Sign-on, Passwortrichtlinien, Code in der Datenbank, Verschlüsselung, Anonymisierung und Container. Bei einer gemeinsamen Buchung stimmen wir den Themenschnitt vorab ab, damit nichts doppelt kommt.

Hilft das Seminar bei einem Audit nach ISO 27001 oder BSI IT-Grundschutz?

Es liefert Prüfschritte, einen Härtungsplan und eine Zuordnung der Maßnahmen zu ISO 27001, zum BSI-Baustein für relationale Datenbanken und zu den Anforderungen der DSGVO an die Sicherheit der Verarbeitung. Eine Zertifizierung oder Rechtsberatung ersetzt es nicht; es bereitet die technische Seite so vor, dass ihr sie belegen könnt.

Geht Single Sign-on mit jeder PostgreSQL-Version?

Die Anmeldung über OAuth 2.0 / OpenID Connect gibt es erst in den neuesten Hauptversionen und braucht ein Validator-Modul für den jeweiligen Identity-Provider. Auf älteren Versionen bleibt Kerberos/GSSAPI gegen Active Directory der empfohlene Weg zur zentralen Anmeldung; beides wird im Seminar behandelt.

Wird Transparent Data Encryption behandelt?

Als Ausblick. TDE steckt bisher nicht in der Community-Version von PostgreSQL, sondern nur in Distributionen mit angepasstem Server, etwa pg_tde bei Percona. Den Schwerpunkt legt das Seminar auf Verfahren, die mit jeder Installation funktionieren: Volume-Verschlüsselung, Spaltenverschlüsselung mit pgcrypto und verschlüsselte Sicherungen.

Können wir an unserer eigenen Instanz arbeiten?

Bei einem Inhouse-Seminar gern, am besten im Praxistag und an einer anonymisierten Kopie. Werden dabei personenbezogene Daten berührt, schließen wir vorab eine Vereinbarung zur Auftragsverarbeitung. Im Standardprogramm arbeitest du an einer Übungsinstanz mit vorbereiteten Schwachstellen.

Wie viele Personen können teilnehmen und was bekomme ich an Unterlagen?

Die Teilnehmerzahl stimmen wir mit der Anfrage ab; sie richtet sich nach Format und Ziel. Du erhältst ein Teilnehmerskript mit Parameter-Checkliste, die Übungsumgebung und eine Vorlage für den Härtungsplan.

Was kostet das Seminar?

Der Preis richtet sich nach Format, Umfang und Teilnehmerzahl und wird auf Anfrage genannt.

Individuell anfragen

Nach deiner Anfrage klären wir, welche Versionen und Umgebungen ihr betreibt, ob ein Audit ansteht und wo der Schwerpunkt liegen soll — Anmeldung, Rechte, Audit oder Verschlüsselung. Danach bekommst du einen Termin- und Inhaltsvorschlag. Die Anfrage ist unverbindlich und kostenlos.

Individuell anfragen