5f360480ae
All checks were successful
Build and Push Docker Image / build-and-push (push) Successful in 53m24s
Compliance-Runde 2 (ohne Doppelstrukturen; baut auf v1.7–v1.9 auf): FKS/FEUKOS (dokumentierte schriftliche Genehmigung 17.02.2026): - legal.ts: fksAttribution (exakte Quellenangabe, Genehmigungsdatum, Nutzungshinweis) + operatorType - Neue Seite /quellen-und-lizenzen (+ Footer/Sitemap-Link) - FKS-Abschnitt in Nutzungsbedingungen (§10a); Quellenangabe im Symbol-Panel und in PDF/PNG-Export - Terminologie entschärft: "offizielle FKS/BABS-Signaturen" -> "FEUKOS-Symbole der FKS" (keine Partnerschaft/Zertifizierung/Empfehlung suggeriert) - FKS_ATTRIBUTION als Dokumenttyp (Migration-Seed, LegalDocumentType), Kontexte erweitert - licenses-and-attributions.md aktualisiert; .gitignore: private-legal-evidence/ Datenschutz/Transparenz: - [REGION]-Platzhalter in der Subprozessorenliste durch öffentlich bekannte Firmensitze ersetzt (keine Platzhalter mehr öffentlich sichtbar) - Journal-Freitext-Warnung (keine schutzwürdigen Daten) Docs: current-state-audit, international-data-transfers, backup-and-restore, privacy-risk-assessment, manual-action-checklist Tests: Krypto-Round-Trip (crypto-secret); legal-config-Test aktualisiert; 17 grün. tsc+build ok. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.5 KiB
2.5 KiB
Datenschutz-Risikovorprüfung — Lageplan
Stand: 2026-07-24 · sorgfältiger Entwurf. Vorprüfung, keine abschliessende Datenschutz- Folgenabschätzung (DSFA). Ob eine vertiefte DSFA nötig ist, muss eine Fachperson beurteilen — dies wird hier nicht pauschal verneint.
Skala: Wahrscheinlichkeit/Auswirkung = niedrig / mittel / hoch.
| # | Risiko | Wahrsch. | Auswirkung | Bestehende Massnahmen | Restrisiko | Weitere Massnahme | Rolle |
|---|---|---|---|---|---|---|---|
| 1 | Offenlegung von Gebäude-/Zufahrts-/Gefahren-/Hydranten-/Schlüsselstellen-Infos | mittel | hoch | Mandantentrennung, Rollen, Zugriffskontrolle, Verbot sensibler Daten (NB) | mittel | Org-Sensibilisierung, ggf. Feldklassifizierung | Betreiber/Org |
| 2 | Organisationsübergreifender Zugriff (IDOR) | niedrig | hoch | getProjectWithTenantCheck, serverseitige Prüfung, autom. Tests |
niedrig | periodische Tests/Pentest | Betreiber |
| 3 | Datenleck über Dateizugriffe | niedrig | hoch | serve-Routen mit Tenant-Check, MinIO nicht öffentlich für private Objekte | niedrig | Pentest, Bucket-Policy-Review | Betreiber |
| 4 | Kompromittierung Adminkonto | niedrig | hoch | MFA (TOTP/WebAuthn), Rate-Limiting, bcrypt | niedrig | MFA für alle Admins erzwingen (Option) | Betreiber |
| 5 | Auslandbearbeitung (Stripe/E-Mail/Karten) | mittel | mittel | Transparente Doku, optionale Dienste, IP nur clientseitig | mittel | DPA/SCC prüfen | Betreiber |
| 6 | Standortdaten (GPS) der Nutzer | niedrig | mittel | nur zur Kartenfunktion, keine dauerhafte Speicherung durch App | niedrig | Doku bestätigen | Betreiber |
| 7 | Besonders schützenswerte Daten in Freitext/Journal | mittel | hoch | NB-Verbot, In-App-Warnungen (Journal, Dashboard), Org-Bestätigung | mittel | ggf. Muster-Erkennung/Hinweis | Betreiber/Org |
| 8 | Verlust/Nichtverfügbarkeit von Daten | niedrig | mittel | Backups (lokal + verschlüsselt off-site) | niedrig | Restore-Test durchführen | Betreiber |
| 9 | Datenleck durch Drittanbieter-Subprozessor | niedrig | mittel | minimale Datenweitergabe, Subprozessorenliste | mittel | Anbieterprüfung dokumentieren | Betreiber |
| 10 | Fehlende/veraltete fachliche Prüfung eines Plans | mittel | hoch | Hinweise in App/Export; Planstatus (in Umsetzung) | mittel | Freigabe-Workflow finalisieren | Org |
Empfehlung
Eine vertiefte DSFA sollte durch eine qualifizierte Fachperson geprüft werden — insbesondere wegen sicherheitsrelevanter Objekt-/Infrastrukturdaten (Risiko 1, 3, 7). Diese Vorprüfung ersetzt sie nicht.