=====================================================================
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
- HIN: TLS-Version, Cipher Suites, PFS – nicht in hin_docs belegt
- HIN: Hardware-Token / Smartcard – nicht in hin_docs belegt
- HIN: SSO-Protokoll (SAML/OAuth/OIDC) – nicht in hin_docs belegt
- HIN: Passwort-Hashing-Verfahren – nicht in hin_docs belegt
- HIN: Token-Ablaufzeiten – nicht in hin_docs belegt
- HIN: Credential-Speicherung – nicht in hin_docs belegt
- AZA: Python-Default-TLS-Verhalten hängt von Systemkonfiguration ab – nicht geprüft
- AZA: Supabase-Sicherheitskonfiguration – nicht im Scope dieser Analyse
- 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.
