diff --git a/ENTERPRISE_READINESS_PLAN.md b/ENTERPRISE_READINESS_PLAN.md new file mode 100644 index 0000000..45c6031 --- /dev/null +++ b/ENTERPRISE_READINESS_PLAN.md @@ -0,0 +1,524 @@ +# 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: , 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*