305 lines
13 KiB
Markdown
305 lines
13 KiB
Markdown
# 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.*
|