The Public Schema in PostgreSQL < 15 : An Underestimated Security Risk

The Public Schema in PostgreSQL: Security Risks and Changes in Version 15

If you use PostgreSQL, you probably think your database is secure and reliable. But what if I told you that PostgreSQL comes with a default security risk that could jeopardize your most sensitive data? Welcome to the Public Schema, the often-overlooked Achilles' heel of many PostgreSQL databases. Let’s explore how this issue impacts versions <15 and how it changed with version 15 and later.

What Is the Public Schema?

The Public Schema is a pre-installed schema that exists in every new PostgreSQL database. Its purpose is to provide a default location for objects like tables and functions. However, its behavior differs significantly depending on your PostgreSQL version.

In Versions <15

• All users in the database automatically have access to it.
• Any user created in the database can create objects in the Public Schema.
• These objects are visible and accessible to other users by default unless you take steps to restrict access.

These default permissions can lead to significant security vulnerabilities, especially in multi-user environments.

In Versions >=15

• Default CREATE permissions are revoked: Users no longer have the ability to create objects in the Public Schema unless explicitly granted.
• The Public Schema is now owned by the database owner, improving control and security.
• Usage and access to the Public Schema must be explicitly defined.

These changes address many of the vulnerabilities associated with the Public Schema in earlier versions.

A Realistic Scenario: Data Leaks via the Public Schema

Imagine the following scenario in PostgreSQL versions <15:

1. You create a new user dev_user in your PostgreSQL database.
2. Without your knowledge, dev_user creates a table in the Public Schema:

   CREATE TABLE public.sensitive_data (id SERIAL, secret TEXT);

3. Another user in the database, such as analyst_user, automatically has access to this table:

   SELECT * FROM public.sensitive_data; -- Success!

In versions >=15, this scenario is no longer possible by default because the CREATE permissions are revoked for all users in the Public Schema.

How to Secure the Public Schema

The good news? You can secure the Public Schema in any PostgreSQL version with a few targeted steps:

For Versions <15

1. Revoke default access to the Public Schema:

   REVOKE ALL ON SCHEMA public FROM PUBLIC;
   REVOKE USAGE ON SCHEMA public FROM PUBLIC;

2. Grant access only to specific users:

   GRANT USAGE, CREATE ON SCHEMA public TO admin_user;

3. Create dedicated 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;

For Versions >=15

1. Review and adjust schema permissions: Ensure only necessary users have access to the Public Schema.

   GRANT USAGE ON SCHEMA public TO trusted_user;

2. Use the database owner role: Manage permissions through the `pg_database_owner` role to maintain control over the Public Schema.
3. Regularly review permissions:

   SELECT grantee, privilege_type 
   FROM information_schema.role_schema_grants 
   WHERE schema_name = 'public';

Be Cautious During Migrations

When migrating databases, be aware that the default behavior of the Public Schema can be carried over depending on the migration method. For example:

• Dump-and-restore methods may replicate old permissions unless explicitly modified.
• Replication tools can preserve Public Schema configurations, unintentionally introducing outdated security risks into the new environment.

Always review and adjust schema permissions as part of your migration process to ensure the new setup complies with your security standards.

Conclusion: The Public Schema – Convenience or Catastrophe?

The Public Schema has been a longstanding security concern in PostgreSQL, especially in versions <15. With the changes introduced in version 15, many of these issues have been mitigated, but it remains essential to review and configure permissions to suit your specific needs.

By understanding the differences between PostgreSQL versions and applying best practices, you can ensure that your database is both secure and efficient.

Secure your data – whether you’re using PostgreSQL <15 or >=15!

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!

Willkommen bei Datenakrobat – Dein Blog für Oracle und PostgreSQL

 

Willkommen bei Datenakrobat – Dein Blog für Oracle und PostgreSQL

Hallo und herzlich willkommen auf Datenakrobat! 🎉
Hier dreht sich alles um Datenbanken – mit einem besonderen Fokus auf Oracle und PostgreSQL. Egal, ob du ein Anfänger bist, der die ersten Schritte in der Welt der relationalen Datenbanken macht, oder ein erfahrener Profi, der tiefer in die Materie eintauchen möchte: Dieser Blog ist für dich.

---

Was erwartet dich auf Datenakrobat?

Wir verstehen, dass Datenbanken manchmal komplex und herausfordernd wirken können. Deshalb bieten wir dir:

• Praktische Tutorials: Lerne, wie du Oracle und PostgreSQL effizient einrichtest, nutzt und optimierst.
• Vergleiche und Analysen: Erfahre, wie sich die beiden Systeme unterscheiden und welches für deinen Anwendungsfall besser geeignet ist.
• Tipps für Migrationen: Wechselst du von Oracle zu PostgreSQL (oder umgekehrt)? Wir zeigen dir, wie es geht.
• Technische Insights: Von Performance-Tuning bis hin zu Sicherheitsmaßnahmen.

---

Unser erster Deep-Dive: Das Data Dictionary

Unser nächster Beitrag taucht direkt in die Praxis ein:
"Data Dictionary: Oracle vs. PostgreSQL – So findest du alle Infos zu Objekten und Benutzern".

Das Data Dictionary ist das Herzstück jeder Datenbank. Es enthält alle Metadaten – von Tabellen, Views und Indizes bis hin zu Benutzern, Rollen und Berechtigungen. Wir vergleichen die Ansätze von Oracle und PostgreSQL und zeigen dir, wie du die wichtigsten Informationen mit wenigen Abfragen erhältst.

• Welche Tabellen gehören einem Benutzer?
• Welche Berechtigungen hat ein Nutzer?
• Wo finde ich Details zu Spalten und Datentypen?

Sei gespannt auf eine praktische und verständliche Einführung in eines der mächtigsten Werkzeuge beider Systeme!

---

Mach mit und werde Teil der Datenakrobat-Community!

Hast du Fragen, Vorschläge oder ein bestimmtes Thema, das dich interessiert? Schreib uns in den Kommentaren oder per Nachricht. Gemeinsam können wir diesen Blog zu einer Wissensquelle für Datenbankbegeisterte machen.

Bleib dran, wir sehen uns beim nächsten Beitrag! 🚀
Bis dahin,
Das Datenakrobat-Team