CRM Bot
5.1 KiB
5.1 KiB
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:
- Coolify-Backup-Schedule konfigurieren (BKP-01)
- Restore-Runbook erstellen (BKP-02)
- Restore-Drill durchführen (BKP-03)
Empfehlungen für Phase 7 (Quality-Reviewer)
- Backup-Konfiguration prüfen – Ist der Coolify-Backup-Schedule aktiv und getestet? Existiert ein Storage-Backend (S3, SFTP, oder lokaler Pfad)?
- Runbook-Review – Runbook auf Vollständigkeit prüfen: Deckt es alle Fehlerszenarien ab (Datenbank-Korruption, versehentliches Löschen, Coolify-Ausfall)?
- 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.
- Backup-Monitoring – Healthcheck-Endpoint (
/health) sollte DB-Connectivity prüfen, aber nicht Backup-Status. Optional: Coolify-Health-Webhook, der Backup-Erfolg meldet. - 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.