Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m290_guko:learningunits:lu12:theorie:a_einfuerung [2025/11/11 21:28] – gkoch
+++ modul:m290_guko:learningunits:lu12:theorie:a_einfuerung [2025/11/12 00:13] (aktuell) – gkoch
@@ Zeile 1: / Zeile 1: @@
-====== LU12a: Data Security & User Management (DCL) – Rollen & Berechtigungen ======
+====== LU12a - Data Security & User Management (DCL) ======
 <WRAP round 80% box center>
-**Lernziele (gemäss Bildungsplan)**
+**MySQL 9.4** · In **zwei Seiten** bauen wir mit der Beispiel-WordPress-Datenbank des Reiseblogs **wetraveltheworld.de** ein sauberes **User-, Rechte- und Rollen-Konzept** auf.
-  * **Rollen/Berechtigungen** vergeben (**GRANT/REVOKE**, Benutzer & Rollen verwalten)
+Die Lernenden kennen die Blog-Autor:innen bereits aus den JOIN-Übungen: **Caro Steig**, **Martin Merten** und **Shaolin Tran**.
-  * **Datensicherheit/Datenschutz**: Prinzipien & schützenswerte Daten erkennen
-  * MySQL-spezifische **DCL-Befehle** (MySQL **9.4**) sicher anwenden
 </WRAP>
-<WRAP info round 80% center>
-**Voraussetzungen**
-  * MySQL **9.4**, WebStorm mit DB-Plugin, Root-Verbindung vorhanden.
-  * Achtung: Für Produktivsysteme nie mit ''root'' arbeiten – im Unterricht nutzen wir ''root'' **nur** zum Einrichten.
-</WRAP>
-===== 0) Kontext & Prinzipien =====
-  * **Least Privilege**: Jeder Account erhält nur die **minimal** benötigten Rechte.
-  * **Trennung nach Aufgaben**: Lese-User (**RO**)((**RO = Read-Only**: darf nur lesen (SELECT).)), Schreib-User (**RW**) ((**RW = Read-Write**: darf lesen + schreiben (SELECT/INSERT/UPDATE/DELETE).)), Admin-User (DDL/Grants).
-  * **Datenschutz**: Personenbezug erkennen (**PII**) ((**PII = Personally Identifiable Information**: personenbezogene Daten wie Name, E-Mail, Adresse, Geburtsdatum.)), Zugriff beschränken, Backups schützen.
-==== 0.1) Was ist der **root**-User – wofür (nicht)? ====
-<WRAP round 80% box>
-**root** ist der **Superuser** von MySQL: hat **alle** Rechte auf dem Server (Benutzer/Grant-Verwaltung, alle Schemas, alle Objekte).
-**Verwenden für:** Installation/Initialkonfiguration, **Benutzer/Rollen anlegen**, **Rechte vergeben**, **DDL/Administration**, Backups testen.
-**Nicht verwenden für:** Applikationsbetrieb, tägliche Abfragen, Unterrichtsübungen mit normalem CRUD – hier **dedizierte Rollen/Benutzer** (RO/RW) einsetzen.
-**Warum?** Minimierung von Risiken (Fehlbedienung, Datenabfluss), bessere Nachvollziehbarkeit (Auditing), saubere Trennung von Verantwortlichkeiten.
-</WRAP>
-===== 1) Begriffe – einfach erklärt =====
-<WRAP round 80% box>
-**Datenbank vs. Schema**
-In MySQL sind **„Datenbank“** und **„Schema“** **synonym** (''CREATE DATABASE …''). Eine **Tabelle** ist eine Struktur innerhalb der Datenbank (Zeilen/Spalten).
-**Benutzer (User)**
-Login-Identität in der Form ''user'@'host'' (z. B. ''app_ro'@'localhost''). Steuert **wer** sich **woher** verbinden darf.
-**Rolle (Role)**
-Bündel aus **Rechten** (Privilegien). Erleichtert Verwaltung: Rechte **einmal** an die Rolle vergeben, Rolle an **viele Benutzer** zuweisen.
-**Grant (Privileg)**
-Konkrete **Berechtigung**, z. B. ''SELECT'' auf eine Tabelle oder ''ALL PRIVILEGES'' auf ein Schema. Mit **GRANT/REVOKE** vergeben/entziehen.
-</WRAP>
-==== 1.1) Wo wirken Rechte? (Ebenen) ====
-<WRAP round 80% box>
-^ Ebene ^ Beispiel ^ Typische Grants ^
-| **Global** (Serverweit) | alles auf dem Server | ''CREATE USER'', ''SUPER'', ''RELOAD'' |
-| **Datenbank/Schema** | ''app_demo.*'' | ''SELECT'', ''INSERT'', ''ALL PRIVILEGES'' |
-| **Tabelle** | ''app_demo.notes'' | ''SELECT'', ''UPDATE'' |
-| **Spalte** | ''notes(owner)'' | ''SELECT(owner)'' |
-| **Routine** | ''PROCEDURE p_sync'' | ''EXECUTE'' |
-</WRAP>
-//Hinweis: Hier folgt in der Stunde eine **Grafik** (Levels-Diagramm).//
-==== 1.2) Benutzer vs. Rollen vs. Grants – auf einen Blick ====
-<WRAP round 80% box>
-^ Begriff ^ Kurzdefinition ^ Beispiel-Befehl ^
-| **Benutzer** | Wer darf sich von **wo** verbinden? | ''CREATE USER 'app_ro'@'localhost' IDENTIFIED BY '…';'' |
-| **Rolle** | Bündel von Rechten, mehrfach nutzbar | ''CREATE ROLE 'app_read'; GRANT SELECT ON app_demo.* TO 'app_read';'' |
-| **Grant** | Konkrete Berechtigung | ''GRANT SELECT ON app_demo.* TO 'app_ro'@'localhost';'' |
-| **Zuweisung** | Rolle → Benutzer | ''GRANT 'app_read' TO 'app_ro'@'localhost';'' |
-| **Aktivierung** | Standardrolle setzen | ''SET DEFAULT ROLE 'app_read' TO 'app_ro'@'localhost';'' |
-</WRAP>
-==== 1.3) Hosts – ''localhost'' vs. ''%'' ====
-<WRAP round 80% box>
-**''user'@'host''** bestimmt, **von wo** der Login erlaubt ist.
-• **''localhost''**: Zugriffe **vom gleichen Rechner** (oft via Unix-Socket).
-• **''%''**: **beliebiger Host** (Vorsicht, nur wenn nötig!).
-• **Spezifische Hosts/IPs**: z. B. '''app_ro'@'192.168.1.%'’' (nur internes Netz).
-**Best Practice:** so **eng wie möglich** einschränken (z. B. nur App-Server IP), nie unnötig ''%''.
-</WRAP>
-===== 2) Schritt-für-Schritt: Rollen & Benutzer anlegen =====
-<WRAP tip round 80% center>
-**Ziel**: Demo-Datenbank ''app_demo'' + Rollen ''app_read'', ''app_write'', ''app_admin'' + passende Benutzer (RO/RW/Admin).
-**Werkzeug**: WebStorm → Datenbank → SQL-Konsole (als ''root'').
-</WRAP>
-<WRAP round 80% box>
-**2.1 Demo-Schema & Tabelle**
-<code sql>
-CREATE DATABASE IF NOT EXISTS app_demo;
-USE app_demo;
-CREATE TABLE IF NOT EXISTS notes(
-  id INT PRIMARY KEY AUTO_INCREMENT,
-  owner VARCHAR(64) NOT NULL,
-  body  TEXT
-);
-</code>
-**2.2 Rollen definieren**  (MySQL **8+ / 9.4**)
-<code sql>
-CREATE ROLE IF NOT EXISTS 'app_read', 'app_write', 'app_admin';
-GRANT SELECT                         ON app_demo.* TO 'app_read';
-GRANT SELECT, INSERT, UPDATE, DELETE ON app_demo.* TO 'app_write';
-GRANT ALL PRIVILEGES                 ON app_demo.* TO 'app_admin';
-</code>
-**2.3 Benutzer anlegen (lokal)**
-<code sql>
-CREATE USER IF NOT EXISTS 'app_ro'@'localhost'    IDENTIFIED BY 'Str0ng!Ro';
-CREATE USER IF NOT EXISTS 'app_rw'@'localhost'    IDENTIFIED BY 'Str0ng!Rw';
-CREATE USER IF NOT EXISTS 'app_admin'@'localhost' IDENTIFIED BY 'Str0ng!Admin';
-</code>
-**2.4 Rollen zuweisen & Standardrolle setzen**
-<code sql>
-GRANT 'app_read'  TO 'app_ro'@'localhost';
-GRANT 'app_write' TO 'app_rw'@'localhost';
-GRANT 'app_admin' TO 'app_admin'@'localhost';
-SET DEFAULT ROLE 'app_read'  TO 'app_ro'@'localhost';
-SET DEFAULT ROLE 'app_write' TO 'app_rw'@'localhost';
-SET DEFAULT ROLE 'app_admin' TO 'app_admin'@'localhost';
-</code>
-**2.5 Kontrolle**
-<code sql>
-SHOW GRANTS FOR 'app_rw'@'localhost';
-</code>
-</WRAP>
-===== 3) Test: Rollen wirken lassen =====
 <WRAP round 80% box center>
-**Als ''app_ro'' verbinden** (neue Verbindung in WebStorm).
+**Wichtig (Abgrenzung WordPress vs. MySQL):**
-Erwartung: ''SELECT'' ✅, ''INSERT/UPDATE/DELETE'' ❌.
+WordPress-**Rollen** (z. B. **Administrator**, **Redakteur**, **Autor**) sind **Anwendungs-Rollen** innerhalb von WordPress.
+Hier modellieren wir **MySQL-Rollen** (DB-Rechte). Wir bilden die WP-Rollen **sinngemäss** ab, damit ihr Least-Privilege auf DB-Ebene versteht.
+Im echten WP-Betrieb verwendet man i. d. R. **einen** DB-Benutzer mit definierten Rechten; App-Rollen regelt WordPress selbst.
 </WRAP>
+===== Was ist der root-User? =====
 <WRAP round 80% box>
-**3.1 Read-Only testen**
+**root** ist der **Superuser** von MySQL: hat **alle** Rechte auf dem Server (alle Datenbanken, Benutzerverwaltung, Serveroperationen).
-<code sql>
+**Verwenden für:** Installation, **Benutzer/Rollen anlegen**, **Rechte vergeben/entziehen**, Backups testen.
--- als app_ro
+**Nicht verwenden für:** Applikationsbetrieb, tägliche Queries. Dafür dedizierte **RO**- (Read-Only) und **RW**-Benutzer (Read-Write) einsetzen (**Least Privilege**).
-USE app_demo;
-SELECT * FROM notes;  -- sollte funktionieren
-INSERT INTO notes(owner, body) VALUES ('lisa','hello');  -- sollte fehlschlagen (permission)
-</code>
-**3.2 Rechte ändern (root)**
-<code sql>
--- als root
-REVOKE 'app_write' FROM 'app_rw'@'localhost';
-GRANT  'app_read'  TO   'app_rw'@'localhost';
-SHOW GRANTS FOR 'app_rw'@'localhost';
-</code>
 </WRAP>
-===== 4) Feingranular & Sicherheit =====
+===== Grundbegriffe (einfach) =====
 <WRAP round 80% box>
-**Spaltenrechte**
+^ Begriff ^ Kurz erklärt ^ Beispiel ^
-<code sql>
+| **Datenbank/Schema** | In MySQL synonym; Container für Tabellen | ''CREATE DATABASE app_demo;'' |
-GRANT SELECT(id, owner) ON app_demo.notes TO 'app_ro'@'localhost';
+| **Tabelle** | Struktur mit Zeilen/Spalten | ''CREATE TABLE notes(...);'' |
-</code>
+| **Benutzer** | Login-Identität ''user''@''host'' | ''CREATE USER 'eva'@'localhost' ...;'' |
+| **Host** | Woher der Login kommen darf | ''localhost'' = gleicher Rechner; ''%'' = von überall (vorsichtig!) |
-**Passwort-Policy & Ablauf**
+| **Grant (Privileg)** | Konkrete Berechtigung (z. B. SELECT) | ''GRANT SELECT ON db.* TO ...;'' |
-<code sql>
+| **Rolle** | Bündel aus Rechten; an viele Benutzer zuweisbar | ''CREATE ROLE 'app_read';'' |
-ALTER USER 'app_rw'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
-ALTER USER 'app_rw'@'localhost' ACCOUNT LOCK;   -- bei Bedarf
--- ALTER USER 'app_rw'@'localhost' ACCOUNT UNLOCK;
-</code>
-**Benutzer & Hosts auflisten**
-<code sql>
-SELECT user, host FROM mysql.user ORDER BY user, host;
-</code>
-</WRAP>
-===== 5) Mini-Quiz (Kontrollfragen) =====
-  * Worin unterscheiden sich **Benutzer**, **Rollen** und **Grants** – und wie spielen sie zusammen?
-  * Warum ist ''GRANT ALL ON *.*'' für App-User problematisch?
-  * Was bedeutet ''user'@'localhost'' vs. ''user'@'%' – und welche Risiken bestehen?
-  * Bonus: Warum gehört **root** nicht in den Applikationsbetrieb?
-<WRAP alert round 80% center>
-**Best Practice**
-  * Keine App unter ''root'' betreiben.
-  * Host einschränken (''localhost''/IP statt ''%'').
-  * Rollen verwenden (RO/RW/Admin).
-  * Passwörter rotieren; Accounts sperren/ablaufen lassen.
-  * Backups schützen (siehe **LU12B**).
-  * Im Code **Prepared Statements** verwenden (Thema in der Backend-LU).
 </WRAP>