137 lines
4.9 KiB
Markdown
137 lines
4.9 KiB
Markdown
# INCIDENT REPORT – CREDENTIAL EXPOSURE
|
||
# Datum: 2026-02-22
|
||
# Klassifikation: SICHERHEITSVORFALL (intern)
|
||
|
||
---
|
||
|
||
## 1. Zusammenfassung
|
||
|
||
Im Rahmen der systematischen Sicherheitsanalyse (STEP 4.4 – Klartext-Credentials
|
||
entfernen) wurde ein produktives E-Mail-Passwort im Klartext in einer
|
||
Konfigurationsdatei des Projekts entdeckt.
|
||
|
||
---
|
||
|
||
## 2. Betroffene Komponente
|
||
|
||
- **Datei:** `aza_email_config.json`
|
||
- **Modul:** AZA E-Mail (aza_email.py)
|
||
- **Feld:** `password` im `accounts`-Array
|
||
- **Betroffener Account:** Produktiver Mail-Account (Details bewusst nicht aufgeführt)
|
||
|
||
---
|
||
|
||
## 3. Entdeckung
|
||
|
||
- **Entdeckt durch:** Automatisierte Security Gap-Analyse (STEP 3) und
|
||
bestätigt bei der Implementierung von STEP 4.4
|
||
- **Entdeckungsdatum:** 2026-02-22
|
||
- **Entdeckungsmethode:** Grep-Suche nach `password`, `secret`, `token`
|
||
in allen JSON/YAML/Config-Dateien des Projekts
|
||
|
||
---
|
||
|
||
## 4. Risikoanalyse
|
||
|
||
### Worst-Case-Szenarien
|
||
|
||
| Szenario | Risiko | Schwere |
|
||
|----------|--------|---------|
|
||
| Unbefugter Zugriff auf das Dateisystem | Passwort-Exfiltration | HOCH |
|
||
| Account-Übernahme (Mail) | Lesen/Senden von E-Mails im Namen des Kontoinhabers | HOCH |
|
||
| Mail-Missbrauch | Spam, Phishing, Social Engineering über legitimen Account | HOCH |
|
||
| Laterale Bewegung | Falls Passwort wiederverwendet: Zugriff auf weitere Systeme | KRITISCH |
|
||
| Datenschutzverletzung | Zugriff auf medizinische Kommunikation (Patientendaten) | KRITISCH |
|
||
| Backup-/Export-Exposition | Passwort in Backups, Cloud-Syncs oder Transfers vorhanden | MITTEL |
|
||
|
||
### Besondere Faktoren
|
||
|
||
- **Medizinischer Kontext:** E-Mail-Account einer Arztpraxis – potenziell
|
||
Patientendaten in Mails (DSG/DSGVO-relevant)
|
||
- **Expositionsdauer:** Unbekannt. Das Passwort war seit der Erstellung
|
||
der Konfigurationsdatei im Klartext gespeichert.
|
||
- **Zugriffskreis:** Alle Personen/Systeme mit Lesezugriff auf das
|
||
Projektverzeichnis, Backups oder Transfers dieser Datei.
|
||
|
||
---
|
||
|
||
## 5. Sofortmassnahmen
|
||
|
||
| Nr | Massnahme | Status | Verantwortlich |
|
||
|----|-----------|--------|----------------|
|
||
| 1 | Passwort aus Konfigurationsdatei entfernt | ERLEDIGT (STEP 4.4) | Security Engineer |
|
||
| 2 | Code umgestellt auf ENV-basierte Credentials | ERLEDIGT (STEP 4.4) | Security Engineer |
|
||
| 3 | Migrationswarnung implementiert | ERLEDIGT (STEP 4.4) | Security Engineer |
|
||
| 4 | **Passwort beim Mail-Provider rotieren** | **OFFEN – DRINGEND** | Projektinhaber |
|
||
| 5 | Prüfung ob Account kompromittiert wurde | OFFEN | Projektinhaber |
|
||
|
||
---
|
||
|
||
## 6. Empfohlene Folgeaktionen
|
||
|
||
### Sofort (innerhalb 24h)
|
||
|
||
- [ ] **Passwort beim Mail-Provider ändern** (neues, starkes Passwort,
|
||
mindestens 16 Zeichen, keine Wiederverwendung)
|
||
- [ ] **2FA aktivieren**, falls der Mail-Provider dies unterstützt
|
||
- [ ] **Login-Protokolle prüfen**: Gibt es unbekannte Zugriffe auf den
|
||
betroffenen Mail-Account?
|
||
|
||
### Kurzfristig (innerhalb 1 Woche)
|
||
|
||
- [ ] **Passwort-Wiederverwendung prüfen**: Wurde dasselbe Passwort für
|
||
andere Dienste/Systeme verwendet? Falls ja: dort ebenfalls rotieren.
|
||
- [ ] **Backups durchsuchen**: Prüfen, ob Kopien der Datei
|
||
`aza_email_config.json` in Backups, Cloud-Speicher, USB-Sticks,
|
||
E-Mail-Anhängen oder anderen Transfers vorhanden sind.
|
||
Falls ja: Passwort dort ebenfalls als exponiert betrachten.
|
||
- [ ] **Projekt-Kopien prüfen**: Alle `backup *`-Ordner und Kopien
|
||
des Projektverzeichnisses auf Klartext-Passwörter durchsuchen.
|
||
|
||
### Mittelfristig (Empfehlung)
|
||
|
||
- [ ] **Secret-Scanning** in CI/CD-Pipeline einführen (z.B. git-secrets,
|
||
truffleHog, GitHub Secret Scanning), um zukünftige Klartext-Credentials
|
||
automatisch zu erkennen.
|
||
- [ ] **OS-Keychain-Integration** evaluieren (Windows Credential Manager),
|
||
um Passwörter sicher und benutzerfreundlich zu speichern.
|
||
|
||
---
|
||
|
||
## 7. Lessons Learned
|
||
|
||
### Ursache
|
||
|
||
Das Passwort wurde direkt im GUI-Dialog eingegeben und ohne
|
||
Schutzmassnahmen in eine JSON-Datei auf der Festplatte geschrieben.
|
||
Es gab keine Trennung zwischen Konfiguration und Credentials.
|
||
|
||
### Präventionsmassnahmen (implementiert)
|
||
|
||
1. **Credentials werden NIE mehr in Dateien geschrieben**
|
||
(`_strip_passwords()` in `save_email_config()`)
|
||
2. **Credentials kommen ausschliesslich aus ENV-Variablen**
|
||
(`AZA_EMAIL_PASSWORD_0`, `_1`, ...)
|
||
3. **Migrationswarnung** bei bestehenden Klartext-Passwörtern in der Config
|
||
4. **Klartext-Passwörter in JSON werden ignoriert** (kein Auto-Migrate)
|
||
|
||
### Präventionsmassnahmen (empfohlen, nicht implementiert)
|
||
|
||
1. Secret-Scanning in CI/CD
|
||
2. Pre-Commit-Hooks für Secret-Detection
|
||
3. OS-Keychain als sicherer Credential-Store
|
||
4. Regelmässige Audits der Konfigurationsdateien
|
||
|
||
---
|
||
|
||
## 8. Referenzen
|
||
|
||
- STEP 3 – GAP-Analyse: Lücke #28 identifiziert
|
||
- STEP 4.4 – Implementierung der Credential-Entfernung
|
||
- STEP 4.4 Handover: `/security/handovers/STEP_4_4_CREDENTIALS.md`
|
||
|
||
---
|
||
|
||
*Erstellt: 2026-02-22 im Rahmen des AZA/MedWork Security & Compliance Projects*
|
||
*Klassifikation: Intern – Nicht zur externen Weitergabe bestimmt*
|