Aufgabe 12 - Benutzer und Rechte mit Northwind

Aufgabe 12 - Benutzer und Rechte mit der Northwind-Datenbank

Worum geht es?

In dieser Übung wird an der Northwind-Datenbank ein Least-Privilege-Rollenkonzept praktisch angelegt, getestet und mit Systemviews überprüft (siehe Kapitel 5 - Benutzer und Rechte). Im Expertenteil werden fehlerhafte Rechtekonfigurationen systematisch diagnostiziert und behoben.

Was Sie dafür brauchen

• Kapitel 5 - Benutzer und Rechte.
• Ein PostgreSQL-Server; das Northwind-Schema von northwind_psql.

Welche Kompetenzen Sie erwerben und zeigen

• Sie legen Benutzer an und verstehen die Standardrechte in PostgreSQL.
• Sie vergeben abteilungsspezifische Rechte nach Least Privilege.
• Sie prüfen vergebene Rechte mit Systemviews.
• Sie diagnostizieren und beheben Fehlkonfigurationen systematisch.

Pädagogische Einordnung

• Reproduktion: Benutzer anlegen und den Standardzugriff testen (Teil A).
• Reorganisation und Transfer: abteilungsspezifische Rechte vergeben (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: Rechte analysieren und Fehler debuggen (Teile C und D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Benutzer und Standardrechte

1. Eine Datenbank northwind_permissions anlegen und Schema samt Daten importieren.
2. Drei Benutzer mit Login und Passwort anlegen: sales_user (Vertrieb), inventory_user (Produktverwaltung), report_user (Controlling).
3. Sich als sales_user anmelden und eine einfache Abfrage auf einer Northwind-Tabelle versuchen. Funktioniert der Zugriff sofort? Falls nicht: warum? Was sagt das über die Standardrechte aus?

Teil B - Abteilungsrechte

1. Vertrieb: sales_user bekommt nur Leserechte auf customers, orders, order_details. Testen: lesen (ok), ändern und löschen (blockiert).
2. Produktverwaltung: inventory_user darf products lesen und aktualisieren und suppliers lesen, aber nicht auf Kunden-/Bestelldaten zugreifen. Testen.
3. Controlling: report_user darf alle Tabellen lesen, aber nichts ändern. Testen: SELECT (ok), INSERT/UPDATE/DELETE (blockiert).

Teil C - Rechte prüfen und Rollen

1. Eine Systemview finden, die Tabellenprivilegien auflistet (z. B. information_schema.role_table_grants). Die Rechte auf customers analysieren und prüfen, welche Rechte sales_user hat.
2. Statt Einzelrechte eine Gruppenrolle für den Vertrieb entwerfen, ihr die nötigen Rechte geben und sales_user zuweisen. Begründen, warum Rollen in großen Systemen leichter zu verwalten sind.

Teil D - Expertenteil: Fehlkonfigurationen systematisch debuggen

Ein Admin hat Rechte falsch gesetzt. Diagnostizieren und beheben Sie drei Fälle, und dokumentieren Sie jeweils, wie Sie den Fehler systematisch gefunden haben (nicht durch Raten, sondern über information_schema.role_table_grants bzw. \dp).

1. Szenario 1: Der Vertrieb meldet ERROR: permission denied for table customers. Situation nachstellen, fehlendes Recht bestimmen (fehlt SELECT? oder USAGE auf dem Schema? oder CONNECT?), beheben.
2. Szenario 2: inventory_user erhält beim Produkt-Update ERROR: permission denied for table products. Analysieren, welches Recht für ein UPDATE nötig ist und welches der Benutzer tatsächlich hatte, dann korrigieren.
3. Szenario 3: report_user kann plötzlich Daten löschen. Die vergebenen Privilegien analysieren, das unnötige DELETE-Recht entziehen und nachweisen, dass nur noch SELECT bleibt.
4. Kapselung (Zusatz): Legen Sie eine Function an, die eine kontrollierte Änderung durchführt (SECURITY DEFINER), geben Sie sales_user nur EXECUTE darauf und zeigen Sie, dass er die Änderung über die Function ausführen kann, ohne direktes Schreibrecht auf der Tabelle zu haben.

Wissenscheck

1. Warum funktioniert eine Abfrage direkt nach dem Anlegen eines Benutzers oft noch nicht?
2. Welche Rechte braucht ein UPDATE mindestens?
3. Mit welcher Systemview prüft man Tabellenprivilegien?
4. Warum sind Gruppenrollen in großen Systemen leichter zu verwalten?
5. Wie diagnostiziert man ein permission denied systematisch statt durch Raten?

Abgabe

• Eine Dokumentation (1–2 Seiten) mit den angelegten Benutzern/Rollen, dem Nachweis der Rechte per Systemview, mindestens zwei dokumentierten Fehlermeldungen samt Erklärung und der Analyse mindestens eines Debugging-Szenarios aus Teil D.

---

HTL Villach, 2025-2026,
https://www.htl-villach.at