Übungsaufgaben zu Benutzern und Rechten in SQL (DCL)

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „SQL: Benutzer und Rechte
verwalten (DCL)“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/sql-dcl
- https://oer-informatik.de/sql-ddl-basics
- Stilbeispiel: https://oer-informatik.de/sql-dcl-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- SQL
- DCL
- Berechtigungskonzept
- GRANT
- REVOKE
- Rollen
- Prinzip der minimalen Rechte
- MariaDB

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Authentifizierung: Beim Verbindungsaufbau prüft MariaDB, ob das Terminal das Konto benutzen darf, mit dem es sich meldet: Kontoname, Passwort und die Adresse, von der die Verbindung kommt (Hostteil, hier ein Rechner im Netz 172.20.40.0/24). (1 Punkt)

• Autorisierung: Danach prüft MariaDB bei jeder einzelnen Anweisung, ob das Konto sie ausführen darf – zum Beispiel, ob das Terminal den Status eines Termins ändern oder einen Auftrag anlegen darf. (1 Punkt)

Die Anleitung ist für PostgreSQL geschrieben. Die Anweisungen sehen ähnlich aus, gehören aber nicht zur MariaDB-Syntax. Je Anweisung 1 Punkt:

1. ENCODING 'UTF8' kennt MariaDB nicht; dort heißt es CHARACTER SET utf8mb4.

2. WITH PASSWORD heißt in MariaDB IDENTIFIED BY. Außerdem gehört zum Konto ein Hostteil, der festlegt, von wo aus es sich anmelden darf.

3. Ein Recht CONNECT auf eine Datenbank gibt es in MariaDB nicht. Die Anweisung entfällt: Jedes angelegte Konto darf sich anmelden (USAGE), Rechte auf Daten bekommt es erst mit GRANT.

4. ON ALL TABLES IN SCHEMA public heißt in MariaDB ON werkstattportal.*. Das Recht gilt dann auch für Tabellen, die später angelegt werden.

CREATE DATABASE werkstattportal CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_app'@'172.20.41.12' IDENTIFIED BY 'Wp!Portal_2027';
GRANT SELECT, INSERT, UPDATE, DELETE ON werkstattportal.* TO 'wp_app'@'172.20.41.12';

Bewertung: CREATE DATABASE mit dem Namen ohne Hochkommas 1 Punkt (die Zeichensatzangabe ist nicht gefordert), CREATE USER mit Hostteil '172.20.41.12' und Passwort in Hochkommas 1,5 Punkte, GRANT mit genau den vier Datenrechten auf werkstattportal.* 1,5 Punkte. Eine Anweisung für CONNECT gibt es nicht; wer ALL PRIVILEGES vergibt, erhält für das GRANT 0 Punkte, weil das Konto damit auch Tabellen löschen könnte.

Weil der MariaDB-Client beim ersten Fehler abbricht, hat Jonas’ Versuch nichts angelegt; das Skript kann also ohne Aufräumen ausgeführt werden.

Beurteilung (je Punkt 1 Punkt, höchstens 2 Punkte):

• ON *.* gilt für alle Datenbanken auf db-sen, also auch für fremde Daten, und schließt globale Rechte wie CREATE USER ein. Die Agentur braucht nur werkstattportal.

• WITH GRANT OPTION erlaubt der Agentur, selbst weitere Konten zu berechtigen; CSB-Rad verliert den Überblick, wer worauf zugreift.

• '%' erlaubt die Anmeldung von jedem Rechner. Wird das Passwort bekannt, kann es von überall benutzt werden; das VPN-Netz reicht aus.

Anweisungen (3 Punkte):

CREATE USER 'webwerk'@'172.20.240.%' IDENTIFIED BY 'Tw!Wartung_0127';
GRANT ALL PRIVILEGES ON werkstattportal.* TO 'webwerk'@'172.20.240.%';

Bewertung: Hostteil auf das VPN-Netz beschränkt 1 Punkt, ALL PRIVILEGES ON werkstattportal.* 1 Punkt, kein WITH GRANT OPTION 1 Punkt. ALL PRIVILEGES ist hier vertretbar, weil die Agentur bei Updates auch Tabellen ändern muss; es gilt aber nur innerhalb dieser einen Datenbank.

Bewertung: je Konto 2 Punkte. Für bludwig ist auch SELECT auf werkstattportal.* richtig. Wer beim Terminal UPDATE nur auf die Spalte status von termin vergibt, setzt die Anforderung noch enger um (volle Punktzahl). SELECT auf auftrag für das Terminal ist vertretbar, wenn es begründet wird. Nicht richtig sind Rechte auf arbeitszeit für nwrobel und DELETE für das Terminal.

CREATE USER 'wp_terminal'@'172.20.40.%' IDENTIFIED BY 'Annahme#40_ws';
GRANT SELECT, UPDATE ON werkstattportal.termin TO 'wp_terminal'@'172.20.40.%';
GRANT INSERT ON werkstattportal.auftrag TO 'wp_terminal'@'172.20.40.%';

GRANT SELECT ON werkstattportal.* TO 'bludwig';
GRANT INSERT, UPDATE ON werkstattportal.kostenvoranschlag TO 'bludwig';

GRANT SELECT ON werkstattportal.auftrag TO 'nwrobel';
GRANT SELECT ON werkstattportal.kostenvoranschlag TO 'nwrobel';

Bewertung: CREATE USER für das Terminal mit Hostteil und Passwort 1 Punkt, Rechte des Terminals 1 Punkt, Rechte für bludwig 1,5 Punkte, Rechte für nwrobel 1,5 Punkte (zwei Anweisungen, weil GRANT je Anweisung nur ein Objekt kennt), kein erneutes CREATE USER für die vorhandenen Konten 1 Punkt.

'bludwig' steht für 'bludwig'@'%'. Das Passwort enthält #; in Hochkommas ist das unproblematisch.

REVOKE ALL PRIVILEGES ON werkstattportal.* FROM 'webwerk'@'172.20.240.%';
ALTER USER 'webwerk'@'172.20.240.%' ACCOUNT LOCK;
SHOW GRANTS FOR 'webwerk'@'172.20.240.%';

Bewertung: REVOKE auf derselben Ebene wie das GRANT (werkstattportal.*) und mit FROM 1 Punkt, Sperren mit ACCOUNT LOCK 1 Punkt (DROP USER erfüllt die Vorgabe nicht, weil das Konto erhalten bleiben soll), Kontrolle mit SHOW GRANTS 1 Punkt. Danach zeigt SHOW GRANTS nur noch GRANT USAGE ON *.* …. Für die nächste Wartung genügen ALTER USER … ACCOUNT UNLOCK und ein neues GRANT.

1. Jede Anwendung und jedes Gerät meldet sich mit einem eigenen Datenbankkonto an. Das Konto root ist der Administration vorbehalten und darf nie in Konfigurationsdateien von Anwendungen oder Geräten gespeichert werden.

2. Konten erhalten nur die Rechte, die sie für ihre Aufgabe brauchen (Prinzip der minimalen Rechte). Anwendungen dürfen die Struktur von Tabellen nicht ändern können.

3. Brauchen mehrere Personen dieselben Rechte, wird eine Rolle angelegt; die Rechte werden der Rolle statt jedem einzelnen Konto gegeben.

4. Konten von Geräten werden auf das Netz beschränkt, in dem sich die Geräte befinden.

5. Konten von Personen, die die Schule verlassen, werden innerhalb einer Woche gesperrt oder gelöscht.

Bewertung: je Vorgabe 1 Punkt, wenn der Sinn vollständig wiedergegeben ist (bei 1: eigenes Konto und root-Verbot; bei 2: minimale Rechte und keine Strukturänderung). Eine wörtliche Übersetzung ist nicht nötig.

Bewertung: je richtiger Zuordnung 0,5 Punkte.

Mitglieder der Rolle rf_verwaltung: awolf und hbrinkmann.

Bewertung: rf_backend, rf_monitor und tbecker je 1 Punkt; Rolle auf nutzer 2 Punkte (für UPDATE gibt es den Punkt nur, wenn deutlich wird, dass nur die Einwilligung geändert werden darf; UPDATE auf die ganze Tabelle verstößt gegen Anforderung 4), Rolle auf klasse 1 Punkt, awolf auf haltepunkt mit Weitergaberecht 1 Punkt, Mitglieder 1 Punkt. Wer SELECT auf haltepunkt zusätzlich für Andrea Wolf einträgt, wird nicht abgewertet. Wer die Rechte für rf_backend in jeder Zeile einzeln einträgt statt in der Zeile *, erhält die volle Punktzahl. Ohne Rolle (alle Rechte einzeln an awolf und hbrinkmann) höchstens 2 Punkte für die Verwaltung, weil die Rolle vorgegeben ist.

CREATE USER 'rf_monitor'@'10.50.20.%' IDENTIFIED BY 'Fl8r!Mon_27';
GRANT SELECT ON ratzfahrt.v_monitor TO 'rf_monitor'@'10.50.20.%';

Bewertung:

• CREATE USER mit Konto und Passwort in Hochkommas: 1,5 Punkte

• Hostteil '10.50.20.%' (Beschränkung auf das VLAN 520, Anforderung 2 und Vorgabe 4 der Richtlinie): 1 Punkt; '%' oder kein Hostteil: 0 Punkte für diesen Teil

• GRANT SELECT ON ratzfahrt.v_monitor TO … mit demselben Konto: 1,5 Punkte

Ohne Datenbankangabe (ON v_monitor) ist die Anweisung richtig, wenn vorher USE ratzfahrt; ausgeführt wurde. Die Schreibweise '10.50.20.0/255.255.255.0' (Netzmaske) ist ebenfalls korrekt.

GRANT INSERT, UPDATE ON ratzfahrt.haltepunkt TO 'awolf' WITH GRANT OPTION;

Bewertung: INSERT, UPDATE 1 Punkt, ON ratzfahrt.haltepunkt TO 'awolf' 1 Punkt, WITH GRANT OPTION 1 Punkt. Kein CREATE USER, weil das Konto bereits existiert. SELECT zusätzlich zu vergeben ist sinnvoll (zum Nachsehen vorhandener Haltepunkte und für UPDATE … WHERE) und wird nicht abgewertet.

REVOKE INSERT, UPDATE, DELETE ON ratzfahrt.buchung FROM 'jwolff';
SHOW GRANTS FOR 'jwolff';

Bewertung: REVOKE mit den drei Rechten 1 Punkt, ON ratzfahrt.buchung 0,5 Punkte, FROM 'jwolff' 1,5 Punkte (mit TO statt FROM: 0 Punkte für diesen Teil), SHOW GRANTS FOR 'jwolff' 1 Punkt.

Das REVOKE muss auf derselben Ebene stehen wie das ursprüngliche GRANT (hier die Tabelle buchung). Wäre das Recht für ratzfahrt.* vergeben worden, ließe es sich nicht für die einzelne Tabelle entziehen. Das Konto jwolff bleibt bestehen; gelöscht würde es erst mit DROP USER, wenn Jonas die Schule verlässt (Vorgabe 5 der Richtlinie).

CREATE USER 'hbrinkmann' IDENTIFIED BY 'Sekr#Einw2027';
CREATE ROLE rf_verwaltung;

GRANT SELECT ON ratzfahrt.nutzer TO rf_verwaltung;
GRANT SELECT ON ratzfahrt.klasse TO rf_verwaltung;
GRANT UPDATE (einwilligung_eltern) ON ratzfahrt.nutzer TO rf_verwaltung;

GRANT rf_verwaltung TO 'awolf', 'hbrinkmann';
SET DEFAULT ROLE rf_verwaltung FOR 'awolf';
SET DEFAULT ROLE rf_verwaltung FOR 'hbrinkmann';

Bewertung:

• CREATE USER für hbrinkmann mit Passwort: 1 Punkt

• CREATE ROLE rf_verwaltung: 1 Punkt

• SELECT auf nutzer und klasse an die Rolle (zwei Anweisungen, weil GRANT je Anweisung nur ein Objekt kennt): 1 Punkt

• UPDATE (einwilligung_eltern) ON ratzfahrt.nutzer an die Rolle: 2 Punkte (UPDATE auf die ganze Tabelle: 0,5 Punkte)

• Rolle beiden Konten zugewiesen: 1 Punkt

• SET DEFAULT ROLE für beide Konten: 1 Punkt. Ohne diesen Schritt ist die Rolle in MariaDB zugewiesen, aber nicht aktiv; die Konten müssten sie in jeder Sitzung mit SET ROLE rf_verwaltung; einschalten.

Das Passwort enthält #. In Hochkommas ist das unproblematisch; ohne Hochkommas würde MariaDB alles ab # als Kommentar lesen.

1. Zeile 1: Das Passwort steht nicht in Hochkommas. Das ist ein Syntaxfehler; zusätzlich beginnt mit # in MariaDB ein Kommentar, sodass der Rest der Zeile ignoriert würde.

2. Zeile 2: ALL PRIVILEGES ON *.* gibt dem Backend alle Rechte auf alle Datenbanken des Servers, auch DROP, ALTER und CREATE USER. Das verstößt gegen das Prinzip der minimalen Rechte und gegen die Vorgabe, dass Anwendungen keine Tabellen ändern dürfen.

3. Zeile 3: Es fehlt das Objekt (ON ratzfahrt.*).

4. Zeile 4: REVOKE verlangt FROM statt TO. Außerdem würde das globale DROP aus Zeile 2 durch ein REVOKE auf Datenbankebene nicht entzogen, weil die Ebenen nicht übereinstimmen. Mit einem richtigen GRANT ist die Zeile überflüssig.

Korrigiertes Skript:

CREATE USER 'rf_backend'@'localhost' IDENTIFIED BY 'Rf#Backend_2027';
GRANT SELECT, INSERT, UPDATE, DELETE ON ratzfahrt.* TO 'rf_backend'@'localhost';

Bewertung: je beschriebenem Fehler 1 Punkt (4 Punkte), korrigiertes Skript 1 Punkt. Als Fehler gilt nicht, dass Benutzername und Host in Hochkommas stehen oder fehlen; beides ist zulässig. Wer Rechte statt auf ratzfahrt.* einzeln auf alle zehn Tabellen und die Sicht vergibt, erhält die volle Punktzahl.

Bewertung: je Zeile 1 Punkt (0,5 Punkte Ergebnis, 0,5 Punkte Begründung).

Mögliche Gründe (je Grund 1 Punkt, höchstens 3 Punkte):

• Datenminimierung: Die Tabellen angebot und gesuch enthalten die IDs der Fahrer*innen und Mitfahrenden (fahrer_id, nutzer_id) und damit Personenbezug; die Sicht liefert nur die anonymen Spalten, die die Monitore brauchen (DSGVO Art. 5 Abs. 1 lit. c, Datenschutz durch Technikgestaltung nach Art. 25).

• Schadensbegrenzung: Die Player hängen frei zugänglich in Fluren. Werden ihre Zugangsdaten ausgelesen, sind über die Sicht nur ohnehin öffentlich angezeigte Daten erreichbar (Prinzip der minimalen Rechte).

• Gefilterte Daten: Die Sicht zeigt nur offene und aktuelle Einträge; abgesagte oder vergangene Fahrten erscheinen gar nicht erst.

• Entkopplung: Ändert sich die Tabellenstruktur, wird nur die Sicht angepasst; die Player-Software und ihre Rechte bleiben gleich.

• Interessenkonflikt (1 Punkt): Die Datenschutzbeauftragte darf nach DSGVO Art. 38 Abs. 6 andere Aufgaben übernehmen, aber nur, wenn diese nicht zu einem Interessenkonflikt führen. Als Administratorin entscheidet Andrea Wolf selbst über Konten, Rechte und Sichten, also über Mittel der Verarbeitung. Als Datenschutzbeauftragte müsste sie genau diese Entscheidungen unabhängig überwachen (Art. 39) – sie würde sich selbst kontrollieren.

• Folgen (1 Punkt): Fehler im Berechtigungskonzept fallen bei einer Selbstkontrolle leichter durch. Außerdem bündelt die Doppelrolle sehr weitreichende Rechte bei einer Person, was dem Prinzip der minimalen Rechte und der Funktionstrennung widerspricht.

• Vorschlag (1 Punkt): Die Administration übernimmt eine andere Person (z. B. eine Lehrkraft aus dem IT-Bereich oder die Schul-IT OWL). Andrea Wolf bleibt Datenschutzbeauftragte und erhält nur die Leserechte, die sie zur Kontrolle braucht (z. B. auf Sichten und Protokolle). Ebenso vertretbar: Sie bleibt Administratorin, und die Schule benennt eine andere Datenschutzbeauftragte.

Andere schlüssig begründete Vorschläge mit klarer Trennung der Rollen erhalten ebenfalls die volle Punktzahl.

Bewertung: lm_api 1 Punkt, lm_import und bsommer zusammen 1 Punkt, lm_moderation 1,5 Punkte, arahimi 1 Punkt, cneumann/anguyen 1,5 Punkte, mkowalczyk 1 Punkt, ydemir 1 Punkt.

CREATE VIEW letsmeet.v_aktivitaet_statistik AS
SELECT h.kategorie,
       DATE_FORMAT(a.beginn, '%Y-%m')   AS monat,
       COUNT(DISTINCT a.aktivitaet_id) AS aktivitaeten,
       COUNT(t.benutzer_id)            AS teilnahmen
FROM letsmeet.aktivitaet a
JOIN letsmeet.hobby h ON h.hobby_id = a.hobby_id
LEFT JOIN letsmeet.teilnahme t
       ON t.aktivitaet_id = a.aktivitaet_id AND t.status = 'teilgenommen'
WHERE a.status = 'stattgefunden'
GROUP BY h.kategorie, DATE_FORMAT(a.beginn, '%Y-%m');

Ergebnis:

Bewertung: Sicht mit Gruppierung und Filter auf stattgefunden 2 Punkte, Zählung der Teilnahmen nur mit teilgenommen (Bedingung im ON des LEFT JOIN oder im WHERE) 1 Punkt, Ergebnis 1 Punkt, Erläuterung 2 Punkte.

Erläuterung: Eine Sicht läuft in MariaDB standardmäßig mit den Rechten der Person, die sie angelegt hat (SQL SECURITY DEFINER). Yusuf Demir darf die Tabellen lesen; Clara Neumann braucht nur SELECT auf die Sicht. So sieht sie die Zahlen, aber keine Namen, E-Mail-Adressen oder Geburtsdaten.

Ein LEFT JOIN stellt sicher, dass auch eine stattgefundene Aktivität ohne Teilnahme mit 0 gezählt wird; mit COUNT(DISTINCT a.aktivitaet_id) zählt jede Aktivität trotz mehrerer Teilnahmezeilen nur einmal.

-- Backend: nur noch Datenrechte
REVOKE ALL PRIVILEGES ON letsmeet.* FROM 'lm_api'@'10.99.4.20';
GRANT SELECT, INSERT, UPDATE, DELETE ON letsmeet.* TO 'lm_api'@'10.99.4.20';

-- Moderation: UPDATE auf meldung nur für zwei Spalten, Rolle für arahimi
REVOKE UPDATE ON letsmeet.meldung FROM lm_moderation;
GRANT UPDATE (bearbeitet_am, ergebnis) ON letsmeet.meldung TO lm_moderation;
GRANT lm_moderation TO 'arahimi';
SET DEFAULT ROLE lm_moderation FOR 'arahimi';

-- Auswertungen: Tabellenrechte entziehen, Rolle mit Recht auf die Sicht
REVOKE SELECT ON letsmeet.aktivitaet FROM 'cneumann';
REVOKE SELECT ON letsmeet.teilnahme FROM 'cneumann';
REVOKE SELECT ON letsmeet.hobby FROM 'cneumann';
REVOKE SELECT ON letsmeet.* FROM 'anguyen';
CREATE ROLE lm_analyse;
GRANT SELECT ON letsmeet.v_aktivitaet_statistik TO lm_analyse;
GRANT lm_analyse TO 'cneumann', 'anguyen';
SET DEFAULT ROLE lm_analyse FOR 'cneumann';
SET DEFAULT ROLE lm_analyse FOR 'anguyen';

-- Datenschutzbeauftragte
GRANT SELECT ON letsmeet.v_aktivitaet_statistik TO 'mkowalczyk';

-- Leiter Entwicklung: nur noch die Datenbank letsmeet
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'ydemir';
GRANT ALL PRIVILEGES ON letsmeet.* TO 'ydemir' WITH GRANT OPTION;

Bewertung: lm_api 2 Punkte (Entzug und neue Vergabe), Spaltenrecht auf meldung statt Tabellenrecht 2 Punkte, arahimi mit Standardrolle 1 Punkt, Auswertungen 3 Punkte (Tabellenrechte entzogen 1 Punkt, Rolle mit Recht auf die Sicht 1 Punkt, Zuweisung mit Standardrolle 1 Punkt), Datenschutzbeauftragte 1 Punkt, ydemir 2 Punkte (Entzug aller Rechte einschließlich Weitergaberecht 1 Punkt, neue Vergabe auf letsmeet.* 1 Punkt).

Hinweise:

• REVOKE muss auf derselben Ebene stehen wie das vorhandene GRANT: Das Recht von anguyen auf letsmeet.* lässt sich nicht für einzelne Tabellen entziehen, die drei Tabellenrechte von cneumann nur einzeln.

• REVOKE ALL PRIVILEGES, GRANT OPTION FROM … entzieht in MariaDB alle Rechte auf allen Ebenen einschließlich des Weitergaberechts; danach werden die Rechte auf letsmeet.* neu vergeben.

• Ein Konto hat in MariaDB nur eine Standardrolle. Gehört arahimi später auch einer zweiten Rolle an, muss er diese mit SET ROLE einschalten – oder die Rechte werden in einer gemeinsamen Rolle gebündelt.

• Statt des Einzelrechts kann mkowalczyk auch Mitglied von lm_analyse werden (dann mit SET DEFAULT ROLE).

DROP USER 'lm_import'@'localhost';
REVOKE GRANT OPTION ON letsmeet.* FROM 'ydemir';

Bewertung: Entfernen des Übernahmekontos 1 Punkt (DROP USER entfernt das Konto mit allen Rechten; ein vorheriges REVOKE ist möglich, aber nicht nötig), Entzug des Weitergaberechts auf derselben Ebene letsmeet.* 2 Punkte, Beschreibung 1 Punkt.

Beschreibung: MariaDB entzieht bei REVOKE GRANT OPTION nicht automatisch die Rechte, die Yusuf Demir vorher weitergegeben hat (kein kaskadierender Entzug). Da SHOW GRANTS nicht anzeigt, wer ein Recht vergeben hat, muss die Administration mit SHOW GRANTS FOR … für die Konten des Teams prüfen, welche Rechte auf letsmeet sie haben, und nicht mehr gewollte Rechte einzeln entziehen.

Bewertung: je Zeile 1 Punkt (0,5 Punkte Ergebnis, 0,5 Punkte Begründung).

Mögliche Stellungnahme (Argumente je 1 Punkt, höchstens 3 Punkte; begründetes Fazit 1 Punkt):

• Datenminimierung und Datenschutz durch Technikgestaltung (DSGVO Art. 5 Abs. 1 lit. c, Art. 25): Mit SELECT auf alle Tabellen wären Namen, E-Mail-Adressen, Geburtsdaten, Passwort-Hashes und Meldungen lesbar – auch von Minderjährigen ab 16 Jahren. Für Auswertungen werden diese Daten nicht gebraucht.

• Zweckbindung: Meldungen und Teilnahmen dürfen nur für die Moderation und den Betrieb der App verwendet werden, nicht beliebig ausgewertet.

• Risiko: Ein Auswertungsprogramm speichert Zugangsdaten oft lokal oder in der Cloud; gelangen sie in falsche Hände, sind alle personenbezogenen Daten betroffen.

• Auch anonyme Zahlen können Personen erkennbar machen: Bei sehr kleinen Gruppen (z. B. eine Aktivität mit drei Teilnehmenden in Herford) lassen sich Personen unter Umständen zuordnen. Neue Auswertungen sollte deshalb die Datenschutzbeauftragte prüfen.

Fazit: Der Vorschlag ist abzulehnen. Als Kompromiss kann das Entwicklungsteam weitere Sichten bereitstellen, der Rolle lm_analyse das Leserecht darauf geben und das Angebot auf Wunsch zügig erweitern – oder eine pseudonymisierte Auswertungskopie der Datenbank einrichten.