CRM Bot
44 lines
5.1 KiB
Markdown
44 lines
5.1 KiB
Markdown
# 06d – Backup-/Recovery-Audit (Security & Data-Engineering)
|
||
|
||
**Projekt:** CRM System v1.0
|
||
**Datum:** 2026-06-04
|
||
**Auditor:** Security Data Engineer (Phase 6)
|
||
**Repository:** `Leopoldadmin/crm-system`, Branch `main`
|
||
**Scope:** DB-Backup-Strategie, Coolify-Backup-Konfiguration, Wiederherstellungs-Test, Disaster-Recovery-Plan, RTO/RPO
|
||
|
||
---
|
||
|
||
## Findings
|
||
|
||
| ID | Severity | Kategorie | Beschreibung | Empfehlung |
|
||
|----|----------|-----------|-------------|------------|
|
||
| BKP-01 | **WARN** | Backup-Strategie | NFR-6 fordert tägliches PostgreSQL-Dump-Backup via Coolify mit 7 Tagen Retention. In `COOLIFY_SETUP.md` und `docker-compose.yml` ist keine Backup-Konfiguration dokumentiert. Coolify bietet native Database-Backups (S3-kompatibler Storage), aber diese sind weder eingerichtet noch dokumentiert. | **Vor Production:** Coolify-Database-Backup-Schedule konfigurieren (täglicher Dump, 7d Retention, Storage-Backend definieren). Backup-Konfiguration als Code dokumentieren (z.B. Coolify-API-Script in `/scripts/backup-setup.sh`). |
|
||
| BKP-02 | **WARN** | Restore-Runbook | NFR-6 fordert ein Restore-Runbook unter `docs/runbook-backup-restore.md`. Diese Datei existiert nicht im Repository (`ls docs/runbook-backup-restore.md` → nicht vorhanden). | **Vor Production:** Runbook erstellen mit Schritt-für-Schritt-Anleitung: 1) Coolify-Backup auswählen, 2) PostgreSQL-Restore-Kommando, 3) App-Neustart, 4) Smoke-Test. |
|
||
| BKP-03 | **WARN** | Wiederherstellungs-Test | Kein dokumentierter Backup-Restore-Test durchgeführt. Ohne Test kann nicht garantiert werden, dass Backups im Ernstfall wiederherstellbar sind. | **Vor Production:** Restore-Drill durchführen: Backup aus Coolify herunterladen, in lokales PostgreSQL einspielen, App starten, Healthcheck + Login-Smoke-Test. Ergebnis dokumentieren. |
|
||
| BKP-04 | **INFO** | RTO 4h / RPO 24h | Requirements (NFR-6) definieren Recovery-Time-Objective ≤ 4h und Recovery-Point-Objective ≤ 24h. Diese Ziele sind mit täglichem Coolify-Backup + manuellem Restore erreichbar, aber nicht formal verifiziert. | RTO/RPO in Runbook verankern und im Restore-Drill messen. Coolify-Restore-Zeit für PostgreSQL 16 (Alpine) typischerweise < 30 min – innerhalb 4h. |
|
||
| BKP-05 | **INFO** | Backup-Dokumentation | `COOLIFY_SETUP.md` erwähnt keine Backups. `README.md` und `docker-compose.yml` enthalten keine Backup-Referenzen. Einziger Anhaltspunkt: NFR-6 in `01-requirements.md`. | Backup-Dokumentation in Coolify-Setup integrieren oder als separates `docs/backup-strategy.md` führen. |
|
||
| BKP-06 | **PASS** | Datenbank-Volume | `docker-compose.yml` definiert benanntes Volume `pgdata` für PostgreSQL-Daten (`pgdata:/var/lib/postgresql/data`). Volumes sind persistent und können unabhängig vom Container gesichert werden. | Docker-Volume-Backup (z.B. `docker run --rm -v crm_pgdata:/data -v $(pwd):/backup alpine tar czf /backup/pgdata-backup.tar.gz -C /data .`) als Fallback für Coolify-Backup dokumentieren. |
|
||
| BKP-07 | **PASS** | Pre-Start-Migration | `prestart.sh` führt `alembic upgrade head` aus – idempotente Migration vor jedem App-Start. Dies stellt sicher, dass ein Restore aus einem älteren Backup funktioniert, solange das DB-Schema kompatibel ist. | Alembic-Migrationen sind Forward-kompatibel. Backup-Restore + `alembic upgrade head` ist ein gültiger Recovery-Pfad. |
|
||
| BKP-08 | **INFO** | Diskrepanz PostgreSQL vs. SQLite | Entwicklung nutzt SQLite (`dev.db`), Produktion PostgreSQL. Backups sind nur für PostgreSQL relevant, aber SQLite-DB könnte Entwicklerdaten enthalten, die gesichert werden müssen (z.B. vor Branch-Wechsel oder DB-Reset). | Entwickler-Backup-Strategie dokumentieren: `sqlite3 dev.db ".backup dev-backup-$(date +%Y%m%d).db"` oder Migration zu PostgreSQL auch in Dev. |
|
||
|
||
---
|
||
|
||
## Summary: **WARN** ⚠️
|
||
|
||
Die Backup-Strategie ist **nicht produktionsreif**. Während die technischen Voraussetzungen (PostgreSQL-Volume, Alembic-Migrationen, Coolify-Database-Backup-Feature) gegeben sind, fehlen die konkrete Konfiguration, das Restore-Runbook und ein verifizierter Wiederherstellungs-Test.
|
||
|
||
**Kritisch vor Production-Go-Live:**
|
||
1. Coolify-Backup-Schedule konfigurieren (BKP-01)
|
||
2. Restore-Runbook erstellen (BKP-02)
|
||
3. Restore-Drill durchführen (BKP-03)
|
||
|
||
---
|
||
|
||
## Empfehlungen für Phase 7 (Quality-Reviewer)
|
||
|
||
1. **Backup-Konfiguration prüfen** – Ist der Coolify-Backup-Schedule aktiv und getestet? Existiert ein Storage-Backend (S3, SFTP, oder lokaler Pfad)?
|
||
2. **Runbook-Review** – Runbook auf Vollständigkeit prüfen: Deckt es alle Fehlerszenarien ab (Datenbank-Korruption, versehentliches Löschen, Coolify-Ausfall)?
|
||
3. **RTO/RPO-Messung** – Im Restore-Drill die tatsächliche Recovery-Zeit messen und mit den 4h-RTO abgleichen. Wenn nicht erreichbar: Automatisierte Restore-Prozedur implementieren.
|
||
4. **Backup-Monitoring** – Healthcheck-Endpoint (`/health`) sollte DB-Connectivity prüfen, aber nicht Backup-Status. Optional: Coolify-Health-Webhook, der Backup-Erfolg meldet.
|
||
5. **Release-Readiness-Entscheidung** – Ohne konfiguriertes Backup und Restore-Runbook ist das Deployment gemäß Requirements (NFR-6) nicht freigabefähig. Phase 7 muss dies als Blocker behandeln.
|