Aufgabe 11 - Benutzer und Rechte

Exercise 11 - Berechtigungskonzepte & Least Privilege in PostgreSQL

Szenario: Unternehmens DB Security Hardening

Sie sind in einem Team für die Datenbankarchitektur verantwortlich und müssen nun das Sicherheitskonzept implementieren. Das Unternehmen ist ein Streamingdienstleister und hat strikte Compliance-Vorgaben: Ein “Superuser“ darf im Tagesgeschäft nicht verwendet werden. Jede Anwendung und jeder Mitarbeiter darf nur exakt die Rechte besitzen, die für die jeweilige Aufgabe zwingend erforderlich sind (Principle of Least Privilege).

Sie sind als Database Security Engineer beauftragt, das Rollenkonzept zu entwerfen und die kritische Unterscheidung zwischen Ownership und Privileges abzusichern.

Auftrag 1 - Konzepte der Zugriffskontrolle

Verfassen Sie einen kompakten Text (ca. 1/2 Seite), der die theoretischen Grundlagen für die Geschäftsleitung erläutert. Gehen Sie dabei auf folgende Punkte ein:

Authentifizierung vs. Autorisierung: Erklären Sie den Unterschied zwischen dem Login und der Rechteprüfung.
Das Schichtenmodell in PostgreSQL: Kann ein User trotz Tabellenrechten scheitern, wenn CONNECT- oder USAGE-Rechte fehlen? Erläutern Sie die verschiedenen Ebenen der Zugriffskontrolle (Datenbank, Schema, Objekt).
Rollen-Vererbung: Erklären Sie den Vorteil von Gruppenrollen gegenüber der direkten Rechtevergabe an einzelne User.

Auftrag 2 - Rollen-Steckbriefe & Sicherheitsanalyse

Erstellen Sie für die folgenden drei Standard-Rollentypen des Unternehmens jeweils einen kurzen Steckbrief in Fließtextform.

Migration-Role (Owner)
Application-Service-Role (DML)
Audit/Reporting-Role (Read-Only)

Der Steckbrief muss enthalten:

Typische SQL-Befehle, die diese Rolle ausführen darf (DML vs. DDL).
Notwendige Privilegien auf Datenbank-, Schema- und Objektebene.

Fügen Sie anschließend für das Konzept “Application-User als Owner” (ein häufiger Fehler) eine Analyse an:

PRO: (Finden Sie mindestens ein Argument, warum Entwickler dies oft so machen).
CON: Erläutern Sie mindestens drei konkrete Gefahren, insbesondere im Hinblick auf DROP und ALTER Befehle, die nicht durch REVOKE entzogen werden können.

Erstellen Sie in SQL die entsprechenden Rollen mit den notwendigen Privilegien und erläutern Sie die Unterschiede in der Rechtevergabe. Erzeugen Sie auch User-Accounts für die jeweiligen Rollen (z.B. migration_bot, app_user, report_bot) und weisen Sie ihnen die Rollen zu.

Erzeugen Sie zusätzliche Tabellen und Schemata, um die Unterschiede in der Rechtevergabe zu demonstrieren (z.B. billing Schema für die Reporting-Rolle, app_data Schema für die Application-Service-Role). Demonstrieren Sie mit SQL-Befehlen, wie die verschiedenen Rollen auf die Tabellen zugreifen können oder auch nicht, abhängig von den vergebenen Privilegien. Notieren Sie die Ergebnisse und Fehlermeldungen, um die Auswirkungen der Rechtevergabe zu verdeutlichen.

Auftrag 3 - Das “Hardened Schema” Szenario (Komplex)

Entwickeln Sie eine Strategie für den Bereich “Streaming-Abrechnung” des Unternehmens. Hier liegen sensible Rechnungsdaten.

Ownership-Strategie: Legen Sie fest, welche Rolle die Tabellen erstellt und warum der app_user niemals der Owner sein darf.
Das Schema-Dilemma: Das Unternehmen nutzt ein Schema namens billing. Welche Befehle sind nötig, damit ein neuer report_bot überhaupt die erste Zeile lesen kann? (Berücksichtigen Sie CONNECT, USAGE und SELECT) .
Die “Sehr Schwere” Herausforderung (Default Privileges):

Szenario: Ein Admin erstellt in absehbarer Zukunft eine neue Tabelle invoices_2026. Warum kann der report_bot diese trotz eines vorherigen GRANT SELECT ON ALL TABLES nicht lesen?.
Lösen Sie das Problem theoretisch mit dem Konzept der Default Privileges.

Ineinandergreifen der Typen: Definieren Sie ein Szenario, in dem ein api_user nur eine Stored Procedure ausführen darf (EXECUTE), ohne jedoch direkten Schreibzugriff (UPDATE, INSERT oder DELETE) auf die zugrunde liegende Tabelle zu haben.

Auftrag 4 - Realwelt-Sicherheitsvorfälle (Recherche)

Recherchieren Sie reale Beispiele oder technische Dokumentationen zu folgenden Sicherheitsaspekten:

SQL-Injection & Least Privilege - positive: Finden Sie ein Beispiel, wie begrenzte Datenbankrechte den Schaden eines erfolgreichen SQL-Injection-Angriffs in einer Webanwendung verhindert oder minimiert haben.
SQL-Injection & Least Privilege - negative: Finden Sie min. 3 Beispiele, wie begrenzte Datenbankrechte den Schaden eines erfolgreichen SQL-Injection-Angriffs in einer Webanwendung verhindert hätten können. Führen Sie im Schadensfall die entstandenen Schäden auf und erläutern Sie, wie eine bessere Rechtevergabe den Schaden hätte minimieren können.
Privilege Escalation: Suchen Sie nach dem Risiko von WITH GRANT OPTION oder SUPERUSER-Accounts in Cloud-Umgebungen (z.B. AWS RDS oder Azure Database for PostgreSQL).
Ownership-Probleme bei Teamarbeit: Welche Probleme entstehen in großen Projekten (z.B. wissenschaftliche Großprojekte), wenn “Mixed Ownership” herrscht?.

Abgabe

Erstellen Sie einen strukturierten Bericht für die Geschäftsleitung mit folgenden Teilen:

Erläuterung der Zugriffskonzepte (Authentifizierung vs. Autorisierung).
Steckbriefe der Rollen inkl. der kritischen Owner-Analyse.
Technisches Konzept für das “Least Privilege”-Billing-Szenario.
Reale Fallbeispiele zur Bedeutung von Datenbank-Sicherheit.

Zielsetzung: Präzise, technisch fundiert, Fokus auf Schadensminimierung durch Ownership-Trennung.

HTL Villach
INSY 2024-2025