Ein Praxisbeispiel für Netzwerksegmentierung wird dann relevant, wenn ein einzelner Netzwerkvorfall nicht nur Büroarbeitsplätze betrifft, sondern Produktion, Logistik oder kritische Services gefährdet. Genau diese Ausgangslage begegnet Unternehmen häufig nach Jahren des Wachstums: flache Netze, historisch gewachsene Ausnahmen, unklare Verantwortlichkeiten und Systeme, die aus betrieblichen Gründen nie abgeschaltet werden können.
Die technische Lösung ist selten das eigentliche Problem. VLANs, Firewalls, Network Access Control und zentrale Identitätsdienste sind verfügbar. Kritisch wird das Projekt dort, wo Produktionsanforderungen, Betriebsverantwortung, Security, externe Dienstleister und enge Wartungsfenster zusammenkommen. Netzwerksegmentierung ist deshalb kein reines Security-Upgrade, sondern ein Infrastruktur- und Transformationsprojekt mit direktem Business Impact.
Ausgangslage: Ein Produktionswerk mit flachem Netzwerk
Ein internationaler Maschinenbaukonzern modernisiert die Netzwerklandschaft eines Werks mit rund 900 Endpunkten. Das Netzwerk war über mehr als zehn Jahre erweitert worden. Office-IT, Engineering-Arbeitsplätze, Produktionsanlagen, Scanner in der Intralogistik, Drucker, Kameras und externe Wartungszugänge nutzten weitgehend gemeinsame Netzbereiche.
Das Risiko war sichtbar, aber bislang ohne spürbare Konsequenz geblieben. Ein kompromittierter Client hätte sich jedoch lateral zu Systemen bewegen können, die für Produktionsplanung, Materialfluss oder Maschinendaten relevant sind. Gleichzeitig bestand ein betriebliches Problem: Bei Störungen ließ sich kaum nachvollziehen, welche Systeme tatsächlich miteinander kommunizieren mussten. Jede kurzfristige Firewall-Regel hatte das Potenzial, einen Prozess auf dem Shopfloor zu beeinträchtigen.
Der Auslöser für das Projekt war kein erfolgreicher Angriff, sondern ein internes Audit. Es stellte drei wesentliche Schwachstellen fest: fehlende Trennung zwischen Office- und Produktionsumgebung, nicht dokumentierte Kommunikationsbeziehungen von Altanlagen sowie uneinheitliche Zugänge externer Servicepartner. Die Audit-Feststellungen mussten geschlossen werden, ohne den geplanten Produktionsausstoß zu gefährden.
Warum das Projekt nicht mit VLANs beginnt
Die naheliegende Reaktion wäre, neue VLANs anzulegen und Firewall-Regeln zu definieren. Das reduziert jedoch nur dann Risiken, wenn die Segmentierung die tatsächlichen Geschäfts- und Betriebsprozesse abbildet. Wer zuerst Technologie auswählt, produziert häufig neue Inseln, Sonderfreigaben und einen hohen manuellen Betriebsaufwand.
Im beschriebenen Werk wurde deshalb zunächst ein gemeinsames Zielbild erarbeitet. Die zentrale Frage lautete nicht: „Welche IP-Bereiche sollen getrennt werden?“ Sie lautete: „Welche Systeme benötigen aus welchem Grund welche Kommunikation – und wer verantwortet diese Freigabe?“
Daraus entstand eine Segmentierungslogik entlang von Schutzbedarf und Funktion. Office-IT, zentrale Infrastruktur, Engineering, Produktionszellen, Logistik, Gebäudetechnik und externe Zugänge wurden getrennt betrachtet. Besonders wichtig war die Abgrenzung der Produktionszellen: Nicht jede Anlage musste mit jedem Server oder jeder anderen Maschine erreichbar sein.
Die Bestandsaufnahme als kritischer Projektabschnitt
Für vier Wochen sammelte das Projektteam Daten aus Netzwerkmonitoring, Switch-Konfigurationen, Firewall-Logs, CMDB-Auszügen und Gesprächen mit Fachbereichen. Diese Kombination war notwendig, weil keine einzelne Quelle vollständig und verlässlich war. Die CMDB enthielt nicht alle Altgeräte, Logs erklärten nicht den fachlichen Zweck einer Verbindung, und die Produktion kannte zwar ihre Anlagen, aber nicht immer deren technische Abhängigkeiten.
Das Ergebnis war eine Kommunikationsmatrix. Sie dokumentierte Quelle, Ziel, Protokoll, Port, fachlichen Zweck, Systemverantwortung und Kritikalität. Damit wurde aus einer diffusen Sicherheitsanforderung ein prüfbarer Arbeitsbestand.
Gerade in Produktionsumgebungen zeigt sich hier ein entscheidender Unterschied zu klassischen Office-Migrationen: Eine scheinbar unnötige Verbindung kann für Fernwartung, Rezeptwechsel, Zeitserver oder Qualitätsdatenerfassung erforderlich sein. Wird sie ohne abgestimmten Test blockiert, entsteht kein Security-Gewinn, sondern ein Produktionsrisiko.
Das Praxisbeispiel für Netzwerksegmentierung in der Umsetzung
Das Programm wurde in klar abgegrenzte Wellen aufgeteilt. Ein Big-Bang-Ansatz wäre zwar auf dem Papier schneller gewesen, hätte aber im Werk ein nicht vertretbares Ausfallrisiko erzeugt. Die erste Welle umfasste nicht kritische Office-Netze und zentrale Verwaltungsservices. Danach folgten Logistikbereiche mit definierten Betriebsfenstern. Erst nach diesen Erkenntnissen wurden Engineering und Produktionszellen migriert.
Für jede Welle galt derselbe Ablauf: Kommunikationsbeziehungen prüfen, Regeln im Monitoring-Modus vorbereiten, Tests mit System- und Prozessverantwortlichen durchführen, Freigabe im Change Board einholen und die Segmentierung in einem vereinbarten Wartungsfenster aktivieren. Nach jeder Umstellung wurde die erhöhte Beobachtung fortgesetzt. Auffälligkeiten wurden nicht durch pauschale Freigaben gelöst, sondern anhand der Kommunikationsmatrix bewertet.
Vier Steuerungsmechanismen sorgten dafür, dass das Projekt beherrschbar blieb:
- Ein verbindlicher Owner je Applikation entschied über die fachliche Notwendigkeit von Verbindungen.
- Ein zentrales Regelwerk verhinderte, dass einzelne Teams lokale Firewall-Ausnahmen ohne Dokumentation einführten.
- Ein Go-/No-Go-Verfahren koppelte technische Tests an klar definierte Produktionskriterien.
- Ein tägliches Issue-Management während der Migrationsfenster beschleunigte Entscheidungen zwischen Netzwerk, Security, OT und Betrieb.
Diese Struktur war wichtiger als ein besonders komplexes Regelwerk. Netzwerksegmentierung scheitert selten daran, dass Teams keine Firewall bedienen können. Sie scheitert an ungeklärten Zuständigkeiten, nicht entscheidungsfähigen Gremien und Änderungen, deren betriebliche Wirkung niemand verbindlich bewertet.
Der Umgang mit Altanlagen und Ausnahmen
Nicht jede Anlage konnte kurzfristig die gewünschten Security-Vorgaben erfüllen. Einige ältere Steuerungen unterstützten keine moderne Authentifizierung. Bei anderen war der Herstellerzugang nur über fest definierte Protokolle möglich. Solche Systeme einfach auszutauschen, hätte Investitionen und längere Produktionsunterbrechungen erfordert.
Das Projekt entschied sich daher für kompensierende Maßnahmen. Altanlagen wurden in besonders restriktive Zonen verschoben, Zugänge ausschließlich über definierte Jump Hosts geführt und externe Wartungen zeitlich begrenzt protokolliert. Das ist kein Ersatz für eine langfristige Modernisierung. Es schafft aber eine nachvollziehbare Risikoreduzierung, bis ein Anlagenwechsel wirtschaftlich und betrieblich möglich ist.
Diese Abwägung ist für Entscheider zentral. Maximale Isolation kann die Verfügbarkeit beeinträchtigen und erhebliche Kosten verursachen. Zu viele Ausnahmen machen dagegen das Sicherheitsziel wirkungslos. Eine gute Projektleitung macht diese Zielkonflikte transparent, bewertet Optionen mit Security, Betrieb und Fachbereich und führt Entscheidungen in eine belastbare Roadmap über.
Messbare Ergebnisse nach der Migration
Nach sechs Monaten waren rund 85 Prozent der Endpunkte einer klaren Sicherheitszone zugeordnet. Der direkte Datenverkehr zwischen Office-Netz und Produktionsnetzen sank auf wenige, dokumentierte Kommunikationswege. Externe Dienstleister erhielten keine pauschalen Netzwerkzugänge mehr, sondern rollen- und zeitbezogene Zugriffe über kontrollierte Übergänge.
Mindestens ebenso relevant war der operative Effekt. Die IT konnte Störungen schneller eingrenzen, weil Abhängigkeiten und Verantwortlichkeiten sichtbar waren. Neue Maschinen oder Applikationen mussten nicht mehr über informelle Abstimmungen angebunden werden. Sie durchliefen einen definierten Onboarding-Prozess mit Architekturprüfung, Kommunikationsanforderungen und Freigabe.
Die Segmentierung reduzierte damit nicht nur die potenzielle Angriffsfläche. Sie verbesserte die Steuerbarkeit der Infrastruktur. Genau dieser Nutzen wird oft unterschätzt: Ein strukturiertes Netzwerk liefert die Grundlage für spätere Modernisierungen, etwa für MES-Integration, neue Shopfloor-Services, Standortrollouts oder die kontrollierte Anbindung von Cloud-Diensten.
Was Unternehmen aus diesem Beispiel ableiten sollten
Ein Projekt zur Netzwerksegmentierung braucht ein klares Mandat über Teamgrenzen hinweg. Wenn Security die Anforderungen formuliert, der Betrieb aber die Folgen allein tragen soll und die Fachbereiche erst im Wartungsfenster informiert werden, entstehen Verzögerungen und Widerstand. Die Verantwortung muss deshalb von Beginn an in einer gemeinsamen Governance verankert sein.
Ebenso wichtig ist eine realistische Ressourcenplanung. Neben Netzwerkarchitekten werden Security-Verantwortliche, OT-Spezialisten, Applikation Owner, Service Manager und gegebenenfalls Hersteller benötigt. In Konzernstrukturen kommt häufig die Abstimmung mit zentralen Architektur- und Compliance-Vorgaben hinzu. Ohne ein belastbares PMO, klare Entscheidungswege und ein konsequentes Abhängigkeitsmanagement wird aus einer technischen Migration schnell ein unsteuerbares Nebenprojekt.
Externe Projektleitung kann hier gezielt entlasten, wenn intern technische Expertise vorhanden ist, aber Koordination, Governance und Umsetzungskapazität fehlen. ITNB unterstützt Unternehmen in solchen Konstellationen mit einer strukturierten Projektsteuerung, die technische Risiken, Betriebsanforderungen und Management-Reporting in einem umsetzbaren Plan zusammenführt.
Der richtige erste Schritt ist daher nicht die Bestellung neuer Firewall-Kapazitäten. Er ist eine belastbare Sicht auf Systeme, Kommunikationswege, Risiken und Verantwortlichkeiten. Sobald diese Grundlage steht, wird Netzwerksegmentierung von einer schwer kalkulierbaren Eingriffsmaßnahme zu einem steuerbaren Infrastrukturprogramm.