LU12b: Berechtigungskonzept & Rollenmodell

Sie können …

• erklären, was ein Berechtigungskonzept ist und warum es für DSG/DSGVO wichtig ist.
• das Prinzip der minimalen Privilegien (Least Privilege / Need-to-know) anwenden.
• Rollen und Rechte für typische Schulsysteme (WebUntis, Moodle, Notenbuch, etc.) beschreiben.

Ein Berechtigungskonzept beschreibt:

• wer (Rollen, Personen, Anwendungen) auf welche Daten und Systeme zugreifen darf mit welchen Aktionen (lesen, schreiben, löschen, ändern)

Es konzentriert sich auf interne Zugriffsrechte:

• Wer darf welche Personendaten sehen?
• Wer darf Daten ändern oder löschen?
• Wer darf neue Benutzer/Kurse/Klassen anlegen?

→ Es ist eine technische & organisatorische Massnahme gemäss DSG/DSGVO (Art. 32 DSGVO: Vertraulichkeit, Integrität, Verfügbarkeit).

Wichtig: Ein Berechtigungskonzept ersetzt keine anderen Sicherheitsmassnahmen wie Firewalls oder Verschlüsselung – es ergänzt sie.

Idee: Jede Person, jede Rolle, jede Anwendung erhält nur die Rechte, die sie für ihre Aufgabe unbedingt braucht – nicht mehr.

Warum ist das so wichtig?

• Risikominimierung: Weniger Rechte → kleinere Angriffsfläche.
• Schadensbegrenzung: Kompromittierter Account kann nur begrenzt Schaden anrichten.
• Compliance: DSG/DSGVO verlangen diese Begrenzung.
• Stabilität: Verhindert unbeabsichtigte Änderungen (z. B. versehentliches DROP TABLE).

Typische Fehler:

• Anwendung benutzt den root-Account der Datenbank.
• GRANT ALL PRIVILEGES auf alles, „damit es läuft“.
• Entwickler/*innen haben Vollzugriff auf Produktivdaten.

• Welche Systeme/Applikationen gibt es? (z. B. WebUntis, Moodle, Absenzen-Tool, Notenbuch, Lohnliste)
• Welche Daten werden dort verarbeitet? (Stundenpläne, Noten, Löhne, Absenzen …)
• Welche Rollen/Personen benötigen Zugriff? (Lehrpersonen, Lernende, Verwaltung, IT)

• Identitäten = Benutzerkonten (Menschen oder Anwendungen).
• Ähnliche Identitäten werden zu Rollen zusammengefasst.

Für jede Rolle definieren:

• Darf die Rolle lesen (SELECT)?
• Darf sie schreiben/ändern (INSERT/UPDATE)?
• Darf sie löschen (DELETE)?
• Darf sie Struktur ändern (DDL: CREATE/ALTER/DROP)?

Rollen basierend auf Aufgaben, z. B.:

• teacher_role
• student_role
• admin_role

Umsetzung des Need-to-know-Prinzips:

• Buchhaltung → sieht Finanzen, aber keine Noten.
• Lehrperson → sieht Noten ihrer Lernenden, nicht die Löhne der Kolleg:innen.
• Lernende → sehen Inhalte auf Moodle, aber können diese aber nicht ändern.

Im RDBMS (MySQL): Benutzer, Rollen, GRANT/REVOKE (siehe Seite 3).

In Applikationen: Identity Access Management (IAM), z. B. Azure AD, Role Management in Moodle. → mache das einfacher: gehe hier darauf ein, dass wir später ein Backendserver auf Nodejs und Express entwicklen, welcher entsprechende app-berechtigungen haben muss.

• Zugriff auf eigene Lektionen, Klassen, Räume.
• Rechte: SELECT auf Stundenplandaten für eigene Klasse / Fächer.

• Erfassen, ändern, löschen von Stundenplänen, Räumen, Klassenzuteilungen.
• Rolle: webuntis_admin
• Rechte (wahrscheinlich): SELECT, INSERT, UPDATE, DELETE auf Stundenplan-Tabellen.