Internes Dokument · Anlage zum AVV · nicht öffentlich verlinkt
Technische und organisatorische Maßnahmen (TOM)
Vertraulichkeit (Art. 32 Abs. 1 lit. b)
| Maßnahme | Stand |
|---|---|
| Zutrittskontrolle Rechenzentrum | Hetzner-RZ Falkenstein/Nürnberg, ISO 27001 zertifiziert |
| Zugangskontrolle Server | SSH nur per ed25519-Key; Passwort-Login server-weit deaktiviert (PasswordAuthentication no); Root nur per Key (prohibit-password). Fail2ban an SSH-Port. |
| Berechtigungskonzept (Anwendung) | 9 Rollen-Typen (Admin, Manager/Standortleitung, Bereichsleitung, Facility, Baker, Tradesman, Employee, Minijobber, External/Gast) mit klar definierten Zugriffsrechten auf Modul-Ebene. Verwaltungs-Rolle „Verwaltung (delegiert)" mit ~20 fein granulierten Kompetenz-Bereichen — pro Mandant frei kombinierbar, ohne Voll-Admin-Rechte vergeben zu müssen. Modul-Sichtbarkeit via Service-Toggles pro Mandant (ServiceConfig). Die vollständige Rolle×Modul-Berechtigungsmatrix ist in der Rollen-Matrix-Anlage zum AVV dokumentiert; Drift wird automatisiert durch tests/test_role_map_routes.py und tests/test_role_matrix_extended.py in der CI-Pipeline überprüft. |
| Rollentrennung Betrieb | Entwicklung, Betrieb und Datenschutz-Ansprechpartner liegen formal beim Inhaber Stefan Eschbach. Aufgaben-Trennung wird durch dokumentierte Prozesse abgebildet: Deploy-Pipeline (GitHub-Webhook → Provisioner-Skript) trennt Code-Push (Entwicklung) von Betrieb; Mandanten-Daten sind für Entwicklung nur auf ausdrückliche Weisung des Auftraggebers zugänglich (Support-Ticket). |
| Mehr-Faktor-Authentifizierung (MFA) | Admin-Login der Mandanten-Instanz: 2-Faktor per E-Mail-Code (6-stellig, 5 Min gültig). Superadmin (KiNi-Plattform-Backoffice): Login + 2FA per E-Mail an separate Sicherheits-Mailbox. Server-SSH: ed25519-Key + lokale Key-Passphrase als zweiter Faktor. Mitarbeitende: optional über Browser-/Geräte-Bindung; Pflicht-MFA für Mitarbeitende ist als zukünftige Erweiterung vorgesehen. |
| Berechtigungs-Rezertifizierung | Mandanten-Admin prüft die User-Liste seiner Instanz quartalsweise (interner Prozess, durch jährlichen AVV-Reminder unterstützt). KiNi-Superadmin-Zugang wird durch den Inhaber halbjährlich überprüft (Self-Audit); Sub-Auftragsverarbeiter-Zugänge werden im Rahmen der jährlichen AVV-Review (siehe „Verfahren") nachgehalten. |
| Zugriffskontrolle Anwendung | Rollenbasierte Berechtigungen mit serverseitigem Permission-Gate auf jeder Route (`require_roles` / `require_competence`); Argon2-Passwort-Hash; Session-Cookies signiert (itsdangerous); Recovery-Code (8-stellig) statt Passwort-Reset per Mail. |
| Trennungskontrolle Mandanten | Pro Mandant separate Postgres-DB + Subdomain + Docker-Container. Keine geteilten Tabellen, keine Cross-Mandanten-Abfragen möglich. |
| Pseudonymisierung / Anonymisierung | Logs ohne PII (kein User-Name in Log-Zeilen); Demo-Instanz mit Musterdaten; Weiterbildungs-Feedback ohne User-Bezug (SHA-256-Hash für Doppel-Abgabe-Schutz); Beschwerde/KVP/Beauftragten-Nachrichten mit drei Anonymitäts-Modi (named/pseudonym/full). |
| Transport-Sicherheit | TLS 1.2+ erzwungen; Sicherheits-Header (HSTS, CSP, X-Frame-Options, nosniff, Referrer-/Permissions-Policy) auf App und Website. Let's-Encrypt-Zertifikate mit automatischer Verlängerung (certbot-cron). |
| Externe Ressourcen | Schriften und JS-Bibliotheken selbst gehostet (kein Google-Fonts-/CDN-Drittland-Transfer); Karten nur über OpenStreetMap; Push-Notifications über die Browser-eigenen Push-Services (Apple/Google/Mozilla mit SCC, Inhalt Ende-zu-Ende-verschlüsselt). |
Integrität (Art. 32 Abs. 1 lit. b)
| Maßnahme | Stand |
|---|---|
| Weitergabekontrolle | TLS 1.2+ erzwungen (nginx) |
| Eingabekontrolle | Audit-Log für administrative Änderungen (Server-Logs mit Zeitstempel und User-ID); Lösch-Protokolle für Soft-Delete / Hard-Delete (vgl. AVV §11 Abs. 4 und „Löschkonzept" unten). |
| Protokollierung (Application Logs) | Strukturierte App-Logs (FastAPI/uvicorn) mit Anfrage-Pfad, HTTP-Status, Latenz, anonymisierter Client-IP; keine Personendaten in Log-Zeilen. Rotation 14 Tage, Off-Site-Replikation. Login-Versuche, 2FA-Eingaben und Admin-Logins werden mit Erfolg/Fehlschlag mitprotokolliert. |
| Datei-Upload-Validation | Drei-Stufen-Validation auf jedem Upload-Endpoint (Bilder, Chat-Anhänge, Anbieter-PDFs, Beauftragten-Dokumente, …): (1) Block-Liste gefährlicher Endungen — .exe/.scr/.bat/.cmd/.com/.pif/.vbs/.js/.ps1/.jar/.sh/.py/.php/… sowie Doppelendungen wie foo.pdf.exe; auch Makro-Office-Formate (.docm/.xlsm/.pptm) sind ausgeschlossen. (2) Magic-Byte-Check — Header-Signatur muss zur deklarierten Endung passen (PNG/JPG/GIF/WebP/SVG/PDF/OLE-Office/OpenXML); Text-Formate werden gegen Executable-Magics (MZ/ELF/Mach-O/Shebang) geprüft. (3) Antivirus-Hook — produktive ClamAV-Anbindung über Unix-Socket (/var/run/clamav/clamd.ctl) ist aktiv (CLAMAV_ENABLED=1 in allen App-Containern; Daemon als Systemdienst clamav-daemon auf dem Hetzner-Host). Treffer werden mit Logger-Eintrag blockiert; bei temporärer Nichterreichbarkeit des Daemons fail-open (Block-Liste + Magic-Byte greifen weiterhin) und Warning-Log. Signatur-Updates über freshclam (cron, täglich). Größengrenzen: Chat 15 MB, Branding/Anbieter/Beauftragte 5 MB. Dateinamen werden im Server-Pfad durch UUIDs ersetzt, Original-Name bleibt nur als Anzeige-Attribut. Blockierte Versuche landen im Logger app.upload.security auf Warning-Level. Chat-Nachrichten und Chat-Anhänge sowie Postfach-Nachrichten werden nach 30 Tagen automatisch gelöscht. |
Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b)
| Maßnahme | Stand |
|---|---|
| Backup | Tägliche pg_dump-Backups je Mandanten-DB (3 Uhr, Cron), Aufbewahrung 14 Tage. |
| Backup-Verschlüsselung | Backups werden vor der Off-Site-Replikation mit AES-256 verschlüsselt; der Schlüssel ist auf dem Primär-Server in einer schreibgeschützten Datei mit ausschließlichem Root-Zugriff hinterlegt und Bestandteil des Disaster-Recovery-Runbooks. Auf dem Off-Site-Server liegen ausschließlich verschlüsselte Dumps. |
| Off-Site-Backup | Nächtliche Replikation auf separaten Zweit-Server (anderer Hetzner-Standort), eigener IP-restringierter SSH-Key, 14 Tage Aufbewahrung. |
| Wiederanlauf-Zeiten | RTO ≤ 8 Stunden (Recovery Time Objective): vollständige Wiederherstellung aller aktiven Mandanten-Instanzen aus Off-Site-Backup. RPO ≤ 24 Stunden (Recovery Point Objective): maximaler Datenverlust ein Tagesbackup. Bei kritischen Ausfällen einzelner Container greift Docker-Restart-Policy in < 1 Minute. |
| Disaster Recovery | Wiederherstellung per pg_restore aus lokalem oder Off-Site-Dump. DR-Runbook in /root/SUPERADMIN_ANLEITUNG.md auf dem Server; jährlich getestet. |
| Monitoring & Uptime | Self-hosted Uptime-Check alle 5 Min (curl /auth/login jeder aktiven Instanz + Provisioner-Healthz + Superadmin-Healthz). Bei 2 aufeinanderfolgenden Fails: Postmark-Mail an stefaneschbach@yahoo.de; Recovery-Mail beim Wiederanlauf. |
Verfahren zur regelmäßigen Prüfung (Art. 32 Abs. 1 lit. d)
| Maßnahme | Stand |
|---|---|
| Patch-Management | Betriebssystem: Debian-Stable, unattended-upgrades aktiv für Security-Pakete, manuelle Re-Boots quartalsweise im Wartungsfenster. Container: Python-Base-Image-Rebuild monatlich, Library-Updates bei CVE-Treffer innerhalb 7 Tagen. App-Code: Continuous Deployment per GitHub-Webhook nach jedem Push auf main; Notfall-Patches innerhalb 24 h. Dependency-Scan: pip-audit und GitHub Dependabot wöchentlich. |
| Sicherheits-Selbstprüfung | Internes Prüf-Skript (siehe Superadmin-Button „Sicherheits-Selbstprüfung") wird automatisiert monatlich sowie auf Klick durch den Inhaber gegen alle aktiven Instanzen ausgeführt und prüft u. a. Passwort-Hash-Algorithmen, Session-Sicherheit, HTTPS-Konfiguration, CSRF-Schutz, Upload-Validierung, Datei-Berechtigungen sowie OWASP-Top-10-Klassen (SQL-Injection via Parameterized-Query-Audit, XSS via Sanitizer-Tests, IDOR via Permission-Matrix-Tests, Auth-Bypass via Negative-Permission-Tests, SSRF in Geocode-/URL-Endpoints, sensitive-Data-Exposure). Ein ergänzender externer Penetrationstest wird anlassbezogen bei signifikantem Mandanten-Wachstum oder Aufnahme besonders sensibler Datenkategorien erwogen; ein verbindliches Intervall wird in der nächsten TOM-Review festgelegt. |
| Incident-Management | Erkennung: Uptime-Mails, App-Error-Mails, Anwender-Tickets per info@kini.solutions. Eskalation: Inhaber wird primär kontaktiert; bei vermuteter Datenpanne läuft das §9-AVV-Verfahren (24-h-Meldung). Dokumentation: Vorfälle werden im Incident-Ordner mit Zeitstempel, Ursache, Auswirkung, Gegenmaßnahmen und Nachprüfung archiviert. Lessons-Learned: Nachgelagerte Schritte als Ticket im Backlog. |
| DSGVO-Scan | Wird durch internes Prüf-Tool (scripts/security_scan.py) wiederkehrend durchgeführt — vom Superadmin per Knopfdruck auslösbar. |
| AVV-Review Sub-Auftragsverarbeiter | Jährlich; aktuelle Liste: Hetzner, Postmark, Stripe, Apple/Google/Mozilla (Push). Bei Änderung an Sub-AVs Vorab-Information der Mandanten gemäß AVV §7. |
| Mitarbeiter-Schulung | Da KiNi Solutions ein Einzelunternehmen ist, beschränkt sich die Schulungspflicht auf den Inhaber selbst. Stefan Eschbach hält den DSGVO-Wissensstand durch Lektüre aktueller Aufsichtsbehörden-Veröffentlichungen, BMI-Hinweise und einschlägiger Fachblogs aufrecht. Sollte das Unternehmen wachsen, ist eine jährliche Pflichtschulung neu hinzukommender Mitarbeitender vorgesehen. |
| Berechtigungs-Rezertifizierung | Halbjährlich für Superadmin-Zugang; jährliche AVV-Reminder-Mail an Mandanten mit Aufruf zur Überprüfung der instanz-eigenen User-Liste. |
Löschkonzept (Art. 5 Abs. 1 lit. e DSGVO)
Verweist auf das ausführliche Löschkonzept. Kernpunkte:
| Maßnahme | Stand |
|---|---|
| Soft-Delete-Phase nach Vertragsende | 30 Tage logische Sperre, kein eigenständiger AV-Zugriff, Export-Möglichkeit für Mandant. Vgl. AVV §11. |
| Irreversible Löschung | Automatisierter Lösch-Job nach Ablauf der 30 Tage. Bei buchhaltungsrelevanten Daten (§ 257 HGB): gesonderte Archivierung, Löschung nach Ablauf der gesetzlichen Frist. |
| Lösch-Protokoll | Pro Löschvorgang: Zeitstempel, Mandant-Identifikator, Anzahl gelöschter Datensätze pro Tabelle, SHA-256-Prüfsumme der Operation. Aufbewahrung 7 Jahre im internen Audit-Bereich. |
| Backup-Behandlung | Backups mit Mandanten-Daten werden mit der nächsten Rotation (max. 14 Tage) automatisch mit-gelöscht. |
| Anwendungs-internes Löschen | Chat-Nachrichten und Chat-Anhänge sowie Postfach-Nachrichten werden täglich um 03:00 UTC nach 30 Tagen automatisch gelöscht; gelöschte Beschwerden/KVP bleiben als Soft-Delete-Vermerk in der Statistik (Status „Gelöscht"), Inhalt entfernt; gelöschte Konten werden mit Konto-Schließung physisch entfernt. |
Auftragskontrolle (Art. 28)
| Maßnahme | Stand |
|---|---|
| AVV mit jedem Kunden | Template vorhanden, siehe AVV |
| AVV mit Subdienstleistern | Hetzner, Postmark, Stripe – einzuholen bzw. abzulegen |
Verantwortlich für die TOM-Pflege
Stefan Eschbach – Aktualisierung mindestens jährlich oder bei wesentlichen Änderungen.