Einen GPU-Server absichern: BMC, Firmware, NVIDIA-Treiber, Container Toolkit, Inferenz-APIs, Modelldateien und gemeinsam genutzte GPUs

Die Angriffsfläche, Ebene für Ebene

Ein GPU-Server fügt der üblichen Checkliste Ebenen hinzu, und zwei davon liegen unterhalb des Betriebssystems: Die CISA beschreibt Baseboard Management Controller als Komponenten, die „getrennt vom Betriebssystem (OS) und von der Firmware arbeiten, um Fernverwaltung und Fernsteuerung zu ermöglichen, selbst wenn das System heruntergefahren ist“. Versionen und Daten: Stand September 2026.

Unsere Zusammenfassung der folgenden Abschnitte; Quellen: Dokumentation und CVE-Einträge von CISA, AMI, NVIDIA, vLLM, Ollama, PyTorch und Hugging Face, abgerufen im September 2026.

BMC und Firmware

In einem technischen Blogbeitrag vom Juni 2025 warnt NVIDIA, dass kompromittierte BMCs „zu einer Plattform für Persistenz über alle Systeme hinweg werden, die sie kontrollieren“. Seine ersten Empfehlungen lauten: „Platzieren Sie BMC-Schnittstellen in isolierten Managementnetzen und machen Sie sie niemals aus dem Internet erreichbar“ und „Arbeiten Sie mit Ihren Herstellern zusammen, um sicherzustellen, dass die BMC-Firmware aktualisiert wird und CVEs verfolgt werden“. Außerdem rät NVIDIA, BMC-Ereignisse als Teil von Protokollierung und Erkennung zu behandeln.

Isolation ersetzt das Patchen nicht. CVE-2024-54085 in der BMC-Firmware MegaRAC SPx von AMI erlaubt es einem Angreifer, in den Worten des CVE-Eintrags, „die Authentifizierung aus der Ferne über das Redfish Host Interface zu umgehen“. AMI bewertet die Lücke nach CVSS-Version 4.0 mit 10,0, und AMIs Sicherheitshinweis vom 11. März 2025 nennt die SPx-Versionen, in denen sie behoben ist; die CISA hat sie am 25. Juni 2025 „auf Grundlage von Belegen für eine aktive Ausnutzung“ in ihren „Known Exploited Vulnerabilities Catalog“ aufgenommen. Fragen Sie Ihren Serverhersteller, welches BMC-Release die Korrektur enthält. IPMI bringt ein älteres Risiko mit: Die IPMI-Spezifikation in Version 2.0 selbst erlaubt es einem Angreifer aus der Ferne, vom BMC einen Passwort-Hash zu beschaffen, um das Passwort offline zu erraten (CVE-2013-4786). Wo Redfish, das über HTTPS läuft, Ihren Bedarf abdeckt, würden wir IPMI over LAN abschalten; jeder BMC braucht ein langes, individuelles Passwort.

Derselbe Sicherheitshinweis von AMI führt außerdem CVE-2024-54084 auf, eine BIOS-Lücke in AMIs Firmware Aptio V. Auch GPUs haben Firmware: Im Product Brief zur H200 NVL beschreibt NVIDIA, dass der CEC-Baustein der Karte „den Inhalt des GPU-Firmware-ROMs authentifiziert, bevor er der GPU erlaubt, von ihrem ROM zu booten“, mit Schutz vor Rollbacks und Widerruf von Schlüsseln, und die Produktseite der L40S sowie das Datenblatt der RTX PRO 6000 Server Edition führen Secure Boot auf. Notieren Sie für jede Karte den Eintrag VBIOS Version, den nvidia-smi -q ausgibt, und beziehen Sie GPU-Firmware nur vom Serverhersteller oder von NVIDIA.

Treiberfixes erscheinen je Zweig

NVIDIA veröffentlicht Sicherheitsbulletins auf seiner Seite „Product Security“, mit E-Mail-Benachrichtigungen für GPU-Produkte, sowie in seinem Repository product-security auf GitHub als Markdown, als maschinenlesbares CSAF und als CVE-Einträge. Die Seite kündigt an, dass NVIDIA PSIRT ab dem 1. Oktober 2026 „Sicherheitsbulletins nur noch auf GitHub in den Formaten Markdown, CSAF und CVE veröffentlichen wird“ und dass alle Bulletins parallel auf der Website „Product Security“ bleiben; abonnieren Sie beides.

NVIDIAs Lebenszyklustabelle sieht für einen Production Branch „vierteljährliche (oder bedarfsweise) Bugfix- und Sicherheits-Releases für 1 Jahr“ vor und für einen Long Term Support Branch dasselbe für 3 Jahre. CVE-2026-24187 zeigt die Folge: Ein Use-after-free-Fehler im Display-Treiber für Linux, veröffentlicht am 26. Mai 2026 und von NVIDIA mit 8,8 bewertet, ist in 595.71.05 auf R595, 580.159.03 auf R580 und 535.309.01 auf R535 behoben, einem Zweig, dessen Supportende NVIDIAs Tabelle mit Juni 2026 angibt. Ein Server erhält das Sicherheits-Release seines eigenen unterstützten Zweigs; unser Treiberleitfaden zeigt, wie man einen Zweig pinnt. Der CVE-Eintrag nennt außerdem vGPU-Gasttreiber und den vGPU Manager bis vGPU 20.0, vGPU 19.4 und vGPU 16.13, also brauchen sowohl der vGPU Manager auf dem Host als auch der Treiber in jedem Gast die Korrektur. Der Angriffsvektor ist lokal, und nach unserer Lesart kann das auch Code in einem Container einschließen, dem eine GPU zugewiesen ist, denn GPU-Container nutzen den Treiber des Hosts.

Das Container Toolkit und der GPU Operator

Das NVIDIA Container Toolkit läuft auf dem Host und richtet jeden GPU-Container beim Start ein; unter Kubernetes stellt der GPU Operator es standardmäßig bereit. Vier Lücken, zwei davon von NVIDIA mit 9,0 bewertet, zeigen, warum es auf seine Version ankommt.

Von NVIDIA veröffentlichte CVE-Einträge (cve.org und NVD), NVIDIAs GitHub-Advisory zu CVE-2024-0132 sowie die Release Notes des Container Toolkits (18. September 2026) und des GPU Operators (23. September 2026). 1.17.8 ist das erste Toolkit-Release außerhalb des Versionsbereichs, den die Einträge als betroffen führen, und GPU Operator 25.3.1 liefert es mit; die Release Notes des Operators nennen CVE-2025-23266 und CVE-2025-23267 erstmals in 25.3.2.

CDI schützte vor CVE-2024-0132 und CVE-2025-23359, nicht aber vor den Lücken in den Hooks, und drei der vier Beschreibungen nennen ein präpariertes Image als Angriffsweg. Beziehen Sie Images nur aus einer Registry, die Sie kontrollieren, pinnen Sie sie per Digest und beschränken Sie, wer GPU-Container starten darf; unter Kubernetes ist das jeder, der Pods auf GPU-Nodes anlegen darf. Prüfen Sie auch eine Voreinstellung: Das README des Device-Plugins, das die NVIDIA-Runtime als Standard-Runtime des Nodes voraussetzt, warnt, dass ein Pod, der keine GPU anfordert, „alle GPUs der Maschine“ bekommt. Seit v25.10.0 bindet der Operator GPUs standardmäßig über CDI ein und macht die Runtime-Klasse nvidia nicht mehr zum Standard-Handler, und die Releases seiner Version 26.7 enthalten Toolkit 1.20. Ein Upgrade über OLM unter OpenShift lässt cdi.enabled unverändert, und laut NVIDIAs Release Notes müssen GPU-Management-Container, die GPUs über NVIDIA_VISIBLE_DEVICES statt über das Device-Plugin erhalten, runtimeClassName: nvidia setzen: Lassen Sie diese Klasse nur für vertrauenswürdige Pods zu.

Inferenz-APIs und Notebooks

vLLM lauscht auf allen Schnittstellen, sofern --host nicht gesetzt ist, und seine Sicherheitsdokumentation zu Release 0.30.0 sagt, dass --api-key nur Endpunkte unter den Präfixen /v1, /v2, /inference und /cohere schützt. /invocations bietet dieselben Inferenzfunktionen ohne Schlüssel, und Endpunkte für den Betrieb wie /pause brauchen kein Token. Die Antwort der Dokumentation ist ein Reverse Proxy, der per Allowlist „nur die Endpunkte, die Sie Endnutzern zugänglich machen wollen“, freigibt, und eine Firewall, die nur den API-Port durchlässt; die Ports für torch.distributed und die Übertragung des KV-Caches sind vertrauenswürdigen Hosts vorbehalten, und der Verkehr zwischen Knoten ist „standardmäßig unsicher“. Setzen Sie VLLM_SERVER_DEV_MODE=1 niemals im Produktivbetrieb: Es fügt /collective_rpc hinzu, das die Dokumentation „extrem gefährlich“ nennt.

Ollama ist in der Voreinstellung sicherer: Es „bindet standardmäßig an 127.0.0.1, Port 11434“, und OLLAMA_HOST ändert das. Sein offizielles Container-Image setzt jedoch OLLAMA_HOST=0.0.0.0:11434, und Docker gibt einen Port, der wie in Ollamas Docker-Anleitung als -p 11434:11434 angegeben ist, standardmäßig auf allen Adressen des Hosts frei. Seine lokale API „erfordert keine Authentifizierung“; ein solcher Container oder ein Server, der mit dieser Einstellung geöffnet wurde, wie es eines von NVIDIAs DGX-Spark-Playbooks für den Fernzugriff tut, antwortet also jedem, der den Port erreichen kann. Jupyter Server schaltet die Token-Authentifizierung standardmäßig ein, und seine Dokumentation benennt, was auf dem Spiel steht: „Zugriff auf den Jupyter Server bedeutet Zugriff auf das Ausführen beliebigen Codes“. Unser Vergleich der Serving-Engines zeigt, auf welchen Adressen drei weitere Engines standardmäßig lauschen.

Für alle gilt: Binden Sie den Dienst an localhost oder eine interne Adresse und stellen Sie ein TLS-Gateway davor, das jedem Team oder jeder Anwendung einen eigenen Schlüssel gibt, Routen per Allowlist freigibt, Anfrageraten begrenzt und protokolliert, wer was gefragt hat. Prompts und Antworten können personenbezogene Daten enthalten, deshalb braucht dieses Protokoll eine eigene Zugriffskontrolle und eine eigene Aufbewahrungsfrist.

Modelldateien und Remote-Code

Eine Modelldatei kann ein Programm sein. Hugging Face warnt: „Es gibt gefährliche Angriffe mit Ausführung beliebigen Codes, die verübt werden können, wenn Sie eine pickle-Datei laden.“ Pickle ist das Format von Checkpoints wie pytorch_model.bin, und die Prüfung der pickle-Importe, die Hugging Face auf dem Hub vornimmt, „ist nicht zu 100 Prozent narrensicher“. Gegen dieses Risiko wurde safetensors entwickelt: Sein README fragt „Kann ich eine zufällig heruntergeladene Datei verwenden und erwarten, dass kein beliebiger Code ausgeführt wird?“, stuft safetensors als sicher ein und pickle als „unsicher, führt beliebigen Code aus“ und definiert die Datei als eine Header-Länge, einen JSON-Header und einen Byte-Puffer.

Für pickle-Checkpoints setzen Sie PyTorch 2.6 oder neuer ein. Seit Version 2.6 verwendet torch.load die Einstellung weights_only=True, sofern kein pickle-Modul übergeben wird; das beschränkt den Unpickler auf das, was State Dicts aus einfachen Tensoren und einigen primitiven Typen brauchen, und 2.6.0 hat CVE-2025-32434 behoben, eine Lücke zur Codeausführung aus der Ferne in torch.load mit weights_only=True in 2.5.1 und früher.

In Transformers führt trust_remote_code=True Modellcode aus, der aus dem Modell-Repository stammt und nicht aus der Bibliothek; die Dokumentation rät, von einer bestimmten Revision zu laden, einem Commit-Hash, „um zu vermeiden, Modellcode zu laden, der sich geändert haben könnte“. vLLM lässt --trust-remote-code standardmäßig ausgeschaltet und nimmt für dasselbe Pinning --revision und --code-revision entgegen. Außerdem setzt vLLM voraus, dass seine Cache-Verzeichnisse „privat und vertrauenswürdig“ sind; wer in sie schreiben kann, kann vLLM also dazu bringen, Code auszuführen: Nur das Dienstkonto sollte in VLLM_CACHE_ROOT und in die Modellablage schreiben.

Mehrere Mandanten auf einer GPU

MIG gibt jeder Instanz „separate und isolierte Pfade durch das gesamte Speichersystem“, und für den Mehrmandantenbetrieb stellt NVIDIA fest: „MIG stellt sicher, dass ein Client die Arbeit oder das Scheduling anderer Clients nicht beeinträchtigen kann“. Time-Slicing bietet nichts davon, denn „es gibt keine Speicher- oder Fehlerisolierung zwischen Replikaten“: Behandeln Sie Pods mit Time-Slicing als eine einzige Vertrauensdomäne. Unser Kubernetes-Leitfaden vergleicht die Methoden und die MIG-fähigen Karten.

MIG partitioniert die GPU, nicht den Treiber: Jeder Container nutzt weiterhin den Treiber des Hosts, in dem eine lokale Lücke wie CVE-2026-24187 steckt. Mandanten, die einander nicht vertrauen dürfen, gehören in getrennte virtuelle Maschinen mit einer GPU per Passthrough oder einer vGPU, hinter einen Gastkernel und einen Hypervisor. vLLM bringt einen subtileren Kanal mit: Mit dem standardmäßig aktiven Prefix Caching können Unterschiede in der Zeit bis zum ersten Token verraten, ob der zwischengespeicherte Prompt eines anderen Nutzers genauso begann. Seine Dokumentation empfiehlt, bei jeder Anfrage cache_salt zu setzen, „mit einem Geheimnis, das auf die Mandantengrenze zugeschnitten ist, die Sie durchsetzen wollen“.

Confidential Computing schützt Gewichte und Daten während der Verarbeitung vor dem Host selbst. NVIDIA führt es für die H200 NVL (Produktseite) und die RTX PRO 6000 Server Edition (Datenblatt, Dezember 2025) als unterstützt. Die GPU arbeitet dann mit einer vertraulichen virtuellen Maschine auf einer CPU mit AMD SEV-SNP oder Intel TDX zusammen, und in NVIDIAs Referenzarchitektur vom Juni 2026 werden Modellschlüssel nur gegen gültige Attestierungsnachweise freigegeben. Dieses Dokument lässt „anfälligen Inferenzcode innerhalb der CVM“, Seitenkanäle und physische Angriffe außerhalb seines Bedrohungsmodells und verweist für unterstützte Kombinationen auf NVIDIAs Kompatibilitätsmatrix, die sich nach GPU, VBIOS und Treiber durchsuchen lässt.

Netzsegmente und ausgehender Verkehr

Vier Segmente decken die meisten GPU-Server ab: Management für BMCs und Hypervisoren, Storage für Modelle, Datensätze und Backups, ein Cluster-Segment für den Verkehr zwischen Knoten und ein Service-Segment, in dem die Nutzer das Gateway erreichen und sonst nichts. Nur ein gehärteter Jump-Host sollte die BMCs erreichen.

Liegen die Gewichte lokal, braucht ein Inferenzserver keinen Internetzugang. Laden Sie Modelle über einen einzigen kontrollierten Weg in die Modellablage, stellen Sie sie aus einem lokalen Pfad bereit, den die Modelleinstellung von vLLM akzeptiert, und setzen Sie HF_HUB_OFFLINE=1, womit die von vLLM genutzte Client-Bibliothek von Hugging Face keine HTTP-Aufrufe an den Hub absetzt und nur zwischengespeicherte Dateien liest. Für multimodale Modelle begrenzt --allowed-media-domains in vLLM die Hosts, von denen es Medien abruft, als Schutz vor Server-Side Request Forgery, und seine Dokumentation ergänzt VLLM_MEDIA_URL_ALLOW_REDIRECTS=0, damit Weiterleitungen diese Liste nicht umgehen können. Zu Backups der Modellablage siehe Backup eines KI-Servers.

Netzwerksegmentierung, Zero-Trust-Zugriff mit Multi-Faktor-Authentifizierung und Privileged Access Management, EDR/XDR auf Servern und die Ereigniszentralisierung im SIEM sind Teil der unten beschriebenen Leistung Cyber-Resilienz.

Was wir liefern

Eurokommerz baut KI-Server nach Auftrag mit Out-of-Band-Management über IPMI und den BMC, installiert auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime und liefert sie mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung. Unser GPU-Sortiment umfasst die H200 NVL und die RTX PRO 6000 Server Edition, für die NVIDIA Confidential Computing angibt, sowie die L40S, die L4 und die RTX-PRO-Workstation-Karten. Unter demselben Vertrag liefert unser Engineering-Partner Vixen.UNO Cyber-Resilienz: ein segmentiertes Netzwerk mit Zero-Trust-Zugriff, Backups, die durch planmäßige Testwiederherstellungen geprüft werden, und einen Incident-Response-Plan mit Rollen, Maßnahmen und Fristen.

FAQ