Initial commit

2026-03-25 13:42:48 +01:00
commit d6b31e2ef7
2802 changed files with 515196 additions and 0 deletions
--- a/(61)/security/handovers/INCIDENT_2026-02-22_CREDENTIAL_EXPOSURE.md
+++ b/(61)/security/handovers/INCIDENT_2026-02-22_CREDENTIAL_EXPOSURE.md
@@ -0,0 +1,136 @@
+# 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*