KI-Server-Sicherheit: So schützen Sie Ihre GPU-Infrastruktur

Warum KI-Server-Sicherheit eigene Regeln braucht

Klassische Server-Härtung ist die Grundlage, reicht bei KI-Infrastruktur aber nicht aus. Drei Eigenschaften machen GPU-Server zu einem lohnenden Ziel:

• Rechenleistung: Kompromittierte GPUs werden gern für Cryptomining oder fremde Trainingsjobs missbraucht. Das fällt oft erst über ungewöhnliche Auslastung oder steigende Stromaufnahme auf.
• Daten: Auf dem Server liegen Prompts, Dokumente für RAG-Systeme, Trainingsdaten und Logs – häufig mit personenbezogenen oder vertraulichen Inhalten.
• Modelle: Feinjustierte Modelle und LoRA-Adapter sind geistiges Eigentum, in dem Arbeit und Fachwissen stecken.

Hinzu kommt ein Software-Stack, der sich schnell bewegt: Inference-Server, Python-Abhängigkeiten, Container-Images und Modelldateien aus öffentlichen Quellen. Jede dieser Komponenten ist eine potenzielle Angriffsfläche.

Typische Angriffsvektoren

In der Praxis sehen wir immer wieder dieselben Schwachstellen:

• Offene Inference-APIs: Viele Inference-Server bringen keine eigene Authentifizierung mit oder haben sie standardmäßig deaktiviert. Wird ein solcher Port ins Internet geöffnet, kann jeder das Modell nutzen – auf Ihre Kosten und mit Einblick in Ihr System.
• Ungeschützte Notebooks und Dashboards: Jupyter, Grafana oder Admin-Oberflächen ohne Passwort ermöglichen im schlimmsten Fall direkte Codeausführung.
• SSH mit Passwort-Login: Brute-Force-Angriffe auf Port 22 laufen ununterbrochen.
• Veraltete Software: Ungepatchte Treiber, Kernel oder Bibliotheken mit bekannten Sicherheitslücken.
• Unsichere Lieferkette: Container-Images unklarer Herkunft oder Modelldateien in Formaten, die beim Laden Code ausführen können (etwa ältere Pickle-basierte Formate). Bevorzugen Sie Safetensors und vertrauenswürdige Quellen.
• Prompt Injection: Bei RAG- und Agenten-Systemen können manipulierte Dokumente das Modell zu unerwünschten Aktionen verleiten – besonders, wenn es Werkzeuge oder Datenzugriff hat.

Netzwerk-Sicherheit: so wenig Angriffsfläche wie möglich

Die wirksamste Maßnahme ist, Dienste gar nicht erst öffentlich erreichbar zu machen.

• Whitelist-Firewall: Standardmäßig alles blockieren, nur benötigte Ports für definierte Quellnetze freigeben.
• VPN statt offener Ports: Administrativer Zugriff über VPN oder ein Zero-Trust-Zugangsverfahren, SSH nicht direkt aus dem Internet.
• Trennung der Netze: Management-, Daten- und Anwendungsverkehr in getrennten Segmenten bzw. VLANs.
• Reverse Proxy mit TLS: Die Inference-API lauscht nur lokal; nach außen spricht ausschließlich ein Proxy oder Gateway mit TLS, Authentifizierung und Rate Limiting.
• DDoS-Schutz auf Netzwerkebene, damit öffentliche Endpunkte nicht einfach lahmgelegt werden.

Ein vorgeschaltetes Gateway ist bei LLM-Anwendungen ohnehin sinnvoll: Es bündelt Authentifizierung, Protokollierung und Richtlinien an einer Stelle. Wie das konkret aussieht, beschreiben wir auf der Seite zum Local LLM Secure Gateway.

Zugriffskontrolle und Identitäten

• SSH nur mit Schlüsseln, Passwort-Login und direkten Root-Login deaktivieren.
• Persönliche Accounts für jede Person – kein geteilter Root- oder Admin-Zugang, damit Aktionen nachvollziehbar bleiben.
• Multi-Faktor-Authentifizierung für alle Weboberflächen und das Management-Portal.
• Rollenbasierte Rechte (RBAC) in Kubernetes und in KI-Anwendungen: Wer darf Modelle deployen, wer nur Anfragen stellen?
• API-Schlüssel pro Anwendung mit Ablaufdatum und Rotation, niemals im Quellcode oder in Container-Images.
• Least Privilege für Container: keine privilegierten Container, keine unnötigen Host-Mounts.

Härtung von System und Software-Stack

Ein sauberer Grundzustand reduziert das Risiko erheblich:

• Automatische Sicherheitsupdates für das Betriebssystem, geplante Updates für GPU-Treiber und CUDA mit Test vor dem Rollout
• Minimalinstallation: nur Pakete und Dienste, die wirklich benötigt werden
• Schutz vor Brute-Force (z. B. fail2ban) und lokale Firewall als zweite Schicht
• Regelmäßige Schwachstellen-Scans für System und Container-Images
• Verschlüsselte Datenträger und verschlüsselte, getestete Backups
• Signierte bzw. per Prüfsumme verifizierte Images und Modelle

Wer Container einsetzt, findet weitere Hinweise im Beitrag Docker und Kubernetes für KI auf GPU-Servern.

Monitoring und Incident Response

Sicherheit ohne Sichtbarkeit bleibt Theorie. Ein GPU-Server sollte rund um die Uhr überwacht werden – mit Alarmen für Signale, die auf einen Angriff hindeuten:

Ebenso wichtig ist ein vorbereiteter Ablauf für den Ernstfall: Wer wird informiert, wie wird der Server isoliert, welche Logs werden gesichert, wie wird aus einem sauberen Backup wiederhergestellt? Details zur Überwachung finden Sie im Artikel Monitoring und Observability für KI-Workloads.

Datenschutz und Nachvollziehbarkeit

Sicherheit und DSGVO greifen ineinander. Prompts und Antworten können personenbezogene Daten enthalten – legen Sie deshalb fest, was protokolliert wird, wie lange und wer darauf zugreifen darf. Ein Audit-Trail dokumentiert, wer wann welche Anfrage gestellt hat, ohne mehr Daten als nötig zu speichern. Mehr dazu im Beitrag Audit-Trail für KI-Systeme.

Häufige Fehler

• Inference-Port „nur kurz zum Testen“ öffentlich freigegeben – und nie wieder geschlossen
• Ein gemeinsamer Admin-Account für das ganze Team
• Treiber-Updates aus Angst vor Inkompatibilität monatelang aufgeschoben
• Backups vorhanden, aber nie eine Wiederherstellung getestet
• Monitoring nur für CPU und RAM, nicht für GPU und API-Nutzung

So gehen wir bei Verdacloud vor

Unsere Managed KI-Server werden mit einer gehärteten Sicherheits-Baseline ausgeliefert: restriktive Firewall, Schlüssel-basierter Zugang, Schutz vor Brute-Force, regelmäßige Sicherheitsupdates, Schwachstellen-Scans, verschlüsselte Backups und laufendes Monitoring. Betrieben werden die Server in ISO-27001-zertifizierten Rechenzentren in Bayern und Sachsen, mit festem Ansprechpartner. Die Sicherheitsverantwortung für Ihre Anwendungen und Daten stimmen wir dabei klar mit Ihnen ab.