Selbst gehostete KI absichern: Infrastruktur-Härtung für die Produktion

Die meisten Texte zur KI-Sicherheit hören 2026 bei Prompt Injection und Content-Filtering auf. Das ist die Anwendungsschicht. Wer KI selbst betreibt — Ollama auf einem VPS, vLLM auf einem GPU-Server, irgendetwas, das eigene Infrastruktur berührt — hat eine deutlich größere Angriffsfläche darunter: Container, Netzwerke, Secrets, die Datenbank mit den Embeddings, die GPU-Runtime, die Build-Pipeline, die das Image erzeugt hat.

Dieser Leitfaden beschreibt, wie man diesen Stack absichert. Er stammt aus dem Betrieb einer selbst gehosteten KI-Flotte mit 20+ Anwendungen — Ollama für lokale Inferenz, PostgreSQL mit pgvector, Redis, eigene Next.js-Frontends, Caddy als Reverse Proxy — über isolierte Docker-Netzwerke auf Hetzner. Die meisten der unten genannten Fehler waren erst meine, bevor sie zu Lektionen wurden.

Das Bedrohungsmodell, dem Sie tatsächlich begegnen

Vor jeder Kontrolle muss klar sein, wogegen verteidigt wird. Selbst gehostete KI hat in der Praxis vier realistische Bedrohungsklassen:

Container-Härtung: Die nicht verhandelbaren Defaults

Dockers Defaults sind auf Entwicklerfreundlichkeit optimiert, nicht auf produktive Sicherheit. Jeder produktive Container in meiner Flotte hat Folgendes in docker-compose.yml — die Kosten sind nahe null, die Reduktion des Schadensradius enorm.

services:
  app:
    cap_drop: [ALL]
    security_opt: [no-new-privileges:true]
    read_only: true
    tmpfs:
      - /tmp:size=100m
      - /app/.next/cache:size=200m
    user: "1001:1001"

Als Non-Root-User laufen lassen. Das Dockerfile legt einen numerischen User an (UID 1001) und wechselt vor dem Entrypoint dorthin. USER root in der finalen Stage ist ein Review-Flag. Wenn es unvermeidbar ist (manche Python ML-Images), das Capability-Set explizit pinnen und regelmäßig prüfen.

Dateisystem read-only setzen. read_only: true plus tmpfs für die wenigen schreibbaren Pfade (Cache, /tmp). Ein kompromittierter Prozess kann keine Webshell ablegen oder über Restarts persistieren. Beim ersten Aktivieren findet man garantiert eine App, die in /app/logs schreibt — die App fixen, nicht die Constraint lockern.

Ressourcengrenzen sind Pflicht. Ein entgleister LLM-Aufruf kann den Host per OOM abschießen. deploy.resources.limits.memory und deploy.resources.limits.cpus auf jedem Service setzen. pids_limit: 200 stoppt Fork-Bombs.

Netzwerk-Isolation: Jede App in ihrem eigenen Netzwerk

Die Docker-Default-Bridge legt jeden Container in dieselbe Broadcast-Domain. Ein kompromittierter Container kann mit jedem anderen Container auf dem Host sprechen. Tun Sie das nicht.

Auf Host-Ebene eine Default-Deny-Firewall fahren — ufw mit Regeln für SSH, 80, 443. Von außen testen, nicht aus einer Shell auf der Box. Ich habe schon Firewall-Regeln deployed, die richtig aussahen und nicht waren.

Ollama-spezifische Risiken

Ollama ist enorm nützlich und hat Sicherheits-Defaults, die aktiv gemanagt werden müssen:

Datenbank-Sicherheit für KI-Workloads

Vektor-Datenbanken halten etwas Sensibleres als gewöhnliche Nutzerdaten: Embeddings sämtlicher Dokumente. Mit dem richtigen Modell sind diese Embeddings teilweise reversibel. Behandeln Sie sie wie eine Kopie des Quellkorpus.

Secrets-Management ohne Vault

Die meisten selbst gehosteten KI-Flotten sind zu klein, um HashiCorp Vault zu rechtfertigen. Die Alternative: ein paar einfache Disziplinen bringen viel:

Logging und Audit

KI-Anwendungen erzeugen drei Log-Streams, die unterschiedlich behandelt werden müssen: HTTP-Access-Logs, Application-Logs (Entscheidungen, Fehler) und Prompt-Logs (Inputs und Outputs). Jeder ist auf andere Weise sensibel.

Image-Hygiene und Supply Chain

Das KI-Ökosystem bewegt sich schnell und zieht viel Code. Die Supply Chain ist die höchstrisikoreiche Fläche, die die meisten Teams ignorieren:

• Base-Images auf Patch-Tags pinnen. node:22-alpine3.21, nicht node:latest. Monatlicher Rebuild, der neue Patches einsammelt.
• Multi-Stage-Builds. Build-Tools (gcc, native Deps, npm mit devDependencies) leben in einer Builder-Stage. Der Runner ist ein minimales Layer mit nur dem Produktiv-Artefakt.
• Vulnerability-Scanner ausführen. Trivy oder Grype auf jedem gebauten Image, Build bei CRITICAL fehlschlagen lassen. HIGH wöchentlich triagen. Das Signal-zu-Rausch-Verhältnis bei KI-bezogenen CVEs ist schwach; Kontextentscheidungen sind nötig.
• Lockfiles sind Pflicht. npm ci, nicht npm install. poetry install --no-update, nicht pip install -r. Reproduzierbare Builds sind eine Sicherheitskontrolle.

Was ich nicht tue (und warum)

Ehrliche Liste — verbreitete Empfehlungen, die ich auf dieser Skala bewusst überspringe, mit Begründung:

Die Reihenfolge der Umsetzung

Wer einen selbst gehosteten KI-Stack neu aufzieht und die Sicherheitsarbeit sequenzieren muss, kann diese Reihenfolge nehmen — jeder Schritt ist eigenständig wertvoll und blockiert nicht den nächsten:

1. Netzwerk-Isolation: pro App ein Netzwerk, Ports an localhost gebunden, Host-Firewall Default Deny.
2. Container-Härtungs-Defaults auf jedem Service.
3. Non-Root-User und read-only-Dateisystem auf jedem App-Container.
4. Least-Privilege-Datenbank-User; Row-Level Security bei Multi-Tenant.
5. Secrets aus Images heraushalten; Variablen in Compose als Pflicht deklarieren.
6. Gepinnte Base-Images; Lockfile-only-Installs; Trivy in CI.
7. Correlation-IDs und begrenzte Log-Volumes.
8. Optional: Vault, Mesh, Runtime-EDR — nur wenn die Skala es rechtfertigt.

Fazit

KI-Sicherheit ist keine eigene Disziplin neben Infrastruktur-Sicherheit — es ist dieselbe Disziplin, angewendet auf einen Stack mit neuen Komponenten und ein paar neuen Fehlermodi. Wenn Container-, Netzwerk- und Datenbank-Hygiene stimmen, steht die KI-spezifische Arbeit — Prompt-Injection-Abwehr, RAG-Zugriffskontrolle, Output-Filterung — auf solidem Fundament. Wenn das Fundament schwach ist, kompensiert kein Guardrail-Prompting.

Verwandt: RAG-Pipelines gegen Prompt Injection absichern, produktive Docker-Patterns für KI-Anwendungen, und selbst gehostete KI vs. Cloud-APIs.