Stephan Schellworth 9f5f8bfc11 Add e-compliance processes and PowerOn AG documentation.

Includes CACC/FINMA legal processes, updated AGB with PowerOn AG
stammdaten, and internal legal and best-practice analysis report.

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-06-03 08:50:34 +02:00

3.4 KiB

Raw Blame History

Backup und Wiederherstellung

Dokumenttyp: Konzept & Prozess Geltungsbereich: Alle Kundendaten auf db.poweron.swiss Version: 1.0 Status: Entwurf zur internen Freigabe Owner: Betrieb / DevOps Letzte Aktualisierung: 02.06.2026 Deckt ab (CACC): 75, 87 Verweist auf: datenbank-handling.md, bcm_runbook.md

1. Backup-Strategie (mehrschichtig)

PowerOn sichert Daten auf zwei Ebenen (vgl. datenbank-handling.md Abschnitt 4):

Ebene	Mechanismus	Verantwortung
Infrastruktur	Snapshots der Infomaniak Managed PostgreSQL	Infomaniak / Betrieb
Anwendung	Vollständiger JSON-Export aller 13 Datenbanken via Admin-UI oder Script	Betrieb (SysAdmin)

Token- und AuthEvent-Tabellen sowie die Testdatenbank werden vom Export ausgeschlossen.

2. Anforderung #75 — die drei Pflichtelemente

Punkt #75 verlangt explizit drei Dinge. Stand und Massnahmen:

2.1 Angemessener Schutz der gesicherten Daten

Backup-Dateien enthalten alle Kundendaten und sind als vertraulich klassifiziert.
Offen: Export-Dateien aktuell unverschlüsselt → Verschlüsselung einführen (siehe Dok 04).
Ablage nur auf gesicherten Speichern, nicht auf persönlichen Geräten/Cloud (vgl. datenbank-handling.md Abschnitt 6).

2.2 Überwachung der Datensicherung

Offen / [ZU PRÜFEN]: Werden Infomaniak-Snapshots automatisch überwacht (Erfolg/Fehler-Alerting)?
Massnahme: Automatisiertes Alerting bei fehlgeschlagenem Backup einrichten; Backup-Status mindestens wöchentlich kontrollieren.

2.3 Test der Wiederherstellungsverfahren

Das technische Restore-Verfahren ist in bcm_runbook.md Abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + Migrations-Tool).
Offen: Es fehlt ein dokumentierter, regelmässiger Restore-Test.
Massnahme: Mindestens vierteljährlich einen Restore-Test auf der INT-Umgebung durchführen und protokollieren (Datum, getestete DB, Dauer, Ergebnis, Tester).

3. Backup-Frequenz und Aufbewahrung

Anlass	Aktion	Aufbewahrung
Vor jedem Deployment	Export via Admin-UI	bis zum nächsten erfolgreichen Deployment
Vor DB-Migrationen	Export + beschriftet archivieren	mind. 90 Tage
Wöchentlich	Archiv-Export	[ZU PRÜFEN: Aufbewahrungsdauer festlegen, z. B. 90 Tage]
Infrastruktur-Snapshot	automatisch (Infomaniak)	[ZU PRÜFEN: Intervall & Retention bei Infomaniak]

4. Wiederherstellungsziele (RTO/RPO)

Parameter	Zielwert	Bemerkung
RTO (Recovery Time Objective)	[ZU PRÜFEN, Vorschlag: ≤ 4 h]	Restore dauert lt. Runbook „wenige Minuten bis 1 Stunde"
RPO (Recovery Point Objective)	[ZU PRÜFEN, Vorschlag: ≤ 24 h]	Abhängig von Snapshot-/Export-Frequenz

Hinweis: RTO/RPO müssen zu den im SLA gegenüber Kunden zugesagten Werten passen (AGB Anhang B). Aktuell im AGB-Entwurf RTO ≤ 4 h / RPO ≤ 1 h — das erfordert häufigere Sicherungen als die aktuelle wöchentliche Praxis. Abgleich nötig.

5. Restore-Test-Protokoll (Vorlage)

Datum	Getestete DB	Quelle (Backup)	Dauer	Ergebnis	Tester

6. Stand der Umsetzung / Lücken

Thema	Status	Massnahme
Backup-Verschlüsselung	Offen	siehe Dok 04
Backup-Monitoring/Alerting	[ZU PRÜFEN]	Einrichten
Regelmässiger Restore-Test	Offen	Vierteljährlich + Protokoll
RTO/RPO mit SLA abgleichen	Offen	Werte festlegen & Frequenz anpassen

3.4 KiB Raw Blame History