16 KiB
16 KiB
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:
- Produktiv-Zertifikate beschaffen (Let's Encrypt / ACME)
- SMTP-STARTTLS-Erzwingung implementieren (Fehler bei fehlgeschlagenem TLS)
- 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:
- Minimale Passwortlänge auf 8+ Zeichen erhöhen
- 2FA im Workforce Planner (Web-API) implementieren
AZA_2FA_REQUIRED=1als 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:
- Passwort beim Mail-Provider rotieren (INCIDENT offen)
- OS-Keychain-Integration evaluieren (Windows Credential Manager)
- 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:
- AZA_2FA_REQUIRED=1 als Produktiv-Standard
- 2FA im Workforce Planner nachrüsten
- 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:
- log_action() in alle schreibenden API-Endpunkte integrieren
- Fehlgeschlagene Login-Versuche protokollieren
- 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:
- TOMs nach jedem Security-Schritt aktualisieren
- Versionierung/Changelog für TOMs einführen
- 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:
- Incident-Response-Plan erstellen (Rollen, Eskalation, Fristen)
- Meldeprozess an EDÖB definieren (72h-Frist)
- 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:
- Datenverarbeitungsverzeichnis (Art. 12 DSG) erstellen
- Prüfen welche Daten an OpenAI gesendet werden (Anonymisierung?)
- 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:
- Aufbewahrungsfristen pro Datentyp definieren
- Löschfunktion für Patientendaten implementieren
- 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:
- Datenschutz-Verantwortlichen benennen (auch wenn nicht DSB-pflichtig)
- Zugriffsmatrix für Patientendaten erstellen
- 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:
- Kurzschulung "Datenschutz für Praxismitarbeiter" erstellen (1 Seite)
- Benutzerhandbuch für AZA/MedWork mit Security-Hinweisen
- 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:
- Minimaler Change-Management-Prozess definieren
- Checkliste vor Produktiv-Deployment
- 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:
- Automatisiertes tägliches Backup einrichten
- RTO/RPO definieren (z.B. RPO=24h, RTO=4h)
- 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:
pip-auditeinmalig ausführen und Ergebnis dokumentieren- Monatlichen Dependency-Check einführen
- 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:
- Health-Check-Endpunkt für Backend-Services (bereits vorhanden: /health)
- Einfaches Uptime-Monitoring (z.B. Skript mit Alerting)
- 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:
- Datenschutzerklärung für Patienten erstellen
- Einwilligungserklärung für KI-Verarbeitung (OpenAI) erstellen
- 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:
- OpenAI DPA prüfen/abschliessen (existiert als Standard-DPA bei OpenAI)
- Supabase DPA prüfen/abschliessen
- 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:
- Privacy Policy erstellen (Schweizer Recht, medizinischer Kontext)
- Einwilligungsdialog für KI-Verarbeitung in die App integrieren
- 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