91 lines
5.1 KiB
Markdown
91 lines
5.1 KiB
Markdown
---
|
||
title: DSGVO & Compliance-Operationen
|
||
sidebar_label: DSGVO-Operationen
|
||
---
|
||
|
||
Dieses Runbook beschreibt praktische Abläufe für Datenschutz‑Anfragen, Datenlöschung und Aufbewahrungsfristen.
|
||
|
||
## 1. Grundprinzipien
|
||
|
||
- Gäste benötigen kein Konto; die meisten Daten sind Event‑ und Foto‑bezogen.
|
||
- Tenant Admins sind in der Regel Verantwortliche im Sinne der DSGVO, Fotospiel fungiert als Auftragsverarbeiter (je nach Vertragsmodell).
|
||
- Rechtsgrundlagen, Impressum und Datenschutzerklärungen werden über die Legal‑Pages im Admin verwaltet – dieses Dokument fokussiert sich auf **Betriebsprozesse**.
|
||
|
||
## 2. Typische Anfragen & Aktionen
|
||
|
||
- **Auskunftsanfragen**
|
||
- Gast möchte wissen, ob Fotos von ihm/ihr gespeichert sind.
|
||
- Typischer Ablauf:
|
||
- Gast an Tenant verweisen (wenn Veranstalter Ansprechpartner ist).
|
||
- Falls Fotospiel direkt handeln muss: Event/Foto‑IDs anhand bereitgestellter Infos identifizieren (z.B. Link, Screenshot, Zeitfenster).
|
||
- Relevante Datensätze in DB (Fotos, Likes, Meldungen) lokalisieren und dokumentieren.
|
||
- **Löschanfragen**
|
||
- Ein Gast/Tenant bittet um Löschung spezifischer Fotos oder eines ganzen Events.
|
||
- Vorgehen:
|
||
1. Identität und Berechtigung prüfen (z.B. Tenant Admin, verifizierte Anfrage).
|
||
2. Fotos/Ereignisse über Admin UI oder interne Tools löschen/archivieren.
|
||
- Sicherstellen, dass `event_media_assets` und Archiv‑Speicher ebenfalls bereinigt werden.
|
||
3. Prüfen, ob Logs/Audits pseudonymisiert bleiben können, ohne personenbezogene Inhalte.
|
||
4. Anfrage und Zeitpunkt dokumentieren (Ticket, internes Log).
|
||
- **Datenexport**
|
||
- Tenant will einen Export seiner Daten (Events, Medien, Statistiken).
|
||
- Nutzung der vorhandenen Export‑Funktionen (z.B. CSV/ZIP im Admin) bevorzugen.
|
||
- Falls diese nicht ausreichen, manuelle Exporte via Skript/DB mit Datenschutz im Blick (keine unnötigen Felder).
|
||
- Beispiel: nur die Felder exportieren, die für den Zweck der Anfrage wirklich notwendig sind (kein Debug‑Log, keine internen IDs, sofern nicht sinnvoll).
|
||
|
||
### 2.1 Konkrete Tools & Endpoints
|
||
|
||
- **Profil-Datenexport (User-Ebene)**
|
||
- Controller: `App\Http\Controllers\ProfileDataExportController`.
|
||
- UI: Profilbereich der Tenant Admin PWA; Nutzer kann dort einen Export anstoßen.
|
||
- Ablauf:
|
||
1. Nutzer triggert Export → `ProfileDataExportController::store()` legt einen `DataExport`‑Eintrag an (`status = pending`) und dispatcht `GenerateDataExport`.
|
||
2. Der Job `GenerateDataExport` erstellt ein ZIP mit relevanten Daten und setzt `status = ready`, `path`, ggf. `expires_at`.
|
||
3. Nutzer kann die Datei über `ProfileDataExportController::download()` abrufen, solange `isReady()` und nicht `hasExpired()`.
|
||
- Ops-Sicht:
|
||
- Wenn Exporte „hängen bleiben“ (lange `pending`/`processing`), Queue/Horizon und Logs prüfen, ggf. Job neu anstoßen.
|
||
- Für DSGVO‑Exports bevorzugt diesen Pfad nutzen, statt ad‑hoc DB‑Abfragen.
|
||
|
||
- **Account-Anonymisierung (User/Tenant-Ebene)**
|
||
- Service: `App\Services\Compliance\AccountAnonymizer`.
|
||
- Job: `App\Jobs\AnonymizeAccount` nutzt diesen Service typischerweise im Hintergrund.
|
||
- Verhalten:
|
||
- Löscht/entfernt Medien (`EventMediaAsset`, `Photo`) für einen Tenant.
|
||
- Anonymisiert Tenant‑ und User‑Daten (setzt neutrale Namen, entfernt Kontaktinfos, sperrt Accounts).
|
||
- Ops-Sicht:
|
||
- Nur nach klarer Freigabe einsetzen, da Anonymisierung irreversibel ist.
|
||
- Vor Einsatz prüfen, ob für den betreffenden Tenant alle vertraglichen Zusagen (z.B. Datenexport) erfüllt sind.
|
||
|
||
## 3. Retention & automatisierte Löschung
|
||
|
||
- **Event-bezogene Aufbewahrung**
|
||
- Standard‑Retentionsfristen für Events/Fotos (z.B. X Tage nach Eventende/Archivierung) laut Produkt‑Spezifikation.
|
||
- Jobs/Kommandos, die nach Ablauf Medien archivieren oder löschen (siehe `docs/ops/media-storage-spec.md`).
|
||
- **Logs**
|
||
- Aufbewahrungsdauer von Applikations‑Logs (z.B. 30–90 Tage), Rotation/Anonymisierung.
|
||
- **Konfiguration pro Tenant**
|
||
- Wenn Tenants eigene Retention wünschen, prüfen ob das UI/Config‑Model dies unterstützt (nicht ad‑hoc in SQL ändern).
|
||
|
||
## 4. Operative Checkliste bei DSGVO-Fällen
|
||
|
||
1. Anfrage klassifizieren (Auskunft, Löschung, Export, Sonstiges).
|
||
2. Verantwortlichkeit klären (Tenant vs. Fotospiel).
|
||
3. Technische Schritte definieren (welche Events/Fotos/Accounts betroffen).
|
||
4. Durchführung:
|
||
- In Admin UI oder via internen Tools.
|
||
- Medien/Metadaten konsistent behandeln (keine „hängenden“ Records).
|
||
5. Dokumentation:
|
||
- Ticket/E-Mail‑Thread mit Datum, Betreff, Maßnahmen.
|
||
6. Follow‑Up:
|
||
- Prüfen, ob Runbooks/Automatisierungen angepasst werden sollten (z.B. besserer Self‑Service für Tenants).
|
||
|
||
## 5. Verbindung zu Security-Hardening
|
||
|
||
Das Security‑Hardening‑Epic (`docs/process/todo/security-hardening-epic.md`) enthält mehrere Workstreams, die DSGVO‑relevant sind:
|
||
|
||
- Signierte Asset‑URLs statt direkter Storage‑Links.
|
||
- Verbesserte Token‑/Auth‑Flows.
|
||
- Storage‑Health und Checksummen‑Verifizierung.
|
||
|
||
Wenn dort neue Features produktiv gehen, sollten die Auswirkungen auf DSGVO‑Prozesse in diesem Runbook ergänzt werden.
|