Network segmentation: Grundlagen und Strategien 2026

Ein österreichischer Mittelständler betreibt ERP, Buchhaltung, Produktion und Bürokommunikation über Jahre gewachsene Netzwerke. Dann öffnet ein Mitarbeiter einen manipulierten PDF-Anhang. Die Schadsoftware startet auf dem Büro-Laptop, findet über die Domäne weitere Systeme und erreicht schliesslich SAP, Datenbanken und Backup-Ziele. Nicht der erste infizierte Rechner entscheidet über den Schaden, sondern die Frage, wie frei sich der Angreifer im Unternehmensnetz bewegen kann.

Genau dort setzt Network Segmentation an. Sie teilt ein Netzwerk in kontrollierte Bereiche und erzwingt Regeln zwischen diesen Bereichen. Für Finance- und IT-Leiter bedeutet das weniger unkontrollierte Abhängigkeiten, einen kleineren Angriffsradius und bessere Nachweise gegenüber Prüfern. Für Organisationen, die zusätzlich ERP-Connectoren, KI-Agenten oder Produktionssysteme anbinden, wird die Architekturfrage noch konkreter: Welche Systeme dürfen miteinander sprechen, unter welcher Identität und über welchen kontrollierten Übergang?

Inhaltsverzeichnis

• Warum Network Segmentation jetzt entscheidend ist
• Was Network Segmentation wirklich leistet
  • Drei Sicherheitswirkungen
• Segmentierungsstrategien im Vergleich
  • VLAN-Segmentierung
  • Zonale Segmentierung
  • Microsegmentation
• Mapping zu Compliance und Zero Trust
• Umsetzung in hybriden Unternehmensnetzen
  • Asset-Discovery
  • Zonen-Design
  • Pilot
  • Rollout
  • Betrieb
• Praxisbeispiele für ERP und Agent-Kommunikation
  • Übertragbare Architekturentscheidungen
• Wann zu viel Segmentierung schadet
• Entscheidungsleitfaden und Ausblick

Warum Network Segmentation jetzt entscheidend ist

Ein Ransomware-Vorfall startet oft auf einem einzelnen Endgerät. Der Schaden wächst, wenn dieses Gerät im selben Vertrauensbereich wie Domänencontroller, SAP-Applikationsserver, Finance-Datenbanken oder Backups liegt. Ein Perimeter schützt den Übergang zum Internet, verhindert aber nicht automatisch die Kommunikation zwischen bereits kompromittierten internen Systemen.

Für österreichische Unternehmen ist das Risiko konkret. Laut dem Länderbericht zur österreichischen Cybersecurity-Lage des U.S. Department of Commerce erlebten 14 % der österreichischen Unternehmen 2024 täglich Cyberangriffe. Das Bundeskriminalamt registrierte 74.800 gemeldete Cyberdelikte, ein Anstieg von 4,3 % gegenüber 2023. Gleichzeitig hatten nur 26 % der Unternehmen mit mehr als 50 Beschäftigten umfassende Cyber-Notfallpläne. Eine rein reaktive Sicherheitsstrategie reicht unter diesen Bedingungen nicht aus.

Praktische Regel: Plane nicht nur die Bereinigung eines kompromittierten Laptops. Lege fest, welche Systeme dieser Laptop niemals erreichen darf.

Auch die NIS2-Umsetzung in Österreich ab 1. Oktober 2026 konkretisiert diese Anforderungen. Der Entwurf des NISG 2024 wurde am 3. Juli 2024 im Nationalrat abgelehnt. Das ältere NISG 2018 erfasste zunächst nur rund 1.000 zuvor benannte Betreiber.

Für Finance- und IT-Leiter zählt vor allem die Architekturwirkung. ERP- und Finanzsysteme, Produktionsnetze sowie MCP- oder Agent-Konnektoren brauchen klar definierte Übergänge, eigene Zugriffsregeln und nachvollziehbare Identitäten. Segmentierung übersetzt diese Anforderungen in technische Grenzen, statt sie nur in Richtlinien zu dokumentieren.

Ein belastbarer Incident-Response-Prozess wird dadurch präziser. Teams erkennen, welche Zone betroffen ist, welche Verbindungen sie sperren können und welche Systeme für den Betrieb priorisiert bleiben.

Was Network Segmentation wirklich leistet

Stell dir das Unternehmensnetz als Haus vor. Im Erdgeschoss liegen Office-Arbeitsplätze, im abgeschlossenen Raum daneben Finance-Daten, im Technikbereich ERP und im hinteren Gebäudeteil Produktionssysteme. Entwicklung, Backup, Management und externe Dienstleister haben eigene Räume. Segmentierung bedeutet nicht, das ganze Haus zu versiegeln. Sie stattet jeden Raum mit einer eigenen Tür, einem Schloss und klaren Regeln für die Schlüssel aus.

Ein Office-Laptop darf beispielsweise einen bestimmten ERP-Service erreichen, aber nicht direkt die Datenbank, die Backup-Infrastruktur oder die Steuerung einer Produktionsanlage. Ein SAP-Applikationsserver darf seine Datenbank ansprechen, aber keine beliebigen Arbeitsplatzrechner. Ein Lieferant erhält nur Zugang zu einem definierten Drittzugangsbereich, nicht zum gesamten internen Netz.

Drei Sicherheitswirkungen

Erstens reduziert Segmentierung die Fläche für laterale Bewegung. Ein Angreifer, der ein System kompromittiert, muss zusätzliche Kontrollen überwinden, bevor er weitere Zonen erreicht. CISA beschreibt diese Wirkung ausdrücklich und nennt die Trennung von Geschäftsbereichen, IT-Ressourcen sowie OT und IT als Möglichkeit, den Einfluss eines Einbruchs zu begrenzen und die Ausbreitung bösartiger Akteure zu verhindern oder einzuschränken. Das zeigt der Ransomware Guide von CISA.

Zweitens verkleinert sie den Blast Radius. Bei Ransomware ist das besonders wichtig, weil infizierte Systeme sonst automatisch weitere Server, Domain Controller oder Backup-Ziele erreichen können. Eine Einordnung von Network Segmentation bei Ransomware beschreibt Segmentierung deshalb als Kontrollpunkt zwischen dem ersten Kompromiss und dem Ausfall kritischer Infrastruktur.

Drittens entstehen an Segmentgrenzen verwertbare Telemetrie und Entscheidungspunkte. Firewalls, Gateways, Host-Policies oder Identitätsproxies können zeigen, welcher Dienst mit welchem Ziel kommuniziert. Diese Sichtbarkeit hilft nicht nur bei der Prävention, sondern auch bei Analyse, Containment und Audit.

Segmentierung ersetzt aber weder Endpoint-Schutz noch Identity-Management. Ein infizierter Rechner bleibt ein Problem, und eine gestohlene Identität bleibt gefährlich. Die Netzdimension ergänzt jedoch beide Kontrollen. Ohne diese zusätzliche Grenze ähnelt die Sicherheitsarchitektur einem Konzertsaal ohne Brandmauern: Ein einzelner Brandherd kann sich ungebremst ausbreiten.

Die folgende Übersicht vertieft die Grundidee visuell:

Segmentierungsstrategien im Vergleich

Nicht jede Organisation braucht dieselbe Granularität. Ein mittelständisches Büro mit wenigen zentralen Anwendungen kann mit sauber geplanten VLANs beginnen. Ein Unternehmen mit SAP, OT, Cloud-Erweiterungen und externen Dienstleistern braucht meist funktionale Zonen. Microsegmentation kommt dort hinzu, wo selbst innerhalb einer Zone nur sehr bestimmte Workloads miteinander kommunizieren sollen.

VLAN-Segmentierung

VLANs teilen ein physisches Netzwerk logisch in getrennte Broadcast-Domänen. Das eignet sich für klassische Bürobereiche, Drucker, Gästezugänge oder grobe Servergruppen. Die Technik ist etabliert, verständlich und oft bereits in Switches und bestehenden Betriebsprozessen vorhanden.

Ein VLAN ist aber noch keine vollständige Sicherheitskontrolle. Erst Routing, Access Control Lists oder Firewalls erzwingen, was zwischen den VLANs erlaubt ist. Innerhalb eines VLANs kann weiterhin zu viel Kommunikation möglich sein. Für eine neue Cloud-Anwendung oder eine dynamische Agent-Architektur bildet ein statisches Subnetz ausserdem nicht automatisch die tatsächliche Identität eines Dienstes ab.

Zonale Segmentierung

Der zonale Ansatz gruppiert Systeme nach Funktion und Schutzbedarf. Typische Bereiche sind Office, ERP, Finance, Produktion, OT, Management, Backup, Monitoring, DMZ und Drittzugänge. Zwischen diesen Zonen wird ein definierter Traffic-Flow modelliert, idealerweise nach dem Prinzip „deny by default“.

Für österreichische Mittelständler ist das oft der praktikabelste Einstieg. SAP-Applikation und Datenbank können in getrennten Sicherheitszonen liegen, während die Produktionszone nur die wirklich erforderlichen Verbindungen zur ERP-Umgebung zulässt. Diese Struktur ist verständlicher als hunderte Einzelregeln und dennoch deutlich wirksamer als ein flaches internes Netz.

Microsegmentation

Microsegmentation setzt feiner an. Policies orientieren sich an Workloads, Anwendungen, Identitäten oder Tags. Host-Firewalls, Software-defined Networking, Security Groups, Service Meshes und identitätsbasierte Proxies können dabei die Durchsetzung übernehmen.

Der Vorteil ist die präzise Kontrolle, etwa wenn nur ein bestimmter SAP-Service eine Datenbank erreichen darf oder ein KI-Agent nur über einen freigegebenen Connector auf Finance-Daten zugreifen kann. Der Preis ist höherer Modellierungs-, Test- und Betriebsaufwand. Ohne verlässliche Asset- und Abhängigkeitsdaten entstehen schnell Regeln, die niemand mehr sicher erklären kann.

VLAN bleibt sinnvoll, aber es sollte nicht als Endzustand betrachtet werden. Ein zonaler Aufbau liefert häufig den besten Kompromiss. Microsegmentation lohnt sich dort, wo der zusätzliche Kontrollgewinn den Pflegeaufwand rechtfertigt.

Mapping zu Compliance und Zero Trust

NIS2 und das kommende österreichische NISG 2026 schreiben nicht einfach eine bestimmte Firewalltopologie vor. Sie erhöhen die Erwartung an Risikomanagement, Zugriffskontrolle, Meldewege und Betriebsresilienz. Die EU-Übersicht zur NIS2-Implementierung in Österreich verweist dabei auf das Bundesministerium für Inneres als nationale Kontaktstelle.

Für die Architektur folgt daraus eine wichtige Unterscheidung: Compliance verlangt nicht nur ein Dokument, sondern eine nachweisbare Kontrolle. Ein Netzwerkdiagramm kann eine Trennung darstellen. Erst eine technisch erzwungene Policy, ein protokollierter Übergang und ein getesteter Wiederanlauf zeigen, dass die Trennung tatsächlich funktioniert.

Zero Trust liefert dafür die Denkweise. „Never trust, always verify“ bedeutet praktisch, dass ein Gerät nicht allein wegen seines Standorts vertrauenswürdig ist. „Least privilege“ bedeutet, dass ein Benutzer, Dienst oder Agent nur die Kommunikation erhält, die er für seine Aufgabe benötigt. Segmentierung setzt diese Prinzipien in konkrete Kontrollpunkte um.

Ein Security-Governance-Framework sollte deshalb mit dem tatsächlichen Netzwerkmodell verknüpft sein. Wer Segmentierung nur als Diagramm führt, muss im Audit erklären, warum die Kommunikation technisch nicht anders möglich ist. Wer Regeln, Logs, Eigentümer und Testnachweise zusammenführt, kann diese Frage deutlich belastbarer beantworten.

Umsetzung in hybriden Unternehmensnetzen

Eine gute Einführung beginnt nicht mit neuen Firewalls. Sie beginnt mit der Frage, welche Systeme existieren, welche Abhängigkeiten sie haben und welche Geschäftsprozesse bei einer Sperre ausfallen würden.

Asset-Discovery

Erfasse Server, Endgeräte, virtuelle Maschinen, Container, OT-Komponenten, Cloud-Ressourcen, Drucker und Drittverbindungen. Werkzeuge wie CrowdStrike Falcon Discover oder Illumination können bei der Bestandsaufnahme unterstützen. Entscheidend ist nicht der Produktname, sondern die Qualität der Daten: Eigentümer, Zweck, Standort, Abhängigkeiten, kritische Prozesse und bekannte Ausnahmen müssen zusammengeführt werden.

Vergessene Legacy-Server sind ein häufiger Risikotreiber. Ein System kann technisch alt, geschäftlich aber unverzichtbar sein. Ohne diese Information blockiert eine neue Policy entweder den Betrieb oder bleibt so offen, dass sie kaum Schutzwirkung entfaltet.

Zonen-Design

Führe die Modellierung in Workshops mit Netzwerk, Serverbetrieb, Security, Finance, Produktion und den jeweiligen Applikationseigentümern durch. Beginne mit Geschäftsprozessen, nicht mit vorhandenen VLAN-Namen. Zeichne danach die benötigten Kommunikationsbeziehungen.

Ein realistisches Grundmodell kann Office, ERP, Finance, Produktion, OT, Management, Backup, Monitoring und Drittzugänge enthalten. Für hybride Netze kommen Cloud- und Partnerbereiche hinzu. SD-WAN verbindet Standorte, Azure VWAN kann ERP-Erweiterungen aufnehmen, und S2S-VPNs zu Lieferanten sollten in einen kontrollierten Drittzugangsbereich führen.

Pilot

Wähle eine überschaubare Zone mit hohem Nutzen und begrenztem Betriebsrisiko. Ein ERP-Pilot kann den Traffic zunächst spiegeln und sichtbar machen, bevor Regeln durchgesetzt werden. Die Teams prüfen dabei nicht nur erlaubte Verbindungen, sondern auch Wartung, Backup, Monitoring, Notfallzugang und Abhängigkeiten zu Identitätsdiensten.

Betriebsregel: Eine Policy ist erst bereit, wenn der Normalbetrieb, ein Patch, ein Restore und ein Notfallzugang getestet wurden.

Rollout

Roll die Architektur gestaffelt aus, etwa nach Standort, Geschäftsbereich oder Applikationsgruppe. Jede Stufe braucht einen Rückfallplan, einen benannten Verantwortlichen und ein Kommunikationsfenster mit den betroffenen Teams. Regeln sollten nicht direkt in vielen Geräten manuell entstehen. Ein Infrastructure-as-Code-Ansatz erleichtert versionierte Änderungen, Reviews und reproduzierbare Konfigurationen.

Betrieb

Segmentierung ist ein lebendes System. Pflege ein CMDB-gestütztes Segmentregister mit Zonen, Eigentümern, Policies, Ausnahmen, Ablaufdaten und Teststatus. Netzwerkdiagramme gehören ebenso dazu wie technische Regeln. Sie erleichtern Audits und beschleunigen das Onboarding neuer Kolleginnen und Kollegen.

Achte auf typische Bruchstellen: Legacy-Systeme, unklare NAT-Pfade, Lieferantenzugänge und ein unkoordiniertes Service Mesh. Wenn jede Plattform eigene Policies verwaltet, braucht das Unternehmen einen gemeinsamen Änderungsprozess. Sonst entsteht nicht Sicherheit aus mehreren Schichten, sondern widersprüchliche Steuerung.

Praxisbeispiele für ERP und Agent-Kommunikation

Ein Maschinenbauzulieferer kann SAP S/4HANA nicht einfach wie einen weiteren Server behandeln. ERP, Produktion und Office verfolgen unterschiedliche Verfügbarkeits- und Schutzanforderungen. Ein sinnvolles Muster trennt das SAP-System vom restlichen Produktionsnetz und legt Datenbank- und Applikationsserver in eigene Sicherheitszonen.

Die zentrale Entscheidung lautet dabei nicht „SAP isolieren und fertig“. Die Architektur muss festlegen, welche Produktionssysteme Aufträge oder Statusdaten an SAP übergeben, welche administrativen Zugänge erlaubt sind und wie Monitoring, Backup und Notfallbetrieb funktionieren. Flat-Net-Bereiche werden schrittweise zurückgebaut. So bleibt der Produktionsprozess erreichbar, ohne dass jeder Produktionsrechner direkt auf Datenbank- oder Managementsysteme zugreifen kann.

Ein zweites Muster betrifft KI-Agenten, die über das Model Context Protocol mit ERP- und Finance-Datenquellen kommunizieren. Der Agent sollte nicht direkt im allgemeinen Anwendungsnetz stehen. Dedizierte Connector-Subnetze, eingeschränkter DNS-Egress, mTLS und kurzlebige Tokens schaffen getrennte Kontrollpunkte für diese Kommunikation.

Der entscheidende Unterschied zu einem gewöhnlichen API-Zugang liegt im Arbeitsmodell. Ein Agent kann mehrere Werkzeuge aufrufen, Daten aus verschiedenen Systemen kombinieren und Aktionen auslösen. Deshalb müssen Connector, Agent, Zielsystem und Identität getrennt betrachtet werden. Ein kompromittierter Agent darf nicht automatisch weitere Tools entdecken oder beliebige interne Ziele erreichen.

Übertragbare Architekturentscheidungen

• ERP-Zone: SAP-Applikation, Datenbank und relevante Integrationsdienste werden nach ihrer Funktion getrennt.
• Finance-Zone: Buchhaltung und sensible Finanzdaten erhalten klar begrenzte Zugriffe aus ERP, Reporting und autorisierten Benutzerpfaden.
• Connector-Zone: MCP- oder andere Agent-Konnektoren laufen in einem eigenen Bereich mit kontrolliertem Egress.
• Identitätsgrenze: Agenten verwenden eigene Identitäten und kurzlebige Berechtigungen, nicht persönliche Administratorkonten.
• Überwachung: Zugriffe werden an den Übergängen protokolliert und einem Prozess, Dienst oder Eigentümer zugeordnet.

Diese Muster sind keine fertigen Blaupausen. Sie zeigen, wie ein österreichischer Mittelständler NISG-2026-Anforderungen, ERP-Schutz und neue Agent-Kommunikation in einem gemeinsamen Architekturmodell behandelt, statt für jede Technologie eine isolierte Sonderlösung zu bauen.

Wann zu viel Segmentierung schadet

Mehr Zonen bedeuten nicht automatisch mehr Sicherheit. Jede zusätzliche Grenze erzeugt Regeln, Tests, Zuständigkeiten und mögliche Fehler. In einer produktionskritischen Umgebung kann eine zu restriktive Policy den Betrieb stärker gefährden als eine bewusst gröbere, sauber überwachte Zone.

Typische Warnzeichen sind fein granulierte Regeln, die bei jedem Patch manuell angepasst werden müssen, unklare Ausnahmen und ein SecOps-Team, das mehr Zeit mit Policy-Pflege als mit der Bewertung echter Risiken verbringt. Alarmmüdigkeit entsteht auch dann, wenn jede interne Verbindung als gleich kritisch behandelt wird.

ERP-Schnittstellen können ausfallen, wenn zu viele Übergänge, Hop-Limits oder Proxy-Schichten den Datenfluss unterbrechen. Noch kritischer ist ein blockierter Backup-Pfad, der erst beim Restore-Test auffällt. Auch ein LLM-Agent kann seinen Zweck verlieren, wenn der Connector zu SAP Finance zwar sicher isoliert, aber für den vorgesehenen Prozess nicht erreichbar ist.

Resilienztest: Prüfe jede kritische Segmentregel gegen Normalbetrieb, Patch, Backup, Restore, Monitoring und Notfallzugang.

Gegenmassnahmen beginnen mit Policy-Rationalisierung. Entferne redundante Regeln, gruppiere Beziehungen nach Geschäftsprozess und versehe Ausnahmen mit Eigentümer und Ablaufdatum. Automatisierte Regeltests sollten bekannte Kommunikationspfade prüfen, bevor Änderungen ausgerollt werden. Für OT empfiehlt sich ein passives Asset-Inventar und vorsichtige Durchsetzung, damit Schutzmassnahmen keine unvorhergesehenen Produktionsrisiken erzeugen.

Entscheidungsleitfaden und Ausblick

Die richtige Reihenfolge ist wichtiger als maximale Granularität. Zuerst müssen kritische Prozesse, Assets und Abhängigkeiten bekannt sein. Danach folgt ein zonaler Grundriss. Erst wenn die Übergänge stabil laufen und die Datenqualität stimmt, sollte Microsegmentation auf besonders sensible Workloads, Cloud-Dienste oder Agent-Konnektoren ausgeweitet werden.

Die nächste Herausforderung sind dynamische Ost-West-Verbindungen. MCP-Server, Agent-Konnektoren und automatisierte Workflows erzeugen Kommunikationspfade, die statische Netzwerkregeln nur unvollständig beschreiben. Der Reifegrad steigt, wenn Policies als Code versioniert werden, Identitäten statt Standorte die Zugriffsentscheidung bestimmen und jede Verbindung laufend verifiziert wird.

Eine aktuelle Erhebung zur Verbindung von Zero Trust und Microsegmentation zeigt die Lücke zwischen Priorität und Umsetzung: 90 % der befragten IT- und Security-Fachleute bewerteten Zero Trust als sehr oder extrem wichtig, fast 70 % hielten Microsegmentation für sehr wichtig oder essenziell, aber nur 5 % segmentierten ihre Netze bereits entsprechend. Die Erhebung zu Network Segmentation und Zero-Trust-Architekturen macht damit vor allem eines sichtbar: Der nächste Schritt ist kein neues Schlagwort, sondern ein kontrollierter Übergang von Absicht zu Betrieb.

Wenn du ERP-, Finance- und Agent-Konnektoren sicher in eine belastbare Segmentierungsarchitektur integrieren willst, unterstützt Specialty Tokens mit Architektur-Reviews, sicheren MCP-Integrationen, individuellen ERP-Connectoren und eingebetteten Engineering-Teams. Vereinbare den nächsten Schritt, um Asset-Discovery, Zonenmodell und einen realistisch testbaren Pilot für deine Organisation zu definieren.