Montag, 6. Januar 2025

Das Public Schema in PostgreSQL: Ein unterschätztes Sicherheitsrisiko

Das Public Schema in PostgreSQL: Ein unterschätztes Sicherheitsrisiko

Das Public Schema in PostgreSQL: Ein unterschätztes Sicherheitsrisiko, das Ihre Daten gefährdet!

Wenn Sie PostgreSQL verwenden, denken Sie wahrscheinlich, dass Ihre Datenbank sicher und zuverlässig ist. Doch was wäre, wenn ich Ihnen sage, dass PostgreSQL standardmäßig ein potenzielles Sicherheitsrisiko enthält, das Ihre sensibelsten Daten gefährden könnte? Willkommen im Public Schema, der oft übersehenen Achillesferse vieler PostgreSQL-Datenbanken.

Was ist das Public Schema – und warum ist es ein Problem?

Das Public Schema ist ein vorinstalliertes Schema, das in jeder neuen PostgreSQL-Datenbank existiert. Klingt harmlos, oder? Nicht ganz. Die Besonderheit des Public Schemas liegt in seinen Standardberechtigungen:

  • Alle Benutzer in der Datenbank haben automatisch Zugriff darauf.
  • Jeder Benutzer, der in der Datenbank angelegt wird, kann im Public Schema Objekte erstellen.
  • Diese Objekte sind für andere Benutzer standardmäßig sichtbar und zugänglich, es sei denn, Sie ergreifen Maßnahmen, um den Zugriff einzuschränken.

Wenn das Public Schema nicht richtig konfiguriert wird, könnten Benutzer – absichtlich oder versehentlich – Sicherheitslücken öffnen, die Angreifern Tür und Tor öffnen.

Ein realistisches Szenario: Datenlecks durch das Public Schema

Stellen Sie sich folgendes Szenario vor:

  1. Sie legen in Ihrer PostgreSQL-Datenbank einen neuen Benutzer dev_user an.
  2. Ohne, dass Sie es merken, erstellt dev_user eine Tabelle im Public Schema:
    CREATE TABLE public.sensitive_data (id SERIAL, secret TEXT);
  3. Ein anderer Benutzer in der Datenbank, beispielsweise analyst_user, hat automatisch Zugriff auf diese Tabelle:
    SELECT * FROM public.sensitive_data; -- Erfolg!

Der Benutzer kann diese Daten einsehen, ohne dass Sie jemals explizit Zugriff gewährt haben. Das Problem? Sensible Informationen, wie Benutzerdaten, API-Schlüssel oder interne Analysen, könnten plötzlich für Benutzer zugänglich sein, die sie niemals sehen sollten.

Warum das Public Schema gegen das Prinzip der minimalen Rechte verstößt

Das Prinzip der minimalen Rechte (Least Privilege Prinzip) besagt, dass jeder Benutzer nur die minimal notwendigen Berechtigungen haben sollte, um seine Aufgaben zu erfüllen. Doch das Public Schema unterläuft dieses Prinzip durch folgende Standardkonfigurationen:

  • CREATE-Rechte für alle Benutzer: Jeder Benutzer darf Objekte wie Tabellen, Views oder Funktionen im Public Schema erstellen.
  • USAGE-Rechte für alle Benutzer: Benutzer können auf Objekte im Public Schema zugreifen, selbst wenn sie keine expliziten Rechte haben.

Diese offenen Berechtigungen machen das Public Schema zu einer Schwachstelle, die Angriffe durch Insider oder fehlerhafte Konfigurationen ermöglicht.

Oracle vs. PostgreSQL: Warum Oracle hier sicherer ist

Im Vergleich dazu verhält sich Oracle deutlich restriktiver:

  • In Oracle hat ein Benutzer standardmäßig keinen Zugriff auf Objekte anderer Benutzer, es sei denn, die Berechtigungen werden explizit gewährt.
  • Benutzer in Oracle operieren innerhalb ihres eigenen Schemas, und alle Objekte sind standardmäßig privat.
  • Ein freigegebenes Schema wie Public gibt es in dieser Form nicht.

PostgreSQL hingegen geht davon aus, dass eine gemeinsame Nutzung des Public Schemas gewünscht ist – ein potenzielles Sicherheitsrisiko, das Oracle von Haus aus vermeidet.

Wie Sie das Public Schema sichern können

Die gute Nachricht? Sie können das Public Schema absichern, indem Sie ein paar gezielte Schritte unternehmen:

  1. Entziehen Sie den Standardzugriff auf das Public Schema:
    REVOKE ALL ON SCHEMA public FROM PUBLIC;
    REVOKE USAGE ON SCHEMA public FROM PUBLIC;
  2. Gewähren Sie nur bestimmten Benutzern Zugriff:
    GRANT USAGE, CREATE ON SCHEMA public TO admin_user;
  3. Erstellen Sie dedizierte Schemas:
    CREATE SCHEMA app_user_schema;
    GRANT USAGE ON SCHEMA app_user_schema TO app_user;
    GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA app_user_schema TO app_user;
  4. Regelmäßige Überprüfung der Berechtigungen:
    SELECT grantee, privilege_type 
    FROM information_schema.role_schema_grants 
    WHERE schema_name = 'public';

Fazit: Das Public Schema – Komfort oder Katastrophe?

Das Public Schema ist wie ein ungesicherter Tresor in einem ansonsten gut bewachten Gebäude. Wenn Sie PostgreSQL einsetzen, müssen Sie sich bewusst machen, dass dieses Schema standardmäßig nicht sicher ist.

Durch gezielte Konfiguration können Sie jedoch die Sicherheitsrisiken minimieren und PostgreSQL so konfigurieren, dass es dem Prinzip der minimalen Rechte gerecht wird. Ignorieren Sie das Public Schema jedoch, riskieren Sie Datenlecks, die Ihre gesamte Datenbank gefährden könnten.

Sichern Sie Ihre Daten – deaktivieren oder konfigurieren Sie das Public Schema noch heute!

Keine Kommentare:

Kommentar veröffentlichen