Initial commit

backup 24.2.26 - Kopie (61)/security/audit/AUDIT_READINESS_2026-02.md

@@ -0,0 +1,525 @@
+# AUDIT-READINESS ASSESSMENT
+# AZA / MedWork – Februar 2026
+
+**Assessor:** Internes Security-Team (automatisiert)
+**Datum:** 2026-02-22
+**Scope:** AZA/MedWork Gesamtsystem
+**Datenklassifikation:** Besonders schützenswerte Personendaten (Gesundheitsdaten)
+**Rechtsrahmen:** DSG (Schweiz, rev. 2023), DSGVO (ergänzend), HIN-Referenzniveau
+**Referenzdokumente:** TOMs_AZA_MedWork.md, GAP-Analyse (STEP 3), Handovers STEP 4.1–6
+
+---
+
+## 1. Technische Sicherheit
+
+---
+
+### 1.1 Transport Security
+
+#### Status: YELLOW
+
+#### Begründung:
+- TLS >= 1.2 für alle Backend-Services erzwungen (STEP 4.1, verifiziert in 4.1a)
+- Starke Cipher Suites mit PFS (ECDHE+AESGCM, CHACHA20)
+- HTTP wird komplett abgelehnt (kein Redirect, Connection Refused)
+- Fail-Start bei fehlenden Zertifikaten
+- **ABER:** Nur Self-Signed-Zertifikate für Entwicklung vorhanden
+- **ABER:** SMTP STARTTLS ist opportunistisch (nicht erzwungen)
+- **ABER:** Keine Ende-zu-Ende-Verschlüsselung für E-Mails
+
+#### Blocker für externes Audit:
+- Nein, kein harter Blocker. TLS ist implementiert und verifiziert.
+- Produktivzertifikate (Let's Encrypt / CA-signiert) müssen vor Go-Live beschafft werden.
+
+#### Empfohlene nächste Schritte:
+1. Produktiv-Zertifikate beschaffen (Let's Encrypt / ACME)
+2. SMTP-STARTTLS-Erzwingung implementieren (Fehler bei fehlgeschlagenem TLS)
+3. S/MIME oder Gateway-Verschlüsselung für medizinische E-Mails evaluieren
+
+---
+
+### 1.2 Authentifizierung
+
+#### Status: YELLOW
+
+#### Begründung:
+- Passwort-Login mit bcrypt (cost=12, Salt eingebettet) – STEP 4.2
+- Legacy-SHA-256-Migration transparent implementiert und verifiziert – STEP 4.2a
+- TOTP-2FA implementiert (RFC 6238, optional/erzwingbar via ENV) – STEP 6
+- Backup-Codes (8 Einmal-Codes, SHA-256-gehasht) vorhanden
+- Rate-Limiting auf TOTP-Versuche (5/5min)
+- RBAC im Workforce Planner (3 Rollen)
+- **ABER:** 2FA nur im Desktop-Client, nicht im Workforce Planner (Web-API)
+- **ABER:** Kein SSO (SAML/OAuth/OIDC)
+- **ABER:** Keine Identitätsprüfung (Videoidentifikation o.ä.)
+- **ABER:** Minimale Passwortanforderung (4 Zeichen) ist zu schwach
+
+#### Blocker für externes Audit:
+- Ja, teilweise. Für medizinische Systeme wird 2FA in der Regel erwartet.
+  Im Desktop-Client vorhanden, im Web-API fehlt sie.
+
+#### Empfohlene nächste Schritte:
+1. Minimale Passwortlänge auf 8+ Zeichen erhöhen
+2. 2FA im Workforce Planner (Web-API) implementieren
+3. `AZA_2FA_REQUIRED=1` als Standard für Produktion setzen
+
+---
+
+### 1.3 Secrets Management
+
+#### Status: GREEN
+
+#### Begründung:
+- Hardcoded Secret Key entfernt – STEP 4.3
+- Zentrale Validierung: Mindestlänge 32 Zeichen, keine trivialen Muster
+- Fail-Start bei fehlendem oder schwachem Key
+- DEV-Modus mit auto-generiertem Key (explizit AZA_ENV=dev)
+- Klartext-Credentials aus Config entfernt – STEP 4.4
+- E-Mail-Passwörter nur via ENV-Variablen
+- Incident-Dokumentation für exponiertes Passwort erstellt – STEP 4.4a
+- TOTP-Secrets verschlüsselt gespeichert (nie Klartext auf Disk)
+
+#### Blocker für externes Audit:
+- Nein. Secret Management ist solide implementiert und dokumentiert.
+
+#### Empfohlene nächste Schritte:
+1. Passwort beim Mail-Provider rotieren (INCIDENT offen)
+2. OS-Keychain-Integration evaluieren (Windows Credential Manager)
+3. Secret-Scanning in CI/CD-Pipeline einführen
+
+---
+
+### 1.4 2FA
+
+#### Status: YELLOW
+
+#### Begründung:
+- TOTP (RFC 6238) implementiert mit pyotp – STEP 6
+- QR-Code-Provisioning, Erst-Validierung, Backup-Codes
+- Rate-Limiting (5 Versuche / 5 Minuten)
+- ENV-Steuerung (AZA_2FA_ENABLED, AZA_2FA_REQUIRED)
+- **ABER:** Nur im Desktop-Client (basis14.py), nicht im Workforce Planner
+- **ABER:** Aktuell optional (AZA_2FA_REQUIRED=0)
+- **ABER:** Kein Hardware-Token-Support (FIDO2/WebAuthn)
+
+#### Blocker für externes Audit:
+- Teilweise. 2FA ist implementiert, aber nicht standardmässig erzwungen.
+  Für HIN-Niveau wäre 2FA-Pflicht erforderlich.
+
+#### Empfohlene nächste Schritte:
+1. AZA_2FA_REQUIRED=1 als Produktiv-Standard
+2. 2FA im Workforce Planner nachrüsten
+3. FIDO2/WebAuthn als Upgrade-Option evaluieren
+
+---
+
+### 1.5 Logging & Monitoring
+
+#### Status: RED
+
+#### Begründung:
+- Audit-Log-Modell existiert (AuditLog-Tabelle in workforce_planner)
+- log_action()-Funktion definiert
+- **ABER:** log_action() wird in keinem API-Endpunkt aufgerufen
+- **ABER:** Kein Logging fehlgeschlagener Anmeldeversuche
+- **ABER:** Kein zentrales Logging-Framework
+- **ABER:** Kein Monitoring, kein Alerting
+- **ABER:** Debug-Prints statt strukturiertem Logging
+- **ABER:** Kein SIEM
+
+#### Blocker für externes Audit:
+- Ja. Fehlende Nachvollziehbarkeit von Datenzugriffen ist ein Kernproblem
+  für medizinische Systeme (DSG Art. 8, DSGVO Art. 5 Abs. 2).
+
+#### Empfohlene nächste Schritte:
+1. log_action() in alle schreibenden API-Endpunkte integrieren
+2. Fehlgeschlagene Login-Versuche protokollieren
+3. Strukturiertes Logging (Python logging-Modul) einführen
+
+---
+
+## 2. Datenschutz
+
+---
+
+### 2.1 TOMs-Dokumentation
+
+#### Status: GREEN
+
+#### Begründung:
+- Vollständiges TOMs-Dokument erstellt (12 Bereiche) – STEP 5
+- Alle 12 DSG/DSGVO-Bereiche abgedeckt
+- Klare Trennung: implementiert vs. nicht implementiert
+- 35 Massnahmen implementiert, 62 offen
+- Referenzen auf technische Implementierungen vorhanden
+
+#### Blocker für externes Audit:
+- Nein. TOMs-Dokument ist vorhanden und audit-tauglich.
+  Inhaltlich zeigt es aber viele offene Punkte auf.
+
+#### Empfohlene nächste Schritte:
+1. TOMs nach jedem Security-Schritt aktualisieren
+2. Versionierung/Changelog für TOMs einführen
+3. Verantwortlichkeiten pro TOM zuweisen
+
+---
+
+### 2.2 Incident Management
+
+#### Status: YELLOW
+
+#### Begründung:
+- Ein Incident wurde formal dokumentiert (Credential Exposure) – STEP 4.4a
+- Checkliste mit Sofortmassnahmen und Folgeaktionen vorhanden
+- Security-Handovers für alle Schritte dokumentiert
+- **ABER:** Kein formaler Incident-Response-Plan
+- **ABER:** Keine Eskalationsstufen definiert
+- **ABER:** Keine Prozesse für DSG Art. 24 (Meldung an EDÖB innert 72h)
+- **ABER:** Passwort-Rotation (Incident-Empfehlung) noch offen
+
+#### Blocker für externes Audit:
+- Ja, teilweise. Das DSG verlangt eine Meldefähigkeit innert 72h.
+  Ohne definierten Prozess ist diese nicht gewährleistet.
+
+#### Empfohlene nächste Schritte:
+1. Incident-Response-Plan erstellen (Rollen, Eskalation, Fristen)
+2. Meldeprozess an EDÖB definieren (72h-Frist)
+3. Offene Incident-Massnahme abschliessen (Passwort-Rotation)
+
+---
+
+### 2.3 Datenminimierung
+
+#### Status: RED
+
+#### Begründung:
+- Keine formale Datenminimierungsstrategie
+- Patientendaten (KG) werden lokal ohne Löschfristen gespeichert
+- Keine Klassifikation der verarbeiteten Daten
+- Keine Prüfung, ob nur notwendige Daten erhoben werden
+- OpenAI API erhält potenziell Patientendaten (Transkription, KG-Generierung)
+  ohne dokumentierte Notwendigkeitsprüfung
+- E-Mail-Inhalte werden vollständig lokal gecacht
+
+#### Blocker für externes Audit:
+- Ja. Datenminimierung ist ein Grundprinzip (DSG Art. 6 Abs. 2,
+  DSGVO Art. 5 Abs. 1 lit. c). Ohne Nachweis ist ein Audit nicht bestehbar.
+
+#### Empfohlene nächste Schritte:
+1. Datenverarbeitungsverzeichnis (Art. 12 DSG) erstellen
+2. Prüfen welche Daten an OpenAI gesendet werden (Anonymisierung?)
+3. Aufbewahrungsfristen für medizinische Daten definieren (kant. Recht: 10–20 Jahre)
+
+---
+
+### 2.4 Löschkonzepte
+
+#### Status: RED
+
+#### Begründung:
+- Kein Löschkonzept vorhanden
+- Keine automatische Datenlöschung
+- Keine Löschfunktion für Patientendaten
+- Keine Dokumentation der Aufbewahrungsfristen
+- Medizinische Daten: kantonale Aufbewahrungspflichten (typisch 10 Jahre)
+  sind weder dokumentiert noch technisch unterstützt
+
+#### Blocker für externes Audit:
+- Ja. Recht auf Löschung (DSG Art. 32, DSGVO Art. 17) nicht umsetzbar.
+
+#### Empfohlene nächste Schritte:
+1. Aufbewahrungsfristen pro Datentyp definieren
+2. Löschfunktion für Patientendaten implementieren
+3. Automatische Löschung nach Ablauf der Aufbewahrungsfrist
+
+---
+
+## 3. Organisation
+
+---
+
+### 3.1 Rollen & Verantwortlichkeiten
+
+#### Status: YELLOW
+
+#### Begründung:
+- RBAC im Workforce Planner (ADMIN, MANAGER, EMPLOYEE)
+- Rollen-basierte API-Zugriffskontrolle implementiert
+- Security-Projekt hat definierte Rollen (Security Engineer, Architekt, Inhaber)
+- **ABER:** Kein Datenschutzbeauftragter (DSB) benannt
+- **ABER:** Kein IT-Sicherheitsbeauftragter benannt
+- **ABER:** Keine Zugriffsmatrix für Patientendaten
+- **ABER:** Keine regelmässige Berechtigungsüberprüfung
+
+#### Blocker für externes Audit:
+- Teilweise. DSB-Benennung ist für medizinische Praxen in der Schweiz
+  nicht zwingend (< 250 Mitarbeiter), aber empfohlen.
+
+#### Empfohlene nächste Schritte:
+1. Datenschutz-Verantwortlichen benennen (auch wenn nicht DSB-pflichtig)
+2. Zugriffsmatrix für Patientendaten erstellen
+3. Regelmässige Berechtigungsüberprüfung einführen
+
+---
+
+### 3.2 Schulung
+
+#### Status: RED
+
+#### Begründung:
+- Keine Security-Awareness-Schulungen
+- Keine Dokumentation für Endbenutzer
+- Keine Schulung zum Umgang mit Patientendaten
+- Keine Phishing-Awareness
+- Keine Einweisungsprozedur
+
+#### Blocker für externes Audit:
+- Ja. Fehlende Mitarbeiterschulung ist ein Standard-Audit-Finding.
+  DSG Art. 8 verlangt angemessene organisatorische Massnahmen.
+
+#### Empfohlene nächste Schritte:
+1. Kurzschulung "Datenschutz für Praxismitarbeiter" erstellen (1 Seite)
+2. Benutzerhandbuch für AZA/MedWork mit Security-Hinweisen
+3. Jährliche Auffrischung dokumentieren
+
+---
+
+### 3.3 Prozesse
+
+#### Status: RED
+
+#### Begründung:
+- Kein Change-Management-Prozess
+- Kein Release-Management
+- Kein formaler Testprozess vor Produktiv-Updates
+- Kein Code-Review-Prozess
+- Kein Vulnerability-Disclosure-Prozess
+- Security-Projekt folgt strukturiertem Vorgehen (Steps), aber nicht formalisiert
+
+#### Blocker für externes Audit:
+- Teilweise. Fehlende Prozesse sind ein Risiko, aber für eine
+  Einzelpraxis nicht zwingend auditrelevant.
+
+#### Empfohlene nächste Schritte:
+1. Minimaler Change-Management-Prozess definieren
+2. Checkliste vor Produktiv-Deployment
+3. Regelmässige Dependency-Prüfung (pip-audit)
+
+---
+
+## 4. Betrieb
+
+---
+
+### 4.1 Backup & Recovery
+
+#### Status: RED
+
+#### Begründung:
+- Nur manuelle Dateisystem-Backups (Ordner-Kopien)
+- Kein automatisiertes Backup
+- Kein Off-Site-Backup
+- Keine dokumentierte Recovery-Prozedur
+- Keine RTO/RPO definiert
+- Keine Wiederherstellungstests
+
+#### Blocker für externes Audit:
+- Ja. Verfügbarkeitskontrolle ist eine Grundanforderung (DSG Art. 8).
+  Ohne Backup-Konzept für medizinische Daten nicht auditierbar.
+
+#### Empfohlene nächste Schritte:
+1. Automatisiertes tägliches Backup einrichten
+2. RTO/RPO definieren (z.B. RPO=24h, RTO=4h)
+3. Quartalsmässige Wiederherstellungstests durchführen
+
+---
+
+### 4.2 Patching
+
+#### Status: RED
+
+#### Begründung:
+- Kein dokumentiertes Patch-Management
+- Keine automatische Dependency-Prüfung
+- Keine Update-Zyklen definiert
+- Kein Changelog
+
+#### Blocker für externes Audit:
+- Teilweise. Ohne Nachweis aktueller Dependencies besteht Risiko
+  durch bekannte Schwachstellen.
+
+#### Empfohlene nächste Schritte:
+1. `pip-audit` einmalig ausführen und Ergebnis dokumentieren
+2. Monatlichen Dependency-Check einführen
+3. requirements.txt mit festen Versionen pflegen
+
+---
+
+### 4.3 Monitoring
+
+#### Status: RED
+
+#### Begründung:
+- Kein Health-Check-Monitoring
+- Kein Alerting bei Service-Ausfall
+- Kein Performance-Monitoring
+- Keine Anomalie-Erkennung
+
+#### Blocker für externes Audit:
+- Teilweise. Für eine Desktop-App weniger kritisch als für Cloud-Services.
+
+#### Empfohlene nächste Schritte:
+1. Health-Check-Endpunkt für Backend-Services (bereits vorhanden: /health)
+2. Einfaches Uptime-Monitoring (z.B. Skript mit Alerting)
+3. Fehlgeschlagene Login-Versuche loggen und alarmieren
+
+---
+
+## 5. Recht
+
+---
+
+### 5.1 Informationspflichten
+
+#### Status: RED
+
+#### Begründung:
+- Keine Datenschutzerklärung für Patienten
+- Keine Information über Datenverarbeitung beim Einsatz von OpenAI
+- Keine Einwilligungserklärung für KI-gestützte Verarbeitung
+- DSG Art. 19–21 (Informationspflicht) nicht umgesetzt
+
+#### Blocker für externes Audit:
+- Ja. Informationspflicht ist zwingend für medizinische Daten.
+
+#### Empfohlene nächste Schritte:
+1. Datenschutzerklärung für Patienten erstellen
+2. Einwilligungserklärung für KI-Verarbeitung (OpenAI) erstellen
+3. Information über Datenübermittlung ins Ausland (OpenAI-Server)
+
+---
+
+### 5.2 Auftragsverarbeitungsverträge (AV)
+
+#### Status: RED
+
+#### Begründung:
+- Kein AV/DPA mit OpenAI dokumentiert
+- Kein AV/DPA mit Supabase dokumentiert
+- Kein AV/DPA mit E-Mail-Provider
+- Keine Prüfung der Datenverarbeitungsstandorte
+
+#### Blocker für externes Audit:
+- Ja. AV-Verträge sind gesetzlich vorgeschrieben bei Auftragsverarbeitung
+  (DSG Art. 9, DSGVO Art. 28).
+
+#### Empfohlene nächste Schritte:
+1. OpenAI DPA prüfen/abschliessen (existiert als Standard-DPA bei OpenAI)
+2. Supabase DPA prüfen/abschliessen
+3. Datenverarbeitungsstandorte dokumentieren (Schweiz/EU/US)
+
+---
+
+### 5.3 Privacy Policy / Einwilligungen
+
+#### Status: RED
+
+#### Begründung:
+- Keine Privacy Policy vorhanden
+- Keine Einwilligungsmechanismen in der Anwendung
+- Keine Cookie-/Tracking-Hinweise (bei Web-Komponenten)
+- Keine Widerspruchsmöglichkeit
+- Keine Auskunftsfunktion (DSG Art. 25)
+
+#### Blocker für externes Audit:
+- Ja. Fundamentale rechtliche Anforderung nicht erfüllt.
+
+#### Empfohlene nächste Schritte:
+1. Privacy Policy erstellen (Schweizer Recht, medizinischer Kontext)
+2. Einwilligungsdialog für KI-Verarbeitung in die App integrieren
+3. Auskunftsprozess definieren (Patientenrecht auf Einsicht)
+
+---
+
+## GESAMTBEWERTUNG
+
+### Ampelübersicht
+
+| Bereich | Status | Audit-Blocker |
+|---------|:------:|:---:|
+| 1.1 Transport Security | YELLOW | Nein |
+| 1.2 Authentifizierung | YELLOW | Teilweise |
+| 1.3 Secrets Management | GREEN | Nein |
+| 1.4 2FA | YELLOW | Teilweise |
+| 1.5 Logging & Monitoring | RED | Ja |
+| 2.1 TOMs-Dokumentation | GREEN | Nein |
+| 2.2 Incident Management | YELLOW | Teilweise |
+| 2.3 Datenminimierung | RED | Ja |
+| 2.4 Löschkonzepte | RED | Ja |
+| 3.1 Rollen | YELLOW | Teilweise |
+| 3.2 Schulung | RED | Ja |
+| 3.3 Prozesse | RED | Teilweise |
+| 4.1 Backup & Recovery | RED | Ja |
+| 4.2 Patching | RED | Teilweise |
+| 4.3 Monitoring | RED | Teilweise |
+| 5.1 Informationspflichten | RED | Ja |
+| 5.2 AV-Verträge | RED | Ja |
+| 5.3 Privacy Policy | RED | Ja |
+
+### Zählung
+
+| Status | Anzahl |
+|--------|:------:|
+| GREEN | 2 |
+| YELLOW | 5 |
+| RED | 11 |
+
+---
+
+### Gesamturteil
+
+#### DSG-konform: NEIN
+
+Hauptgründe: Fehlende Informationspflichten (Art. 19–21), fehlende
+AV-Verträge (Art. 9), fehlendes Löschkonzept (Art. 32), fehlende
+Nachvollziehbarkeit (Art. 8).
+
+#### DSGVO-konform: NEIN
+
+Hauptgründe: Fehlende Privacy Policy, fehlende Einwilligungen für
+KI-Verarbeitung, fehlende DPAs, fehlende Datenschutz-Folgenabschätzung
+(DSFA/DPIA) für Gesundheitsdatenverarbeitung.
+
+#### Medizinisch auditfähig: NEIN
+
+Hauptgründe: Kein Backup-Konzept, kein Logging, keine Schulung,
+keine Informationspflichten gegenüber Patienten.
+
+#### HIN-nah: TEILWEISE
+
+Technische Basis (TLS, Hashing, 2FA) ist vorhanden.
+Netzwerk-/PKI-/S/MIME-Ebene fehlt komplett.
+Organisatorische Massnahmen fehlen weitgehend.
+
+---
+
+### Priorisierte Top-10-Massnahmen für Audit-Readiness
+
+| Prio | Massnahme | Bereich | Aufwand |
+|:----:|-----------|---------|:-------:|
+| 1 | Datenschutzerklärung + Einwilligung KI | Recht | Niedrig |
+| 2 | OpenAI/Supabase DPA prüfen/abschliessen | Recht | Niedrig |
+| 3 | Incident-Passwort-Rotation abschliessen | Incident | Niedrig |
+| 4 | Automatisiertes Backup einrichten | Betrieb | Mittel |
+| 5 | Audit-Logging in API-Endpunkte integrieren | Technik | Mittel |
+| 6 | Datenverarbeitungsverzeichnis erstellen | Datenschutz | Mittel |
+| 7 | Löschkonzept + Aufbewahrungsfristen definieren | Datenschutz | Mittel |
+| 8 | Kurzschulung Datenschutz erstellen | Organisation | Niedrig |
+| 9 | Minimale Passwortlänge auf 8+ erhöhen | Technik | Niedrig |
+| 10 | AZA_2FA_REQUIRED=1 als Produktiv-Standard | Technik | Niedrig |
+
+---
+
+*Erstellt: 2026-02-22*
+*Nächste Überprüfung: Nach Umsetzung der priorisierten Massnahmen*
+*Klassifikation: Intern – Nicht zur externen Weitergabe*