Netzsegmentierung in der Praxis: Wie ich Arbeitsumgebung, Testlabor und lokale KI voneinander trenne

Was darf ein kompromittiertes System noch erreichen?

In meinem Lab laufen absichtlich verwundbare Anwendungen. Dazu kommen Windows- und Linux-Systeme, Active-Directory-Umgebungen und Webanwendungen, an denen ich Sicherheitstests durchführe. Dass eine Maschine dabei vollständig übernommen wird, kann zum vorgesehenen Ablauf gehören.

Meine Arbeitsumgebung soll dadurch aber nicht ebenfalls zum Übungsziel werden.

Deshalb betreibe ich Arbeitsumgebung, Management, Lab, lokale KI und Storage in getrennten VLAN-Bereichen. Den grundlegenden Aufbau habe ich bereits in meinem LinkedIn-Beitrag vorgestellt. Dahinter steht eine Frage, die für meine Arbeit wichtiger ist als die Anzahl der eingerichteten Netze:

Was darf eine Maschine noch erreichen, wenn sie kompromittiert wurde?

Für einen Auftraggeber ist das durchaus relevant. Bei einem Pentest können interne Dokumentationen, Testzugänge, Quellcode oder Informationen über noch nicht behobene Schwachstellen zusammenkommen. Wer solche Einblicke gewährt, darf auch nach der Arbeitsumgebung des Dienstleisters fragen.

Mit „Ich habe eine Firewall“ wäre diese Frage aus meiner Sicht nicht ausreichend beantwortet. Interessant wird es bei den Grenzen zwischen den Systemen, den verbleibenden Zugriffsrechten und den Ausnahmen, die für die tägliche Arbeit erforderlich sind.

Warum ich nach Aufgaben und Risiken trenne

Eine geschäftliche Arbeitsumgebung hat andere Anforderungen als ein Sicherheitstestlabor. Im Lab möchte ich Verhalten nachvollziehen, Konfigurationen verändern und Systeme auch einmal in einen unsicheren Zustand versetzen. In der Arbeitsumgebung brauche ich dagegen verlässliche Abläufe.

Die lokale KI bringt wiederum eigene Fragestellungen mit: Welche Informationen werden verarbeitet? Welche Werkzeuge stehen einem Agenten zur Verfügung? Darf die Umgebung selbst Verbindungen nach außen aufbauen?

Ich unterscheide deshalb folgende Bereiche:

Die Zuordnung richtet sich nach dem Zweck der Systeme. Dass zwei Maschinen dasselbe Betriebssystem verwenden, ist für mich kein überzeugender Grund, ihnen dieselbe Netzumgebung und dieselben Zugriffsmöglichkeiten zu geben.

Bei einer Testmaschine muss ich mit einer erfolgreichen Kompromittierung rechnen. Bei einem Managementzugang muss ich berücksichtigen, wie weitreichend die darüber möglichen Änderungen sind. Bei einem Speicherdienst steht dagegen im Vordergrund, welche Informationen erreichbar sind und mit welchen Rechten darauf zugegriffen werden kann.

Die Trennung schafft die Voraussetzung, diese Unterschiede technisch abzubilden. Sie ersetzt allerdings nicht die Entscheidungen darüber, welche Verbindungen zwischen den Bereichen zulässig sein sollen.

Was die VLAN-Trennung tatsächlich leistet

Ein VLAN bildet ein logisch getrenntes Netz auf der Sicherungsschicht, also auf Layer 2. Dadurch lassen sich Geräte voneinander trennen, obwohl sie beispielsweise an demselben physischen Switch angeschlossen sind. Sollen sie über die VLAN-Grenze hinweg kommunizieren, braucht es im üblichen gerouteten Aufbau einen Übergang zwischen den Netzen. Dort können Firewall-Regeln den Verkehr kontrollieren.¹

Die VLAN-Nummer selbst entscheidet jedoch nicht, ob ein Zugriff fachlich erforderlich ist. Wenn anschließend großzügig alle Verbindungen zwischen den Netzen erlaubt werden, bleibt vom Sicherheitsgewinn wenig übrig.

Mein Maßstab für solche Übergänge ist deshalb: Eine Verbindung braucht einen konkreten Zweck. Daraus müssen sich Quelle, Ziel, Dienst und gegebenenfalls die Dauer einer Freigabe ableiten lassen. Das zugrunde liegende Prinzip heißt Default Deny: Ohne passende Freigabe wird eine Verbindung nicht zugelassen. Eine solche Beschränkung betrifft sowohl eingehenden als auch ausgehenden Verkehr.²

Ein vereinfachtes Beispiel: Muss eine Anwendung einen bestimmten internen Dienst erreichen, wäre das zunächst eine Anforderung an genau diese Verbindung. Daraus folgt kein Bedarf, der Anwendung Zugriff auf das gesamte Zielnetz zu geben. Noch weniger folgt daraus, dass alle anderen Systeme ihres Quellnetzes dieselben Rechte benötigen.

Auch innerhalb eines VLANs bleibt Arbeit übrig. Geräte können dort normalerweise direkt miteinander kommunizieren, ohne dass der Verkehr den zentralen Router durchläuft. Eine Firewall zwischen den VLANs kontrolliert deshalb nicht automatisch jede Verbindung innerhalb eines Bereichs. Dafür sind je nach Schutzbedarf weitere Grenzen erforderlich, etwa am einzelnen System oder in der Anwendung.¹

Ein Lab-VLAN bedeutet also auch nicht, dass sich sämtliche darin betriebenen Versuche gegenseitig vertrauen sollten.

Eine erlaubte Verbindung ist keine Einbahnstraße

Bei der Planung von Netzregeln wird leicht übersehen, dass die Richtung des Verbindungsaufbaus nicht mit der Richtung des gesamten Datenflusses gleichzusetzen ist.

Angenommen, ein berechtigter Arbeitsplatz darf die Weboberfläche eines Dienstes in einem anderen Bereich aufrufen. Eine zustandsbehaftete Firewall merkt sich diese Verbindung und lässt die zugehörigen Antworten zurück. Der Dienst braucht dafür keine allgemeine Berechtigung, neue Verbindungen zum Arbeitsplatz aufzubauen.³

Damit ist aber noch nichts über die Vertrauenswürdigkeit seiner Antworten gesagt. Der Browser verarbeitet weiterhin Inhalte dieses Dienstes.

Für mich folgt daraus: Die Freigabe eines einzelnen Dienstes begrenzt die erreichbare Angriffsfläche. Sie macht den erlaubten Kommunikationsweg nicht automatisch ungefährlich. Die aufrufende Anwendung und der angebotene Dienst bleiben Teil der Sicherheitsbetrachtung.

Das ist auch für lokale KI wichtig. Ein System ohne freien Internetzugang kann über eine erlaubte Oberfläche weiterhin Informationen an einen berechtigten Nutzer ausgeben. Ob diese Informationen für diesen Nutzer bestimmt sind, muss die Anwendung entscheiden. Das lässt sich nicht allein über die Netzposition lösen.⁴

Genau deshalb spreche ich lieber über konkrete Zugriffe als über pauschal „vertrauenswürdige“ Netze.

Warum das Management einen eigenen Bereich bekommt

Die Verwaltungsebene meiner Infrastruktur ist vom Lab getrennt. Das hat einen anderen Grund als die Trennung zweier gewöhnlicher Anwendungen.

Ein Zugriff auf eine Testanwendung betrifft zunächst diese Anwendung und ihre Umgebung. Ein entsprechend berechtigter Zugriff auf einen Hypervisor kann dagegen Änderungen an mehreren virtuellen Maschinen, ihren Netzanschlüssen und ihren Ressourcen ermöglichen. Wer die Infrastruktur verwalten kann, verfügt damit potenziell auch über Möglichkeiten, ihre bisherigen Grenzen zu verändern.

In meinem Aufbau spielt Proxmox eine Rolle. Die Virtualisierung erlaubt mir, unterschiedliche Testumgebungen zu betreiben. Sie bedeutet aber auch, dass ich die darunterliegende Plattform als gemeinsamen Bestandteil der Sicherheitsarchitektur betrachten muss. Der Hypervisor ist unter anderem dafür verantwortlich, Ressourcen zu vermitteln und die Isolation zwischen virtuellen Maschinen aufrechtzuerhalten.⁵

Ein separates Management-VLAN ist dabei zunächst eine logische Trennung. Es wäre falsch, daraus eine vollständig unabhängige oder physisch isolierte Administrationsumgebung abzuleiten. Für den Schutz kommt es zusätzlich darauf an, von welchen Systemen die Verwaltungsdienste erreichbar sind und welche Berechtigungen dort gelten. Die Beschränkung administrativer Zugänge auf dafür vorgesehene Systeme und Netze ist entsprechend auch Bestandteil einschlägiger Härtungsempfehlungen.²

Dazu kommt die virtuelle Vernetzung. Ein Netzplan kann auf dem Papier sauber aussehen und trotzdem nicht mehr zur tatsächlichen Konfiguration passen. Eine zusätzliche virtuelle Netzwerkkarte oder eine anders zugeordnete virtuelle Bridge verändert möglicherweise die erreichbaren Wege. Die Betrachtung darf deshalb nicht am physischen Switch enden; virtuelle Netze und ihre Übergänge gehören dazu.⁶

Ich verstehe die VLAN-Trennung folglich als eine Schutzschicht. Sie hebt die Abhängigkeit von einer korrekt betriebenen Virtualisierungsplattform nicht auf.

Lokale KI bekommt keinen Sonderstatus

Meine lokal betriebenen KI-Modelle haben einen eigenen Netzbereich. Dass sie auf eigener Infrastruktur laufen, ist für mich kein Grund, ihnen mehr Vertrauen entgegenzubringen als anderen Anwendungen.

Der lokale Betrieb beantwortet zunächst die Frage, wo die Berechnung stattfindet. Welche Daten eine Anwendung erreichen kann und welche Aktionen sie ausführen darf, sind davon getrennte Entscheidungen.

Ausgehende Verbindungen bleiben eingeschränkt

In meinem aktuellen KI-Lab darf der Agent nicht frei nach außen kommunizieren. Der ausgehende Verkehr, häufig als Egress bezeichnet, ist strikt reguliert.

Für einen notwendigen externen Zugriff, beispielsweise für Updates, käme allenfalls ein gesondert begrenzter Weg über einen Proxy mit ausdrücklich freigegebenen Zielen infrage. Das ist keine allgemeine Internetfreigabe für den Agenten. Ein Bedarf an Softwareaktualisierungen rechtfertigt aus meiner Sicht nicht, einer laufenden Anwendung dauerhaft beliebige ausgehende Verbindungen zu erlauben.

Bei solchen Freigaben muss man allerdings präzise bleiben. „Nur bestimmte URLs“ ist technisch etwas anderes als „nur bestimmte Domains“. Ein Proxy, der eine HTTPS-Verbindung lediglich als Tunnel weiterleitet, kann daraus nicht ohne Weiteres den vollständigen angefragten URL-Pfad prüfen. Beim üblichen CONNECT-Verfahren wird zunächst ein Ziel aus Hostname und Port angegeben; die anschließende Verbindung kann Ende-zu-Ende verschlüsselt sein.⁷

Eine behauptete Beschränkung muss deshalb zu dem passen, was die eingesetzte Kontrolle tatsächlich erkennen und durchsetzen kann. Allein das Wort „Proxy“ sagt darüber noch wenig aus.

Für meine KI-Zone ist der Ausgangspunkt entsprechend restriktiv: Der Agent erhält keinen freien Kommunikationsweg ins Internet. Mögliche Ausnahmen müssen gesondert begründet werden.

Netzwerkzugriff und Agentenrechte sind zwei verschiedene Dinge

Unter meinem VLAN-Beitrag auf LinkedIn kam dazu ein berechtigter Einwand: Eine Netzgrenze entscheidet nicht darüber, was ein Agent innerhalb eines erreichbaren Dienstes tun darf.

Ein Beispiel macht den Unterschied deutlich. Hat ein Agent Zugriff auf einen Dokumentendienst, kann die Firewall die Verbindung zu diesem Dienst erlauben oder blockieren. Ob er dort ein Dokument nur lesen, überschreiben oder löschen darf, ergibt sich dagegen aus den bereitgestellten Funktionen und den Berechtigungen seiner technischen Identität.

Für eine unerwünschte Änderung an lokal erreichbaren Daten braucht es keinen Internetzugang.

Die Begrenzung muss daher auch bei den Werkzeugen und Zielsystemen ansetzen. Eine reine Leseaufgabe benötigt keine Löschfunktion. Die Entscheidung, ob eine Aktion erlaubt ist, darf nicht allein dem Sprachmodell überlassen werden. OWASP behandelt diese Kombination aus zu weitreichenden Funktionen, Berechtigungen und Autonomie unter dem Begriff Excessive Agency.⁸

Einen zusätzlichen Proxy, der jede einzelne Agentenaktion vor der Ausführung fachlich bewertet, betreibe ich in meinem aktuellen KI-Lab nicht. Für den derzeitigen Umfang halte ich eine solche zusätzliche Komponente für unnötigen Betriebsaufwand.

Daraus folgt aber keine Gleichsetzung von Netzsegmentierung und Aktionskontrolle. Ein eingeschränkter Netzbereich ersetzt keine Rechteprüfung in einem erreichbaren Dienst. Sollte sich der Einsatzzweck eines Agenten verändern, müsste auch die Bewertung seiner Zugriffsmöglichkeiten neu erfolgen.

Was die Trennung für Kundendaten bedeutet

Für Auftraggeber ist die interessante Frage letztlich nicht, wie viele VLANs vorhanden sind. Es geht darum, ob ein Experiment, eine Testmaschine oder ein zusätzliches Werkzeug Zugang zu Informationen erhält, die es für seine Aufgabe nicht benötigt.

Ein eigenes Storage-Netz beantwortet diese Frage nur teilweise. Es kann den Netzwerkzugang zu Speicherressourcen begrenzen. Welche Verzeichnisse oder Dokumente eine zugelassene Identität tatsächlich lesen darf, muss der jeweilige Dienst entscheiden.

Das lässt sich an einem einfachen Gegenbeispiel zeigen: Wäre ein Netzlaufwerk aus einem Testsystem erreichbar und mit umfassenden Schreibrechten eingebunden, würde das getrennte Storage-VLAN diese Rechte nicht zurücknehmen. Die Freigabe hätte den Zugriff bereits ermöglicht. Entsprechend reicht die Zugehörigkeit zu einem internen Netz auch nicht als Begründung für Vertrauen; Authentisierung und Autorisierung bleiben eigenständige Aufgaben.⁴

Für meine Arbeit ist deshalb wichtig, die Fragen nicht miteinander zu vermischen. Netztrennung, Projektberechtigungen und der Umgang mit Arbeitskopien hängen zusammen, sind aber unterschiedliche Maßnahmen.

Dass eine lokale KI vorhanden ist, beantwortet beispielsweise nicht, ob bestimmte Projektinformationen dort verarbeitet werden sollen. Ebenso sagt ein getrenntes Speichernetz nichts darüber aus, wie lange Unterlagen aufbewahrt werden oder wer nach Projektende noch darauf zugreifen darf.

Solche Punkte gehören für mich in die Auftragsklärung. Eine technische Beschreibung der Infrastruktur sollte diese Abstimmung unterstützen und nicht durch pauschale Sicherheitsversprechen ersetzen.

Warum ein Storage-VLAN noch kein Backup-Konzept ist

Auch die Wiederherstellbarkeit lässt sich nicht aus der Netzsegmentierung ableiten.

Ein Speichersystem in einem eigenen VLAN kann weiterhin über einen erlaubten Dienst oder mit gültigen Zugangsdaten erreichbar sein. Sind darüber auch Sicherungen veränderbar oder löschbar, schützt die Netztrennung allein diese Sicherungen nicht ausreichend.

Für ein Backup-Konzept sind deshalb zusätzliche Fragen zu beantworten: Welche Identität darf Sicherungen löschen? Welche Kopien bleiben bei einer Kompromittierung der Arbeitsumgebung unzugänglich? Und lässt sich aus diesen Kopien tatsächlich wiederherstellen? Die CISA empfiehlt unter anderem offline gehaltene, verschlüsselte Sicherungen und regelmäßige Wiederherstellungstests.⁹

Ähnlich verhält es sich mit Protokollen. Ein Firewall-Log kann zeigen, dass eine Verbindung zugelassen oder verworfen wurde. Was innerhalb einer erlaubten Anwendungssitzung passiert ist, benötigt gegebenenfalls zusätzliche Protokollierung auf Anwendungsebene. Auch deren Schutz und Auswertung sind eigenständige Aufgaben.⁹

Ich würde aus „Management und Storage sind getrennt“ deshalb weder eine vollständige Wiederherstellungsfähigkeit noch eine lückenlose Nachvollziehbarkeit aller Vorgänge ableiten.

Woran sich eine funktionierende Trennung messen lässt

Eine Netzarchitektur muss überprüfbare Erwartungen erzeugen. Die Aussage „Lab und Arbeitsumgebung sind getrennt“ ist dafür noch zu ungenau.

Eine konkrete Prüffrage wäre beispielsweise, ob eine Lab-Maschine einen Verwaltungsdienst erreichen kann, für den sie keine Freigabe erhalten soll. Eine andere wäre, ob ein berechtigter Arbeitsplatz den vorgesehenen Anwendungsdienst nutzen kann, ohne dadurch Zugriff auf weitere Dienste desselben Systems zu bekommen.

Dabei genügt ein fehlgeschlagener Verbindungsversuch nicht als Nachweis. Vielleicht läuft der Zieldienst gerade nicht. Vielleicht stimmt die Zieladresse nicht. Ein aussagekräftiger Test muss unterscheiden können, ob die vorgesehene Sicherheitskontrolle den Zugriff verhindert oder ob lediglich eine andere Voraussetzung fehlt.

Ebenso wichtig ist der Ausgangspunkt. Ein erfolgreicher Test aus der Arbeitsumgebung beschreibt nicht automatisch die Möglichkeiten einer Maschine im Lab. Weitere aktive Netzwerkpfade, etwa über eine zweite Netzwerkkarte oder IPv6, müssen in die Betrachtung einbezogen werden. Sonst wird nur ein Teil der tatsächlichen Erreichbarkeit geprüft.

Bei Änderungen an Firewall-Regeln sind außerdem bestehende Verbindungen zu berücksichtigen. Zustandsbehaftete Firewalls können bereits aufgebaute Sitzungen weiter behandeln, bis deren Zustände beendet oder entfernt werden. Eine neue Regel und eine noch laufende Verbindung müssen deshalb nicht sofort dasselbe Verhalten zeigen.³

Aus diesen Überlegungen ergibt sich für mich ein praktischer Maßstab: Die Trennung ist dann sinnvoll beschrieben, wenn sich für einen Zugriff erklären lässt, warum er möglich ist, wo seine Grenze liegt und wie sich diese Grenze überprüfen lässt. Die tatsächliche virtuelle Netzkonfiguration gehört dabei genauso zur Prüfung wie die vorgesehenen Firewall-Regeln.⁶

Was mir daran als Dienstleister wichtig ist

Ich betreibe ein Testlabor, weil ich technische Zusammenhänge selbst nachvollziehen und praktisch untersuchen möchte. Dazu gehören auch Umgebungen, die bewusst nicht sicher konfiguriert sind. Die Trennung von Arbeitsumgebung, Management, Lab, KI und Storage trägt diesem unterschiedlichen Umgang mit Risiken Rechnung.

Sie ist keine Zusage, dass in meiner Infrastruktur niemals eine Schwachstelle oder ein Konfigurationsfehler auftreten kann. Ihr Zweck ist, Abhängigkeiten zu begrenzen und den möglichen Folgen eines Fehlers nicht unnötig Raum zu geben.

Für einen Auftraggeber halte ich genau diese Unterscheidung für wichtig. Die eigene Arbeitsweise sollte sich erklären lassen, einschließlich ihrer Grenzen. Dazu gehört auch, offen zu benennen, welche Frage eine Maßnahme beantwortet und welche nicht.

Wer mir Einblick in seine Anwendung gibt, darf deshalb nach dem Umgang mit diesen Informationen fragen. Die technische Arbeitsumgebung gehört für mich genauso in dieses Gespräch wie der Testumfang, die benötigten Zugänge und die spätere Übergabe der Ergebnisse.

Technische Referenzen