Stell dir vor, es ist Freitagabend, 17:30 Uhr. Ein neuer Entwickler braucht dringend Zugriff auf die Reporting-Datenbank, um eine Abfrage für das Management vorzubereiten. Du bist unter Zeitdruck, öffnest das Terminal und führst schnell den Befehl Create A Role In Postgresql aus, gefolgt von einem großzügigen SUPERUSER-Flag, weil du keine Lust hast, dich jetzt mit granularen Berechtigungen für einzelne Schemata herumzuschlagen. Drei Monate später stellst du fest, dass ein SQL-Injection-Leck in einer alten Applikation dazu geführt hat, dass jemand über genau diesen Account die gesamte Instanz gelöscht hat – inklusive der Backups, die auf demselben Dateisystem lagen. Ich habe dieses Szenario bei mittelständischen Unternehmen in Deutschland öfter gesehen, als mir lieb ist. Der Fehler kostet nicht nur Tage an Wiederherstellungszeit, sondern im schlimmsten Fall die Existenzgrundlage, wenn die Compliance-Richtlinien der DSGVO verletzt wurden.
Das Missverständnis zwischen User und Create A Role In Postgresql
In der Welt von Postgres gibt es technisch gesehen keinen Unterschied zwischen einem Benutzer und einer Rolle. Das ist der Punkt, an dem viele scheitern. Sie denken in den Kategorien von Windows-Logins oder Linux-Usern. In Postgres ist eine Rolle einfach ein Container für Berechtigungen. Wenn du Create A Role In Postgresql tippst, ohne die Option LOGIN zu verwenden, hast du lediglich eine Gruppe erstellt. Viele Admins wundern sich dann, warum sie sich mit dem neuen Namen nicht einloggen können.
Ich erinnere mich an ein Projekt bei einem Fintech-Startup in Berlin. Die Infrastruktur-Jungs hatten für jeden Service Rollen angelegt, aber vergessen, dass Rollen ohne Passwörter und Login-Rechte in einer Cloud-Umgebung wie AWS RDS völlig anders gehandhabt werden müssen. Sie verbrachten zwei Tage damit, Verbindungsfehler zu debuggen, nur weil sie das Konzept der Vererbung nicht verstanden hatten. Eine Rolle sollte in der Praxis fast immer Teil einer Hierarchie sein. Du erstellst eine Basis-Rolle für "ReadOnly" und weist diese dann dem eigentlichen Nutzer zu. Wer das manuell für jeden User einzeln macht, baut sich ein Wartungsmonster, das bei der ersten Mitarbeiterfluktuation in sich zusammenbricht.
Die Gefahr der Standardberechtigungen in Public Schemata
Ein massiver Fehler, der fast überall auftaucht, ist das Vertrauen in das public-Schema. Wenn du eine Rolle erstellst, hat diese oft standardmäßig das Recht, im public-Schema Tabellen anzulegen. Das ist Wahnsinn. In einer sauberen Umgebung entziehst du der Gruppe public sofort alle Rechte auf das Schema.
Ein Vorher-Szenario sieht so aus: Ein Admin erstellt Rollen für das Team. Jeder kann im Standard-Schema herumfuhrwerken. Nach ein paar Wochen sieht die Datenbank aus wie ein Schlachtfeld. Überall liegen test_tabelle_v1, backup_old und tmp_data herum. Niemand weiß, wem was gehört. Die Performance sinkt, weil Indizes auf diesen Müll-Tabellen wertvollen Arbeitsspeicher fressen.
Das Nachher-Szenario, wie ich es implementiere: Die Rolle wird erstellt, aber sie bekommt explizit nur Zugriff auf ein dediziertes Anwendungs-Schema. Das public-Schema ist für alle gesperrt. Wer Daten braucht, muss über die definierte Schnittstelle gehen. Das spart bei einer Migration auf eine neue Major-Version von Postgres gut und gerne 20 Arbeitsstunden, weil man nicht erst mühsam herausfinden muss, welche der 500 Tabellen im public-Schema eigentlich produktiv sind.
Warum Passwörter in SQL-Skripten dein Untergang sind
Ich sehe das ständig in Deployment-Skripten auf GitHub oder GitLab: CREATE ROLE myuser WITH PASSWORD 'geheim123'. Das ist ein Sicherheits-Gau. Dieses Passwort landet in der history-Datei der Shell, in den Logs des Datenbank-Servers und in deinem Versionskontrollsystem. Wenn ein Angreifer Zugriff auf deinen Jenkins-Server bekommt, hat er den Generalschlüssel für deine Daten.
In der Praxis nutzt du unter Linux die .pgpass-Datei oder Umgebungsvariablen für den initialen Setup-Prozess. Noch besser sind IAM-Rollen, wenn du in der Cloud arbeitest, oder eine Integration mit Vault. Wer Passwörter als Klartext in SQL-Dateien schreibt, handelt grob fahrlässig. Ich habe erlebt, wie ein Werkstudent versehentlich ein solches Skript in ein öffentliches Repo gepusht hat. Innerhalb von vier Minuten wurde die Datenbank von einem Bot-Netzwerk gekapert und verschlüsselt. Die Lösegeldforderung war höher als das Jahresbudget der IT-Abteilung.
Die Vererbung von Rechten richtig steuern
Ein weiterer Stolperstein ist das Keyword INHERIT. Standardmäßig erben Rollen in Postgres die Rechte der Gruppen, in denen sie Mitglied sind. Das klingt praktisch, führt aber zu einer unkontrollierbaren Rechtestruktur. Wenn du eine Rolle erstellst, die Mitglied von admin_gruppe ist, hat sie sofort alle Privilegien.
Das Problem mit der Identität
Wenn du NOINHERIT nutzt, muss der Nutzer explizit SET ROLE ausführen, um die Rechte der Gruppe zu aktivieren. Das ist nervig für den Entwickler, aber ein Segen für die Sicherheit. Warum? Weil der Mensch hinter dem Account aktiv entscheiden muss, wann er mit erweiterten Rechten arbeitet. Es ist wie der Unterschied zwischen ständig als root eingeloggt zu sein oder sudo zu benutzen. In meinen Setups erzwinge ich oft diesen Schritt für alle administrativen Aufgaben. Es verhindert, dass ein simpler Tippfehler in einem DELETE-Statement ohne WHERE-Klausel die gesamte Kundendatenbank leert, nur weil man gerade "nebenbei" mit Admin-Rechten eingeloggt war.
Der richtige Umgang mit Schemata und Eigentümerschaft
Das ist der Punkt, an dem die meisten Junior-DBAs verzweifeln. Du erstellst eine Rolle, gibst ihr SELECT-Rechte auf eine Tabelle, und sie bekommt trotzdem einen "Permission Denied"-Fehler. Warum? Weil Postgres ein zweistufiges System hat. Du brauchst das USAGE-Recht auf dem Schema UND das SELECT-Recht auf der Tabelle.
Ich habe bei einem großen Logistikdienstleister in Hamburg gearbeitet, wo sie versuchten, ein Mandantensystem über Rollen abzubilden. Sie hatten hunderte Rollen angelegt, aber das Schema-Konzept nicht verstanden. Das Resultat war ein Berechtigungs-Wildwuchs, den niemand mehr durchblickte. Die Lösung war radikal: Wir haben alle Rollen gelöscht und von vorne angefangen.
Hier ist eine Liste der Dinge, die du sofort nach der Rollenerstellung prüfen musst:
- Hat die Rolle
USAGEauf dem Schema? - Wurden die
DEFAULT PRIVILEGESgesetzt, damit zukünftige Tabellen automatisch die richtigen Rechte erhalten? - Ist der
search_pathfür die Rolle korrekt gesetzt, damit sie nicht jedes Malschema_name.tabelleschreiben muss?
Ohne ALTER DEFAULT PRIVILEGES wirst du zum Sklaven deiner eigenen Datenbank. Jedes Mal, wenn die Applikation eine neue Tabelle erstellt, musst du manuell ran und die Rechte korrigieren. Das ist verschwendete Lebenszeit. Einmal richtig konfiguriert, läuft das System jahrelang von allein.
Monitoring und das Löschen von Rollen
Rollen zu erstellen ist einfach, sie wieder loszuwerden ist die Hölle. Wenn du versuchst, eine Rolle zu löschen, die noch Eigentümer von Objekten ist, wirft Postgres einen Fehler. "Role cannot be dropped because some objects depend on it."
In meiner Zeit als Berater war das die häufigste Aufgabe: "Cleanup". Wir mussten Skripte schreiben, die erst die Eigentümerschaft auf eine Systemrolle übertragen (REASSIGN OWNED BY), dann alle Privilegien entziehen (DROP OWNED BY) und erst dann die Rolle löschen konnten. Das dauert bei großen Datenbanken mit Millionen von Objekten Stunden und blockiert unter Umständen andere Prozesse.
Prävention ist hier alles. Erstelle niemals Tabellen unter einem personengebundenen Account. Tabellen gehören immer einer Applikations-Rolle oder einer neutralen Besitzer-Rolle. Wenn der Mitarbeiter das Unternehmen verlässt, kannst du seinen persönlichen Login-Account sofort löschen, ohne dass die Datenbankapplikation stehen bleibt. Ich habe gesehen, wie eine gesamte E-Commerce-Plattform offline ging, weil der Account des ehemaligen CTOs gelöscht wurde, dem die Kern-Tabellen der Produktdatenbank gehörten. Die Wiederherstellung der Zugriffsrechte dauerte vier Stunden – vier Stunden ohne Umsatz.
Realitätscheck
Kommen wir zum Punkt: Postgres-Administration ist kein "Learning by Doing" auf dem Livesystem. Wenn du glaubst, dass du mit ein paar Google-Suchen ein sicheres Rollenkonzept aufbaust, irrst du dich gewaltig. Die Syntax ist simpel, aber die Auswirkungen der Architektur sind komplex.
Erwarte nicht, dass du in einer Woche zum Experten wirst. Ein solides Verständnis von Rollen und Rechten erfordert, dass du mindestens einmal ein System komplett gegen die Wand gefahren hast oder unter dem Druck eines Audits stehst. Sicherheit und Bequemlichkeit sind in der Datenbankwelt Feinde. Wenn dein Rollen-Setup sich "leicht und einfach" anfühlt, ist es höchstwahrscheinlich unsicher. Ein professionelles Setup ist am Anfang sperrig, weil es dich zwingt, über jeden Zugriff nachzudenken. Aber es ist das einzige, was dich ruhig schlafen lässt, wenn der nächste große Exploit in den Nachrichten auftaucht. Es gibt keine Abkürzung. Entweder du investierst jetzt die Zeit in ein sauberes Konzept, oder du zahlst später mit Datenverlust oder deiner Reputation. So einfach ist das.
