# Dokument 11: Analyse VM-basierte Kundenisolation

**Qognio Bot-Plattform — Technische Isolationsoptionen**

**Erstellt:** April 2026
**Autor:** fmhconsulting · Qognio
**Version:** 1.0
**Status:** Entscheidungsvorlage

---

## 1. Ausgangslage

### 1.1 Aktuelle Architektur

Qognio betreibt KI-Bots (OpenClaw-basiert) als Managed Service für HR-Anwendungsfälle. Die aktuelle Infrastruktur:

| Komponente | Server | Spezifikation |
|-----------|--------|--------------|
| Website / Control Plane | 46.243.203.43 | 2 GB RAM, 8 GB Disk, Ubuntu |
| Bot-Server | 46.243.203.45 | 16 GB RAM, 253 GB Disk, 4 vCPU, Ubuntu 24.04 |

- **Hosting-Provider:** KI-Bunker (dedizierte Hardware, Standort nördlich von Hamburg)
- **Virtualisierung:** Beide Server sind selbst KVM/QEMU-Gäste (Guest Agent installiert)
- **Aktueller Stand:** ~15 Docker-Container auf dem Bot-Server
- **Provisioning:** Node.js-basierter Provisioner (`osagentsafehosting/provisioner/`) mit Docker-API (dockerode)
- **Isolation:** Docker-Bridge-Netzwerke pro Mandant, separate Volumes, Memory/CPU-Limits

### 1.2 Motivation für stärkere Isolation

Die aktuelle Docker-basierte Mandantentrennung (vgl. TOMs Anlage 1, §1.4 Trennungskontrolle) bietet:
- ✅ Logische Trennung (Namespaces, cgroups)
- ✅ Separate Netzwerke und Dateisysteme
- ⚠️ **Gemeinsamer Kernel** — Container teilen sich den Host-Kernel
- ⚠️ **Kernel-Exploits** betreffen alle Mandanten gleichzeitig
- ⚠️ **DSGVO Art. 32** verlangt "dem Stand der Technik entsprechende" Maßnahmen

Für HR-Datenverarbeitung (Hochrisiko-KI nach EU AI Act Anhang III Nr. 4, vgl. DSFA Dokument 05) ist eine stärkere technische Mandantentrennung empfehlenswert — insbesondere wenn Kunden mit besonderen Datenkategorien (Gesundheitsdaten, Leistungsbeurteilungen) arbeiten.

### 1.3 Anforderungen

| Anforderung | Priorität | Beschreibung |
|-------------|-----------|-------------|
| Kernel-Isolation | Hoch | Kein gemeinsamer Kernel zwischen Mandanten |
| DSGVO-Konformität | Hoch | Nachweisbare technische Mandantentrennung |
| Performance | Mittel | Minimaler Overhead für Bot-Workloads (Node.js, LLM-API-Calls) |
| RAM-Effizienz | Hoch | 16 GB RAM müssen für 10-30 Kunden reichen |
| Betriebskomplexität | Mittel | Solo-Betrieb durch einen Entwickler |
| Kompatibilität | Hoch | OpenClaw Node.js App + Filesystem + Netzwerk |
| Skalierbarkeit | Mittel | Pfad von 15 auf 50-100 Kunden |

---

## 2. Optionsanalyse

### 2.1 Nested Virtualization (KVM-in-KVM)

**Konzept:** Vollständige virtuelle Maschinen innerhalb der bestehenden VMs starten. Jeder Kunde erhält eine eigene VM mit eigenem Kernel, eigenem Userland.

**Technische Voraussetzungen:**
- CPU-Flag `vmx` (Intel) bzw. `svm` (AMD) muss im Guest sichtbar sein
- Host-Hypervisor muss Nested Virtualization aktiviert haben (`nested=1` in KVM-Modul)
- Prüfung: `cat /proc/cpuinfo | grep -E 'vmx|svm'` auf .45

**Bewertung:**

| Kriterium | Bewertung | Details |
|-----------|-----------|---------|
| Sicherheit | ⭐⭐⭐⭐⭐ | Volle Hardware-Isolation, eigener Kernel pro Mandant |
| Performance | ⭐⭐ | 15-30% Overhead durch doppelte Virtualisierung |
| RAM-Overhead | ⭐ | ~512 MB - 1 GB pro VM (Kernel + OS + Services) |
| Komplexität | ⭐⭐ | Volle VM-Verwaltung (libvirt, QEMU, Images, Updates) |
| Kompatibilität | ⭐⭐⭐⭐⭐ | Volle OS-Umgebung, alles ist möglich |
| Skalierbarkeit | ⭐ | Max. ~10-12 VMs bei 16 GB RAM |
| Kosten | ⭐⭐⭐ | Keine Lizenzkosten, aber hoher RAM-Verbrauch |

**Risiken:**
- Nested Virtualization muss vom Provider (KI-Bunker) am Hypervisor aktiviert werden
- Performance-Degradation ist signifikant bei I/O-intensiven Workloads
- Kernel-Updates in jeder Sub-VM müssen separat verwaltet werden
- 16 GB RAM sind für >10 Kunden mit Nested VMs unzureichend

**Fazit:** Maximale Isolation, aber unpraktikabel auf aktueller Hardware. Nur sinnvoll bei deutlich mehr RAM (≥64 GB).

---

### 2.2 MicroVMs (Firecracker / Cloud Hypervisor)

**Konzept:** Leichtgewichtige VMs mit minimalem Footprint. Firecracker (von AWS für Lambda/Fargate entwickelt) startet VMs in ~125ms mit ~5 MB RAM-Overhead für den VMM-Prozess. Cloud Hypervisor (Intel/Microsoft) ist die Alternative mit mehr Features.

**Funktionsweise:**
- Jeder Kunde erhält eine MicroVM mit eigenem Linux-Kernel
- Minimales Root-Filesystem (Alpine/BusyBox-basiert, ~50-150 MB)
- virtio-Netzwerk und -Block-Devices
- KVM als Backend (benötigt `/dev/kvm`)

**Bewertung:**

| Kriterium | Bewertung | Details |
|-----------|-----------|---------|
| Sicherheit | ⭐⭐⭐⭐⭐ | Volle VM-Isolation, eigener Kernel, minimale Angriffsfläche |
| Performance | ⭐⭐⭐⭐ | ~3-5% Overhead, near-native für CPU/Memory-Workloads |
| RAM-Overhead | ⭐⭐⭐⭐ | ~128-256 MB pro MicroVM (Kernel + minimales OS + App) |
| Komplexität | ⭐⭐⭐ | Eigenes Tooling nötig (kein Docker-API), Custom Root-FS |
| Kompatibilität | ⭐⭐⭐ | Node.js läuft, aber kein Docker-in-MicroVM; Custom Images |
| Skalierbarkeit | ⭐⭐⭐⭐ | ~40-50 MicroVMs bei 16 GB RAM theoretisch möglich |
| Kosten | ⭐⭐⭐⭐ | Open Source, geringer Ressourcenverbrauch |

**Voraussetzungen:**
- `/dev/kvm` muss im Guest verfügbar sein → **Nested Virtualization erforderlich!**
- Firecracker nutzt KVM direkt, funktioniert nicht ohne Hardware-Virtualisierung
- Custom Root-Filesystem muss gebaut und gepflegt werden (z.B. mit `firectl` oder `ignite`)

**Integration mit bestehendem Provisioner:**
```
Aktuell:  API → dockerService.ts → Docker API → Container
Neu:      API → firecrackerService.ts → Firecracker API → MicroVM
```
- Der Provisioner müsste um einen `firecrackerService` erweitert werden
- Firecracker hat eine REST-API (Unix Socket), konzeptionell ähnlich wie Docker
- Templates müssten von Docker-Compose auf MicroVM-Konfiguration umgestellt werden

**Risiken:**
- **Gleiche Nested-Virt-Abhängigkeit wie Option 2.1** — ohne `/dev/kvm` unbenutzbar
- Kein Docker-Ökosystem (Images, Compose, etc.)
- Debugging komplexer als bei Containern
- Netzwerk-Setup (TAP devices, Bridge) muss selbst implementiert werden

**Fazit:** Technisch die eleganteste Lösung, aber blockiert durch die gleiche Nested-Virtualization-Abhängigkeit. Wenn KI-Bunker `/dev/kvm` bereitstellt, ist dies die **Top-Empfehlung** für maximale Isolation bei minimalem Overhead.

---

### 2.3 Kata Containers

**Konzept:** OCI-kompatible Container-Runtime, die jeden Container in einer leichtgewichtigen VM startet. Kombination aus Container-API-Kompatibilität und VM-Isolation. Nutzt intern QEMU, Cloud Hypervisor oder Firecracker als VMM.

**Funktionsweise:**
- Docker/containerd-kompatible Runtime (`kata-runtime`)
- Jeder Container startet in einer eigenen VM mit eigenem Kernel
- Transparenter Ersatz für `runc` — bestehende Docker-Compose-Dateien funktionieren
- OCI-Images werden direkt verwendet (keine Custom Root-FS nötig)

**Bewertung:**

| Kriterium | Bewertung | Details |
|-----------|-----------|---------|
| Sicherheit | ⭐⭐⭐⭐⭐ | VM-Isolation mit Container-Komfort |
| Performance | ⭐⭐⭐⭐ | ~5-10% Overhead (VM-Start + virtio) |
| RAM-Overhead | ⭐⭐⭐ | ~128-384 MB pro Container-VM (konfigurierbarer Kernel) |
| Komplexität | ⭐⭐⭐⭐ | Geringer Umbau — Runtime-Austausch statt Architekturwechsel |
| Kompatibilität | ⭐⭐⭐⭐⭐ | Docker-Images, Docker-Compose, OCI-Standard — alles bleibt |
| Skalierbarkeit | ⭐⭐⭐ | ~25-35 Container-VMs bei 16 GB RAM |
| Kosten | ⭐⭐⭐⭐ | Open Source (CNCF-Projekt) |

**Integration mit bestehendem Provisioner:**
```
Aktuell:  API → dockerService.ts → Docker API → runc → Container
Neu:      API → dockerService.ts → Docker API → kata-runtime → VM-Container
```
- **Minimaler Code-Umbau:** Docker-API bleibt, nur Runtime wechselt
- Konfiguration in `/etc/docker/daemon.json` oder `containerd` config
- Templates bleiben Docker-Compose-Dateien
- Optional: Selektiv pro Container (`--runtime=kata-runtime`)

**Voraussetzungen:**
- **Benötigt `/dev/kvm`** → Nested Virtualization erforderlich
- kata-agent im Guest-Kernel
- containerd als Container-Runtime (Docker kann Kata als Runtime-Plugin nutzen)

**Risiken:**
- Wieder Nested-Virt-Abhängigkeit
- Etwas höherer RAM-Verbrauch als reine MicroVMs
- Debugging: Container-Logs + VM-Logs = zwei Ebenen

**Fazit:** Die pragmatischste VM-basierte Lösung — minimaler Umbau des bestehenden Provisioners. **Empfohlen, wenn `/dev/kvm` verfügbar ist.**

---

### 2.4 LXC/LXD (System-Container)

**Konzept:** System-Container, die wie leichtgewichtige VMs funktionieren. Jeder Container hat ein eigenes Init-System, eigene Services, eigene Netzwerk-Konfiguration — aber teilt den Host-Kernel.

**Status quo:**
- `.43` (Website-Server) hat bereits `lxc` Binary installiert
- LXD/Incus kann als Container-Manager eingesetzt werden

**Funktionsweise:**
- Jeder Kunde erhält einen LXC System-Container
- Eigenes Root-Filesystem (Ubuntu/Alpine Image)
- Eigene Netzwerk-Interfaces (veth pairs, Bridge)
- cgroups v2 für Ressourcenlimits
- Optional: AppArmor/SELinux-Profile für zusätzliche Isolation

**Bewertung:**

| Kriterium | Bewertung | Details |
|-----------|-----------|---------|
| Sicherheit | ⭐⭐⭐ | Besser als Docker (eigenes Init, Namespaces), aber **gemeinsamer Kernel** |
| Performance | ⭐⭐⭐⭐⭐ | Near-native, praktisch kein Overhead |
| RAM-Overhead | ⭐⭐⭐⭐⭐ | ~30-80 MB pro Container (kein eigener Kernel) |
| Komplexität | ⭐⭐⭐⭐ | Mature Tooling (LXD/Incus CLI, REST-API) |
| Kompatibilität | ⭐⭐⭐⭐ | Docker-in-LXC möglich (nested containers), volle OS-Umgebung |
| Skalierbarkeit | ⭐⭐⭐⭐⭐ | 50-100+ Container bei 16 GB RAM möglich |
| Kosten | ⭐⭐⭐⭐⭐ | Open Source (Incus, Canonical LXD) |

**Integration mit bestehendem Provisioner:**
```
Aktuell:  API → dockerService.ts → Docker API → Container
Neu:      API → lxdService.ts → LXD REST-API → System-Container → Docker inside
```
- Neuer Service nötig (LXD hat REST-API, Node.js-Client verfügbar)
- Alternativ: OpenClaw direkt in LXC ohne Docker-Layer (einfacher)
- Templates müssen angepasst werden (LXC-Profile statt Docker-Compose)

**DSGVO-Einschätzung:**
- Gemeinsamer Kernel ist ein **Kompromiss** — besser als Docker, aber keine echte VM-Isolation
- Für die meisten DSGVO-Anforderungen **ausreichend**, wenn ergänzt durch:
  - Unprivileged Containers
  - AppArmor-Profile
  - Netzwerk-Segmentierung
  - Disk-Quotas und Verschlüsselung
- Für Hochrisiko-Verarbeitung (besondere Datenkategorien) könnte ein Auditor stärkere Trennung fordern

**Risiken:**
- Kernel-Exploits betreffen weiterhin alle Mandanten
- LXC/LXD-Ökosystem ist kleiner als Docker
- Canonical hat LXD kommerzialisiert; Incus (Community-Fork) ist die offene Alternative

**Fazit:** Beste Balance aus Isolation und Effizienz, wenn echte VM-Isolation nicht verfügbar ist. **Empfohlen als pragmatische Zwischenlösung.**

---

### 2.5 gVisor (runsc)

**Konzept:** Google's Container-Runtime, die einen User-Space-Kernel (Sentry) zwischen Container und Host-Kernel schaltet. Fängt Syscalls ab und reimplementiert sie — Container sehen nie den echten Kernel.

**Funktionsweise:**
- Drop-in-Replacement für `runc` (OCI-kompatibel)
- Sentry (User-Space-Kernel) emuliert ~380 Linux Syscalls
- Gofer-Prozess für Filesystem-Zugriffe
- Keine Hardware-Virtualisierung nötig (kein `/dev/kvm` erforderlich!)

**Bewertung:**

| Kriterium | Bewertung | Details |
|-----------|-----------|---------|
| Sicherheit | ⭐⭐⭐⭐ | Kernel-Emulation schützt vor Kernel-Exploits, aber kein eigener Kernel |
| Performance | ⭐⭐⭐ | 5-15% CPU-Overhead, Syscall-intensive Workloads langsamer |
| RAM-Overhead | ⭐⭐⭐⭐⭐ | ~10-30 MB pro Container (Sentry-Prozess) |
| Komplexität | ⭐⭐⭐⭐⭐ | Einfachste Installation: Binary + Docker-Config |
| Kompatibilität | ⭐⭐⭐ | Meiste Node.js-Apps funktionieren; manche Syscalls nicht implementiert |
| Skalierbarkeit | ⭐⭐⭐⭐⭐ | 50-100+ Container problemlos |
| Kosten | ⭐⭐⭐⭐⭐ | Open Source (Apache 2.0) |

**Integration mit bestehendem Provisioner:**
```
Aktuell:  API → dockerService.ts → Docker API → runc → Container
Neu:      API → dockerService.ts → Docker API → runsc → Container (gVisor)
```
- **Kein Code-Umbau nötig!** Nur Docker-Daemon-Konfiguration:
  ```json
  {
    "runtimes": {
      "runsc": {
        "path": "/usr/local/bin/runsc"
      }
    }
  }
  ```
- Container starten mit `--runtime=runsc`
- Bestehende Docker-Compose-Templates funktionieren unverändert

**OpenClaw-Kompatibilität:**
- Node.js: ✅ Voll unterstützt
- Filesystem (SQLite, Uploads): ✅ Funktioniert über Gofer
- Netzwerk (HTTP, WebSocket): ✅ Funktioniert
- Docker-in-gVisor: ❌ Nicht möglich (kein verschachteltes Docker)

**Risiken:**
- Kein eigener Kernel → DSGVO-Argumentation schwächer als bei echten VMs
- Manche Linux-Features nicht implementiert (z.B. bestimmte ioctl, FUSE-Mounts)
- Bei Syscall-Inkompatibilitäten: schwer zu debuggen
- Google-Projekt — Community kleiner als Docker/Kubernetes

**Fazit:** Sofort einsetzbar, null Umbauaufwand, **kein `/dev/kvm` nötig**. Ideal als schnelle Härtung der bestehenden Docker-Isolation. Für DSGVO-Argumentation ist es eine signifikante Verbesserung gegenüber reinem Docker — der emulierte Kernel verhindert die gesamte Klasse von Kernel-Exploits.

---

### 2.6 Bare-Metal Sub-VMs beim Provider

**Konzept:** Statt Nested Virtualization direkt beim KI-Bunker zusätzliche VMs bestellen. Jeder Kunde (oder Kundengruppe) erhält eine eigene VM auf dem physischen Host.

**Bewertung:**

| Kriterium | Bewertung | Details |
|-----------|-----------|---------|
| Sicherheit | ⭐⭐⭐⭐⭐ | Maximale Isolation — Hypervisor-Level-Trennung |
| Performance | ⭐⭐⭐⭐⭐ | Native KVM-Performance, kein Nested-Overhead |
| RAM-Overhead | ⭐⭐ | ~512 MB - 1 GB pro VM (OS + Kernel + Services) |
| Komplexität | ⭐⭐⭐ | VM-Provisionierung über Provider-API/Panel oder Automatisierung |
| Kompatibilität | ⭐⭐⭐⭐⭐ | Volle Linux-Umgebung, alles möglich |
| Skalierbarkeit | ⭐⭐⭐ | Abhängig von Provider-Kapazität und Kosten |
| Kosten | ⭐⭐ | Jede VM kostet extra (geschätzt: 5-15€/VM/Monat) |

**Integration mit bestehendem Provisioner:**
```
Aktuell:  API → dockerService.ts → Docker API → Container (lokal)
Neu:      API → providerService.ts → KI-Bunker API → VM erstellen
          → SSH/Cloud-Init → OpenClaw installieren → Bot starten
```
- Neuer Service für Provider-API-Integration
- Cloud-Init oder Ansible für automatische VM-Konfiguration
- DNS/Reverse-Proxy-Management auf .43 (Control Plane)

**Kostenabschätzung:**

| Szenario | VMs | Geschätzte Kosten/Monat |
|----------|-----|------------------------|
| 1 VM pro Kunde | 15 | 75 - 225€ |
| 1 VM pro Kunde | 50 | 250 - 750€ |
| Shared VMs (5 Kunden/VM) | 10 | 50 - 150€ |
| Shared VMs (5 Kunden/VM) | 50 | 50 - 150€ (10 VMs) |

**Hybrid-Modell möglich:**
- Standard-Kunden: Shared VM mit gVisor/LXC-Isolation
- Premium-Kunden: Eigene VM (Aufpreis, bessere DSGVO-Garantie)
- Enterprise-Kunden: Dedizierte Hardware

**Risiken:**
- Abhängigkeit von Provider-Verfügbarkeit und -Preisgestaltung
- Automatisierte Provisionierung nur wenn Provider API bietet
- Netzwerk zwischen VMs muss gesichert werden (WireGuard)
- Mehr Angriffsfläche durch mehr exponierte VMs

**Fazit:** Einfachste Lösung für maximale Isolation, aber teuerste. **Ideal für Premium-Tier oder als langfristige Skalierungsstrategie.**

---

## 3. Vergleichsmatrix

| Kriterium | Nested KVM | MicroVM | Kata | LXC/LXD | gVisor | Provider-VM |
|-----------|:----------:|:-------:|:----:|:-------:|:------:|:-----------:|
| **Kernel-Isolation** | ✅ Eigener | ✅ Eigener | ✅ Eigener | ❌ Shared | ⚠️ Emuliert | ✅ Eigener |
| **Braucht /dev/kvm** | ✅ Ja | ✅ Ja | ✅ Ja | ❌ Nein | ❌ Nein | ❌ N/A |
| **RAM pro Kunde** | ~1 GB | ~200 MB | ~250 MB | ~50 MB | ~20 MB | ~512 MB |
| **Max. Kunden/16GB** | ~10 | ~40 | ~30 | ~100 | ~100+ | N/A |
| **Code-Umbau** | Hoch | Hoch | Gering | Mittel | **Keiner** | Hoch |
| **Docker-kompatibel** | Nein | Nein | ✅ Ja | Teilweise | ✅ Ja | Nein |
| **Boot-Zeit** | ~30-60s | ~125ms | ~500ms | ~2-5s | Instant | ~30-60s |
| **DSGVO-Stärke** | ★★★★★ | ★★★★★ | ★★★★★ | ★★★☆☆ | ★★★★☆ | ★★★★★ |
| **Betriebsaufwand** | Hoch | Mittel | Gering | Gering | **Minimal** | Mittel |

---

## 4. Entscheidungsbaum

```
Ist /dev/kvm in der VM verfügbar?
├── JA → Kata Containers (bester Trade-off: VM-Isolation + Docker-Kompatibilität)
│         Alternativ: Firecracker MicroVMs (wenn maximale Kontrolle gewünscht)
│
└── NEIN → Nested Virt beim Provider anfragen
           ├── Provider aktiviert es → siehe JA
           └── Provider kann/will nicht
               ├── SOFORT: gVisor installieren (zero Umbau, deutlich bessere Isolation)
               ├── MITTELFRISTIG: LXC/Incus als System-Container-Layer
               └── PREMIUM-KUNDEN: Eigene VMs beim Provider bestellen
```

---

## 5. Empfehlung: Phasenplan

### Phase 1: Sofort umsetzbar (1-2 Tage)

**→ gVisor (runsc) auf dem Bot-Server installieren**

- Kein Code-Umbau erforderlich
- Installation:
  ```bash
  # gVisor installieren
  curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
  echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main" | \
    sudo tee /etc/apt/sources.list.d/gvisor.list
  sudo apt update && sudo apt install -y runsc
  
  # Docker konfigurieren
  sudo runsc install
  sudo systemctl restart docker
  ```
- Bestehende Container mit `--runtime=runsc` neu starten
- Der Provisioner braucht nur eine kleine Änderung in `dockerService.ts`:
  ```typescript
  // HostConfig ergänzen um:
  Runtime: 'runsc'
  ```
- **Wirkung:** Sofortige Kernel-Isolation durch Syscall-Interception für alle Mandanten-Container

**DSGVO-Dokumentation:**
- TOMs (Dokument 02) aktualisieren: Trennungskontrolle um gVisor-Kernel-Emulation ergänzen
- DSFA (Dokument 05) aktualisieren: Risikobewertung "Container-Breakout" von "mittel" auf "gering"

### Phase 2: Kurzfristig (2-4 Wochen)

**→ Nested Virtualization beim KI-Bunker klären**

Anfrage an KI-Bunker:
1. Ist Nested Virtualization auf dem Host aktiviert? (`kvm_intel nested=1`)
2. Kann `/dev/kvm` im Guest exponiert werden?
3. Gibt es Performance-Garantien für Nested VMs?
4. Alternativ: Können wir einen Bare-Metal-Server (statt VM) mieten?

**Wenn `/dev/kvm` verfügbar:**
→ Kata Containers evaluieren und pilotieren
- Installation über containerd + Kata-Packages
- Einen Testkunden auf Kata-Runtime migrieren
- Performance-Benchmarks durchführen

### Phase 3: Mittelfristig (1-3 Monate)

**→ Hybrid-Modell implementieren**

| Tier | Isolation | Zielgruppe | Aufpreis |
|------|-----------|------------|----------|
| Standard | gVisor (runsc) | Alle Kunden | Inkludiert |
| Professional | Kata Containers oder LXC | Kunden mit besonderen Kategorien | +20-30% |
| Enterprise | Eigene VM beim Provider | Großkunden, Behörden | +50-100% |

- Provisioner um Tier-Auswahl erweitern
- Runtime-Selection in Template-Metadata aufnehmen:
  ```json
  {
    "isolation": {
      "tier": "standard|professional|enterprise",
      "runtime": "runsc|kata-runtime|vm"
    }
  }
  ```

### Phase 4: Langfristig

**→ Skalierung auf dedizierte Hardware**

- Bei >30 Kunden: Migration auf Bare-Metal-Server beim KI-Bunker
- Firecracker/Cloud Hypervisor mit eigenem Orchestrator
- Oder: Kubernetes + Kata Containers für automatische Skalierung

---

## 6. Kosten-Nutzen-Zusammenfassung

| Phase | Investition | Laufende Kosten | Sicherheitsgewinn |
|-------|------------|-----------------|-------------------|
| Phase 1 (gVisor) | 1-2 Tage Arbeit | 0€ | Hoch — Kernel-Exploit-Schutz |
| Phase 2 (Kata/Klärung) | 1-2 Wochen Arbeit | 0€ | Sehr hoch — echte VM-Isolation |
| Phase 3 (Hybrid) | 2-4 Wochen Arbeit | 0-150€/Monat | Differenziert nach Kundenbedarf |
| Phase 4 (Bare-Metal) | 4-8 Wochen Arbeit | 100-500€/Monat | Maximal |

---

## 7. Aktualisierung der TOMs

Nach Umsetzung von Phase 1 sollte §1.4 Trennungskontrolle (TOMs, Dokument 02) wie folgt aktualisiert werden:

> **Ergänzung — Erweiterte Prozessisolation:**
> - Kernel-Level-Isolation durch gVisor (runsc) Container-Runtime mit User-Space-Kernel-Emulation
> - Syscall-Filterung und -Reimplementierung verhindert direkte Kernel-Interaktion von Mandanten-Prozessen
> - Separate Sentry-Prozesse pro Mandant für unabhängige Syscall-Verarbeitung
> - Optionale VM-basierte Isolation (Kata Containers) für Mandanten mit erhöhtem Schutzbedarf

---

## 8. Nächste Schritte

- [ ] **Sofort:** gVisor auf dem Bot-Server (.45) installieren und testen
- [ ] **Sofort:** OpenClaw-Kompatibilität mit `runsc` validieren (Testcontainer)
- [ ] **Diese Woche:** KI-Bunker wegen Nested Virtualization / `/dev/kvm` kontaktieren
- [ ] **Diese Woche:** KI-Bunker nach Bare-Metal-Server-Optionen und Preisen fragen
- [ ] **Nach Klärung:** Kata Containers oder LXC/Incus pilotieren
- [ ] **Bei Umsetzung:** TOMs und DSFA aktualisieren

---

*Dieses Dokument ist Teil des Qognio DSGVO-Dokumentationspakets und sollte bei jeder Architekturänderung aktualisiert werden.*