aza/backup backup backup backup/backup 24.2.26 - Kopie (61)/security/handovers/STEP_9_BACKUP_RECOVERY.md

# STEP 9 – Backup, Recovery & Löschkonzept

## Ziel
Sicherstellung von Datenverlustminimierung, Wiederherstellbarkeit
und Erfüllung der DSG-Löschpflichten.

---

## 1. Datenübersicht

### 1.1 Medizinische / Personenbezogene Daten

| Datei / Speicher | Format | Inhalt | Sensibilität |
|---|---|---|---|
| `kg_diktat_user_profile.json` | JSON | Arztname, Fachgebiet, Passwort-Hash, TOTP-Secret | HOCH |
| `kg_diktat_ablage/KG/` | Dateien | Krankengeschichten | HOCH |
| `kg_diktat_ablage/Briefe/` | Dateien | Arztbriefe | HOCH |
| `kg_diktat_ablage/Rezepte/` | Dateien | Rezepte | HOCH |
| `kg_diktat_ablage/Kostengutsprachen/` | Dateien | Kostengutsprachen | HOCH |
| `kg_diktat_ablage/Diktat/` | Dateien | Diktattexte | HOCH |
| `kg_diktat_notes.json` | JSON | Notizen (ev. Patientenbezug) | MITTEL |
| `kg_diktat_todos.json` | JSON | Aufgaben (ev. Patientenbezug) | MITTEL |
| `kg_diktat_todo_inbox.json` | JSON | Eingehende Aufgaben | MITTEL |
| `kg_diktat_medwork_contacts.json` | JSON | Praxiskontakte | MITTEL |
| `aza_email_contacts.json` | JSON | E-Mail-Kontakte | MITTEL |
| `aza_medwork_messages.json` | JSON | Nachrichten | MITTEL |
| `workforce_planner.db` | SQLite | Mitarbeiter, Abwesenheiten, Audit-Log | MITTEL |

### 1.2 Konfigurationsdaten (nicht personenbezogen)

| Datei | Inhalt |
|---|---|
| `kg_diktat_config.txt` | Grundeinstellungen |
| `kg_diktat_signature.txt` | Arzt-Signatur |
| `kg_diktat_korrekturen.json` | Auto-Korrekturen |
| `kg_diktat_textbloecke.json` | Textbausteine |
| `kg_diktat_autotext.json` | Autotext-Vorlagen |
| `kg_diktat_soap_presets.json` | SOAP-Profile |
| `kg_diktat_brief_presets.json` | Brief-Profile |
| `aza_email_config.json` | E-Mail-Konfiguration (ohne Passwort) |
| Diverse `*_window.txt` | Fensterpositionen / UI-State |

### 1.3 Cloud-Daten

| Dienst | Daten | Speicherort |
|---|---|---|
| Supabase | Synchronisierte Praxisdaten | AWS eu-central-1 |
| OpenAI API | Keine persistente Speicherung (API-Modus, max. 30 Tage) | USA |

---

## 2. Backup-Konzept

### 2.1 Implementierung

Neues Skript: **`aza_backup.py`**

```
python aza_backup.py backup      # Backup erstellen
python aza_backup.py list        # Backups auflisten
python aza_backup.py verify <f>  # Integrität prüfen
python aza_backup.py restore <f> # Wiederherstellen
python aza_backup.py cleanup     # Alte Backups entfernen
```

### 2.2 Was wird gesichert

- Alle medizinischen JSON-Dateien (17 Dateien)
- Alle Konfigurationsdateien (12 Dateien)
- Alle UI-State-Dateien (11 Dateien)
- Komplettes Ablage-Verzeichnis (KG, Briefe, Rezepte, etc.)
- Lernmodus-Export
- Workforce-Planner-Datenbank (SQLite)

### 2.3 Backup-Parameter

| Parameter | Wert | Konfiguration |
|---|---|---|
| Format | ZIP (Deflate, Level 9) | Fest |
| Intervall | Täglich empfohlen | Manuell oder Cron/Task Scheduler |
| Aufbewahrung | 90 Tage (Standard) | `AZA_BACKUP_KEEP_DAYS` |
| Zielverzeichnis | `./backups/` | `AZA_BACKUP_DIR` |
| Integrität | SHA-256 pro Datei + Manifest | Automatisch |
| Benennung | `aza_backup_YYYY-MM-DD_HH-MM-SS.zip` | Automatisch |

### 2.4 Verschlüsselung

- **Transport:** ZIP-Dateien können auf verschlüsseltem Medium gespeichert werden
- **Empfehlung:** Backup-Zielverzeichnis auf BitLocker-verschlüsseltem
  Laufwerk oder verschlüsseltem NAS ablegen
- **ZIP-eigene Verschlüsselung:** Nicht implementiert (Python-zipfile
  unterstützt kein starkes AES; Laufwerksverschlüsselung wird empfohlen)

### 2.5 Offsite-Kopie

- Backup-Verzeichnis (`AZA_BACKUP_DIR`) kann auf externes Medium
  oder Netzlaufwerk zeigen
- Empfohlen: Regelmässige Kopie auf externes verschlüsseltes Medium
- Keine automatische Cloud-Sicherung implementiert

### 2.6 Automatisierung (Windows Task Scheduler)

```
schtasks /create /tn "AZA_Backup" /tr "python C:\...\aza_backup.py backup" /sc daily /st 22:00
```

---

## 3. Recovery-Konzept

### 3.1 Recovery Point Objective (RPO)

| Szenario | RPO |
|---|---|
| Tägliches Backup | Max. 24 Stunden Datenverlust |
| Stündliches Backup (optional) | Max. 1 Stunde |

### 3.2 Recovery Time Objective (RTO)

| Szenario | RTO |
|---|---|
| Einzelne Datei | < 5 Minuten |
| Komplettes System | < 30 Minuten |

### 3.3 Restore-Anleitung

#### Schritt 1: Verfügbare Backups anzeigen
```
python aza_backup.py list
```

#### Schritt 2: Backup-Integrität prüfen
```
python aza_backup.py verify backups/aza_backup_YYYY-MM-DD_HH-MM-SS.zip
```

#### Schritt 3: Dry-Run (was wird wiederhergestellt?)
```
python aza_backup.py restore backups/aza_backup_YYYY-MM-DD_HH-MM-SS.zip --dry-run
```

#### Schritt 4: Tatsächliche Wiederherstellung
```
python aza_backup.py restore backups/aza_backup_YYYY-MM-DD_HH-MM-SS.zip
```

**Sicherheitsmechanismus:** Vor dem Restore wird automatisch eine
Pre-Restore-Sicherung der aktuellen Daten erstellt (in `backups/.pre_restore_*/`),
sodass der Restore rückgängig gemacht werden kann.

### 3.4 Test-Ergebnisse (22.02.2026)

| Test | Ergebnis |
|---|---|
| Backup erstellen | PASS – 44 Dateien, 0.06 MB |
| Backup verifizieren (SHA-256) | PASS – alle Checksummen korrekt |
| Restore Dry-Run | PASS – 44 Dateien korrekt aufgelistet |
| Backup auflisten | PASS – Datum, Grösse, Name korrekt |
| Löschung Dry-Run | PASS – Warnung zu Backups korrekt |

---

## 4. Löschkonzept

### 4.1 Löschfristen

| Datenkategorie | Aufbewahrungsfrist | Rechtsgrundlage |
|---|---|---|
| Krankengeschichten | 10–20 Jahre (kantonal) | Kantonale Gesundheitsgesetze |
| Arztbriefe | 10–20 Jahre | Kantonale Gesundheitsgesetze |
| Rezepte | 10 Jahre | OR Art. 958f |
| Mitarbeiterdaten | Anstellungsdauer + 5 Jahre | OR Art. 128 |
| E-Mail-Kontakte | Bis Löschung durch Benutzer | DSG Art. 6 |
| Backups | 90 Tage (konfigurierbar) | Intern |

### 4.2 Technische Umsetzung

#### Automatische Backup-Bereinigung
```
python aza_backup.py cleanup
```
Entfernt Backups älter als `AZA_BACKUP_KEEP_DAYS` (Standard: 90 Tage).

#### Patientendaten löschen (Recht auf Vergessenwerden)
```
# Dry-Run (nur prüfen, was gelöscht wird)
python aza_backup.py delete-patient "Nachname Vorname"

# Tatsächliche Löschung
python aza_backup.py delete-patient "Nachname Vorname" --execute
```

### 4.3 Lösch-Workflow

1. **Antrag:** Patient stellt Löschanfrage (schriftlich empfohlen)
2. **Prüfung:** Arzt prüft, ob gesetzliche Aufbewahrungspflicht besteht
3. **Dry-Run:** `delete-patient --dry-run` zeigt betroffene Dateien
4. **Dokumentation:** Löschanfrage und Ergebnis im Audit-Log festhalten
5. **Ausführung:** `delete-patient --execute`
6. **Backups:** Bestehende Backups enthalten noch Daten – nach Ablauf
   der Aufbewahrungsfrist (90 Tage) werden diese automatisch entfernt
7. **Cloud:** Supabase-Daten manuell löschen (aktuell kein API-Endpunkt)

### 4.4 Einschränkungen

- Löschung in bestehenden Backups nur durch Warten auf Ablauf
  oder manuelles Löschen der betroffenen Backups
- Supabase-Cloud-Daten müssen manuell gelöscht werden
- OpenAI-API-Daten werden gemäss OpenAI nach max. 30 Tagen gelöscht
- Namensbasierte Suche – funktioniert nur bei Dateinamen / JSON-Inhalt
  mit Patientenname

---

## 5. Geänderte / Neue Dateien

| Datei | Aktion |
|---|---|
| `aza_backup.py` | NEU – Backup, Verify, Restore, Cleanup, Löschung |
| `backups/` | NEU – Backup-Verzeichnis (automatisch erstellt) |

---

## 6. Risiken

| Risiko | Bewertung | Massnahme |
|---|---|---|
| Kein automatischer Backup-Schedule | MITTEL | Task Scheduler einrichten |
| ZIP nicht AES-verschlüsselt | MITTEL | Laufwerksverschlüsselung nutzen |
| Keine Offsite-Kopie konfiguriert | HOCH | `AZA_BACKUP_DIR` auf NAS setzen |
| Supabase-Löschung manuell | MITTEL | API-Endpunkt implementieren |
| Namensbasierte Löschung unvollständig | NIEDRIG | Erweiterte Suche implementieren |
| Kein inkrementelles Backup | NIEDRIG | Bei Datenwachstum nachrüsten |