Lars
34235ef46d
Some checks failed
Deploy Development / deploy (push) Successful in 39s
Test Suite / pytest-backend (push) Successful in 34s
Test Suite / lint-backend (push) Successful in 1s
Test Suite / build-frontend (push) Successful in 11s
Test Suite / playwright-tests (push) Failing after 1m23s
Implementiert server-seitige Rechteerklärungspflicht für alle Medien-Uploads
und Sichtbarkeits-Promotions (konservative Erstannahme: alle Uploads).
Backend:
- backend/media_rights.py (NEU): Kernmodul — validate_rights_declaration,
check_rights_coverage, assert_rights_for_promotion, assert_rights_for_exercise_link,
write_rights_declaration, update_rights_quick_fields
- backend/migrations/048_media_rights_declarations.sql (NEU): Tabelle
media_asset_rights_declarations (Append-only Audit-Log), Felder
rights_status/rights_visibility_level in media_assets
- backend/routers/media_assets.py: P-06-Pflichtprüfung in PATCH (single + bulk),
POST /api/media-assets/{id}/rights-declarations (Re-Deklaration),
GET /api/admin/media-rights/legacy-summary|legacy-assets (Admin-Endpoints)
- backend/routers/exercises.py: P-06-Felder in upload_exercise_media,
assert_rights_for_exercise_link in attach_exercise_media_from_asset
- backend/main.py: admin_rights_router registriert
Frontend:
- frontend/src/components/RightsDeclarationDialog.jsx (NEU): 9-Felder-Dialog
(konservativ: immer alle Fragen), Client-Validierung, VORLÄUFIG-Hinweis
- frontend/src/pages/MediaLibraryPage.jsx: Dialog-Intercept vor Upload,
Altbestand-Indikator (legacy_unreviewed)
- frontend/src/utils/api.js: P-06-Felder in bulkUploadMediaAssets weitergeleitet
Tests:
- backend/tests/test_media_rights_declaration.py (NEU): 28 Unit-/Integrationstests
- backend/tests/test_media_assets_archive.py: P-06 fetchone-Slots + Mock ergänzt
- backend/tests/test_media_assets_copyright_promotion.py: check_rights_coverage gemockt
- tests/dev-smoke-test.spec.js: 5 P-06 E2E-Tests ergänzt
Dokumentation:
- docs/compliance-implementation.md: P-06-Abschnitt
- docs/compliance-package-register.md: Status ⚠️ teilweise umgesetzt (KRIT-04 offen)
- docs/compliance-roadmap.md: P-06 im Freigaben-Log
Offen: KRIT-04 (rechtliche Finalisierung Einwilligungsformulierung) — technisch
vollständig, Rechtstext VORLÄUFIG.
version: 0.8.75
module: media_rights 1.0.0, media_assets 1.13.0, exercises 2.20.0
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
368 lines
22 KiB
Markdown
368 lines
22 KiB
Markdown
# Compliance-Roadmap – Shinkan Jinkendo
|
||
|
||
**Typ:** Lebendes Steuerungsdokument
|
||
**Erstellt:** 2026-05-10
|
||
**App-Version:** 0.8.75
|
||
**Zuletzt aktualisiert:** 2026-05-11
|
||
|
||
---
|
||
|
||
## 1. Zweck und Geltung
|
||
|
||
Dieses Dokument steuert die aktuelle Priorisierung, Release-Readiness und nächste Freigabeschritte für das Compliance-Programm. Es ersetzt **keines** der folgenden Dokumente, sondern ergänzt sie:
|
||
|
||
| Dokument | Rolle |
|
||
|----------|-------|
|
||
| `docs/compliance-audit.md` | Historischer Initialbefund (unveränderlich als Quelle) |
|
||
| `docs/compliance-package-register.md` | Kanonische Quelle für Paket-IDs und aktuellen Paketstatus |
|
||
| `docs/compliance-implementation.md` | Chronologischer Umsetzungsnachweis |
|
||
| **`docs/compliance-roadmap.md`** | **Aktuelle Prioritäten, Release-Gates, nächste Freigaben** |
|
||
|
||
**Bindungsregeln:**
|
||
- Paket-IDs → immer aus dem Paketregister
|
||
- Historische Findings und Severity-Einstufungen → immer aus dem Initial-Audit
|
||
- Aktuelle Reihenfolge und Freigabeempfehlungen → **dieses Dokument**
|
||
|
||
Diese Roadmap ist nach jedem Re-Audit zu aktualisieren. Abweichungen von der bisherigen Priorität werden mit Datum und Begründung dokumentiert (→ §4, §10).
|
||
|
||
---
|
||
|
||
## 2. Aktueller Stand (2026-05-11)
|
||
|
||
### App-Version: 0.8.75
|
||
|
||
### Teilweise umgesetzte Pakete
|
||
|
||
| ID | Titel | Version | Offen |
|
||
|----|-------|---------|-------|
|
||
| P-01 | Rechtstexte | 0.8.74 | Juristische Inhalte — Betreiber + Rechtsanwalt |
|
||
| P-06 | Upload-Einwilligungsdialog | 0.8.75 | KRIT-04: Juristische Validierung (§22 KUG, §8 DSGVO, Widerrufsrecht, Texte p06-v1-conservative) |
|
||
|
||
### Vollständig geschlossene Pakete
|
||
|
||
| ID | Titel | Version |
|
||
|----|-------|---------|
|
||
| P-03 | Papierkorb-Retention-Job aktivieren | 0.8.66 |
|
||
| P-03b | _Nacharbeit:_ Retention-Zeiten 30+30 Tage | 0.8.67 |
|
||
| P-04 | Copyright-Pflicht für Archiv-Promotion vereinheitlichen | 0.8.66 |
|
||
| P-05 | Passwort-Mindestlänge angleichen (alle Endpoints) | 0.8.66–0.8.67 |
|
||
| P-05b | _Nacharbeit:_ reset-password Mindestlänge | 0.8.67 |
|
||
| P-07 | ALLOW_PUBLIC_MEDIA_STATIC dokumentieren + Release-Test | 0.8.66 |
|
||
| P-12 | sessionStorage bei Logout bereinigen | 0.8.68 |
|
||
| P-23 | LoginPage: minLength angleichen + Versionsstring entfernen | 0.8.66 |
|
||
| P-24 | CORS einschränken (Methoden + Header) | 0.8.66 |
|
||
| P-01b | _Nacharbeit:_ Mobile/PWA-Erreichbarkeit Rechtstexte via `/settings/legal` | 0.8.70 |
|
||
| P-01c | _Nacharbeit:_ Admin-konfigurierbare Rechtstexte (DB 047, Superadmin-UI, API) | 0.8.71 |
|
||
| P-01c+ | _Erweiterung:_ Als-Entwurf-kopieren (`copy-as-draft`) | 0.8.72 |
|
||
| P-01c++ | _Erweiterung:_ Echter PDF-Download (jsPDF) + Abschnitts-Sortierung/-Einfügen | 0.8.74 |
|
||
|
||
**Vollständig abgeschlossen:** 7 Hauptpakete + 4 Nacharbeiten + 2 Erweiterungen = 13 Umsetzungseinheiten
|
||
**Teilweise umgesetzt (technisch):** P-01
|
||
|
||
### Offene Pakete (16)
|
||
|
||
P-02, P-06, P-08, P-09, P-10, P-11, P-13, P-14, P-15, P-16, P-17, P-18, P-19, P-20, P-21, P-22
|
||
|
||
### Gesamtstatus
|
||
|
||
> **⛔ Nicht öffentlich freigabefähig**
|
||
|
||
**Begründung:** Die App kann im aktuellen Zustand nicht für allgemeine öffentliche Registrierung beworben oder aktiv vermarktet werden. Folgende zwingende Voraussetzungen fehlen noch:
|
||
|
||
1. **P-01:** Kein Impressum, keine Datenschutzerklärung, keine AGB. Eine öffentlich erreichbare App ohne Impressum ist eine Ordnungswidrigkeit nach § 5 DDG.
|
||
2. **P-06:** Keine Einwilligungserklärung beim Medienupload. Personenbilder können ohne jede Rechteabklärung hochgeladen werden.
|
||
3. **P-02:** Nutzer können ihr Konto nicht selbst löschen (DSGVO Art. 17). Der Prozess ist noch nicht einmal fachlich spezifiziert.
|
||
4. **P-13:** Keine Möglichkeit, rechtswidrige Inhalte zu melden. Bei einer UGC-Plattform mit öffentlichen Inhalten ist dies ein erhebliches Restrisiko, unabhängig davon, ob der DSA formal anwendbar ist.
|
||
5. **P-11:** Kein Legal-Hold-Status. Bei erkannten Rechtsverletzungen dauert es bis zu 30 Tage, bis Inhalte vollständig ausgeblendet sind.
|
||
|
||
**Was geöffnet bleiben kann (mit Dokumentation):** Vereinsinterne Nutzung durch bekannte Trainer-Gruppen ist mit dem aktuellen Stand vertretbar, solange keine öffentliche Vermarktung stattfindet und kein `official`-Content aktiviert wird.
|
||
|
||
---
|
||
|
||
## 3. Aktuelle Blocker vor öffentlichem Betrieb
|
||
|
||
Die folgenden Pakete sind vor der Freigabe für allgemeine öffentliche Registrierung zwingend zu adressieren. Die Reihenfolge entspricht der in §5 definierten Umsetzungsreihenfolge.
|
||
|
||
### Blocker 1 — P-01: Rechtstexte
|
||
|
||
**Finding:** KRIT-01 (Ordnungswidrigkeit, § 5 DDG)
|
||
**Technischer Stand:** ⚠️ Vollständige technische Infrastruktur vorhanden (Version 0.8.74):
|
||
- Routen `/impressum`, `/datenschutz`, `/nutzungsbedingungen`, `/medienrichtlinie` öffentlich ohne Auth erreichbar (P-01, 0.8.69)
|
||
- Mobile/PWA-Erreichbarkeit via `/settings/legal` (P-01b, 0.8.70)
|
||
- Admin-konfigurierbare Rechtstexte: DB-Versionierung, Publish/Archive-Workflow, Superadmin-UI `/admin/legal-documents` (P-01c, 0.8.71)
|
||
- Als-Entwurf-kopieren: Bestehendes Dokument als Basis für neue Version übernehmen (0.8.72)
|
||
- Echter PDF-Download via jsPDF (direkter Dateidownload, kein Druckdialog), Abschnitte sortieren (▲/▼) und an beliebiger Stelle einfügen (0.8.74)
|
||
|
||
**Warum noch offen:** Impressum, Datenschutzerklärung und AGB ohne juristisch geprüfte Inhalte genügen der gesetzlichen Pflicht nicht. Die Superadmin-UI bietet alle Werkzeuge zum Einpflegen, Versionieren und Veröffentlichen von Texten — sobald Inhalte vorliegen, verschwindet der Platzhalter-Banner automatisch.
|
||
**Nächster Schritt:** Rechtsanwalt beauftragen → Inhalte über `/admin/legal-documents` einpflegen → Veröffentlichen → Platzhaltermarkierung verschwindet automatisch.
|
||
|
||
### Blocker 2 — P-06: Upload-Einwilligungsdialog
|
||
|
||
**Finding:** KRIT-04 (§22 KUG, §8 DSGVO)
|
||
**Warum zwingend:** Jeder hochgeladene Bildinhalt mit erkennbaren Personen ist ohne dokumentierte Einwilligung rechtlich problematisch. Das Risiko besteht nicht erst bei öffentlichen Inhalten — es beginnt beim Upload.
|
||
**Abhängigkeit:** Keine; kann als Frontend-Dialog mit Backend-Flag implementiert werden.
|
||
**Spezifikation:** Fachlich-technische Spezifikation erstellt (2026-05-10): `docs/p06-upload-rights-spec.md`. Enthält IST-Analyse, Entscheidungsmatrix, Zielmodell (neue Tabelle `media_asset_rights_declarations` + 3 neue Felder in `media_assets`), 10 Ziel-Flows, Legacy-Konzept für bestehende Medien, Umsetzungsplan P-06a–P-06e.
|
||
**Vor Umsetzung zu klären (12 Punkte):** §22-KUG-Anforderungen im Vereinskontext, Minderjährigenschutz, Einwilligungs-Widerrufsrecht, Speicherfristen — vollständige Klärungsliste in `docs/p06-upload-rights-spec.md` §7.
|
||
|
||
### Blocker 3 — P-11: Legal-Hold Lifecycle-Status
|
||
|
||
**Finding:** MITT-02
|
||
**Warum jetzt statt Etappe 2:** Der aktuelle Papierkorb-Mechanismus reicht für reaktive Maßnahmen bei Rechtsverletzungen nicht aus. Zwischen Meldung und vollständiger Unsichtbarkeit liegen bis zu 30 Tage (Stufe 1). Für eine Plattform mit öffentlichen Inhalten ist das nicht akzeptabel.
|
||
**Abhängigkeit:** Sinnvoll mit P-13 zusammen umzusetzen (Moderationssystem braucht direkten Sperr-Status).
|
||
|
||
### Blocker 4 — P-13: Content-Melde-Backend (Minimalversion)
|
||
|
||
**Finding:** KRIT-03
|
||
**Warum vorgezogen (Abweichung vom Initial-Audit):** → Siehe §4
|
||
**Minimalumfang:** Meldung einreichen + Moderations-Queue für Admin. Nicht der volle P-14–P-16-Stack.
|
||
**Abhängigkeit:** P-11 (Legal-Hold) für direkte Reaktion auf Meldungen empfohlen.
|
||
|
||
### Blocker 5 — P-02: DSGVO-Self-Service (fachliche Spezifikation zuerst)
|
||
|
||
**Finding:** KRIT-02, KRIT-05
|
||
**Warum zuerst spezifizieren, dann umsetzen:** P-02 berührt Kontolöschung, Medienarchiv, Vereinsinhalte, Backups und Fristen. Eine voreilige Implementierung riskiert unvollständige oder juristisch falsche Umsetzung. → Erst spezifizieren (→ §5 Etappe C), dann freigeben.
|
||
**Juristisch zu klären:** Anonymisierung vs. Löschung bei Vereinsinhalten; Backup-Retention-Policy.
|
||
|
||
### Blocker 6 — P-08: HSTS-Betriebsnachweis (Betreiber-Aufgabe)
|
||
|
||
**Finding:** HOCH-02, SEC-01
|
||
**Status:** Außerhalb des Repo-Scopes. HSTS muss am externen Reverse-Proxy (Fritz!Box → Synology → Nginx) konfiguriert sein.
|
||
**Anforderung:** Vor öffentlichem Betrieb: manueller Nachweis (z. B. `curl -I https://shinkan.jinkendo.de` zeigt `Strict-Transport-Security`-Header).
|
||
**Nicht im Code zu lösen** — aber als Release-Gate dokumentiert (→ §7).
|
||
|
||
---
|
||
|
||
## 4. Abweichungen gegenüber der ursprünglichen Audit-Reihenfolge
|
||
|
||
### P-13 wird vorgezogen (Etappe 3 → Etappe B)
|
||
|
||
Das Initial-Audit (`docs/compliance-audit.md` §17) ordnete P-13–P-16 (DSA-Meldeverfahren) in Etappe 3 ein, nach den Sicherheits- und Datenschutzpaketen von Etappe 2. Die Begründung war: juristische Klärung des DSA-Anwendungsbereichs zuerst.
|
||
|
||
**Aktuelle Einschätzung (2026-05-10):** Diese Reihenfolge bleibt für den vollen DSA-Stack (P-14–P-16) richtig. Für den Kern von P-13 — die technische Möglichkeit, eine Inhaltsmeldung abzugeben und zu bearbeiten — ist eine Vorziehung geboten, weil:
|
||
|
||
- Die App erlaubt bereits jetzt Upload und Anzeige von Nutzerinhalten mit `official`-Sichtbarkeit
|
||
- Das Risiko ungemeldeter Rechtsverletzungen ist kein langfristiges, sondern ein unmittelbares
|
||
- Die juristische DSA-Bewertung (ab welcher Nutzerzahl, welche Pflichten) bleibt offen — sie entscheidet über den Umfang, nicht über das Ob einer Grundfähigkeit
|
||
- Eine minimale Melde-Queue kostet weniger als P-14–P-16 zusammen und schafft handlungsfähige Grundstruktur
|
||
|
||
**Keine ID-Änderung:** P-13 bleibt P-13. Die Neuprioritisierung ist eine Planungsentscheidung, keine inhaltliche Änderung des Pakets.
|
||
|
||
### P-22 (HTML-Sanitizer) bleibt in Etappe D
|
||
|
||
Das Initial-Audit platzierte P-22 in Etappe 2. Die aktuelle Einschätzung: CSP `script-src 'self'` reduziert das XSS-Risiko für eingeloggte Nutzer erheblich. Das Risiko ist real, aber kein harter Blocker vor öffentlichem Betrieb im Vergleich zu P-01, P-06, P-11, P-13. P-22 bleibt auf der Roadmap, wird aber nicht als Release-Gate behandelt.
|
||
|
||
---
|
||
|
||
## 5. Aktuell empfohlene Umsetzungsreihenfolge
|
||
|
||
### ✅ Etappe A – Abgeschlossen (2026-05-10, Version 0.8.68)
|
||
|
||
| Paket | Titel | Aufwand | Status |
|
||
|-------|-------|---------|--------|
|
||
| P-12 | sessionStorage bei Logout bereinigen | ~15 min | ✅ umgesetzt |
|
||
|
||
**Abschluss:** P-12 wurde am 2026-05-10 in Version 0.8.68 umgesetzt. `logout()` in `AuthContext.jsx` löscht alle `sj_coach_*`-Schlüssel via Präfix-Iteration. Playwright-Test verifiziert. MITT-05 geschlossen.
|
||
|
||
---
|
||
|
||
### Etappe B – Technische Grundlagen für öffentlichen Betrieb
|
||
|
||
Reihenfolge innerhalb der Etappe ist flexibel; P-01 und P-06 haben keine gegenseitige Abhängigkeit.
|
||
|
||
| Paket | Titel | Aufwand | Abhängigkeit | Freigabe-Formulierung |
|
||
|-------|-------|---------|-------------|----------------------|
|
||
| P-01 | Rechtstexte technisch anlegen (Platzhalter-Seiten, Routen) | 2–4 h Technik | Inhalt durch Rechtsanwalt separat | „Freigabe zur Umsetzung P-01: Rechtstexte" |
|
||
| P-06 | Upload-Einwilligungsdialog | 2–4 Tage | — | „Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog" |
|
||
| P-11 | Legal-Hold Lifecycle-Status | 2–3 Tage | sinnvoll vor P-13 | „Freigabe zur Umsetzung P-11: Legal-Hold Lifecycle-Status" |
|
||
| P-13 | Content-Melde-Backend (Minimalversion) | 3–5 Tage | P-11 empfohlen | „Freigabe zur Umsetzung P-13: Content-Melde-Backend" |
|
||
|
||
**Hinweis P-01:** Die technische Anlage (leere Seiten, Routen `/impressum`, `/datenschutz`, `/nutzungsbedingungen`) ist von der juristischen Ausarbeitung des Inhalts zu trennen. Beide Teilschritte können unabhängig voneinander freigegeben und durchgeführt werden.
|
||
|
||
**Hinweis P-13 Minimalumfang:** Im Rahmen von Etappe B umfasst P-13 ausschließlich:
|
||
- `POST /api/reports` — Meldung einreichen
|
||
- `GET /api/admin/reports` — Moderations-Queue
|
||
- `PATCH /api/admin/reports/{id}` — Status setzen
|
||
|
||
P-14 (Moderations-UI), P-15 (Uploader-Benachrichtigung), P-16 (Beschwerdeverfahren) folgen in Etappe D.
|
||
|
||
---
|
||
|
||
### Etappe C – DSGVO-Self-Service sauber spezifizieren (vor Umsetzungsfreigabe)
|
||
|
||
P-02 erhält eine eigene Spezifikationsphase, bevor eine Umsetzungsfreigabe erteilt wird. Zu klärende Punkte:
|
||
|
||
| Frage | Entscheidungsträger |
|
||
|-------|---------------------|
|
||
| Löschung vs. Anonymisierung bei Vereinsinhalten | Betreiber + Rechtsanwalt |
|
||
| Verhalten bei Medien, die anderen Vereinen zugeordnet sind | Betreiber + Technik |
|
||
| Umgang mit Backups (Retention vs. Löschung auf Antrag) | Betreiber + Rechtsanwalt |
|
||
| Fristen: Bearbeitungszeit für Löschanträge | Rechtsanwalt |
|
||
| Audit-Log für Löschanträge (wer, wann, was) | Technik |
|
||
| Datenexport-Format und Umfang | Technik + Betreiber |
|
||
|
||
Erst wenn diese Fragen beantwortet und als Spec dokumentiert sind, wird P-02 in Etappe C freigegeben.
|
||
|
||
---
|
||
|
||
### Etappe D – Ausbau und langfristige Optimierungen
|
||
|
||
| Paket | Titel | Aufwand | Priorität |
|
||
|-------|-------|---------|-----------|
|
||
| P-09 | Admin-Audit-Log | 3–5 Tage | Hoch |
|
||
| P-10 | Mindestalter-Abfrage | 1–2 Tage | Mittel |
|
||
| P-14 | Moderations-UI (Frontend) | 3–5 Tage | Mittel (nach P-13) |
|
||
| P-15 | Uploader-Benachrichtigung bei Sperrung | 1–2 Tage | Mittel (nach P-13) |
|
||
| P-16 | Beschwerdeverfahren | 2–4 Tage | Niedrig (nach P-15) |
|
||
| P-08 | HSTS-Dokumentation / Betriebsnachweis | Betreiber | Hoch (Release-Gate) |
|
||
| P-22 | HTML-Sanitizer für Rich-Text-Felder | 1–2 Tage | Mittel |
|
||
| P-20 | VVT erstellen | Betreiber | Hoch |
|
||
| P-21 | AV-Verträge abschließen | Betreiber | Hoch |
|
||
| P-02 | Self-Service-Kontolöschung + Datenexport | 5–8 Tage | Hoch (nach Spezifikation Etappe C) |
|
||
| P-17 | MFA für Superadmins (TOTP) | 5–8 Tage | Mittel |
|
||
| P-18 | HttpOnly-Cookie als Auth-Alternative | 3–5 Tage | Niedrig |
|
||
| P-19 | Anti-Virus-Scan (ClamAV) | 3–5 Tage | Niedrig |
|
||
|
||
---
|
||
|
||
## 6. Nächste empfohlene Freigabe
|
||
|
||
**P-01 + P-01b + P-01c technisch vollständig umgesetzt (Version 0.8.74).** Rechtstexte über Login, Desktop-Sidebar und Einstellungen → Rechtliches (Mobile/PWA) erreichbar. Superadmin kann über `/admin/legal-documents` versionierte Rechtstexte anlegen, bearbeiten (inkl. Abschnitts-Sortierung und Einfügen an beliebiger Stelle), als Entwurf kopieren, veröffentlichen und als PDF herunterladen — sobald Inhalte eingepflegt sind, verschwindet der Platzhalter-Banner automatisch. Juristische Inhalte bleiben offen (Betreiber + Rechtsanwalt).
|
||
|
||
Die nächste technische Freigabe sollte **Etappe B** umfassen — beginnend mit P-06:
|
||
|
||
**P-06 Spezifikation vorhanden** (`docs/p06-upload-rights-spec.md`, 2026-05-10). Die Umsetzung setzt die Entscheidung über 12 juristische Klärungspunkte voraus (§22 KUG im Vereinskontext, §8 DSGVO Minderjährigenschutz, Widerrufsrecht, Speicherfristen für Einwilligungen). Erst nach dieser Klärung:
|
||
|
||
> „Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog"
|
||
|
||
oder als Paket (nach Klärung P-06):
|
||
|
||
> „Freigabe zur Umsetzung Etappe B: P-06, P-11, P-13"
|
||
|
||
**Parallel dazu Betreiber-Aufgabe:**
|
||
Rechtsanwalt für die Ausarbeitung der Inhalte von P-01 beauftragen — Inhalte über `/admin/legal-documents` einpflegen und veröffentlichen. Dies ist eine Betreiber-Aufgabe, keine weitere technische Freigabe.
|
||
|
||
**Nach P-01 vollständig (Inhalte eingepflegt):** Gate 1 rückt näher — verbleibende Blocker: P-06, P-02 (Spez.), P-11, P-13, P-08 (Betreiber).
|
||
|
||
---
|
||
|
||
## 7. Release-Gates
|
||
|
||
### Gate 1 — Öffentliche allgemeine Registrierung freischalten
|
||
|
||
Folgende Bedingungen müssen **alle** erfüllt sein:
|
||
|
||
| Bedingung | Paket | Typ |
|
||
|-----------|-------|-----|
|
||
| Impressum und Datenschutzerklärung mit juristisch geprüftem Inhalt | P-01 | ⚠️ Routen vorhanden — Inhalte durch Rechtsanwalt erforderlich |
|
||
| Upload-Einwilligungsdialog aktiv | P-06 | Code |
|
||
| DSGVO-Löschprozess spezifiziert (Spec akzeptiert, auch wenn nicht vollständig implementiert) | P-02 | Spezifikation |
|
||
| Legal-Hold-Status vorhanden | P-11 | Code |
|
||
| Content-Melde-Backend (Minimalversion) aktiv | P-13 | Code |
|
||
| HSTS am externen Reverse-Proxy nachgewiesen | P-08 | Betreiber |
|
||
| Papierkorb-Retention-Job läuft (Monitoring aktiv) | P-03 | Bereits erfüllt |
|
||
| `ALLOW_PUBLIC_MEDIA_STATIC` nicht in Prod-Env gesetzt | P-07 | Bereits erfüllt |
|
||
| sessionStorage bei Logout bereinigt | P-12 | ✅ Bereits erfüllt (Version 0.8.68) |
|
||
|
||
**Darf bei Gate 1 offen bleiben (mit Dokumentation):**
|
||
- P-02 vollständige Implementierung (Spezifikation genügt als Zwischenstand, wenn aktiver Prozess für Löschanfragen per E-Mail dokumentiert ist)
|
||
- P-09 Admin-Audit-Log
|
||
- P-10 Mindestalter-Abfrage
|
||
- P-14–P-16 Moderationsausbau
|
||
- P-17 MFA, P-18 HttpOnly-Cookie, P-19 Anti-Virus-Scan
|
||
- P-20 VVT (in Erstellung), P-21 AV-Verträge (in Klärung)
|
||
|
||
---
|
||
|
||
### Gate 2 — Aktivierung öffentlicher Official-Medien (`visibility = official`)
|
||
|
||
Bevor Inhalte mit `official`-Sichtbarkeit (plattformweit sichtbar, ohne Login) aktiv eingesetzt werden:
|
||
|
||
| Bedingung | Paket | Typ |
|
||
|-----------|-------|-----|
|
||
| Gate 1 vollständig erfüllt | — | Voraussetzung |
|
||
| Upload-Einwilligungsdialog für Personenbilder aktiv | P-06 | Code |
|
||
| Legal-Hold-Status aktiv (Sofortsperrung möglich) | P-11 | Code |
|
||
| Content-Melde-Backend aktiv | P-13 | Code |
|
||
| Copyright-Pflicht bei Promotion aktiv und getestet | P-04 | Bereits erfüllt |
|
||
| Moderationsprozess organisatorisch dokumentiert (wer, wie schnell, Eskalationspfad) | — | Betreiber |
|
||
|
||
---
|
||
|
||
### Gate 3 — Aktivierung öffentlicher Inhalte im Vereinsbereich (`visibility = club`)
|
||
|
||
Bedingungen für Vereinsinhalte sind weniger streng als für `official`, da der Personenkreis begrenzt ist:
|
||
|
||
| Bedingung | Status |
|
||
|-----------|--------|
|
||
| Copyright-Pflicht bei Promotion aktiv | ✅ bereits erfüllt (P-04) |
|
||
| Papierkorb-Retention-Job aktiv | ✅ bereits erfüllt (P-03) |
|
||
| Upload-Einwilligungsdialog vorhanden | muss mit P-06 kommen |
|
||
| Mitgliedschaftsbasierte Zugriffskontrolle funktioniert | ✅ (TenantContext, library_content_visibility_sql) |
|
||
|
||
---
|
||
|
||
## 8. Juristisch zu prüfende Punkte
|
||
|
||
Alle folgenden Punkte erfordern Einschätzung durch einen Rechtsanwalt oder Datenschutzbeauftragten. Keine der nachfolgenden Einschätzungen ist rechtlich verbindlich.
|
||
|
||
| Thema | Frage | Priorität |
|
||
|-------|-------|-----------|
|
||
| **Rechtstexte** | Vollständige Angaben Impressum, Datenschutzerklärung, AGB, Medienrichtlinie. Inhalte können nicht technisch generiert werden. | Sofort |
|
||
| **DSA-Anwendungsbereich** | Ab welcher Nutzerzahl und unter welchen Voraussetzungen gilt der DSA für diese Plattform? Welche Pflichten für sehr kleine Plattformen? | Vor öffentlichem Betrieb |
|
||
| **Einwilligungsmodell Personenbilder** | §22 KUG: Welche Einwilligungen sind für Bilder erkennbarer Personen im Vereinskontext erforderlich? Reicht eine pauschale Upload-Erklärung? | Vor öffentlichem Betrieb |
|
||
| **Minderjährigenschutz** | §8 DSGVO: Ab welchem Alter ist keine elterliche Einwilligung nötig? Wie ist mit Bildern Minderjähriger umzugehen? | Vor öffentlichem Betrieb |
|
||
| **DSGVO-Löschprozess** | Anonymisierung vs. Löschung bei Vereinsinhalten; Umgang mit Backups; Fristen für Löschanträge (Art. 17) | Vor Implementierung P-02 |
|
||
| **Datenübertragbarkeit** | Welcher Exportumfang ist für Art. 20 DSGVO ausreichend? Welches Format? | Vor Implementierung P-02 |
|
||
| **AV-Verträge** | Welche Dienstleister benötigen einen AVV (SMTP-Anbieter, MediaWiki, OpenRouter)? | Vor öffentlichem Betrieb |
|
||
| **Backup-Retention** | Wie muss die Backup-Retention-Policy aussehen, damit DSGVO-Löschanfragen auch Backups erfassen? | Vor öffentlichem Betrieb |
|
||
| **MediaWiki-Lizenz** | Welche Lizenzanforderungen gelten für Übungsinhalte von karatetrainer.net? | Klärenswert |
|
||
|
||
---
|
||
|
||
## 9. Betreiber-Aufgaben
|
||
|
||
Diese Punkte liegen außerhalb des Code-Scopes und erfordern organisatorische Maßnahmen durch den Betreiber:
|
||
|
||
| Aufgabe | Bezug | Dringlichkeit |
|
||
|---------|-------|--------------|
|
||
| Rechtsanwalt beauftragen (Rechtstexte, DSA, KUG) | P-01, P-06 | Sofort |
|
||
| VVT erstellen (DSGVO Art. 30) | P-20 | Vor öffentlichem Betrieb |
|
||
| AV-Verträge klären (SMTP, MediaWiki, OpenRouter) | P-21 | Vor öffentlichem Betrieb |
|
||
| HSTS am Reverse-Proxy (Fritz!Box/Synology) konfigurieren und nachweisen | P-08 | Vor öffentlichem Betrieb |
|
||
| Backup-Konzept dokumentieren und Restore-Test durchführen | — | Dringend empfohlen |
|
||
| Moderationsprozess organisatorisch festlegen: Wer moderiert? Wie schnell? Eskalationspfad? | P-13–P-16 | Vor Aktivierung öffentlicher Inhalte |
|
||
| Notfallkontakt für Datenpannen benennen (DSGVO Art. 33) | — | Vor öffentlichem Betrieb |
|
||
| Papierkorb-Retention-Job überwachen (`docker logs shinkan-retention-cron`) | P-03 | Laufend |
|
||
|
||
---
|
||
|
||
## 10. Aktualisierungsregel
|
||
|
||
| Anlass | Maßnahme |
|
||
|--------|----------|
|
||
| Nach jedem Re-Audit | §2 (Aktueller Stand) und §5 (Reihenfolge) aktualisieren |
|
||
| Nach jeder Freigabe | Paketregister (`docs/compliance-package-register.md`) aktualisieren; §2 dieser Roadmap anpassen |
|
||
| Prioritätsänderung gegenüber bisheriger Roadmap | Datum und Begründung in §4 dokumentieren |
|
||
| Neue Paket-IDs | Immer im Initial-Audit + Paketregister vergeben; nie nur in dieser Roadmap |
|
||
| Paketstatus | Nie direkt in dieser Roadmap pflegen — immer aus Paketregister übernehmen |
|
||
|
||
**Diese Roadmap enthält keine eigenständigen Statusangaben.** §2 wird durch Abfrage des Paketregisters befüllt und bei Aktualisierungen synchronisiert.
|
||
|
||
---
|
||
|
||
## Anhang: Schnellreferenz Freigabe-Formulierungen
|
||
|
||
| Freigabe | Formulierung | Status |
|
||
|----------|-------------|--------|
|
||
| ~~P-12 allein~~ | ~~„Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen"~~ | ✅ historisch abgeschlossen (Version 0.8.68) |
|
||
| ~~P-01 technisch~~ | ~~„Freigabe zur Umsetzung P-01: Rechtstexte technisch anlegen"~~ | ✅ historisch abgeschlossen (Version 0.8.69) |
|
||
| ~~P-01b~~ | ~~„Freigabe zur Umsetzung P-01b: Mobile/PWA-Zugriff auf Rechtliches"~~ | ✅ historisch abgeschlossen (Version 0.8.70) |
|
||
| ~~P-01c~~ | ~~„Freigabe zur Umsetzung P-01c: Admin-konfigurierbare Rechtstexte"~~ | ✅ historisch abgeschlossen (Version 0.8.71); Erweiterungen copy-as-draft (0.8.72) + jsPDF/Sortierung (0.8.74) |
|
||
| **P-06** | **„Freigabe zur Umsetzung P-06 auf Basis konservativer Erstannahmen"** | ✅ erteilt + umgesetzt (2026-05-11, v0.8.75) — technisch umgesetzt unter `p06-v1-conservative`; KRIT-04 bleibt bis juristische Validierung |
|
||
| Etappe B komplett | „Freigabe zur Umsetzung Etappe B: P-11, P-13" | ⬅ nächste empfohlene Freigabe (nach juristischer Klärung P-06/KRIT-04 und Rechtstexten P-01) |
|
||
| P-02 Spezifikation | „Freigabe zur Spezifikation P-02: DSGVO-Self-Service-Prozess" | offen |
|
||
|
||
---
|
||
|
||
*Erstellt: 2026-05-10 | Quellen: `docs/compliance-audit.md`, `docs/compliance-package-register.md`, `docs/compliance-implementation.md` | Kein Rechtsanwalt; alle rechtlichen Einschätzungen sind juristisch zu prüfen.*
|