Management-Netz trennen: Redundante Architektur für den Notfall

Management-Netz trennen: Redundante Architektur für den Notfall

Ein Notfallzugang über dasselbe Netz, das er retten soll, ist keiner. Wer sein Management-Netzwerk trennen will, baut damit die Redundanz auf, die im Ernstfall den Unterschied macht zwischen einem Reset-Befehl aus der Ferne und einer nächtlichen Autofahrt ins Rechenzentrum.

Kurz beantwortet

Out-of-Band-Zugriff gehört auf ein eigenes VLAN oder ein physisch getrenntes Netz, niemals direkt erreichbar aus dem Internet. Der BSI-Baustein NET.1.1 verlangt Segmentierung, DMZ-Konzepte und redundante Komponenten, damit ein Ausfall des Produktivnetzes den Notfallzugang nicht mit sich reißt.

Management-Netzwerk trennen: was der BSI-Grundschutz verlangt

Der IT-Grundschutz-Baustein NET.1.1 zur Netzarchitektur und -design beschreibt, wie Netze strukturiert sein müssen, damit ein einzelner Fehler nicht die gesamte Infrastruktur mitreißt. Gefordert sind Segmentierung, ein durchdachtes DMZ-Konzept und redundante Komponenten an neuralgischen Punkten (BSI, IT-Grundschutz-Kompendium). Das Out-of-Band-Management gehört deshalb auf ein eigenes VLAN oder, wo der Aufwand vertretbar ist, auf ein physisch getrenntes Netz. Direkt ins Internet gehört ein BMC unter keinen Umständen, auch nicht hinter einer einzelnen Firewall-Regel.

Ein BMC, der aus dem Internet erreichbar ist, gehört zu den beliebtesten Zielen automatisierter Scans, weil viele Geräte im Feld mit Werkseinstellungen oder veralteter Firmware laufen. Wer einen BMC übernimmt, bekommt damit potenziell vollen Zugriff auf die Konsole, das Dateisystem über Virtual Media und die Stromversorgung des Servers, unabhängig vom Betriebssystem und dessen eigenen Schutzmaßnahmen. Die Trennung vom Produktivnetz wirkt als erste Verteidigungslinie, lange bevor eine Firewall-Regel oder ein Passwort überhaupt zum Tragen kommt.

IPMI over LAN bringt eine zusätzliche Altlast mit. Das Protokoll überträgt Zugangsdaten in älteren Implementierungen unverschlüsselt oder mit schwacher Verschlüsselung, weshalb es ausschließlich im isolierten Segment laufen sollte, nie über ein Netz, das auch für andere Zwecke offen ist. Redfish löst dieses Problem über TLS und eine moderne Authentifizierung, die die DMTF in der Spezifikation festschreibt (DMTF, Redfish-Spezifikation). Die Grundregel bleibt davon unberührt. Das Management-Netz ist getrennt, unabhängig vom verwendeten Protokoll.

NET.1.1

Der BSI-Baustein zur Netzarchitektur verlangt Segmentierung, ein DMZ-Konzept und redundante Komponenten an neuralgischen Punkten.

BSI, IT-Grundschutz-Kompendium

Adressplan, Sprungserver und Zwei-Faktor am Zugangspunkt

In der Praxis beginnt die Trennung mit einem eigenen Adressplan für das Management-Netzwerk, getrennt von den Bereichen für Produktiv-, Storage- und Backup-Verkehr. Jeder BMC bekommt eine feste Adresse in diesem Segment, dokumentiert in einer zentralen Liste statt verstreut über einzelne Konfigurationsdateien. Feste statt dynamisch zugewiesener Adressen erleichtern zusätzlich die spätere Fehlersuche, weil sich ein Alarm sofort einem bestimmten Server zuordnen lässt, ohne erst in einer DHCP-Historie nachschlagen zu müssen.

Der Zugang von außen läuft über einen einzelnen, gehärteten Sprungserver, auch Jump-Host genannt. Niemand verbindet sich direkt vom Arbeitsplatz aus mit einem BMC, jede Verbindung passiert diesen einen kontrollierten Punkt. Am Sprungserver selbst ist Zwei-Faktor-Authentifizierung Voraussetzung, weil ein kompromittiertes Passwort an dieser Stelle Zugriff auf die gesamte Serverflotte eröffnen würde. Jede Sitzung wird protokolliert: wer sich wann von wo verbunden hat und auf welchen BMC zugegriffen wurde. Diese Protokolle sind im Ernstfall oft die einzige verlässliche Quelle, um eine Störung zeitlich einzuordnen.

Für Administratoren, die von zu Hause oder unterwegs arbeiten, führt der Weg zum Sprungserver über ein eigenes VPN-Profil, getrennt vom VPN-Zugang für den restlichen Firmenbetrieb. Diese Trennung verhindert, dass ein kompromittiertes Standard-VPN automatisch auch den Weg ins Management-Netz öffnet.

Notfallzugang, wenn das Hauptnetz ausfällt

Redundanz beim Management-Netzwerk bedeutet mehr als eine zweite Netzwerkkarte im Server. Sie bedeutet einen zweiten, unabhängigen Weg zum Sprungserver, der nicht über dieselbe Leitung, denselben Router oder denselben Provider läuft wie das Produktivnetz. Fällt der Hauptuplink aus, etwa durch einen Bagger vor dem Gebäude oder einen Ausfall beim Provider, bleibt der Zugang zum Management-Netz über einen getrennten Uplink oder einen Mobilfunkrouter erhalten. Ohne diese zweite Anbindung sitzt der Administrator vor einem Netz, das genau dann nicht erreichbar ist, wenn er es am dringendsten braucht.

Diese zweite Anbindung muss nicht dieselbe Bandbreite liefern wie der reguläre Betrieb. Sie muss lediglich reichen, um eine Konsolensitzung offenzuhalten und Power-Befehle abzusetzen, wie sie der Beitrag Remote-Power-Management: hängende Server ohne Vor-Ort-Einsatz neu starten beschreibt. Ein LTE- oder 5G-Router mit eigener SIM-Karte reicht dafür in den meisten Fällen aus. Wichtig ist nur, dass dieser Router unabhängig vom Hauptrouter mit Strom versorgt wird, etwa über eine eigene kleine USV, sonst fällt er zusammen mit dem Rest der Infrastruktur aus.

VLAN oder physische Trennung: eine Kostenfrage

Ein VLAN trennt logisch, ein physisch getrenntes Netz trennt zusätzlich auf Kabel- und Portebene. Beides erfüllt die Grundanforderung der Segmentierung. Der Unterschied liegt im Restrisiko und im laufenden Aufwand.

VLAN und physische Trennung im Vergleich
Kriterium VLAN Physisch getrennt
Restrisiko Höher, abhängig von der Switch-Konfiguration Geringer, keine gemeinsame Hardware
Investition Gering, meist vorhandene Switches nutzbar Eigene Switches, Ports und Verkabelung
Laufender Aufwand Konfigurationspflege, Kontrolle der Regeln Zusätzliche Hardware im Betrieb
Typischer Einsatz Einzelner Standort, überschaubare Serverzahl Mehrere Mandanten, hohe Sicherheitsanforderung
GrenzeEin physisch getrenntes Netz kostet eigene Switch-Ports, zusätzliche Verkabelung und laufende Pflege. Für kleinere Umgebungen mit überschaubarer Serverzahl kann ein diszipliniert konfiguriertes VLAN mit strenger Zugriffskontrolle der angemessenere Kompromiss sein, solange die Segmentierung konsequent durchgesetzt wird und niemand aus Bequemlichkeit eine Ausnahme einrichtet.

Wo die Grenze zwischen beiden Varianten verläuft, hängt von der Risikobereitschaft und der Zahl der betroffenen Systeme ab. Eine Serverflotte mit mehreren Kunden oder Mandanten rechtfertigt in der Regel den höheren Aufwand der physischen Trennung. Ein einzelner Standort mit wenigen Servern kommt häufig mit einem strikt abgeschotteten VLAN aus, sofern die Switch-Konfiguration regelmäßig kontrolliert wird und nicht nur einmal beim Aufbau.

Redundanten Zugang zum Management-Netz einrichten
Ein Adressplan und ein Sprungserver beantworten noch nicht die Frage, was beim Ausfall des Hauptuplinks passiert. Ein zweiter, unabhängiger Weg zum Management-Netz gehört in jede Planung, die einen Netzausfall von vornherein einkalkuliert.

Kontakt aufnehmen

Häufige Fragen

VLAN oder physisch getrennt?

Beides erfüllt die Grundanforderung der Segmentierung nach BSI-Grundschutz. Ein physisch getrenntes Netz bietet das geringere Restrisiko, kostet aber eigene Ports, Verkabelung und Pflege. Für kleinere Umgebungen reicht ein konsequent abgeschottetes VLAN mit strenger Zugriffskontrolle häufig aus.

Wie kommt man ins Management-Netz, wenn das Hauptnetz ausfällt?

Über eine zweite, unabhängige Anbindung, die nicht denselben Uplink, Router oder Provider nutzt wie das Produktivnetz. In der Praxis funktioniert dafür ein separater Internetanschluss oder ein Mobilfunkrouter mit eigener SIM-Karte und eigener Stromversorgung. Ohne diese zweite Anbindung ist der Notfallzugang genau dann blockiert, wenn er gebraucht wird.

Gehört der Sprungserver ins Management-Netz?

Der Sprungserver sitzt am Übergang zwischen einem kontrollierten Zugangsnetz und dem Management-Netz, nicht mittendrin im selben Segment wie die BMCs. Diese Platzierung verhindert, dass ein kompromittierter Sprungserver direkten Zugriff auf alle BMCs im Netz hätte, ohne dass eine zusätzliche Zugriffsregel greift.

torck betreibt die eigene Infrastruktur in Maxhütte-Haidhof, Wien und Rabat über ein getrenntes Management-Netzwerk und kennt die Fallstricke aus erster Hand, etwa wenn eine Firewall-Regel den Sprungserver blockiert, statt ihn zu schützen. Die Entwicklungsteams arbeiten in einer gemeinsamen Zeitzone, die Projektleitung spricht Deutsch, Vertragspartner ist die deutsche torck GmbH. Diese Erfahrung fließt direkt in die Zugriffsverwaltung und die Protokollierung der eigenen Software ein, ohne dass Kunden die Netzarchitektur von Grund auf neu entwerfen müssen. Wer die eigene Architektur für den Notfall gegenprüfen lassen will, vereinbart dazu ein Erstgespräch über die Produktseite von KVM Fleet.

Gespräch vereinbaren

Frage zu diesem Beitrag?

Zwei Sätze zu Ihrer Situation genügen. Es antwortet jemand, der solche Systeme selbst baut.

Antwort innerhalb eines Werktags.torck · Code mit Drehmoment
Florian Blischke
Geschäftsführer torck GmbH · über 20 Jahre Softwareentwicklung
Florian Blischke ist Geschäftsführer der torck GmbH und seit über 20 Jahren in der Softwareentwicklung tätig. Er verantwortet Individualsoftware für Industrie und Handel, von der Anbindung physischer Prozesse über IoT bis zu Cloud-Architektur und daten- sowie KI-gestützten Systemen. Bei torck begleitet er unter anderem die Energieplattform Jouvoli und das Fleet-Management-Produkt KVM Fleet. torck entwickelt an den Standorten Maxhütte-Haidhof, Wien und Rabat und legt Wert auf Software, die im Betrieb tatsächlich funktioniert.

Steht bei Ihnen dieselbe Frage an?

Wir bauen seit 2017 Software für Industrie und Handel, von Maxhütte-Haidhof aus, mit Teams in Wien und Rabat. Ein Erstgespräch dauert 30 Minuten und kostet nichts. Danach wissen Sie, ob sich das Vorhaben lohnt, auch wenn die Antwort nein lautet.

Weitere Beiträge