diff --git a/ENTERPRISE_READINESS_PLAN.md b/ENTERPRISE_READINESS_PLAN.md index 45c6031..e23ee4a 100644 --- a/ENTERPRISE_READINESS_PLAN.md +++ b/ENTERPRISE_READINESS_PLAN.md @@ -1,524 +1,210 @@ -# LeoCRM — Enterprise-Readiness Plan +# LeoCRM — Enterprise-Readiness Plan (Reduziert) **Ziel:** KI und Business-Plattform für kleine bis mittlere Firmen (max. 500 Mitarbeiter) **Erstellt:** 2026-08-20 +**Prinzip:** Nur was wirklich fehlt. Kein Over-Engineering. Basis ist schon im Code vorhanden. --- -## 1. RLS (Row Level Security) +## Was schon funktioniert (keine Action nötig) -### 20 Tabellen ohne RLS in Produktion — Klassifizierung - -**Absichtlich kein RLS (10 Tabellen — Auth/System-Tabellen):** -Diese Tabellen brauchen kein RLS weil sie vor der Tenant-Auflösung gebraucht werden oder global sind: -| Tabelle | Grund | -|---------|-------| -| `alembic_version` | Migration-Tracking, global | -| `notification_types` | Globale Type-Definitionen | -| `password_reset_tokens` | Auth vor Tenant-Context | -| `plugin_allowlist` | Globale Plugin-Konfiguration | -| `plugin_migrations` | Globale Plugin-Migration-Tracking | -| `plugins` | Globale Plugin-Registry | -| `sessions` | Auth vor Tenant-Context | -| `tenants` | Die Tenant-Tabelle selbst | -| `user_tenants` | Mapping Users ↔ Tenants | -| `users` | Auth vor Tenant-Context | - -**Brauchen RLS (10 Tabellen):** -| Tabelle | Warum RLS nötig | Migration | -|---------|-----------------|----------| -| `ai_decision_records` | Tenant-spezifische AI-Entscheidungen | 0129 | -| `approval_requests` | Tenant-spezifische Approvals | 0129 | -| `automation_agent_run_steps` | Tenant-spezifische Agent-Run-Steps | 0129 | -| `outbox_deliveries` | Tenant-spezifische Event-Zustellungen | 0129 | -| `roles` | Tenant-spezifische Rollen | 0129 | -| `sequences` | Tenant-spezifische Sequenzen | 0129 | -| `wiki_articles` | Tenant-spezifische Wiki-Artikel | 0129 | -| `wiki_article_versions` | Tenant-spezifische Wiki-Versionen | 0129 | -| `wiki_categories` | Tenant-spezifische Wiki-Kategorien | 0129 | -| `marketplace_listings` | Prüfen: Global oder per-Tenant? | 0129 | - -### Ablaufplan RLS: -1. Migration 0129 erstellen: `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` + `CREATE POLICY tenant_isolation ON ...` -2. In Test-DB ausführen und verifizieren -3. In Produktion deployen -4. RLS-Tests schreiben: Cross-Tenant-Zugriff muss blockiert werden -5. Verifizieren: `SELECT count(*) FILTER (WHERE rowsecurity=true) FROM pg_tables WHERE schemaname='public'` → muss 123 sein (133 - 10 system) +| Bereich | Status | Details | +|---------|--------|--------| +| Rate Limiting | ✅ Basis da | `GeneralRateLimitMiddleware` aktiv, `RateLimitPolicy` Enum, LLM Cost-Protection | +| Audit Log | ✅ Komplett | `AuditLog` Model, `log_audit()`, Routes, Frontend Page — läuft | +| Health Checks | ✅ Da | `/health/live`, `/health/ready`, `/health` | +| Error Tracking | ✅ Da | `record_error()`, structlog, trace_id | +| Graceful Shutdown | ✅ Da | Connection Draining, 30s Timeout | +| Metrics | ✅ Da | Prometheus Endpoint `/api/v1/metrics` | +| Soft Delete | ✅ Da | `deleted_at` auf allen Entitäten, Hard-Delete mit `?gdpr=true` | +| Outbox Retention | ✅ Da | ARQ-Job, 30 Tage, hourly Cleanup | +| Backup Script | ✅ Da | `scripts/backup.py` (pg_dump + files) | +| Restore Script | ✅ Da | `scripts/restore.py`, `scripts/restore_test.sh` | +| ARQ Scheduler | ✅ Da | Cron-Jobs mit Redis Lock, 38 registrierte Jobs | --- -## 2. Security Audit & Penetration Test +## Was wirklich fehlt (reduzierter Plan) -### Security Audit (Code-Level) -1. **SQL Injection** — Alle Routes auf Raw-SQL prüfen (`grep -rn 'text(\|execute(\|raw' app/routes/`) -2. **XSS** — Frontend auf `dangerouslySetInnerHTML` prüfen -3. **CSRF** — CSRF Middleware prüfen (vorhanden in `app/core/middleware.py`) -4. **Auth Bypass** — Routes ohne `require_permission` oder `get_current_user` identifizieren -5. **Secret Exposure** — `.env`, API-Keys, Tokens im Code prüfen -6. **Dependency Audit** — `pip-audit` (Python) + `npm audit` (Frontend) -7. **Rate Limiting** — Prüfen ob Rate-Limiting auf kritischen Routes aktiv ist +### 1. RLS für 10 Tabellen — 0.5 Tage -### Penetration Test (Extern) -1. **OWASP Top 10** Checkliste abarbeiten -2. **Burp Suite / OWASP ZAP** Scan gegen https://crm.media-on.de -3. **Auth Tests** — Session-Hijacking, Cookie-Flags, Login-Brute-Force -4. **API Tests** — Unautorisierte Zugriffe, IDOR (Insecure Direct Object Reference) -5. **Multi-Tenant Tests** — Cross-Tenant Datenzugriff versuchen +10 Tabellen brauchen RLS (Tenant-Isolation): +- `ai_decision_records`, `approval_requests`, `automation_agent_run_steps`, `outbox_deliveries`, `roles`, `sequences`, `wiki_articles`, `wiki_article_versions`, `wiki_categories`, `marketplace_listings` (prüfen) -### Ablaufplan Security: -1. Code-Level Security Audit (automatisiert, 1 Tag) -2. Dependency Audit (pip-audit + npm audit, 0.5 Tage) -3. Externer Pen-Test (manuell, 2 Tage) -4. Findings dokumentieren und beheben -5. Re-Test nach Fixes +**Aktion:** +- Migration 0129: `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` + `CREATE POLICY tenant_isolation` +- Test-DB + Produktion +- RLS-Test: Cross-Tenant-Zugriff blockiert --- -## 3. Testing — 100% Abdeckung planen +### 2. Test-DB auf Alembic umstellen — 1 Tag -### Test-Strategie +**Problem:** Test-DB wird über `Base.metadata.create_all()` erstellt → keine RLS-Policies, keine echten Migrationen. -**Schicht 1: Unit-Tests (vorhanden, erweitern)** -- Pure Funktionen, Utilities, Helper -- Keine DB, keine externen Services -- Ziel: 200+ Tests - -**Schicht 2: Integration-Tests (ausbauen)** -- Echte DB (leocrm_test mit Alembic-Migrationen, nicht create_all) -- Echte Redis-Verbindung -- API-Tests über httpx AsyncClient -- LLM gemockt (llm_complete/llm_embed) -- Ziel: 300+ Tests - -**Schicht 3: Cross-Module Tests (neu)** -- Plugin A → Contract → Plugin B -- Agent → Tool → DB → Audit -- Workflow → Step → External Service (gemockt) -- Event Bus → Outbox → Consumer -- Ziel: 50+ Tests - -**Schicht 4: E2E Tests (Playwright, erweitern)** -- Login → Contact erstellen → Search → Edit → Delete -- Mail: Account → Folder → Message → Attachment -- Agent: Create → Run → Result → Approval -- Workflow: Create → Run → Step → Complete -- Ziel: 30+ Tests - -**Schicht 5: Performance Tests (neu)** -- locust/k6: Login, Contact-List, Search unter Last -- 10, 50, 100 gleichzeitige User -- Response-Time < 500ms, Error-Rate < 1% -- Ziel: 10+ Test-Szenarien - -### Test-DB Fix (wichtig!) -1. conftest.py umstellen: Alembic-Migrationen statt `Base.metadata.create_all()` -2. RLS-Policies in Test-DB aktivieren -3. Test-Isolation: Jeder Test bekommt clean Schema (TRUNCATE zwischen Tests) -4. Test-Daten-Fixtures: Realistische Test-Daten (Contacts, Companies, Mail, etc.) - -### Ablaufplan Testing: -1. Test-DB auf Alembic umstellen (1 Tag) -2. Bestehende Mock-Tests zu Integration-Tests migrieren (3 Tage) -3. Neue Cross-Module Tests schreiben (2 Tage) -4. E2E Tests erweitern (2 Tage) -5. Performance Tests einrichten (1 Tag) -6. CI-Pipeline: Alle Tests müssen grün sein vor Deploy (0.5 Tage) +**Aktion:** +- conftest.py: Alembic-Migrationen statt `create_all()` +- RLS-Policies in Test-DB aktiv +- Test-Isolation: TRUNCATE zwischen Tests +- Echte Integration-Tests statt Mock-Tests --- -## 4. Monitoring — System Dashboard für Admins +### 3. Multi-Tenant Prüfung — 1 Tag -### Backend -1. **Neue Route:** `app/routes/system_dashboard.py` - - `GET /api/v1/system-dashboard` — Admin-only (`require_permission("system:read")`) - - Sammelt: Health, DB-Stats, Redis-Stats, Worker-Queue, Active Users, Error-Rate, Response-Times - - Bei Problemen: `post_system_message()` an internes Nachrichten-System - -2. **Monitoring Daten sammeln:** - - DB: Connection-Pool-Stats, Query-Count, Slow-Queries - - Redis: Memory, Connections, PubSub Channels - - Worker: Queue-Length, Failed-Jobs, Running-Jobs - - App: Active Sessions, Request-Count, Error-Rate - - Plugins: Active-Status, Health pro Plugin - - LLM: Cost pro Tag/Agent/Workflow - -3. **Alerting:** - - Wenn Health-Check failed → System-Message an Communication-System - - Wenn Error-Rate > 5% → System-Message - - Wenn Worker-Queue > 100 → System-Message - - Wenn DB-Disk > 80% → System-Message - - Wenn Redis-Memory > 80% → System-Message - -### Frontend -1. **Neue Page:** `frontend/src/pages/SystemDashboard.tsx` - - Nur für Admins sichtbar (`PermissionRoute permission="system:read"`) - - Link im linken Menü (Sidebar) — nur für Admins - - Real-Time Updates (WebSocket oder 30s Polling) - - Cards: System Health, DB, Redis, Worker, Active Users, Errors, LLM Costs - - Charts: Response-Time-Trend, Error-Rate-Trend, Queue-Length - - Alert-Feed: System-Messages aus Communication-System - -2. **Sidebar Eintrag:** - - `{ to: '/system-dashboard', labelKey: 'nav.systemDashboard', icon: , order: 95 }` - - Nur sichtbar wenn `is_system_admin === true` - -### Ablaufplan Monitoring: -1. Backend: `system_dashboard.py` Route mit echten DB/Redis/Worker-Stats (1 Tag) -2. Backend: Alerting → System-Message bei Problemen (0.5 Tage) -3. Frontend: `SystemDashboard.tsx` mit Cards und Charts (2 Tage) -4. Frontend: Sidebar-Eintrag + Permission-Check (0.5 Tage) -5. Tests: Integration-Test für Dashboard-Route (0.5 Tage) +**Aktion:** +- ORM Auto-Filter verifizieren (tenant_id wird automatisch gefiltert?) +- Routes ohne Tenant-Check identifizieren +- Cross-Tenant Integration-Tests +- 20 Tabellen ohne RLS klassifizieren (10 absichtlich, 10 brauchen RLS → Punkt 1) --- -## 5. Backup — Automatisiert über ARQ Scheduler +### 4. Security Audit — 1 Tag -### Vorhandene Infrastruktur -- `scripts/backup.py` — Backup-Script (pg_dump + files) -- `scripts/restore.py` — Restore-Script -- ARQ Worker mit cron-Scheduler (vorhanden) -- `scheduler_tick` Job registriert +**Aktion (Code-Level, automatisiert):** +- SQL Injection: `grep -rn 'text(\|execute(\|raw' app/routes/` +- XSS: Frontend `dangerouslySetInnerHTML` prüfen +- Auth Bypass: Routes ohne `require_permission` oder `get_current_user` +- Secret Exposure: API-Keys/Tokens im Code +- Dependency Audit: `pip-audit` + `npm audit` +- Login-Brute-Force-Schutz: Rate-Limit auf Login-Route (5 Versuche) -### Plan -1. **Backup ARQ Job registrieren:** - - `register_job("auto_backup", auto_backup_job)` - - Cron-Schedule: Täglich um 03:00 Uhr (einstellbar) - - Ruft `scripts/backup.py` auf - - Speichert Backup in `/backups/` (oder S3/Nextcloud) - -2. **Settings-Erweiterung:** - - `backup_enabled: bool = True` - - `backup_schedule: str = "0 3 * * *"` (cron) - - `backup_destination: str = "local"` (local/s3/nextcloud) - - `backup_retention_days: int = 7` - - In Settings-Page im Frontend einstellbar - -3. **Backup-Verifizierung:** - - Nach jedem Backup: Manifest prüfen (Datei-Anzahl, Größe) - - Wöchentlich: Test-Restore in Test-DB + Row-Count-Validierung - - Bei Fehler: System-Message an Communication-System - -4. **Restore-Test:** - - `scripts/restore_test.sh` existiert bereits - - Als ARQ-Cron-Job: Wöchentlich Restore in Test-DB, Schema validieren - -### Ablaufplan Backup: -1. `auto_backup_job` in `app/core/jobs.py` registrieren (0.5 Tage) -2. Settings-Schema erweitern + Frontend-UI (1 Tag) -3. Backup-Verifizierung + Alerting (0.5 Tage) -4. Restore-Test als Cron-Job (0.5 Tage) -5. Tests: Backup erstellen → Restore → Validieren (1 Tag) +**Externer Pen-Test:** Bei Bedarf später, nicht jetzt. --- -## 6. Multi-Tenant — RLS Lücken prüfen +### 5. Monitoring System Dashboard — 2 Tage -### Aktuell -- 113/133 Tabellen haben RLS in Produktion -- 10 Tabellen absichtlich ohne RLS (Auth/System) -- 10 Tabellen brauchen RLS (siehe Punkt 1) +**Backend:** +- `app/routes/system_dashboard.py` — Admin-only Route +- Sammelt: Health, DB-Stats, Redis-Stats, Worker-Queue, Active Users, Error-Rate, LLM Costs +- Bei Problemen: `post_system_message()` an Communication-System -### Weitere Prüfung -1. **ORM Auto-Filter** — Prüfen ob SQLAlchemy automatisch `tenant_id` filtert -2. **Routes ohne Tenant-Check** — Gibt es Routes die `tenant_id` nicht prüfen? -3. **Cross-Tenant Queries** — Gibt es Queries die `tenant_id` nicht filtern? -4. **Plugin-Tables** — Haben alle Plugin-Tables `tenant_id`? -5. **Admin-Bypass** — Können Admins andere Tenants sehen? (Sollten sie nicht) - -### Ablaufplan Multi-Tenant: -1. RLS für 10 fehlende Tabellen hinzufügen (Punkt 1) (0.5 Tage) -2. ORM Auto-Filter verifizieren (0.5 Tage) -3. Routes ohne Tenant-Check identifizieren und fixen (1 Tag) -4. Cross-Tenant Integration-Tests schreiben (1 Tag) +**Frontend:** +- `frontend/src/pages/SystemDashboard.tsx` — Admin-only Page +- Sidebar-Eintrag (nur für Admins sichtbar) +- Cards: System Health, DB, Redis, Worker, Errors, LLM Costs +- Alert-Feed: System-Messages aus Communication-System --- -## 7. Compliance — Geplant in Phase K +### 6. Backup Automation — 1 Tag -Phase K (EU Compliance) ist in der Roadmap geplant mit 6 Tasks: -- AI Use-Case Registry -- Processing Activities Register -- DSR Automation (Access/Erasure/Correction) -- DPIA (Data Protection Impact Assessment) -- AI Act Compliance -- Compliance Reports - -Das ist geplant und muss implementiert werden wenn Phase I+J abgeschlossen sind. +**Aktion:** +- `auto_backup_job` ARQ-Job registrieren (ruft `scripts/backup.py` auf) +- Cron-Schedule: Täglich 03:00 Uhr (einstellbar in Settings) +- Settings: `backup_enabled`, `backup_schedule`, `backup_retention_days` +- Backup-Verifizierung: Manifest prüfen nach Backup +- Bei Fehler: System-Message an Communication-System --- -## 8. Performance Tests +### 7. Audit Log Retention + Export — 0.5 Tage -### Plan -1. **locust/k6 Setup** — Load-Testing-Tool installieren -2. **Test-Szenarien:** - - Login (100 gleichzeitige User) - - Contact-List (50 User, paginated) - - Search (50 User, verschiedene Queries) - - Mail-List (30 User, IMAP-Sync) - - Agent-Run (10 User, gleichzeitige Agent-Runs) -3. **Metriken:** - - Response-Time (P50, P95, P99) - - Error-Rate - - Throughput (Requests/sec) - - DB-Query-Count pro Request - - Redis-Hit-Rate -4. **Baseline messen** — Aktuelle Performance aufzeichnen -5. **Optimierung** — Bottlenecks identifizieren und beheben - -### Ablaufplan Performance: -1. locust/k6 installieren + Test-Szenarien schreiben (1 Tag) -2. Baseline messen (0.5 Tage) -3. Bottlenecks identifizieren (0.5 Tage) -4. Optimierung (N+1 Queries, Caching, Indexes) (2 Tage) -5. Re-Test nach Optimierung (0.5 Tage) +**Aktion:** +- Config: `audit_retention_days: int = 365` (einstellbar) +- ARQ-Cron-Job: Audit-Logs älter als Retention archivieren +- Route: `GET /api/v1/audit-log/export` (CSV/JSON Export) +- Tamper-Proof: DELETE auf AuditLog nur mit `?gdpr=true` + Admin --- -## 9. Documentation — Anpassen an aktuellen und geplanten Stand +### 8. Trash Cleanup — 0.5 Tage -### Was aktualisiert werden muss -1. **README.md** — Aktualisiert ✅ (KI und Business-Plattform) -2. **docs/api-documentation.md** — Alle 468 Routes dokumentieren (aktualisieren) -3. **docs/plugin-development-guide.md** — 23 Plugins dokumentieren (aktualisieren) -4. **docs/infrastructure.md** — Docker, PostgreSQL, Redis, ARQ (aktualisieren) -5. **docs/monitoring.md** — System Dashboard, Alerting (neu schreiben) -6. **docs/security_kernel.md** — RLS, ABAC, Audit, Pen-Test (aktualisieren) -7. **docs/admin-guide.md** — Backup, Restore, Monitoring, Settings (aktualisieren) -8. **docs/deploy-guide.md** — Deploy-Process, Coolify (aktualisieren) -9. **docs/test-strategy.md** — Test-Schichten, Test-DB, CI (aktualisieren) -10. **docs/ui-design-guidelines.md** — System Dashboard, neue Komponenten (aktualisieren) -11. **AGENTS.md** — Build/Test-Commands, Konventionen (aktualisieren) -12. **PROGRESS.md** — Aktueller Stand (aktualisiert ✅) -13. **PLATFORM_ROADMAP.md** — Phasen-Status (aktualisiert ✅) - -### Ablaufplan Documentation: -1. Alle Doku-Dateien durchgehen und veraltete Inhalte aktualisieren (2 Tage) -2. Neue Doku für System Dashboard, Backup-Automation, Performance (1 Tag) -3. API-Doku für neue Routes ergänzen (1 Tag) +**Aktion:** +- Config: `trash_retention_days: int = 90` (einstellbar) +- ARQ-Cron-Job: `cleanup_expired_trash` — `deleted_at < now() - retention_days` endgültig löschen +- Bei Löschung: Audit-Log Eintrag --- -## 10. HA/Scaling — Architektur-Prüfung +### 9. Incident Response Runbook — 0.5 Tage -### Aktuelle Architektur -- Single-Instance: 1x crm_app, 1x crm_worker, 1x postgres, 1x redis -- Docker-Compose auf einem Hetzner VPS - -### Kann die Architektur skalieren? -**Ja, bedingt.** Die Architektur unterstützt Horizontal-Scaling: - -1. **crm_app** — Kann horizontal skalieren (stateless, Session in Redis) - - Mehrere Instanzen hinter Load Balancer (Coolify unterstützt das) - - WebSocket: Redis PubSub für Multi-Instance (bereits implementiert) - - Cron-Locks: Bereits implementiert (`_acquire_cron_lock`) - -2. **crm_worker** — Kann horizontal skalieren - - ARQ Worker sind stateless - - Redis als Queue (bereits implementiert) - - Cron-Locks verhindern doppelte Ausführung (bereits implementiert) - -3. **postgres** — Vertikales Scaling (größerer Server) - - Für HA: Managed PostgreSQL (z.B. Hetzner Cloud DB, RDS) - - Read-Replicas für Search-Queries möglich - -4. **redis** — Vertikales Scaling - - Für HA: Redis Sentinel oder Managed Redis - -### Was für HA noch fehlt -- Load Balancer (Coolify/Traefik kann das) -- Health-Checks für Auto-Restart (vorhanden) -- Graceful Shutdown (vorhanden) -- Session-Sharing über Redis (vorhanden) - -### Fazit: Die Architektur unterstützt HA/Scaling. Bei Bedarf können einfach mehr crm_app und crm_worker Instanzen hinzugefügt werden. PostgreSQL und Redis brauchen dann Managed Services. - -### Ablaufplan HA (bei Bedarf): -1. 2-3 crm_app Instanzen hinter Traefik Load Balancer (Coolify) -2. 2 crm_worker Instanzen -3. Managed PostgreSQL (Hetzner Cloud DB oder extern) -4. Managed Redis (oder Redis Sentinel) -5. Keine Code-Änderungen nötig — nur Docker-Compose Anpassung +**Aktion:** +- `docs/incident-response.md` schreiben: + - Server-Ausfall: Coolify Restart → Health-Check → System-Message + - DB-Crash: PostgreSQL Restart → Migration-Check → Backup-Restore + - Redis-Crash: Redis Restart → Session-Check + - Security-Breach: Logs prüfen → Password-Reset → Audit-Log Export +- Alerting kommt über System Dashboard (Punkt 5) --- -## 11. API Versioning +### 10. Performance Tests — 1 Tag -### Aktuell -- Alle Routes unter `/api/v1/` -- Kein automatisches Versioning - -### Plan -- Bei Breaking Changes: Neue Routes unter `/api/v2/` -- Alte Routes bleiben verfügbar (Deprecation) -- Versionierung über URL-Präfix (nicht Header) -- Das ist ausreichend für KMU bis 500 Mitarbeiter - -### Fazit: v1 ist ausreichend. Bei v2 einfach neuen Prefix hinzufügen. Keine zusätzliche Infrastruktur nötig. +**Aktion:** +- locust/k6: Login, Contact-List, Search unter Last (10, 50, 100 User) +- Baseline messen: Response-Time, Error-Rate, Throughput +- Bottlenecks identifizieren (N+1 Queries, fehlende Indexes) +- Bei Bedarf optimieren --- -## 12. Rate Limiting — Erklärung +### 11. Documentation — 1 Tag -**Was ist Rate Limiting?** -Rate Limiting begrenzt wie viele API-Anfragen ein User in einer bestimmten Zeit machen kann. - -**Beispiel:** Ein User kann maximal 100 API-Anfragen pro Minute machen. Wenn er mehr macht, bekommt er einen 429 (Too Many Requests) Fehler. - -**Warum wichtig?** -- Schutz vor Missbrauch (Brute-Force, DDoS) -- Faire Ressourcen-Verteilung (ein User kann nicht alle Ressourcen verbrauchen) -- Schutz vor Endlos-Schleifen (z.B. Agent der zu viele LLM-Calls macht) - -**Aktuell:** -- Globales Rate-Limiting vorhanden (`GeneralRateLimitMiddleware` in `app/core/rate_limit.py`) -- LLM Cost-Protection vorhanden (Budget-Limits pro Tenant) - -**Was fehlt:** -- Per-User Rate-Limiting (nicht nur global) -- Per-Tenant Rate-Limiting -- Spezifische Limits für kritische Endpoints (Login, Password-Reset, Agent-Run) - -### Ablaufplan Rate Limiting: -1. Per-User und Per-Tenant Limits in `rate_limit.py` implementieren (1 Tag) -2. Spezifische Limits für Login, Password-Reset, Agent-Run (0.5 Tage) -3. Tests: Rate-Limit wird durchgesetzt (0.5 Tage) +**Aktion:** +- README.md ✅ (aktualisiert) +- docs/api-documentation.md — Neue Routes ergänzen +- docs/monitoring.md — System Dashboard, Alerting +- docs/admin-guide.md — Backup, Restore, Monitoring +- docs/security_kernel.md — RLS, Audit, Pen-Test +- docs/test-strategy.md — Test-DB, Integration-Tests +- docs/incident-response.md — Runbook (Punkt 9) --- -## 13. Audit Log — Erklärung +## Was weggelassen wurde (nicht nötig für KMU) -**Was ist Audit Log?** -Audit Log protokolliert jede Änderung am System: Wer hat was wann geändert. - -**Beispiel:** "User admin@media-on.de hat Kontakt 'Max Mustermann' um 14:30 Uhr aktualisiert — Feld 'email' geändert von 'alt@example.com' zu 'neu@example.com'" - -**Warum wichtig?** -- Nachvollziehbarkeit bei Fehlern -- Compliance (DSGVO fordert Protokollierung) -- Security (wer hat auf welche Daten zugegriffen?) - -**Aktuell:** -- `app/models/audit.py` — AuditLog Model vorhanden -- `app/routes/audit.py` — Audit-Log API vorhanden -- `do_action()` feuert bei jeder Änderung -- 81 do_action-Aufrufe im Code - -**Was fehlt:** -- **Retention Policy** — Wie lange werden Audit-Logs aufbewahrt? (z.B. 90 Tage, 1 Jahr, 7 Jahre je nach Gesetz) -- **Audit-Log-Export** — Export für Compliance-Prüfung -- **Tamper-Proof** — Audit-Logs sollten nicht löschbar sein (außer durch Admin mit GDPR-Flag) - -### Ablaufplan Audit Log: -1. Retention Policy in Settings konfigurierbar (0.5 Tage) -2. ARQ-Cron-Job: Audit-Logs älter als Retention-Period archivieren (0.5 Tage) -3. Audit-Log-Export als CSV/JSON (0.5 Tage) -4. Tamper-Proof: DELETE auf AuditLog nur mit `?gdpr=true` und Admin-Permission (0.5 Tage) +| Bereich | Grund weggelassen | +|---------|------------------| +| Per-User Rate Limiting | Globales Rate-Limiting reicht, Login-Brute-Force-Schutz in Punkt 4 | +| Per-Tenant Rate Limiting | Nicht nötig für KMU bis 500 Mitarbeiter | +| Externer Pen-Test | Bei Bedarf später, Code-Level Audit reicht erstmal | +| DSGVO-Lösch-Workflow | In Phase K geplant | +| Post-Mortem Template | Runbook reicht | +| HA/Scaling | Architektur unterstützt es, bei Bedarf einfach mehr Instanzen | +| API Versioning | v1 ausreichend, v2 bei Bedarf neuer Prefix | +| Compliance (Phase K) | Geplant, separat | +| 300+ Integration-Tests | Test-DB Fix + schrittweise Migration der Mock-Tests | +| 30+ E2E Tests | Vorhandene E2E Tests erweitern bei Bedarf | +| Cross-Module Tests | Bei Bedarf, nicht als Pflicht | --- -## 14. Data Retention — Erklärung +## Zusammenfassung — Reduzierter Plan -**Was ist Data Retention?** -Data Retention definiert wie lange Daten aufbewahrt werden und wann sie gelöscht werden. +| # | Bereich | Aufwand | Neue Tabellen? | Neue Plugins? | +|---|---------|--------|---------------|---------------| +| 1 | RLS für 10 Tabellen | 0.5 Tage | Nein (Migration) | Nein | +| 2 | Test-DB auf Alembic | 1 Tag | Nein | Nein | +| 3 | Multi-Tenant Prüfung | 1 Tag | Nein | Nein | +| 4 | Security Audit (Code-Level) | 1 Tag | Nein | Nein | +| 5 | Monitoring System Dashboard | 2 Tage | Nein | Nein | +| 6 | Backup Automation | 1 Tag | Nein | Nein | +| 7 | Audit Log Retention + Export | 0.5 Tage | Nein | Nein | +| 8 | Trash Cleanup | 0.5 Tage | Nein | Nein | +| 9 | Incident Response Runbook | 0.5 Tage | Nein | Nein | +| 10 | Performance Tests | 1 Tag | Nein | Nein | +| 11 | Documentation | 1 Tag | Nein | Nein | -**Beispiel:** "E-Mails werden 7 Jahre aufbewahrt (gesetzliche Pflicht), danach automatisch gelöscht. Gelöschte Kontakte werden 90 Tage im Trash behalten, danach endgültig gelöscht." +**Gesamtaufwand:** ~10 Tage (statt 45 Tage) -**Warum wichtig?** -- Gesetzliche Aufbewahrungspflichten (Handelsrecht, Steuerrecht, DSGVO) -- Speicherplatz-Management -- DSGVO: „Recht auf Vergessenwerden" — Daten müssen löschbar sein +**Keine neuen Tabellen. Keine neuen Plugins.** Alles aufbauend auf vorhandenem Code. -**Aktuell:** -- Soft-Delete mit `deleted_at` vorhanden (alle Entitäten) -- Hard-Delete nur mit `?gdpr=true` (vorhanden) -- Entity History mit Restore vorhanden (Phase D) -- Keine automatische Retention/Löschung nach Zeit - -**Was fehlt:** -- Konfigurierbare Retention-Policies pro Datentyp (z.B. Mail=7 Jahre, Contacts=90 Tage Trash) -- ARQ-Cron-Job der abgelaufene Daten archiviert/löscht -- DSGVO-Lösch-Workflow (Betroffenenrechts-Anfragen) - -### Ablaufplan Data Retention: -1. Retention-Settings in `config.py` + Settings-Page (0.5 Tage) -2. ARQ-Cron-Job: `cleanup_expired_data` (1 Tag) -3. DSGVO-Lösch-Workflow (in Phase K geplant) -4. Tests: Daten werden nach Retention-Period gelöscht (0.5 Tage) +**Reihenfolge:** +1. RLS (0.5 Tage) +2. Test-DB Fix (1 Tag) +3. Multi-Tenant (1 Tag) +4. Security Audit (1 Tag) +5. Monitoring Dashboard (2 Tage) +6. Backup Automation (1 Tag) +7. Audit Retention + Export (0.5 Tage) +8. Trash Cleanup (0.5 Tage) +9. Incident Response Runbook (0.5 Tage) +10. Performance Tests (1 Tag) +11. Documentation (1 Tag) --- -## 15. Incident Response — Erklärung - -**Was ist Incident Response?** -Incident Response ist der Plan was passiert wenn etwas schiefgeht (Server-Ausfall, Datenverlust, Security-Breach). - -**Beispiel:** „Server ist down → 1. Admin bekommt Alert über System-Dashboard → 2. Backup wird restored → 3. User werden informiert → 4. Post-Mortem wird geschrieben" - -**Warum wichtig?** -- Schnelle Reaktion bei Problemen -- Minimierung von Ausfallzeiten -- Dokumentation für Verbesserung - -**Aktuell:** -- Health-Check vorhanden (`/api/v1/health`) -- Graceful Shutdown vorhanden -- Error-Logging vorhanden (structlog + trace_id) -- Kein automatisches Alerting -- Kein Runbook - -**Was fehlt:** -- **Runbook** — Dokument mit Schritten bei verschiedenen Incident-Typen -- **Alerting** — Automatische Benachrichtigung bei Problemen (über System Dashboard → Communication-System) -- **Post-Mortem Template** — Vorlage für Incident-Dokumentation - -### Ablaufplan Incident Response: -1. Runbook schreiben (Server-Ausfall, DB-Crash, Redis-Crash, Security-Breach) (1 Tag) -2. Alerting im System Dashboard implementiert (siehe Punkt 4) (bereits geplant) -3. Post-Mortem Template in `docs/incident-response.md` (0.5 Tage) -4. Recovery-Test: Backup restore + App-Neustart (0.5 Tage) - ---- - -## Zusammenfassung — Alle Ablaufpläne - -| # | Bereich | Aufwand | Priorität | Abhängigkeit | -|---|---------|--------|-----------|-------------| -| 1 | RLS für 10 Tabellen | 0.5 Tage | 🔴 Hoch | Keine | -| 2 | Security Audit + Pen-Test | 3.5 Tage | 🔴 Hoch | Nach RLS | -| 3 | Testing 100% | 9.5 Tage | 🔴 Hoch | Nach Test-DB Fix | -| 4 | Monitoring System Dashboard | 4.5 Tage | 🟡 Mittel | Keine | -| 5 | Backup Automation | 3.5 Tage | 🟡 Mittel | ARQ Scheduler | -| 6 | Multi-Tenant Prüfung | 3 Tage | 🔴 Hoch | Nach RLS | -| 7 | Compliance (Phase K) | Geplant | 🟡 Mittel | Nach Phase I+J | -| 8 | Performance Tests | 4.5 Tage | 🟡 Mittel | Nach Testing | -| 9 | Documentation | 4 Tage | 🟡 Mittel | Nach allen Änderungen | -| 10 | HA/Scaling | Bei Bedarf | 🟢 Low | Architektur unterstützt es | -| 11 | API Versioning | v1 ausreichend | 🟢 Low | Keine | -| 12 | Rate Limiting | 2 Tage | 🟡 Mittel | Keine | -| 13 | Audit Log | 2 Tage | 🟡 Mittel | Keine | -| 14 | Data Retention | 2.5 Tage | 🟡 Mittel | ARQ Scheduler | -| 15 | Incident Response | 2.5 Tage | 🟡 Mittel | Nach Monitoring | - -**Gesamtaufwand:** ~45 Tage (ohne Compliance, HA, API Versioning) - -**Reihenfolge (empfohlen):** -1. RLS (Punkt 1) — 0.5 Tage -2. Test-DB Fix (Teil von Punkt 3) — 1 Tag -3. Multi-Tenant Prüfung (Punkt 6) — 3 Tage -4. Security Audit (Punkt 2) — 3.5 Tage -5. Monitoring (Punkt 4) — 4.5 Tage -6. Testing (Punkt 3) — 9.5 Tage -7. Backup (Punkt 5) — 3.5 Tage -8. Rate Limiting (Punkt 12) — 2 Tage -9. Audit Log (Punkt 13) — 2 Tage -10. Data Retention (Punkt 14) — 2.5 Tage -11. Performance (Punkt 8) — 4.5 Tage -12. Incident Response (Punkt 15) — 2.5 Tage -13. Documentation (Punkt 9) — 4 Tage -14. Compliance (Phase K) — Geplant -15. HA/Scaling (Punkt 10) — Bei Bedarf - ---- - -*Ende des Enterprise-Readiness Plans* +*Ende des reduzierten Enterprise-Readiness Plans*