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.
