210 lines
7.6 KiB
Markdown
210 lines
7.6 KiB
Markdown
# =====================================================================
|
||
# 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.
|