STEP 3 – FORMELLE GAP-ANALYSE (HIN vs. AZA)

Status: ABGESCHLOSSEN

Ziel des Schrittes

Formale Gegenüberstellung des HIN Security Stacks mit dem aktuellen AZA/MedWork-Sicherheitszustand. Nur faktenbasierter Vergleich, keine Empfehlungen, keine Implementierung.

Konkrete Änderungen

NEU: /security/handovers/STEP_03_GAP_ANALYSE.md (vollständige Gap-Analyse)

Betroffene Dateien

Keine Dateien geändert. Nur Analyse-Dokument erstellt.

Analysierte Quelldateien:

basis14.py (Passwort-Hashing, Login)
aza_email.py (SMTP/IMAP, Mail-Sicherheit)
aza_email_config.json (Credential-Speicherung)
aza_config.py (Supabase-Zugriff)
backend_main.py (API-Token, User-Header)
todo_server.py (HTTP-Server, Firewall)
transcribe_server.py (kein TLS)
workforce_planner/api/auth.py (JWT, bcrypt)
workforce_planner/config.py (Secret Key)
workforce_planner/core/enums.py (Rollen)
workforce_planner/core/models.py (Employee-Modell)

Sicherheitsauswirkung

29 Lücken identifiziert, alle 5 Bereiche mit Kritikalität HIGH:

Transport: 5 Lücken (kein S/MIME, kein verschlüsselter App-Kanal, HTTP-Server)
Netzwerk: 6 Lücken (kein Perimeter, kein VPN, kein DDoS-Schutz)
PKI: 5 Lücken (keine CA, keine Zertifikate, kein Schlüsselmanagement)
Authentifizierung: 7 Lücken (keine 2FA, SHA-256 ohne Salt, hardcoded Secret)
Mail: 6 Lücken (keine Verschlüsselung, Klartext-Passwörter in Config)

Offene Punkte

9 Vergleichspunkte nicht vollständig bewertbar (HIN-Dokumentation fehlt)
Supabase-Sicherheitskonfiguration nicht im Scope
Python-Default-TLS-Verhalten systemabhängig

Risiken

Alle 5 Bereiche zeigen fundamentale Lücken zum HIN-Standard
Besonders kritisch: Klartext-Passwörter in aza_email_config.json
Besonders kritisch: SHA-256 ohne Salt in basis14.py
Besonders kritisch: Hardcoded Secret Key "dev-secret-change-in-production"
Besonders kritisch: HTTP-Server ohne TLS (todo_server, transcribe_server, backend)

1.9 KiB Raw Blame History Unescape Escape