PostgreSQL-Sicherheit 2026: Risiken, Lösungen und bewährte Verfahren

Wichtigste Erkenntnisse

• PostgreSQL wird mit sinnvollen Standardeinstellungen ausgeliefert, doch „sinnvoll“ bedeutet nicht gleich „produktionsreif“ – Authentifizierung, Netzwerkexposition und Rollenberechtigungen müssen alle aktiv abgesichert werden, bevor Sie den Betrieb aufnehmen.
• Integrierte Funktionen wie SCRAM-SHA-256, Row-Level Security und TLS-Verschlüsselung übernehmen den Großteil der Arbeit – allerdings nur, wenn Sie diese tatsächlich aktivieren und regelmäßig überprüfen.
• Für Bereitstellungen, auf denen PostgreSQL 13 über das Ende der Lebensdauer (EOL) im November 2025 hinaus läuft, stellt TuxCare so lange wie nötig Patches für Sicherheitslücken bereit, bis Sie die Migration durchführen können.

Die meisten Angriffe auf PostgreSQL beginnen nicht mit einem Zero-Day. Sie beginnen mit einer vorübergehenden Ausnahme – trust Authentifizierung noch vorhanden pg_hba.conf nach einer langen Debugging-Sitzung – die niemand jemals wieder herausnimmt.

Bei der PostgreSQL-Sicherheit im Jahr 2026 geht es weniger um exotische Angriffe als vielmehr um die wenig glamouröse Arbeit, Konfigurationen streng zu halten, Patches auf dem neuesten Stand zu halten und Zugriffsbeschränkungen durchzusetzen. Die peinliche Wahrheit ist, dass die meisten Sicherheitsverletzungen vermeidbar sind – sie passieren, weil die langweiligen Aufgaben nicht erledigt wurden. Im Folgenden werden die Bedrohungen beschrieben, denen PostgreSQL-Installationen derzeit tatsächlich ausgesetzt sind, die integrierten Abwehrmaßnahmen, die einen entscheidenden Unterschied machen, sowie die Maßnahmen zur Absicherung, die Ihre Zeit wert sind.

Warum sollten sich PostgreSQL-Anwender Gedanken über Sicherheit machen?

PostgreSQL verfügt über ein wirklich robustes Sicherheitsmodell – das ist nicht das Problem. Das Problem ist, dass die Sicherheit im Produktivbetrieb nach wie vor von einer sorgfältigen Konfiguration abhängt: Die Standardeinstellungen sind darauf ausgelegt, den Betrieb in Gang zu bringen, nicht aber, die Sicherheit unter realen Lastbedingungen zu gewährleisten. Authentifizierungsmethoden, Listen-Adressen, Rollenberechtigungen, Protokollierung – all das erfordert eine bewusste Konfiguration. Das ist kein Fehler in der Software; es ist lediglich eine Lücke, die jedes Team selbst schließen muss, was viele erst tun, wenn etwas schiefgeht.

Auch die Bedrohungslage hat sich in einer Weise verändert, die die Teams unvorbereitet trifft. Bei Cryptojacking-Angriffen werden mittlerweile automatisierte Scanner eingesetzt, die gezielt nach ungeschützten PostgreSQL-Instanzen am Port 5432 suchen und, sobald sie Zugang erhalten haben, über PL/Python oder PL/Perl Mining-Programme installieren. SQL-Injection Das spielt nach wie vor eine Rolle, wo immer dynamisches SQL, Erweiterungen oder prozedurale Sprachen zum Einsatz kommen. Unabhängig davon – und in zunehmendem Maße – können Supply-Chain-Angriffe auf die Abhängigkeiten Ihrer Anwendung Daten abgreifen .pgpass Dateien, Umgebungsvariablen oder Verbindungszeichenfolgen, bevor PostgreSQL überhaupt eine Anfrage erhält. Und falls Ihr Unternehmen den Bestimmungen von PCI DSS, HIPAA, oder SOC 2, die Frage ist nicht, ob Sie Ihre Datenbank absichern sollen – die Prüfer werden dies verlangen, und sie werden dokumentierte Nachweise verlangen, nicht nur gute Absichten.

Teams, die damit gut umgehen, behandeln Sicherheitsschulden genauso wie technische Schulden – sie erfassen sie, planen ihre Bearbeitung ein und bauen sie schrittweise ab. Diejenigen, die dies nicht tun, müssen dies meist auf die harte Tour erfahren, und zwar in der Regel zum ungünstigsten Zeitpunkt.

Häufige Sicherheitsbedrohungen für PostgreSQL

Keine der unten aufgeführten Bedrohungen ist hypothetisch. Es handelt sich um Angriffe, die derzeit aktiv gegen PostgreSQL-Installationen eingesetzt werden – oft gegen Teams, die fest davon überzeugt waren, ihre Sicherheitslage vollständig im Griff zu haben.

Bedrohung Nr. 1: SQL-Injection über Erweiterungen und prozedurale Sprachen

SQL-Injection ist die älteste Angriffsmethode überhaupt, doch das Ökosystem der PostgreSQL-Erweiterungen findet immer wieder neue Wege, sie aktuell zu halten. CVE-2025-1094, das im Februar 2025 bekannt gegeben wurde, ist ein gutes Beispiel dafür, wie sich dies weiterentwickelt – es handelte sich um eine Sicherheitslücke in Quoting-Funktionen von libpq (PQescapeLiteral, PQescapeIdentifier und andere): Sie konnten die Quoting-Syntax in Text, der ungültige Byte-Sequenzen enthielt, nicht neutralisieren; wenn diese Ausgabe an psql übergeben wurde, konnte ein Angreifer daher eine SQL-Injection auslösen. Die Schwachstelle wies einen CVSS-Score von 8,1 auf, betraf alle unterstützten Versionen vor 17.3, 16.7, 15.11, 14.16 und 13.19 und war – laut Rapid7 – in jedem von ihnen getesteten Szenario erforderlich, um die BeyondTrust-Schwachstelle (CVE-2024-12356) in eine Remote-Code-Ausführung umzuwandeln.

Das Interessante an dieser CVE ist, dass es sich nicht um eine neuartige Technik handelte – die Verarbeitung ungültiger Byte-Sequenzen ist seit Jahren als Problemklasse bekannt. Sie war lediglich in diesem speziellen Codepfad noch nicht entdeckt worden, bis jemand gründlich genug danach gesucht hat.

Prozedurale Sprachen vergrößern die Angriffsfläche auf andere Weise. Es ist die nicht vertrauenswürdig prozedurale Sprachen – PL/Python (das nur als plpython3u) und plperlu – das beliebigen Code auf Betriebssystemebene ausführen kann. Das ist ein Feature, kein Bug. Der Haken ist genau das Gegenteil von dem, was man vermuten würde: ein vertrauenswürdig eine Sprache wie plperl ist in einer Sandbox ausgeführt und für Benutzer ohne Sonderrechte sicher, während nur Superuser Funktionen in nicht vertrauenswürdigen Umgebungen erstellen können. Das eigentliche Risiko besteht also darin, diese Berechtigung – oder den Superuser-Zugang selbst – großzügiger zu vergeben, als man denkt. Ein 40-köpfiges SaaS-Team, das eine gemeinsam genutzte Datenbank betreibt, sollte diese Berechtigung nicht vergeben CREATE FUNCTION für jeden, der kein DBA ist – aber viele tun es trotzdem, weil es schneller geht, als ordentliche Migrationsskripte zu schreiben, und niemand damit rechnet, dass es eine Rolle spielt, bis es doch dazu kommt.

Profi-Tipp: Die Behebung des Problems ist nicht gerade glamourös. Alle Abfragen parametrisieren, einschränken, wer sie ausführen darf CREATE EXTENSION und Funktionen in nicht vertrauenswürdigen Sprachen erstellen, Ihre installierten Erweiterungen regelmäßig überprüfen und widerrufen CREATE aus einer beliebigen Rolle, ohne dass hierfür ein dokumentierter betrieblicher Bedarf vorliegt.

Bedrohung Nr. 2: Falsch konfigurierte pg_hba.conf

Dies ist der häufigste Fehler bei der PostgreSQL-Sicherheit. Die Datei für die hostbasierte Authentifizierung legt fest, wer von wo aus und auf welchem Weg eine Verbindung zu Ihrer Datenbank herstellen darf. Schon eine einzige falsch konfigurierte Zeile kann Ihre Datenbank unbemerkt für das Internet öffnen.

Die beiden Muster, die Teams am stärksten zu schaffen machen:

• Die Vertrauensauthentifizierung wurde nach dem lokalen Debugging in der Produktionsumgebung belassen. Bei der Vertrauensauthentifizierung akzeptiert PostgreSQL jeden Benutzernamen ohne Passwort, solange die Verbindung von einem zugelassenen Host stammt.
• Wildcard-Host-Einträge (0.0.0.0/0) in Verbindung mit schwachen Passwortverfahren, wodurch die Datenbank über nichts weiter als ein leicht zu erratendes Passwort dem Internet ausgesetzt ist.

pg_hba.conf wird von oben nach unten ausgewertet, und die erste übereinstimmende Regel hat Vorrang. Genau dieser Punkt führt bei vielen zu Verwirrung: Eine weniger strenge Regel, die über einer strengeren steht, wird nicht außer Kraft gesetzt – sie hat jedes Mal stillschweigend Vorrang, ohne dass ein Fehler oder eine Warnung ausgegeben wird. Das Ergebnis ist eine Verbindung, die niemals hätte zugelassen werden dürfen, und in den Protokollen gibt es keinen Hinweis darauf, warum dies geschehen ist.

Hinweis: Wenn Ihre PostgreSQL-Instanz von außerhalb von 127.0.0.1 oder Ihrer privaten VPC erreichbar ist, hören Sie hier auf zu lesen und überprüfen Sie zunächst diese Datei.

Bedrohung Nr. 3: Nicht gepatchte CVEs

PostgreSQL veröffentlicht Sicherheitsupdates nach einem vorhersehbaren Zeitplan – das Problem sind nicht die Updates selbst, sondern die Zeitspanne zwischen „Veröffentlichung“ und „Einführung in der Produktion“. CVE-2024-10979, das im November 2024 bekannt wurde, veranschaulicht gut, worum es geht: Eine Schwachstelle mit hohem Schweregrad (CVSS 8,8) in PL/Perl ermöglichte es nicht privilegierten Benutzern, Umgebungsvariablen wie PATH zu ändern und beliebigen Code auszuführen. Betroffen waren alle Versionen vor 17.1, 16.5, 15.9, 14.14, 13.17 und 12.21.

Das sind sechs Nebenversionszweige. Viele Teams haben an mindestens einem davon gearbeitet, und viele arbeiten auch heute noch an einem davon.

Dann gibt es noch das Problem des End-of-Life, das wohl noch gravierender ist. Der Support durch die PostgreSQL-Community läuft für jede Hauptversion fünf Jahre lang. PostgreSQL 12 erreichte im November 2024 das EOL, PostgreSQL 13 folgte im November 2025. Beide laufen nun ohne Sicherheitspatches vom Upstream – es gibt keine Korrekturen, unabhängig vom Schweregrad, es sei denn, man führt ein Upgrade durch oder vereinbart einen erweiterten Support.

Wenn Sie aufgrund einer Anwendungsabhängigkeit oder einer immer wieder aufgeschobenen Plattformmigration an einer der beiden Versionen festhängen, brauchen Sie einen Plan. TuxCare bietet „Endless Lifecycle Support“ (ELS) speziell für PostgreSQL 13 nach Ablauf des EOL an, was bedeutet, dass Ihre Installation weiterhin Sicherheitspatches erhält, während Sie das Upgrade durchführen.

Bedrohung Nr. 4: Cryptojacking durch Remote-Code-Ausführung

Sobald ein Angreifer auf einem PostgreSQL-Host RCE erlangt hat, ist Cryptomining der Weg des geringsten Widerstands. Für ihn ist das Risiko gering – es müssen keine Daten abgezogen werden, es sind keine Verhandlungen im Zusammenhang mit Ransomware zu führen – er nutzt lediglich Rechenleistung, die ihm kostenlos zur Verfügung steht. Automatisierte Scanner suchen nach exponierten Instanzen auf Port 5432, führen „Credential Sprays“ gegen den Postgres-Superuser durch und installieren bei Erfolg einen Miner über COPY ... FROM PROGRAM oder PL/Python.

Die meisten Teams stellen es auf dieselbe Weise fest: Die CPU-Auslastung auf dem Datenbank-Host liegt bei 100 %, Abfragen kommen fast zum Stillstand, und schließlich öffnet jemand htop und entdeckt einen Prozess, den er nicht erkennt. Zu diesem Zeitpunkt ist der Angreifer in der Regel bereits seit Tagen im System.

Die Schutzmaßnahmen überschneiden sich stark mit allgemeinen Sicherheitsmaßnahmen: Der Port 5432 darf nicht ins Internet freigegeben werden, und es muss eine starke Authentifizierung für den postgres Superuser und andere privilegierte Rollen sowie die Funktionen, die Angreifer zur Codeausführung missbrauchen, sperren – einschränken COPY ... FROM PROGRAM (bereits auf Superuser und berechtigte Rollen beschränkt) pg_execute_server_program) und vermeiden Sie die Installation nicht vertrauenswürdiger prozeduraler Sprachen wie PL/Python, es sei denn, Sie benötigen diese tatsächlich.

Bedrohung Nr. 5: Angriffe auf die Lieferkette über Abhängigkeiten

Eines der schwerwiegendsten Risiken bei PostgreSQL ist nicht ein PostgreSQL-Sicherheitslücke Überhaupt nicht – es handelt sich um die Anwendungsschicht. Bei bösartigen oder kompromittierten npm-Paketen wurde genau das festgestellt, was man erwarten würde: das Auslesen von Umgebungsvariablen, das Scraping von .pgpass Dateien und das heimliche Abgreifen von Verbindungsstrings. Sobald diese Anmeldedaten einmal im Umlauf sind, wird Ihre Datenbank zum Ziel – ganz gleich, wie gut PostgreSQL selbst abgesichert ist.

PostgreSQL kann hier allein keinen Schutz bieten – die Anmeldedaten wurden gestohlen, noch bevor sie überhaupt die Datenbank erreichten. Die Lösung liegt darin, wie Sie die Grenze zwischen Anwendungscode und Datenbankzugriff verwalten: Wechseln Sie die Anmeldedaten nach einem festgelegten Zeitplan, beschränken Sie die Berechtigungen jedes Datenbankbenutzers auf das tatsächlich erforderliche Minimum und nutzen Sie kurzlebige Anmeldedaten oder ein Geheimnis-Management, sofern Ihre Infrastruktur dies zulässt.

Für weiterführende Informationen zum Thema Abhängigkeiten sind die Beiträge von TuxCare zu transitiven Abhängigkeiten und deren SBOM-Leitfaden die richtigen Anlaufstellen.

Wichtige Sicherheitsfunktionen von PostgreSQL

PostgreSQL bietet Ihnen die grundlegenden Funktionen, um ein solides Sicherheitsmodell aufzubauen. Im Folgenden werden die Funktionen vorgestellt, die in der Praxis tatsächlich von Bedeutung sind, zusammen mit den Konfigurationsdetails, die den Unterschied zwischen „technisch möglich“ und „tatsächlich funktionsfähig“ ausmachen.

Funktion Nr. 1: Authentifizierungsmethoden

PostgreSQL unterstützt eine Vielzahl von Authentifizierungsmethoden, doch diejenigen, deren Einsatz sich im Jahr 2026 lohnt, sind SCRAM-SHA-256, die zertifikatsbasierte Authentifizierung sowie die Integration mit einem externen Identitätsanbieter über LDAP oder Kerberos.

SCRAM-SHA-256 wurde zum Standardwert für password_encryption In PostgreSQL 14 – dort wurde es bereits seit PostgreSQL 10 unterstützt und empfohlen – ersetzt es MD5, das bekanntermaßen Schwachstellen aufweist. Doch hier ist der Punkt, der oft übersehen wird: Bei einem Upgrade Ihrer PostgreSQL-Version werden Ihre bestehenden Passwort-Hashes nicht automatisch migriert.

Benutzer, die ihre Passwörter vor der Umstellung festgelegt haben, verwenden intern weiterhin MD5, bis sie diese zurücksetzen. Sie müssen explizit festlegen, password_encryption = scram-sha-256 in postgresql.conf und eine Passwortrotation erzwingen – und selbst dann ist zu beachten, dass bestehende Passwörter weiterhin als MD5-Hash gespeichert bleiben, bis jeder Benutzer sie zurücksetzt. Sobald ein Passwort als SCRAM-Hash gespeichert ist, wird ein md5 Zeile in pg_hba.conf wird es automatisch über SCRAM authentifizieren – das verbleibende Risiko besteht also in nicht zurückgesetzten Passwörtern und unklaren Konfigurationen, nicht darin, dass die Authentifizierungszeile unbemerkt die Oberhand gewinnt.

Die zertifikatsbasierte Authentifizierung ist die sicherste Option für Verbindungen zwischen Diensten. Jeder Client legt ein von Ihrer Zertifizierungsstelle signiertes Zertifikat vor, und PostgreSQL überprüft dieses, bevor die Verbindung akzeptiert wird. Es können keine Passwörter offengelegt werden, und es gibt keine gemeinsam genutzten Geheimnisse in Umgebungsvariablen.

Für menschliche Benutzer sollten Sie auf eine LDAP- oder Kerberos-Integration hinarbeiten, damit Sie die Kontoverwaltung und das Offboarding zentralisieren können. Ein Benutzer, der das Unternehmen verlässt, sollte noch am selben Tag automatisch den Zugriff auf die Datenbank verlieren.

Funktion Nr. 2: Rollenbasierte Zugriffskontrolle

Das Rollen- und Berechtigungssystem von PostgreSQL gehört zu den detailliertesten aller Open-Source-Datenbanken. Sie können Berechtigungen für Datenbanken, Schemata, Tabellen, Spalten, Sequenzen, Funktionen und vieles mehr vergeben. Außerdem können Sie Rollenhierarchien erstellen, in denen eine Rolle die Berechtigungen einer anderen Rolle erbt.

Das entscheidende Prinzip lautet: Jede Rolle erhält genau die Mindestberechtigungen, die sie benötigt, und nicht mehr. In der Praxis bedeutet dies, dass Anwendungsrollen nur SELECT-, INSERT-, UPDATE- und DELETE-Befehle für die spezifischen Tabellen ausführen können, auf die sie zugreifen – keine pauschalen ALL PRIVILEGES für das gesamte Schema und schon gar keine Superuser-Rechte.

Ein Realitätscheck: Die meisten Teams, die glauben, sie würden das Prinzip der geringsten Berechtigungen befolgen, tun dies in Wirklichkeit gar nicht. Die Anwendung wird als Rolle mit weitreichenden Zugriffsrechten angemeldet, „um die Dinge einfach zu halten“, und niemand rührt daran, weil die Neugestaltung der Berechtigungsmatrix mühsam ist. Es lohnt sich trotzdem, dies zu tun.

Funktion Nr. 3: Sicherheit auf Zeilenebene

Mit „Row-Level Security“ (RLS) können Sie Tabellen Richtlinien zuweisen, die filtern, welche Zeilen eine bestimmte Rolle einsehen oder ändern darf. Dies ist das richtige Werkzeug für mandantenfähige Anwendungen, bei denen eine Datenbank Daten für viele Kunden enthält und Sie eine zuverlässige Garantie benötigen, dass Kunde A niemals die Zeilen von Kunde B einsehen kann.

Was RLS wirklich wertvoll macht, ist die Tatsache, dass die Garantie in der Datenbank und nicht in der Anwendung verankert ist. Filterung auf Anwendungsebene kann vergessen werden, durch eine Abfrage umgangen werden, die nicht die richtige WHERE-Klausel enthält, oder durch eine ORM-Abstraktion unbemerkt außer Kraft gesetzt werden. RLS setzt die Richtlinie serverseitig für die davon betroffenen Rollen durch – eine fehlerhafte Abfrage, die vergisst, nach tenant_id Es kommt dennoch nicht zu einem Datenleck, da PostgreSQL die Richtlinie anwendet, bevor die Ergebnisse zurückgegeben werden. Der Haken, der vielen zu schaffen macht: Tabellenbesitzer, Superuser und Rollen mit BYPASSRLS Standardmäßig werden Richtlinien übersprungen. Stellen Sie daher sicher, dass Ihre Anwendungsrolle keiner dieser Rollen entspricht, und verwenden Sie FORCE ROW LEVEL SECURITY dort, wo es darauf ankommt.

Der Haken daran ist, dass die Fehlerbehebung bei RLS schwierig sein kann und dass es Auswirkungen auf die Leistung gibt, die Sie testen müssen. Die Richtlinien werden für jede Zeile ausgewertet, und komplexe Richtlinien bei großen Tabellen können die Abfragepläne beeinträchtigen. Testen Sie das System unter realistischen Lastbedingungen, bevor Sie sich darauf verlassen.

Funktion Nr. 4: SSL/TLS-Verschlüsselung

Daten, die zwischen Client und Server übertragen werden, sollten verschlüsselt werden. PostgreSQL unterstützt TLS, allerdings muss dies konfiguriert werden – in den meisten Installationen ist diese Funktion standardmäßig nicht aktiviert.

Zwei Einstellungen müssen korrekt vorgenommen werden: „ssl = on“ in der Datei „postgresql.conf“ sowie „hostssl“-Einträge (nicht „host“) in der Datei „pg_hba.conf“ für jede Verbindung, die verschlüsselt werden soll. Ohne die „hostssl“-Anforderung können Clients weiterhin eine Verbindung im Klartext herstellen, wenn sie dies wünschen.

Zur Client-Überprüfung setzen Sie auf der Client-Seite „sslmode=verify-full“. Dadurch überprüft der Client sowohl das Serverzertifikat als auch die Übereinstimmung des Hostnamens, wodurch Man-in-the-Middle-Angriffe verhindert werden. sslmode=require Das allein reicht nicht aus – es verschlüsselt zwar die Verbindung, überprüft aber nicht die Identität des Servers, so wie verify-ca oder verify-full Das ist der Fall, sodass ein Angreifer auf Netzwerkebene sich weiterhin als der Server ausgeben kann.Funktion Nr. 5: Audit-Protokollierung und pgAudit

Die native Protokollierung von PostgreSQL erfasst zwar bereits viele Informationen, doch für Audit-Trails auf Compliance-Niveau benötigen Sie die Erweiterung „pgaudit“. Diese protokolliert strukturierte Datensätze zu jeder ausgeführten Anweisung, einschließlich der ausführenden Rolle, der betroffenen Objekte und der verwendeten Parameter. Dadurch lassen sich Nachweise für SOC 2, HIPAA und PCI DSS wesentlich einfacher erstellen – allerdings auf Kosten eines erheblichen Protokollvolumens, wenn Sie den Erfassungsbereich zu weit fassen.

Ein praktischer Tipp: Beschränken Sie den Parameter „pgaudit.log“ von pgAudit auf die Kategorien, die Sie tatsächlich benötigen – in der Regel DDL, Rollen und Lesezugriffe auf sensible Tabellen –, anstatt eine pauschale Protokollierung zu aktivieren. Eine vollständige Protokollierung aller Anweisungen in einer stark ausgelasteten Datenbank erzeugt Datenmengen, die niemand tatsächlich liest, und der Speicherplatzbedarf für die Protokolle wird zu einem eigenen betrieblichen Problem. Protokollieren Sie nur das, was Ihre Auditoren benötigen, leiten Sie die Daten an Ihr SIEM-System weiter und widerstehen Sie der Versuchung, „nur für den Fall“ alles zu protokollieren.

Bewährte Verfahren zur Verbesserung der PostgreSQL-Sicherheit

Die Absicherung von Systemen ist kein einmaliges Projekt. Es handelt sich um eine fortlaufende operative Disziplin, und Teams, die dies gut umsetzen, verfügen in der Regel über Systeme, die die langweiligen Aufgaben automatisieren. In den folgenden Vorgehensweisen kommt diese Disziplin konkret zum Ausdruck.

1. Patches umgehend installieren

Der einzige Faktor, der kompromittierte PostgreSQL-Bereitstellungen am konsequentesten von sicheren unterscheidet, ist die Patch-Verzögerung – also die Zeitspanne zwischen der Bekanntgabe einer CVE und dem Zeitpunkt, zu dem der Fix tatsächlich in der Produktion implementiert wird. In diesem Zeitfenster agieren Angreifer, und je größer dieses Zeitfenster ist, desto größer ist Ihr Sicherheitsrisiko.

Führen Sie Minor-Version-Updates umgehend durch – sie enthalten ausschließlich Sicherheits- und Fehlerbehebungen und erfordern lediglich einen Neustart des Dienstes. Das Risiko, sie durchzuführen, ist fast immer geringer als das Risiko, sie zu überspringen. Die Teams, die ins Hintertreffen geraten, sind in der Regel diejenigen, die auf ein offizielles Wartungsfenster warten, um einen zweiminütigen Neustart zu rechtfertigen.

2. Sperren pg_hba.conf und Netzwerkzugriff

Behandeln Sie die Datei „pg_hba.conf“ wie einen Satz von Firewall-Regeln. Dokumentieren Sie jeden Eintrag. Überprüfen Sie die Datei regelmäßig – vierteljährlich ist angemessen. Entfernen Sie alles, was nicht aktiv genutzt wird.

Besondere Vorschriften:

• Verwende kein trust Authentifizierung für jede TCP-Verbindung, einschließlich Loopback; bei lokalen Unix-Domain-Socket-Verbindungen wird bevorzugt peer Die Datenbankidentität ist also an den Betriebssystembenutzer gebunden.
• Verwenden Sie „hostssl“ anstelle von „host“ für alle nicht-lokalen Verbindungen.
• Beschränken Sie die Quell-IP-Adressen auf bestimmte CIDR-Bereiche. 0.0.0.0/0 ist so gut wie nie die richtige Lösung.
• Binden Sie PostgreSQL mithilfe von `listen_addresses` an bestimmte Adressen, nicht an `*`.

Wenn Sie in einer Cloud-VPC arbeiten, ergänzen Sie dies durch Sicherheitsgruppen, damit die Datenbank nur von Ihrer Anwendungsschicht aus erreichbar ist. Mehrschichtige Sicherheit – pg_hba.conf ist eine Ebene, Netzwerk-ACLs eine weitere.

3. Rollen, Berechtigungen und Erweiterungen regelmäßig überprüfen

In jeder langlebigen Datenbank kommt es zu einer Ausweitung der Berechtigungen. Jemand benötigt vorübergehend Superuser-Zugriff für eine Migration. Die Berechtigung wird nie wieder entzogen. Multipliziert man das mit Jahren, erhält man einen Berechtigungsgraphen, den niemand mehr vollständig versteht.

Führen Sie eine vierteljährliche Überprüfung durch:

• Listen Sie alle Rollen und deren Berechtigungen mithilfe von \du+ und der Ansicht „information_schema.role_table_grants“ auf.
• Ermitteln Sie Rollen, bei denen in den letzten 90 Tagen keine Anmeldung stattgefunden hat. Deaktivieren Sie diese oder verlangen Sie zumindest eine Begründung für deren Beibehaltung.
• Listen Sie die installierten Erweiterungen mit dem Befehl „SELECT * FROM pg_extension“ auf. Alles, was nicht aktiv genutzt wird, stellt ein Risiko dar, ohne einen Nutzen zu bieten.
• Überprüfen Sie, ob Rollen mit den Berechtigungen SUPERUSER, CREATEDB oder CREATEROLE vorhanden sind. Für jede dieser Rollen muss ein dokumentierter Grund vorliegen.

Das Ziel ist nicht Perfektion. Es geht darum, sicherzustellen, dass Ihr Privilegienmodell das widerspiegelt, was Sie heute tatsächlich brauchen – und nicht das, was Sie vor zwei Jahren gebraucht haben.

Tools zur Verbesserung der PostgreSQL-Sicherheit

Die folgenden Tools decken die wichtigsten Lücken einer Standard-PostgreSQL-Bereitstellung ab: Patching, Audits, Scans und Compliance-Berichte. Da kein einzelnes Tool all diese Aufgaben gleichermaßen gut bewältigt, setzen die meisten Teams letztendlich eine Kombination aus mehreren Tools ein.

Tool Nr. 1: TuxCare

PostgreSQL 13 hat im November 2025 das Ende seines Lebenszyklus erreicht, PostgreSQL 12 bereits im November 2024. Beide Versionen werden nun ohne Sicherheitspatches vom Upstream-Entwickler betrieben – das bedeutet, dass bis zu einem Upgrade keine Fehlerbehebungen von der Community bereitgestellt werden, unabhängig vom Schweregrad der Sicherheitslücke.

Für Teams, die nicht sofort ein Upgrade durchführen können – sei es aufgrund von Anwendungsabhängigkeiten, Integrationen von Drittanbietern oder der Komplexität der Migration –, sorgt der „Endless Lifecycle Support“ von TuxCare für PostgreSQL 13 dafür, dass diese Installationen weiterhin Sicherheitspatches erhalten, während eine ordnungsgemäße Migration geplant wird. Das ist ein wesentlich anderer Ansatz als der Betrieb ohne Patches in der Hoffnung, dass keine kritischen Sicherheitslücken auftreten, bevor man bereit ist.

Die praktischen Argumente für ELS liegen auf der Hand: Ein unter dem Druck einer kritischen CVE überstürzt durchgeführtes Upgrade auf eine neue Hauptversion ist genau die Art von Situation, die zu Ausfällen führt. ELS verschafft Ihnen Zeit, die Migration ordnungsgemäß durchzuführen.

Tool Nr. 2: pgAudit

pgAudit ist die De-facto-Erweiterung für Audit-Protokollierung auf Compliance-Niveau in PostgreSQL. Sie erzeugt strukturierte Protokolleinträge, die genau den Anforderungen von SOC-2-, HIPAA- und PCI-DSS-Prüfern entsprechen. Die Konfiguration ist unkompliziert, doch das Protokollvolumen kann schnell stark ansteigen – planen Sie daher ausreichend Speicherplatz ein und sorgen Sie für die Weiterleitung an ein SIEM-System, anstatt die Protokolle lokal ansammeln zu lassen.

Es ist kostenlos, wird regelmäßig gepflegt und ist weit verbreitet. Der Nachteil ist, dass es lediglich Protokolle erstellt – mehr nicht. Sie benötigen weiterhin ein separates System, um die Protokolle tatsächlich zu analysieren und bei Auffälligkeiten Warnmeldungen auszugeben. Kombinieren Sie es mit dem SIEM-System, das Ihr Sicherheitsteam bereits einsetzt.

Tool Nr. 3: pg_stat_statements + Prometheus-Exporter

Zwar handelt es sich dabei nicht um ein reines Sicherheitstool, doch bieten „pg_stat_statements“ in Kombination mit einem Prometheus-Exporter (wie beispielsweise „postgres_exporter“) die erforderliche Transparenz auf Abfrageebene, um Missbrauchsmuster zu erkennen. Plötzliche Spitzen bei COPY-Anweisungen, Abfragen auf Systemkataloge durch Anwendungsrollen oder ungewöhnlich hohe Verbindungszahlen von neuen IP-Adressen sind allesamt Signale, die eine Warnmeldung auslösen sollten.

Es handelt sich um die kostengünstige Variante einer Lösung zur Überwachung von Datenbankaktivitäten. Nicht ganz so ausgereift wie ein spezielles DAM-Tool, aber kostenlos, ressourcenschonend und gut genug für die meisten Teams, die sich die Preise für Unternehmenslösungen nicht leisten können.

Tool Nr. 4: Schwachstellenscanner

In Umgebungen, in denen PostgreSQL auf Linux-Hosts läuft, die Sie selbst verwalten, erkennen Schwachstellenscanner bekannte CVEs in Ihren PostgreSQL-Binärdateien und -Abhängigkeiten. Die meisten Scanner zeigen Ihnen zwar an, wo Schwachstellen bestehen, haben jedoch Schwierigkeiten bei der Überprüfung der Behebung – sie kennzeichnen eine CVE auch dann noch als offen, wenn sie bereits durch einen Backport behoben wurde, was zu Fehlalarmen führt und das Vertrauen in die Ergebnisse untergräbt.

Verbessern Sie die Sicherheit von PostgreSQL mit TuxCare

Die Sicherheit von PostgreSQL ist kein Projekt mit einem festen Fertigstellungstermin – es ist eine fortlaufende betriebliche Disziplin. Es tauchen ständig neue CVEs auf, Konfigurationen weichen vom Soll ab, Rollen sammeln Berechtigungen an, die sie nicht haben sollten, und EOL-Fristen rücken näher, ob man darauf vorbereitet ist oder nicht. Die Teams, die immer einen Schritt voraus sind, leisten keine Heldentaten. Sie haben Systeme aufgebaut, die routinemäßige Sicherheitsaufgaben transparent, wiederholbar und kaum zu übersehen machen – sodass das nächste CVE oder der nächste EOL-Termin eine geplante Aufgabe ist und keine Panikmaßnahme.

Für Teams, die PostgreSQL 13 über dessen EOL im November 2025 hinaus einsetzen, sorgt der „Endless Lifecycle Support“ von TuxCare dafür, dass weiterhin Sicherheitspatches bereitgestellt werden, während die Migration nach einem realistischen Zeitplan geplant wird – und nicht unter dem Druck einer Krise, die durch die nächste kritische CVE-Sicherheitslücke ausgelöst wird.

FAQs