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*
|