# =====================================================================
# STEP 3 – FORMELLE GAP-ANALYSE (HIN vs. AZA)
# =====================================================================
# Datenquellen: /security/reference/hin_docs/ + Projekt-Code
# Methode: Nur technisch belegbare Fakten
# =====================================================================

## 1. Transport Security

### HIN:
- S/MIME als primärer Transportschutz (nicht TLS)
- TLS optional, nicht erzwungen auf SMTP-Ebene
- Wireguard-Protokoll für Stargate (App-zu-App, kein VPN)
- SCION-Netzwerk für SSHN (any-to-any Verschlüsselung)
- Routing ausschliesslich über Schweizer Netze

### AZA:
- SMTP mit STARTTLS (Port 587) – aza_email.py Zeilen 1433–1436, 2994–2997
- IMAP über SSL/TLS (Port 993, IMAP4_SSL) – aza_email.py Zeilen 1470, 1705
- Keine eigene TLS-Konfiguration (Python-Defaults)
- Keine Zertifikatsverifikation im Code gesetzt
- todo_server.py: reiner HTTP-Server, kein HTTPS – Zeile 228
- transcribe_server.py: kein TLS
- backend_main.py: kein TLS
- Supabase-Zugriff über HTTPS – aza_config.py Zeile 176

### GAP:
| Aspekt | HIN | AZA | Lücke |
|--------|-----|-----|-------|
| Mail-Verschlüsselung | S/MIME (RSA 4096) | Nur STARTTLS (opportunistisch) | JA |
| App-zu-App Transport | Wireguard | Kein verschlüsselter Kanal | JA |
| Netzwerk-Routing | SCION, nur CH | Internet, global | JA |
| Server-Kommunikation | Verschlüsselt | HTTP (Klartext) | JA |
| TLS-Konfiguration | UNBEKANNT | Python-Defaults | UNBEKANNT |

### Kritikalität: **HIGH**

---

## 2. Netzwerkmodell

### HIN:
- Geschlossener Vertrauensraum (Gated Community)
- SCION/SSHN mit AS-Nummern und Zertifikaten
- DDoS-Schutz durch Architektur
- 1 Instanz pro Organisation (keine Mandantenfähigkeit)
- Redundante Transportwege, automatischer Fail-over
- Governance: HIN, FMH, pharmaSuisse, BAG, SWITCH

### AZA:
- Kein Netzwerk-Perimeter definiert
- Kein VPN
- Kein DDoS-Schutz
- Keine Netzwerk-Segmentierung
- Einzige Netzwerk-Massnahme: Windows-Firewall-Regel für Todo-Server-Port – todo_server.py Zeilen 209–220
- Backend-Services auf localhost (HTTP)
- Supabase als externer Cloud-Service (HTTPS)

### GAP:
| Aspekt | HIN | AZA | Lücke |
|--------|-----|-----|-------|
| Vertrauensraum | Geschlossen, verifiziert | Offen, kein Perimeter | JA |
| DDoS-Schutz | SCION-basiert | Keiner | JA |
| Segmentierung | 1 Instanz/Organisation | Keine | JA |
| Redundanz | Multi-Path, Fail-over | Keine | JA |
| Governance | 5 Organisationen | Keine | JA |
| VPN | Wireguard (Stargate) | Keiner | JA |

### Kritikalität: **HIGH**

---

## 3. PKI

### HIN:
- Eigene CA: "HIN MGW Issuing CA 2022"
- RSA 4096-bit, SHA256withRSAEncryption
- Domain-Zertifikate (10 Jahre Gültigkeit)
- SSHN-Zertifikate (72h Gültigkeit, automatische Erneuerung)
- Zentrale Zertifikatsverteilung über HIN-Backend
- Geschlossenes System

### AZA:
- Keine PKI
- Keine eigene CA
- Keine Zertifikate (weder Client- noch Server-Zertifikate)
- Kein Zertifikatsmanagement
- Kein CSR-Prozess
- Keine Signierung von Daten oder Kommunikation

### GAP:
| Aspekt | HIN | AZA | Lücke |
|--------|-----|-----|-------|
| Eigene CA | HIN MGW Issuing CA 2022 | Keine | JA |
| Zertifikate | RSA 4096, Domain-Zerts | Keine | JA |
| Zertifikatsverteilung | Zentral, automatisch | Nicht vorhanden | JA |
| Schlüsselmanagement | Zentral über Backend | Nicht vorhanden | JA |
| Hardware-Token | UNBEKANNT | Nicht vorhanden | UNBEKANNT |

### Kritikalität: **HIGH**

---

## 4. Authentifizierung

### HIN:
- 2FA in drei Varianten:
  - HIN Client: Passwort + kryptographischer Geräteschlüssel
  - HIN Gateway: mTAN/Auth-App + Active Directory
  - Mobil: mTAN/Auth-App + HIN Login+Passwort
- Identitätsprüfung via Videoidentifikation
- eID-Typen: Persönlich, Organisation, Team
- SSO für HIN-geschützte Anwendungen
- Berufsqualifikation über Register/Verbände verifiziert

### AZA:
- basis14.py: SHA-256 Passwort-Hash OHNE Salt – Zeilen 1298–1300
- workforce_planner: bcrypt mit Salt – auth.py Zeilen 23–28
- workforce_planner: JWT mit HS256 – auth.py Zeilen 31–37
- workforce_planner: Secret Key hardcoded als Fallback "dev-secret-change-in-production" – config.py Zeile 19
- workforce_planner: Token-Ablauf 480 Minuten (8h) – config.py Zeile 20
- backend_main.py: API-Token via Header "X-Api-Token" – Zeilen 154–157
- backend_main.py: User-Identifikation via Header "X-User" – Zeilen 162–164
- Rollen: ADMIN, MANAGER, EMPLOYEE – enums.py Zeilen 33–36
- Rollenbasierte Zugriffskontrolle mit require_role() – auth.py Zeilen 59–66
- Keine 2FA / MFA / OTP
- Keine zertifikatsbasierte Authentifizierung
- Keine Identitätsprüfung (Videoidentifikation o.ä.)
- Kein SSO-Protokoll (SAML/OAuth/OIDC)

### GAP:
| Aspekt | HIN | AZA | Lücke |
|--------|-----|-----|-------|
| 2FA | Ja (3 Varianten) | Nein | JA |
| Passwort-Hashing | UNBEKANNT | SHA-256 ohne Salt (basis14) / bcrypt (workforce) | JA (basis14) |
| Secret Key | UNBEKANNT | Hardcoded Fallback | JA |
| Identitätsprüfung | Videoidentifikation | Keine | JA |
| SSO | Ja | Nein | JA |
| Zertifikats-Auth | Ja (Geräteschlüssel) | Nein | JA |
| Token-Ablauf | UNBEKANNT | 480 min (8h) | UNBEKANNT |
| Rollen | eID-basiert (3 Typen) | RBAC (3 Rollen) | TEILWEISE |

### Kritikalität: **HIGH**

---

## 5. Mail-Sicherheit

### HIN:
- S/MIME Gateway-zu-Gateway mit Domain-Zertifikaten (RSA 4096)
- Automatische Verschlüsselung/Entschlüsselung durch Gateway
- HIN Mail Global: GINA/SEPPMail für externe Empfänger
- SMS-Code-Authentifizierung für externe Empfänger
- Domain-Prüfung gegen HIN-Domainliste
- Betreffzeile bei HIN Mail Global: UNVERSCHLÜSSELT
- Header "X-HIN-Encrypted" für Steuerung

### AZA:
- SMTP mit STARTTLS (opportunistisch, nicht erzwungen) – aza_email.py
- IMAP über SSL (IMAP4_SSL) – aza_email.py
- Keine S/MIME-Implementierung
- Keine PGP/GPG-Implementierung
- Keine Gateway-Verschlüsselung
- Keine Ende-zu-Ende-Verschlüsselung
- Keine Signierung von E-Mails
- Passwörter im Klartext in aza_email_config.json gespeichert
- Keine Zertifikatsverifikation im SMTP/IMAP-Code

### GAP:
| Aspekt | HIN | AZA | Lücke |
|--------|-----|-----|-------|
| Mail-Verschlüsselung | S/MIME (RSA 4096) | Keine | JA |
| Gateway-Verschlüsselung | Automatisch | Keine | JA |
| Externe Empfänger | HIN Mail Global (GINA) | Keine Lösung | JA |
| Signierung | S/MIME Signatur | Keine | JA |
| Credential-Speicherung | UNBEKANNT | Klartext JSON | JA |
| Zertifikatsverifikation | Domain-Zertifikate | Python-Defaults | JA |

### Kritikalität: **HIGH**

---

## OFFENE TECHNISCHE FRAGEN

1. HIN: TLS-Version, Cipher Suites, PFS – nicht in hin_docs belegt
2. HIN: Hardware-Token / Smartcard – nicht in hin_docs belegt
3. HIN: SSO-Protokoll (SAML/OAuth/OIDC) – nicht in hin_docs belegt
4. HIN: Passwort-Hashing-Verfahren – nicht in hin_docs belegt
5. HIN: Token-Ablaufzeiten – nicht in hin_docs belegt
6. HIN: Credential-Speicherung – nicht in hin_docs belegt
7. AZA: Python-Default-TLS-Verhalten hängt von Systemkonfiguration ab – nicht geprüft
8. AZA: Supabase-Sicherheitskonfiguration – nicht im Scope dieser Analyse
9. AZA: Ob STARTTLS erzwungen oder opportunistisch ist – Code zeigt keine Prüfung auf Erfolg

---

## ZUSAMMENFASSUNG

| Bereich | Kritikalität | Anzahl Lücken |
|---------|-------------|---------------|
| 1. Transport Security | HIGH | 5 |
| 2. Netzwerkmodell | HIGH | 6 |
| 3. PKI | HIGH | 5 |
| 4. Authentifizierung | HIGH | 7 |
| 5. Mail-Sicherheit | HIGH | 6 |
| **GESAMT** | **HIGH** | **29 identifizierte Lücken** |

Alle 5 Bereiche haben Kritikalität HIGH.
9 Punkte konnten mangels HIN-Dokumentation nicht vollständig verglichen werden.