feat(superadmin): migrate internal docs from docusaurus to guava kb
This commit is contained in:
Codex Agent
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: DSGVO & Compliance-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 wird in bd-Issues gepflegt und enthält mehrere DSGVO‑relevante Workstreams:
|
||||
|
||||
- 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.
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: How-to – DSGVO-Löschung eines Fotos
|
||||
---
|
||||
|
||||
Dieses How‑to beschreibt den operativen Ablauf, wenn ein Gast verlangt, dass ein konkretes Foto DSGVO‑konform gelöscht wird.
|
||||
|
||||
## 1. Anfrage & Berechtigung prüfen
|
||||
|
||||
Bevor du etwas löschst:
|
||||
|
||||
- Handelt der Gast über den Veranstalter (Tenant) oder direkt bei Fotospiel?
|
||||
- Kann das Foto eindeutig identifiziert werden?
|
||||
- Am besten via Link zur Galerie / Foto‑Detailseite.
|
||||
- Alternativ via Screenshot + Event‑Name + Zeitfenster.
|
||||
- Ist der Tenant (Veranstalter) einverstanden?
|
||||
- In der Regel sollte die Entscheidung, ob ein Foto gelöscht wird, beim Tenant liegen, sofern der Vertrag dies vorsieht.
|
||||
|
||||
Alle relevanten Informationen und Entscheidungen sollten im Ticket erfasst werden.
|
||||
|
||||
## 2. Foto im System identifizieren
|
||||
|
||||
1. Über die Admin‑UI:
|
||||
- In der Tenant Admin PWA den betroffenen Event öffnen.
|
||||
- Foto über Moderations‑/Galerieansicht suchen.
|
||||
- ID des Fotos notieren (sofern sichtbar) oder den direkten Admin‑Link verwenden.
|
||||
2. Falls nötig, über DB/Logs:
|
||||
- Anhand von Dateinamen/URLs aus Logs (`event_media_assets.path`, `photos.thumbnail_path`) das Foto lokalisieren.
|
||||
|
||||
## 3. Löschung über Admin-UI (präferiert)
|
||||
|
||||
Wenn die Admin‑Oberfläche eine Delete/Hide‑Funktion bietet:
|
||||
|
||||
1. Tenant Admin das Foto über das Moderationsinterface löschen lassen.
|
||||
2. Sicherstellen, dass:
|
||||
- Foto nicht mehr in Galerie/Moderationslisten erscheint.
|
||||
- Share‑Links oder öffentliche Galerien das Foto nicht mehr anzeigen.
|
||||
3. Falls es trotzdem noch angezeigt wird:
|
||||
- Caches prüfen (Browser, CDN, ggf. Thumbnail‑Caches).
|
||||
|
||||
## 4. Technischer Löschpfad (Backend)
|
||||
|
||||
Falls eine UI‑Löschung nicht ausreicht oder du nachkontrollieren willst:
|
||||
|
||||
1. **Datenbank**
|
||||
- `photos`:
|
||||
- Prüfen, dass der Eintrag für das Foto gelöscht oder hinreichend anonymisiert wurde.
|
||||
- `event_media_assets`:
|
||||
- Alle Einträge, die auf dieses Foto (`photo_id`) zeigen, identifizieren.
|
||||
- Pfade (`disk`, `path`) notieren.
|
||||
2. **Storage**
|
||||
- Für alle relevanten `EventMediaAsset`‑Einträge:
|
||||
- Dateien im Hot‑/Archive‑Storage löschen (Original + Derivate/Thumbnails).
|
||||
3. **Verknüpfungen**
|
||||
- Sicherstellen, dass keine weiteren Verweise existieren:
|
||||
- Likes/Statistiken für dieses Foto (z.B. `photo_likes`) – optional mit entfernen, sofern vorhanden.
|
||||
|
||||
> Hinweis: Wenn ihr `AccountAnonymizer` auf Tenant‑/User‑Ebene verwendet, löscht dieser im Regelfall großflächig Medien. Für Einzelfälle (ein Foto) ist der oben skizzierte Weg geeigneter.
|
||||
|
||||
## 5. Dokumentation & Bestätigung
|
||||
|
||||
- Im Ticket festhalten:
|
||||
- Welches Foto (Event, ID/URL).
|
||||
- Wer die Löschung veranlasst und genehmigt hat.
|
||||
- Welche Schritte tatsächlich durchgeführt wurden (UI, DB, Storage).
|
||||
- Tenant/Gast informieren:
|
||||
- Bestätigung, dass das Foto aus Galerie und Speicher entfernt wurde.
|
||||
- Hinweis, dass ggf. Browser‑/CDN‑Caches eine kurze Zeit nachlaufen können, aber keine neuen Zugriffe mehr möglich sind.
|
||||
|
||||
## 6. Präventive Verbesserungen
|
||||
|
||||
Wenn dieser Vorgang häufig vorkommt:
|
||||
|
||||
- Prüfen, ob die Admin‑UI einen klareren, selbstbedienbaren Weg zur Foto‑Löschung bietet.
|
||||
- Sicherstellen, dass die Dokumentation für Tenant Admins (siehe Help‑Center) erklärt, wie sie Fotos eigenständig löschen und wie sich das auf Gäste auswirkt.
|
||||
|
||||
Dieses How‑to ergänzt `docs/ops/compliance-dsgvo-ops.md` um einen konkreten Einzelfall. Für komplexere Anonymisierungs‑Szenarien siehe den Abschnitt zum `AccountAnonymizer`.
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: How‑to – Tenant‑Komplett‑Export
|
||||
---
|
||||
|
||||
Dieses How‑to beschreibt, wie du für einen Tenant kurz vor Vertragsende einen möglichst vollständigen Daten‑Export erstellst.
|
||||
|
||||
## 1. Anfrage prüfen
|
||||
|
||||
- Schriftliche Anfrage des Tenants (E‑Mail/Ticket).
|
||||
- Klarer Scope:
|
||||
- Nur Medien?
|
||||
- Medien + Metadaten (Events, Gäste, Likes)?
|
||||
- Billing‑Nachweise (Rechnungen)?
|
||||
|
||||
## 2. Medien‑Export
|
||||
|
||||
- Für jeden relevanten Event:
|
||||
- Prüfen, ob alle Upload‑Jobs durch sind (`event_media_assets` ohne `pending`/`failed`).
|
||||
- Archiv‑Export nutzen (sofern vorhanden) oder:
|
||||
- Medien‑Ordner pro Event aus dem Storage exportieren.
|
||||
- Thumbnails optional, Originale Pflicht.
|
||||
|
||||
## 3. Metadaten‑Export
|
||||
|
||||
- Events, Gäste, Likes, Kommentare nach Bedarf exportieren:
|
||||
- Entweder über bestehende Export‑Funktion (CSV/JSON).
|
||||
- Oder über einen einmaligen, internen Report (z.B. `php artisan make:report`‑ähnlicher Flow, falls vorhanden).
|
||||
- Output als ZIP mit klarer Ordnerstruktur:
|
||||
- `media/`
|
||||
- `metadata/events.csv`
|
||||
- `metadata/guests.csv`
|
||||
|
||||
## 4. Billing-Unterlagen
|
||||
|
||||
- Rechnungen / Zahlungsbelege:
|
||||
- Lemon Squeezy‑Belege (Links oder PDFs).
|
||||
- Interne Rechnungs‑PDFs (falls generiert).
|
||||
|
||||
## 5. Nach dem Export
|
||||
|
||||
- Export dem Tenant sicher zur Verfügung stellen (z.B. Download‑Link mit Ablaufdatum).
|
||||
- Dokumentieren:
|
||||
- Datum des Exports.
|
||||
- Umfang (welche Tabellen/Events enthalten).
|
||||
- Speicherort und Aufbewahrungsdauer des Export‑Bundles.
|
||||
|
||||
Siehe auch:
|
||||
|
||||
- `docs/ops/compliance-dsgvo-ops.md`
|
||||
- `docs/ops/backup-restore.md`
|
||||
Reference in New Issue
Block a user