LU12c: MySQL – Rollen & Berechtigungen im Reiseblog

MySQL-Benutzerkonten werden dagegen im System mysql.user gespeichert, z. B.:

* 'caro'@'%' * 'travel_app'@'localhost'

Wichtig: Die Einträge in travel_blog.users und in mysql.user sind zwei verschiedene Ebenen, auch wenn sie zufällig gleich heissen:

* travel_blog.users → Wer darf sich im Reiseblog einloggen? (Anwendung) * mysql.user → Wer darf direkt mit MySQL sprechen? (Datenbank)

Diese Trennung ist wichtig für Datenschutz (DSG/DSGVO) und Datensicherheit.

—

Best Practice: ''root'' nur für Administration

Der Benutzer root wird bei der MySQL-Installation automatisch erstellt.

* root hat volle Kontrolle über den Server (alle Datenbanken, alle Tabellen, alle Benutzer). * Anwendungen sollten niemals mit root arbeiten.

Besser ist:

* eine Admin-Benutzerin (z. B. caro) mit einer Admin-Rolle (db_admin), * ein eigener technischer Benutzer für die Anwendung (z. B. travel_app), der nur die minimal nötigen Rechte erhält.

So setzen Sie das Prinzip der minimalen Privilegien (Need-to-know) auch auf Datenbankebene um.

—

Schritt 1: travel_blog-Datenbank vorbereiten

Annahme: Die Datenbank travel_blog mit den Tabellen posts, users, categories, post_category existiert bereits.

Wir ergänzen eine Tabelle comments für Blog-Kommentare:

USE travel_blog;
 
CREATE TABLE comments (
id INT AUTO_INCREMENT PRIMARY KEY,
post_id INT NOT NULL,
user_id INT NOT NULL,
comment_text TEXT NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_comments_post
FOREIGN KEY (post_id) REFERENCES posts(id)
ON DELETE CASCADE,
CONSTRAINT fk_comments_user
FOREIGN KEY (user_id) REFERENCES users(id)
ON DELETE CASCADE
); 

Damit ist klar, wo Kommentare gespeichert werden und wie sie mit Posts und Benutzer*innen verknüpft sind.

—

Schritt 2: Zwei Rollen definieren

Wir vereinfachen bewusst und arbeiten nur mit zwei Rollen:

* einer Admin-Rolle für die verantwortliche Person im Projekt, * einer Anwendungsrolle für den technischen Zugriff der Webanwendung.

Rolle 1: ''db_admin''

* volle Rechte auf travel_blog.* * darf Rechte weitergeben (GRANT OPTION) * gedacht für: Caro Steig (Admin im Reiseblog-Projekt)

Rolle 2: ''blog_app''

* SELECT, INSERT, UPDATE, DELETE auf allen Tabellen in travel_blog * keine Berechtigungen, die Struktur zu ändern (kein CREATE TABLE, kein DROP usw.) * gedacht für: den technischen Benutzer travel_app (Backend / Node.js / Express)

Rollen in MySQL anlegen

CREATE ROLE db_admin;
CREATE ROLE blog_app; 

Merksatz: Berechtigungen werden an Rollen vergeben. Die eigentlichen Benutzer erhalten später nur Rollen – nicht einzelne Privilegien.

—

Schritt 3: Rechte an Rollen vergeben (GRANT)

Nun legen Sie fest, was die beiden Rollen genau dürfen.

Rolle ''db_admin'' – volle Kontrolle über travel_blog

GRANT ALL PRIVILEGES
ON travel_blog.*
TO db_admin
WITH GRANT OPTION; 

Die Rolle db_admin kann damit alles in der Datenbank travel_blog tun (Tabellen anlegen, Daten ändern, Rechte vergeben usw.). Sie ist vergleichbar mit einer Schulleitung / IT-Administration im Schulbeispiel.

Rolle ''blog_app'' – Lesen und Schreiben, aber keine Strukturänderungen

GRANT SELECT, INSERT, UPDATE, DELETE
ON travel_blog.*
TO blog_app; 

Die Rolle blog_app darf:

* Daten lesen (SELECT), * neue Datensätze anlegen (INSERT), * vorhandene Datensätze ändern (UPDATE), * Datensätze löschen (DELETE).

Sie darf aber keine Tabellen anlegen oder löschen und keine Rechte vergeben. Damit ist die Schadenswirkung im Falle eines Fehlers oder Angriffs deutlich begrenzt – ganz im Sinne von DSG/DSGVO.

—

Schritt 4: Zwei Benutzer erstellen

Jetzt legen Sie genau zwei MySQL-Benutzer an:

* eine Admin-Benutzerin (caro), * einen technischen Benutzer für die Anwendung (travel_app).

Benutzer anlegen (CREATE USER)

CREATE USER 'caro'@'%'
IDENTIFIED BY 'CaroS!2025';
 
CREATE USER 'travel_app'@'localhost'
IDENTIFIED BY 'TravelApp!2025'; 

Hinweise:

* 'caro'@'%' → Caro darf sich von überall her mit passenden Zugangsdaten verbinden (nur zu Demonstrationszwecken). * 'travel_app'@'localhost' → Die Anwendung darf nur vom Server selbst aus auf MySQL zugreifen. * In der Praxis sollten Sie selbstverständlich stärkere und individuelle Passwörter verwenden.

Rollen an Benutzer zuweisen (GRANT … TO)

GRANT db_admin
TO 'caro'@'%';
 
GRANT blog_app
TO 'travel_app'@'localhost'; 

Damit ist die Zuordnung klar und leicht erklärbar:

* Caro ist fachlich und technisch verantwortlich für die Datenbank travel_blog (Admin-Rolle). * travel_app ist eine reine Service-Kennung für den Webserver / das Backend und arbeitet mit eingeschränkten Rechten.

—

Schritt 5: Rechte kontrollieren (SHOW GRANTS)

Mit SHOW GRANTS können Sie jederzeit prüfen, welche Rechte ein Benutzer effektiv besitzt.

SHOW GRANTS FOR 'caro'@'%';
SHOW GRANTS FOR 'travel_app'@'localhost'; 

So können Sie im Unterricht sehr gut sichtbar machen:

* Admin-Benutzerin caro → viele Rechte (über die Rolle db_admin), * Anwendungsbenutzer travel_app → nur die minimal nötigen Rechte (blog_app).

Wenn sich später Aufgaben ändern (z. B. eine andere Person übernimmt die Adminrolle), können Sie einfach:

* eine neue Benutzerkennung anlegen, * die Rolle db_admin von caro entziehen und der neuen Person geben.

Das Berechtigungskonzept bleibt dabei klar und einfach.

—

Verbindung zu DSG/DSGVO & Schulbeispielen

Mit diesen zwei Rollen und zwei Benutzern setzen Sie bereits zentrale Datenschutzprinzipien um:

* Schutz vor unbefugtem Zugriff:

• Nur db_admin und blog_app haben Zugriff auf travel_blog.

* Prinzip der minimalen Privilegien:

• Die Anwendung arbeitet nicht mit root, sondern mit travel_app und eingeschränkten Rechten.

* Vertraulichkeit und Integrität:

• Strukturänderungen und Rechtevergabe sind nur über die Adminrolle möglich, nicht über die Anwendung.

Die Logik entspricht den Schulbeispielen (WebUntis, Moodle, Absenzen-Tool, Notenbuch, Lohnliste):

* Die „Schulleitung/IT“ entspricht hier der Rolle db_admin (Caro). * Die „Fachanwendung“ (z. B. Absenzen-Tool) entspricht hier dem Benutzer travel_app mit Rolle blog_app.

In früheren Lerneinheiten (LU08, LU09) haben Sie Daten modelliert, in Beziehung gesetzt und abgefragt. Jetzt ergänzen Sie die Frage:

* Wer darf was mit diesen Daten tun?

Genau das ist der Kern des Handlungsziels: Rollen und Berechtigungen vergeben, um Datensicherheit und Datenschutz (DSG/DSGVO) zu gewährleisten.