leocrm/ENTERPRISE_READINESS_PLAN.md

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.

---

Was schon funktioniert (keine Action nötig)

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

---

Was wirklich fehlt (reduzierter Plan)

1. RLS für 10 Tabellen — 0.5 Tage

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)

Aktion:

• Migration 0129: ALTER TABLE ... ENABLE ROW LEVEL SECURITY + CREATE POLICY tenant_isolation
• Test-DB + Produktion
• RLS-Test: Cross-Tenant-Zugriff blockiert

---

2. Test-DB auf Alembic umstellen — 1 Tag

Problem: Test-DB wird über Base.metadata.create_all() erstellt → keine RLS-Policies, keine echten Migrationen.

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

---

3. Multi-Tenant Prüfung — 1 Tag

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)

---

4. Security Audit — 1 Tag

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)

Externer Pen-Test: Bei Bedarf später, nicht jetzt.

---

5. Monitoring System Dashboard — 2 Tage

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

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

---

6. Backup Automation — 1 Tag

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

---

7. Audit Log Retention + Export — 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

---

8. Trash Cleanup — 0.5 Tage

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

---

9. Incident Response Runbook — 0.5 Tage

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)

---

10. Performance Tests — 1 Tag

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

---

11. Documentation — 1 Tag

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)

---

Was weggelassen wurde (nicht nötig für KMU)

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

---

Zusammenfassung — Reduzierter Plan

#	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

Gesamtaufwand: ~10 Tage (statt 45 Tage)

Keine neuen Tabellen. Keine neuen Plugins. Alles aufbauend auf vorhandenem Code.

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)

---

Ende des reduzierten Enterprise-Readiness Plans