Ein Hardening-Baseline für selbst gehostete LLMs: Vom exponierten Endpoint zur Produktionsreife

In Sicherheit von Self-Hosted LLMs haben wir uns angesehen, warum On-Premise-KI nicht standardmäßig sicher ist — 175.000 im öffentlichen Internet erreichbare Inferenz-Server haben das besser belegt als jedes Argument. Dieser Artikel ist die praktische Fortsetzung: eine Baseline Schicht für Schicht, um ein Self-Hosted-Deployment von „läuft auf der GPU-Box" zu etwas zu bringen, das man in die Nähe von Produktionsdaten lassen würde.

Das mentale Modell ist einfach: ein Inferenz-Server ist ein produktiver Netzwerkdienst. Alles, was man bereits für eine Datenbank tut, gilt auch hier — plus ein paar KI-spezifische Schichten, die die meisten Teams auslassen.

Schicht 1: Netzwerk — nichts lauscht im Internet

Der häufigste Fehler ist auch der günstigste, um ihn zu beheben. Ollama, vLLM und ähnliche Engines werden ohne Authentifizierung ausgeliefert; ihr einziger echter Schutz besteht darin, nicht erreichbar zu sein.

• Binde die Engine an localhost oder ein privates Interface — niemals an 0.0.0.0 auf einer öffentlich erreichbaren Maschine. Bei Ollama bedeutet das, OLLAMA_HOST auf dem Standardwert 127.0.0.1:11434 zu belassen und der Versuchung des „Quick Fix", der es öffnet, zu widerstehen.
• Blockiere den Inferenz-Port (standardmäßig 11434 bei Ollama, 8000 bei vLLM) auf Firewall- und Cloud-Security-Group-Ebene. Öffne ihn nur für deinen Reverse Proxy oder ein bestimmtes vertrauenswürdiges Subnetz.
• Platziere jeden Consumer hinter einem authentifizierten Einstiegspunkt. Die leichtgewichtige Variante ist nginx oder Caddy, das API-Keys oder mTLS vor einer an localhost gebundenen Engine erzwingt:

server {
    listen 443 ssl;
    server_name llm.internal.example.com;

    location / {
        if ($http_authorization != "Bearer ${LLM_API_KEY}") {
            return 401;
        }
        proxy_pass http://127.0.0.1:11434;
    }
}

Die schwergewichtigere Variante — lohnenswert, sobald mehrere Teams sich das Deployment teilen — ist ein dedizierter LLM-Gateway, der Keys pro Consumer, Rate Limits, Budgets und Audit-Logs an einer Stelle bündelt.

• Segmentiere den KI-Stack in eine eigene Netzwerkzone mit expliziten Allow-Lists in beide Richtungen. Und entscheidend: filtere den Egress. Ein Inferenz-Worker braucht so gut wie nie ausgehenden Internetzugang. Default-Deny-Egress ist die günstigste Kontrolle, die man sowohl gegen Datenexfiltration als auch gegen vergiftete Modell-Callbacks hat — und macht aus vielen „kritischen" Schwachstellen Non-Events.

Schicht 2: Plattform — den Wirkungsradius eindämmen

GPU-Workloads verleiten Teams zu --privileged-Containern und Root-Prozessen. Das ist genau falsch herum: GPU-Treiber geben dieser Software bereits ungewöhnlich weitreichenden Zugriff auf den Host, also sollte der Container darum so eng wie möglich sein.

• Betreibe die Engine als Non-Root-User, entferne alle nicht benötigten Capabilities und mounte das Modellverzeichnis read-only. Gewähre GPU-Zugriff explizit (--gpus, Device Plugins) — niemals über Privileged Mode.
• Pinne die Versionen für den gesamten Stack: Engine, CUDA-Runtime, Treiber, Base Image. Reproduzierbare Deployments sind eine Sicherheitskontrolle, keine reine Ops-Annehmlichkeit.
• Patche nach Upstream-Releases, nicht nach CVE-Feeds. Der Fall Bleeding Llama (CVE-2026-7482) zeigte, dass ein Fix Monate vor der Existenz der CVE ausgeliefert wurde — wer auf Scanner-Alerts wartete, blieb die ganze Zeit verwundbar, mit grünen Dashboards. Abonniere die Release-Feeds deiner Engine und aktualisiere nach Zeitplan.
• Auf gemeinsam genutzter Infrastruktur gilt: Serving-Engines bündeln Nutzer über gemeinsam genutzten GPU-Speicher und KV-Caches. Wenn Tenants stark isoliert sein müssen, isoliere sie auf Instanzebene — separate Engine-Prozesse oder Nodes — nicht nur auf API-Ebene.

Schicht 3: Modell-Artefakte — verifiziere, was du lädst

Gewichte sind ausführbare Artefakte und verdienen dieselbe Supply-Chain-Behandlung wie Container-Images.

• Nur safetensors. Pickle-basierte Formate (.bin, .pt) können beim Laden Code ausführen; 2026 gibt es dafür keine produktive Rechtfertigung mehr.
• Pinne jedes Modell an einen kryptografischen Hash und verifiziere beim Deployment, genau wie einen Image-Digest. Beziehe Modelle aus offiziellen Publisher-Repositories, nicht aus Community-Re-Uploads, und verifiziere Signaturen, wo der Publisher sie bereitstellt.
• Behandle intern fine-getunte Modelle als Kronjuwelen des geistigen Eigentums: zugriffskontrollierter Speicher, Verschlüsselung im Ruhezustand, Audit-Logs bei jedem Zugriff. Wenn dein Modell auf proprietären Daten getunt wurde, ist das Modell die Daten.

Schicht 4: Anwendung — davon ausgehen, dass das Modell manipuliert wird

Alles oben Genannte sichert die Infrastruktur ab. Das Verhalten des Modells ist eine separate Angriffsfläche — die wir ausführlich in Prompt Injection behandelt haben — und die Baseline hier geht darum, zu begrenzen, was ein manipuliertes Modell anrichten kann:

• Least-Privilege-Tools: wo möglich read-only, keine Produktions-Credentials in Reichweite des Agenten.
• Modell-Output als nicht vertrauenswürdigen Input behandeln — validiert, bevor er eine Shell, SQL oder eine nachgelagerte API berührt.
• Sandboxed, egress-eingeschränkte Ausführung für jeden vom Modell generierten Code.
• Menschliche Bestätigung für irreversible Aktionen.
• Vollständiges Prompt- und Tool-Call-Logging in dein SIEM. Inferenz-Logs sind Sicherheits-Telemetrie: Injection-Versuche, Probing und anomale Tool-Nutzung sollten Alerts auslösen, nicht erst in einem Post-Incident-Review auftauchen.

Die Ein-Seiten-Checkliste

Netzwerk: Localhost-Binding · Firewalled Inferenz-Ports · authentifizierter Proxy oder Gateway · Segmentierung · Default-Deny-Egress. Plattform: Non-Root-Container · kein Privileged Mode · gepinnte Versionen · Release-basiertes Patchen · Tenant-Isolation auf Instanzebene. Artefakte: nur safetensors · hash-gepinnt · vertrauenswürdige Quellen · signiert, wo verfügbar · fine-getunte Gewichte als geschütztes IP. Anwendung: Least-Privilege-Tools · validierte Outputs · Sandboxed Execution · Human-in-the-Loop bei irreversiblen Aktionen · Inferenz-Telemetrie im SIEM.

Nichts davon erfordert exotisches Tooling — ein Reverse Proxy, eine Firewall, eine Container-Runtime und Disziplin decken das meiste davon ab. Der Abstand zwischen einer exponierten Ollama-Box und einem produktionsreifen Deployment lässt sich in Tagen Arbeit messen, nicht in Monaten. Was es braucht, ist die Entscheidung, KI-Infrastruktur als das zu behandeln, was sie tatsächlich ist: ein produktiver Dienst mit Zugriff auf deine sensibelsten Daten.

Bei NextVector bauen wir Backend-, Blockchain- und KI-Infrastruktur, bei der Sicherheit von Tag eins an eine Design-Vorgabe ist. Planst du ein On-Premise-LLM-Deployment? Kontaktiere uns.