# 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)