aza/AzA march 2026/security/compliance/TOMs_AZA_MedWork.md

# Technische und Organisatorische Massnahmen (TOMs)
# AZA / MedWork – Medizinische Desktop- und Backend-Anwendung

**Version:** 1.0
**Stand:** 2026-02-22
**Geltungsbereich:** AZA/MedWork Gesamtsystem (Desktop-Client, Backend-Services, E-Mail-Modul, Workforce Planner)
**Rechtsgrundlage:** Schweizer Datenschutzgesetz (DSG, rev. 2023), DSGVO (ergänzend)
**Datenklassifikation:** Besonders schützenswerte Personendaten (Gesundheitsdaten, Art. 5 lit. c DSG)

---

## 1. Zugangskontrolle

*Massnahmen, die verhindern, dass Unbefugte Zugang zu Datenverarbeitungsanlagen erhalten.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Passwort-geschützter Login | Desktop-Client (basis14.py): Passwort-Dialog bei jedem Start, kein Zugriff ohne Authentifizierung | basis14.py, Zeilen 1318–1366 |
| Workforce Planner: Token-basierte Authentifizierung | JWT (HS256) mit Ablaufzeit 480 Minuten, Bearer-Token in HTTP-Header | workforce_planner/api/auth.py |
| Backend API-Token | API-Zugriff auf Backend-Services nur mit gültigem Token (Header X-Api-Token) | backend_main.py |
| TLS-Verschlüsselung aller Backend-Services | HTTPS erzwungen für todo_server, transcribe_server, backend_main; HTTP wird abgelehnt (kein Redirect, Connection Refused) | aza_tls.py, STEP 4.1 |
| Fail-Start bei fehlender TLS-Konfiguration | Server startet nicht, wenn AZA_TLS_REQUIRE=1 und Zertifikate fehlen | aza_tls.py |

### Nicht implementiert

- Keine Multi-Faktor-Authentifizierung (2FA/MFA)
- Keine biometrische Zugangskontrolle
- Keine automatische Bildschirmsperre der Anwendung bei Inaktivität
- Kein SSO-Protokoll (SAML/OAuth/OIDC)
- Keine zertifikatsbasierte Client-Authentifizierung

---

## 2. Zugriffskontrolle

*Massnahmen, die sicherstellen, dass Berechtigte nur auf die ihnen zugewiesenen Daten zugreifen können.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Rollenbasierte Zugriffskontrolle (RBAC) | Workforce Planner: 3 Rollen (ADMIN, MANAGER, EMPLOYEE) mit Dependency-basierter Prüfung pro API-Endpunkt | workforce_planner/core/enums.py, api/auth.py |
| Rollenprüfung bei schreibenden Operationen | Mitarbeiterverwaltung und Abwesenheitsmanagement erfordern ADMIN oder MANAGER Rolle | routes_employees.py, routes_absences.py |
| Löschoperationen nur für ADMIN | Mitarbeiter-Löschung ist auf ADMIN-Rolle beschränkt | routes_employees.py |
| Profil-Zugriff mit Passwortprüfung | Passwortänderung im Desktop-Client erfordert Eingabe des alten Passworts | basis14.py, Zeilen 1545–1554 |

### Nicht implementiert

- Keine granulare Datenzugriffskontrolle auf Patienten-/Datensatzebene
- Kein Berechtigungskonzept für Patientenakten (KG)
- Keine Zugriffsmatrix dokumentiert
- Keine regelmässige Überprüfung der Berechtigungen

---

## 3. Weitergabekontrolle

*Massnahmen, die verhindern, dass personenbezogene Daten bei der Übermittlung unbefugt gelesen oder verändert werden.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| TLS >= 1.2 für alle Backend-Services | Erzwungen via zentrale Konfiguration; TLS 1.3 wird bevorzugt; starke Cipher Suites (ECDHE+AESGCM, ECDHE+CHACHA20, DHE+AESGCM) | aza_tls.py, STEP 4.1 |
| Perfect Forward Secrecy (PFS) | Cipher Suites erfordern ECDHE oder DHE Schlüsselaustausch | aza_tls.py |
| IMAP über SSL/TLS | E-Mail-Empfang über IMAP4_SSL (Port 993) | aza_email.py |
| SMTP mit STARTTLS | E-Mail-Versand über SMTP mit STARTTLS (Port 587) | aza_email.py |
| Credentials nicht in Dateien | E-Mail-Passwörter werden ausschliesslich aus ENV-Variablen geladen, nie auf Disk geschrieben | aza_email.py, STEP 4.4 |
| Secret Keys nicht hardcoded | JWT-Signing-Key kommt aus ENV (AZA_SECRET_KEY), mit Validierung auf Länge und Komplexität | workforce_planner/config.py, STEP 4.3 |

### Nicht implementiert

- Keine Ende-zu-Ende-Verschlüsselung für E-Mails (kein S/MIME, kein PGP)
- Keine Signierung von E-Mails
- Kein VPN oder Netzwerk-Tunnel
- Keine Zertifikatsverifikation im SMTP-Client (STARTTLS ist opportunistisch)
- Keine Verschlüsselung lokaler Daten auf Disk (SQLite-Datenbank, JSON-Dateien)

---

## 4. Eingabekontrolle

*Massnahmen, die nachvollziehbar machen, wer wann welche Daten eingegeben oder verändert hat.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Audit-Log für schreibende Aktionen | Workforce Planner: AuditLog-Tabelle mit user_id, action, entity_type, entity_id, old_values, new_values, timestamp, ip_address, user_agent | workforce_planner/core/models.py, api/audit.py |
| Benutzeridentifikation | Jede API-Aktion wird dem authentifizierten Benutzer zugeordnet (JWT-Token enthält employee_id und role) | workforce_planner/api/auth.py |

### Nicht implementiert

- Audit-Log-Funktion ist definiert, aber nicht in alle API-Endpunkte integriert (log_action wird nur in audit.py referenziert, keine Aufrufe in Routes gefunden)
- Kein Audit-Log für Desktop-Client-Aktionen (basis14.py)
- Kein Audit-Log für E-Mail-Aktionen
- Keine Protokollierung von Datenzugriffen (nur schreibende Aktionen vorgesehen)
- Kein manipulationssicheres Logging (kein WORM, kein Syslog)

---

## 5. Auftragskontrolle

*Massnahmen, die sicherstellen, dass im Auftrag verarbeitete Daten nur gemäss Weisung verarbeitet werden.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Externe Dienstleister dokumentiert | OpenAI API für Transkription und KI-Funktionen; Supabase für Cloud-Speicher | basis14.py, aza_config.py |
| API-Key-basierter Zugriff auf externe Dienste | OpenAI-Zugriff nur mit gültigem API-Key aus ENV-Variable | basis14.py |

### Nicht implementiert

- Kein formaler Auftragsverarbeitungsvertrag (AVV/DPA) mit OpenAI dokumentiert
- Kein formaler AVV/DPA mit Supabase dokumentiert
- Keine Prüfung der Datenverarbeitungsstandorte der Unterauftragnehmer
- Keine vertragliche Regelung zur Löschung nach Vertragsende
- Keine Prüfung der technischen Massnahmen der Unterauftragnehmer

---

## 6. Verfügbarkeitskontrolle

*Massnahmen zum Schutz personenbezogener Daten gegen Zerstörung oder Verlust.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Lokale Datenspeicherung | Patientendaten, Konfigurationen und Notizen werden lokal als JSON/SQLite gespeichert | aza_persistence.py |
| Manuelle Backup-Kopien | Projektverzeichnis enthält mehrere Backup-Kopien (basis14 - Kopie*.py) | Dateisystem |
| Fail-Start-Mechanismen | Server starten nicht bei fehlender Konfiguration (TLS, Secret Key) – verhindert ungesicherten Betrieb | aza_tls.py, workforce_planner/config.py |

### Nicht implementiert

- Kein automatisiertes Backup-Konzept
- Kein Disaster-Recovery-Plan
- Keine Redundanz der Backend-Services
- Kein Monitoring der Dienstverfügbarkeit
- Kein USV-Schutz dokumentiert
- Keine regelmässigen Wiederherstellungstests

---

## 7. Trennungsgebot

*Massnahmen, die sicherstellen, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden.*

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Modulare Architektur | Separate Module für KG-Diktat (basis14), E-Mail (aza_email), Workforce Planning (workforce_planner), Todo (todo_server), Transkription (transcribe_server) | Dateisystem |
| Getrennte Datenbanken | Workforce Planner: eigene SQLite-Datenbank (workforce_planner.db); Desktop-Client: separate JSON-Config-Dateien | workforce_planner/config.py, aza_persistence.py |
| Getrennte Konfigurationen | Jedes Modul hat eigene Konfigurationsdateien | aza_config.py |

### Nicht implementiert

- Keine mandantenfähige Datentrennung
- Keine formale Datenklassifikation implementiert
- Keine technische Trennung von Produktiv-/Testdaten
- Keine Trennung von medizinischen und administrativen Daten auf Datenbankebene

---

## 8. Incident Management

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Incident-Dokumentation | Formale Incident-Notiz erstellt bei Entdeckung exponierter Credentials | INCIDENT_2026-02-22_CREDENTIAL_EXPOSURE.md |
| Sofortmassnahmen dokumentiert | Checkliste mit Verantwortlichkeiten und Status | INCIDENT_2026-02-22_CREDENTIAL_EXPOSURE.md |
| Security-Handover-Dokumentation | Jeder Sicherheitsschritt wird formal dokumentiert mit Änderungen, Tests und Restrisiken | /security/handovers/ |

### Nicht implementiert

- Kein formaler Incident-Response-Plan
- Keine definierten Eskalationsstufen
- Keine Meldepflicht-Prozesse (DSG Art. 24: Meldung an EDÖB innert 72h)
- Keine automatische Anomalie-Erkennung
- Kein Security Operations Center (SOC)

---

## 9. Backup & Recovery

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Manuelle Dateisystem-Backups | Mehrere datierte Backup-Kopien des Projekts vorhanden | Dateisystem (backup-Ordner) |
| Lokale Datenpersistenz | Alle Daten lokal gespeichert (kein Single Point of Failure durch Cloud-Abhängigkeit) | aza_persistence.py |

### Nicht implementiert

- Kein automatisiertes, regelmässiges Backup
- Keine Versionierung der Datenbanken
- Kein Off-Site-Backup
- Keine dokumentierte Recovery-Prozedur
- Keine Recovery Time Objective (RTO) / Recovery Point Objective (RPO) definiert
- Keine regelmässigen Wiederherstellungstests

---

## 10. Patch- & Update-Management

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Python-Paketmanagement | Dependencies über pip/requirements installierbar | Projektstruktur |
| Aktuelle Kryptographie-Bibliotheken | bcrypt und cryptography-Bibliothek im Einsatz | basis14.py, aza_tls.py |

### Nicht implementiert

- Kein dokumentiertes Patch-Management-Verfahren
- Keine automatische Dependency-Prüfung auf bekannte Schwachstellen (kein pip-audit, kein Dependabot)
- Keine regelmässigen Update-Zyklen definiert
- Keine Testprozedur vor Produktiv-Updates
- Kein Changelog oder Release-Management

---

## 11. Logging & Monitoring

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Audit-Log-Modell | Datenbankmodell für Änderungsprotokoll mit Benutzer, Aktion, Zeitstempel, alte/neue Werte, IP-Adresse | workforce_planner/core/models.py (AuditLog) |
| Debug-Logging | Print-basiertes Debug-Logging in E-Mail-Modul (SMTP/IMAP-Verbindungen) | aza_email.py |
| Sicherheitswarnungen auf stderr | Migrationswarnung bei Klartext-Credentials, Fail-Start-Meldungen bei fehlender Konfiguration | aza_email.py, aza_tls.py, workforce_planner/config.py |

### Nicht implementiert

- Audit-Log-Integration in API-Endpunkte nicht vollständig
- Kein zentrales Logging-Framework (kein strukturiertes Logging)
- Kein Log-Rotation-Mechanismus
- Kein Monitoring-Dashboard
- Keine Alerting-Mechanismen
- Keine Protokollierung fehlgeschlagener Anmeldeversuche
- Kein SIEM (Security Information and Event Management)

---

## 12. Mitarbeiterschulung

### Implementiert

| Massnahme | Umsetzung | Referenz |
|-----------|-----------|----------|
| Keine | Keine formalen Schulungsmassnahmen implementiert | — |

### Nicht implementiert

- Keine Security-Awareness-Schulungen
- Keine Dokumentation für Endbenutzer zum sicheren Umgang
- Keine Schulung zum Umgang mit Patientendaten
- Keine Phishing-Awareness
- Keine dokumentierte Einweisungsprozedur für neue Benutzer

---

## Zusammenfassung

| Bereich | Implementiert | Teilweise | Nicht implementiert |
|---------|:---:|:---:|:---:|
| 1. Zugangskontrolle | 5 | — | 5 |
| 2. Zugriffskontrolle | 4 | — | 4 |
| 3. Weitergabekontrolle | 6 | — | 5 |
| 4. Eingabekontrolle | 2 | — | 5 |
| 5. Auftragskontrolle | 2 | — | 5 |
| 6. Verfügbarkeitskontrolle | 3 | — | 6 |
| 7. Trennungsgebot | 3 | — | 4 |
| 8. Incident Management | 3 | — | 5 |
| 9. Backup & Recovery | 2 | — | 6 |
| 10. Patch- & Update-Management | 2 | — | 5 |
| 11. Logging & Monitoring | 3 | — | 7 |
| 12. Mitarbeiterschulung | 0 | — | 5 |

**Total: 35 Massnahmen implementiert, 62 Massnahmen offen**

### Implementierte Security-Schritte (Bezug)

| Schritt | Massnahme | Status |
|---------|-----------|--------|
| STEP 4.1 | TLS-Pflicht für alle Backend-Services | Erledigt, verifiziert (STEP 4.1a) |
| STEP 4.2 | Sicheres Passwort-Hashing (bcrypt, cost=12) | Erledigt, verifiziert (STEP 4.2a) |
| STEP 4.3 | Hardcoded Secret Key entfernt | Erledigt, getestet |
| STEP 4.4 | Klartext-Credentials entfernt | Erledigt, getestet |
| STEP 4.4a | Incident-Dokumentation Credential Exposure | Erledigt |

---

*Dieses Dokument beschreibt den Ist-Zustand der technischen und organisatorischen
Massnahmen des AZA/MedWork-Systems. Es dient als Grundlage für die Weiterentwicklung
des Sicherheitskonzepts und als Nachweis gegenüber Aufsichtsbehörden.*

*Nächste Überprüfung: Bei Abschluss weiterer Security-Schritte oder spätestens
nach 6 Monaten.*