leocrm/ENTERPRISE_READINESS_PLAN.md

LeoCRM — Enterprise-Readiness Plan

Ziel: KI und Business-Plattform für kleine bis mittlere Firmen (max. 500 Mitarbeiter) Erstellt: 2026-08-20

---

1. RLS (Row Level Security)

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)

---

2. Security Audit & Penetration Test

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

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

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

---

3. Testing — 100% Abdeckung planen

Test-Strategie

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)

---

4. Monitoring — System Dashboard für Admins

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: <Activity />, 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)

---

5. Backup — Automatisiert über ARQ Scheduler

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

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)

---

6. Multi-Tenant — RLS Lücken prüfen

Aktuell

• 113/133 Tabellen haben RLS in Produktion
• 10 Tabellen absichtlich ohne RLS (Auth/System)
• 10 Tabellen brauchen RLS (siehe Punkt 1)

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)

---

7. Compliance — Geplant in Phase K

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.

---

8. Performance Tests

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)

---

9. Documentation — Anpassen an aktuellen und geplanten Stand

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)

---

10. HA/Scaling — Architektur-Prüfung

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

---

11. API Versioning

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.

---

12. Rate Limiting — Erklärung

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)

---

13. Audit Log — Erklärung

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)

---

14. Data Retention — Erklärung

Was ist Data Retention? Data Retention definiert wie lange Daten aufbewahrt werden und wann sie gelöscht werden.

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."

Warum wichtig?

• Gesetzliche Aufbewahrungspflichten (Handelsrecht, Steuerrecht, DSGVO)
• Speicherplatz-Management
• DSGVO: „Recht auf Vergessenwerden" — Daten müssen löschbar sein

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)

---

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