Während alle darüber streiten, welches Modell den besten Code schreibt, wächst still und leise neben jedem neuen KI-Rechenzentrum ein viel älteres und deutlich weniger glamouröses Problem: der Baseboard Management Controller oder BMC. Sicherheitsforscher präsentierten diese Woche Erkenntnisse, denen zufolge Tausende internetverbundene Server großer Hersteller über Schwachstellen in diesen Controllern aus der Ferne mit Backdoors versehen werden können – einige der Schwachstellen sind über ein Jahrzehnt alt. Das ist überhaupt keine Geschichte über KI. Es ist eine Geschichte über die Hardware, auf der KI läuft, und sie ist wissenswert, wenn du darüber nachdenkst, woher die nächste Welle von Sicherheitsjobs im Umfeld von KI kommen wird.

Was ein BMC tatsächlich ist und warum er beängstigend ist

Ein BMC ist ein kleiner, separater Computer, der auf praktisch jede Hauptplatine eines Unternehmensservers gelötet ist. Er verwendet sein eigenes Betriebssystem, seinen eigenen Netzwerk-Stack und hat seine eigene IP-Adresse – vollständig unabhängig davon, welches Betriebssystem und welche Anwendungen auf dem Hauptserver laufen. Administratoren verwenden BMCs für die sogenannte „Lights-out“- oder „Out-of-Band“-Verwaltung: einen Rechner neu starten, Firmware neu aufspielen, ein Betriebssystem neu installieren – alles aus der Ferne und, entscheidend, auch dann, wenn der Hauptserver ausgeschaltet ist oder überhaupt nicht mehr reagiert.

Genau das macht einen kompromittierten BMC auch so gefährlich. Ein Angreifer, der in einen solchen BMC gelangt, muss nicht darauf warten, dass das Host-Betriebssystem läuft, muss die darauf installierte Endpunktsicherheit nicht umgehen und kann sich über Neuinstallationen des Betriebssystems hinweg halten, da der BMC unterhalb und außerhalb der Schicht angesiedelt ist, die von gewöhnlichen IT-Sicherheitstools überwacht wird. Laut den diese Woche behandelten Forschungsergebnissen ist das am häufigsten betroffene Protokoll IPMI, und Sicherheitsforscher weisen seit mindestens 2013 auf diese Risikoklasse hin. Mit anderen Worten: Das ist kein neuer Fehler, sondern eine alte, bekannte und strukturell schwer zu behebende Fehlerkategorie, die die Branche seit deutlich mehr als einem Jahrzehnt toleriert.

Warum das jetzt wichtiger ist – und nicht weniger

Der KI-Ausbau ist physisch eine der größten Beschaffungswellen für Server in der Geschichte – Reihen um Reihen von GPU-Servern werden so schnell wie möglich in neue und erweiterte Rechenzentren gebracht. Jeder dieser Server wird mit einem BMC ausgeliefert, denn BMCs sind die Grundlage dafür, dass Rechenzentrumsbetreiber Flotten in großem Maßstab verwalten können; man kann nicht ein gebäudegroßes Lager betreten und zehntausend Rechner von Hand neu starten. Der KI-Boom kauft also nicht nur Rechenleistung – er kauft zwangsläufig eine gleich große Flotte kleiner, unzureichend überwachter Out-of-Band-Computer mit einer dokumentierten Geschichte kritischer Schwachstellen, die mehr als ein Jahrzehnt zurückreicht.

Das ist die technische Schuld: Das Ausbautempo ist darauf optimiert, GPUs in Racks zu montieren und Trainingsläufe zu starten, nicht darauf, die in jedes darunterliegende Mainboard integrierte Management-Firmware zu prüfen. Die Forscher hinter der Offenlegung dieser Woche bezeichneten BMCs Berichten zufolge als eine „allgegenwärtige, unzureichend überwachte und unzureichend gepatchte parallele Angriffsfläche“ – eine Beschreibung, die älter ist als der Boom bei KI-Rechenzentren, die aber genau durch diesen Boom die Zahl der derzeit produktiv eingesetzten BMCs vervielfacht.

Die Nische, die sich hier eröffnet

Wenn du abbildest, wohin sich Sicherheitskarrieren parallel zur KI-Infrastruktur entwickeln, sind die meisten offensichtlichen Bereiche – Red-Teaming von Modellen, Abwehr von Prompt-Injection-Angriffen, Governance für Agenten – bereits überlaufen und werden anderswo gut abgedeckt. Hardware- und Out-of-Band-Sicherheitsprüfungen sind es nicht. Es ist eine unspektakuläre, unsexy Ecke der Infrastruktursicherheit, die in KI-Keynotes nicht auftaucht, und genau darin liegt die Lücke: Die Nachfrage steigt mit jedem neuen Rechenzentrum, während das Angebot an Menschen, die Firmware- und Out-of-Band-Angriffsflächen verstehen, klein ist, weil dies tatsächlich ein anderes Kompetenzprofil als Anwendungs- oder Cloud-Sicherheit erfordert.

Wie die Arbeit konkret aussieht:

  • Kenntnisse von Firmware und Protokollen. IPMI und seine bekannten Schwachstellen – etwa die seit Langem veraltete Cipher-Suite 0, die bei manchen Geräten noch immer standardmäßig aktiviert ist – so gut verstehen, dass du beurteilen kannst, ob eine bestimmte Serverflotte tatsächlich exponiert ist, nicht nur theoretisch verwundbar.
  • Prüfungen der Netzwerksegmentierung. Überprüfen, ob BMC-/Management-Schnittstellen tatsächlich in einem dedizierten Managementnetz isoliert sind oder ob sie aus dem Produktionsnetz oder dem allgemeinen Internet erreichbar sind – eine grundlegende Maßnahme, die sich in der Praxis immer wieder als nicht umgesetzt erweist.
  • Prüfungen von Zugangsdaten und Patch-Hygiene. BMCs werden häufig mit Standard- oder vom Hersteller gesetzten Zugangsdaten sowie mit Firmware ausgeliefert, die nicht Teil des normalen Betriebssystem-Patchzyklus eines Rechenzentrums ist, weil sie nicht zum Betriebssystem gehört – dadurch kann sie leicht außerhalb des Zuständigkeitsbereichs derjenigen liegen, die für das „Patching“ verantwortlich sind.
  • Kenntnis von Herstellern und Lieferketten. BMC-Firmware wird üblicherweise von einer kleinen Zahl spezialisierter Anbieter geschrieben und an Serverhersteller lizenziert. Daher kann sich eine Schwachstelle im Code eines Anbieters gleichzeitig auf viele Hardwaremarken auswirken – genau dieses Muster zeigt die Offenlegung dieser Woche. Zu wissen, welcher Firmware-Stack unter welcher Servermarke steckt, gehört zur Arbeit.

Wie du dich dafür tatsächlich positionierst

Das ist ein wirkliches Nischenfeld, und es ist völlig berechtigt, skeptisch zu sein, wie viele eigene Stellen dafür entstehen werden, statt dass es eine Spezialisierung innerhalb bestehender Infrastruktur- oder Sicherheitsteams bleibt – sei dir ehrlich darüber im Klaren, dass „BMC-Sicherheitsprüfer“ letztlich eine Fähigkeit sein könnte, die du zu einer umfassenderen Rolle in der Hardware- oder Rechenzentrumssicherheit hinzufügst, statt eine eigenständige Berufsbezeichnung zu werden. Einige konkrete, überprüfbare Schritte sind jedoch unabhängig davon sinnvoll: Sammle praktische Erfahrung mit IPMI und Out-of-Band-Management-Tools, wenn du Zugang zu Unternehmensservern oder auch zu gebrauchter Hardware hast, mit der du ein Labor aufbauen kannst; lies die Sicherheitshinweise der Hersteller zur BMC-Firmware von großen Server- und BMC-Firmware-Anbietern, da sie reale Schwachstellen offenlegen, die du studieren kannst; und wenn du bereits in der Cloud- oder Infrastruktursicherheit tätig bist, stelle dem Rechenzentrums- oder Hardwarebeschaffungsteam deiner eigenen Organisation eine einfache, überprüfbare Frage – befindet sich unsere BMC-/IPMI-Managementebene in einem isolierten Netzwerk, und wer ist für ihre Aktualisierung zuständig? Wenn niemand eine sichere Antwort hat, ist das nicht nur ein Befund, sondern ein Beleg für genau die Expertise, die diese Nische braucht.