Mikrosegmentierung nach NIS2 und PCI DSS: Was die Regeln verlangen und was Prüfer sehen wollen

Weder NIS2 noch die Segmentierungs-Guidance des PCI SSC verwenden den Begriff Mikrosegmentierung. NIS2 fordert angemessene und verhältnismäßige Sicherheitsmaßnahmen; für Cloud-, Rechenzentrums- und Managed-Service-Anbieter wird die Netzsegmentierung in einer Durchführungsverordnung konkretisiert. PCI DSS besagt, dass Segmentierung nicht zwingend erforderlich ist, aber ohne sie das gesamte Netzwerk in den Scope fällt. Jede Segmentierung, auf die Sie sich verlassen, muss per Penetrationstest geprüft werden. Der Prüfer will deshalb Ihre Zonen sehen, die erlaubten Flows zwischen ihnen und den Nachweis jeder Änderung an diesen Regeln. Dieser Nachweis entsteht im Firewall-Change-Management.

Dieser Leitfaden richtet sich an die Personen, die diese Fragen beantworten müssen: die Netzwerk- oder Sicherheitsverantwortlichen, die das Segmentierungsprogramm und das anschließende Audit steuern. Wie die Segmente technisch aufgebaut werden, von Zonenmodellen bis zum Regelvolumen, behandeln wir in unserem Leitfaden zur Implementierung der Firewall-Mikrosegmentierung. Hier betrachten wir die Anforderungen der beiden Frameworks und wie Sie Segmentierung so betreiben, dass die Nachweise vorliegen, wenn der Prüfer kommt.

Was fordert NIS2 zur Netzsegmentierung?

NIS2 fordert risikobasierte Maßnahmen, nicht explizit Segmentierung. Artikel 21 der Richtlinie (EU) 2022/2555 verpflichtet wesentliche und wichtige Einrichtungen, „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen“ zu ergreifen, und zwar „unter Berücksichtigung des Stands der Technik und gegebenenfalls der einschlägigen europäischen und internationalen Normen“. Die Liste in Artikel 21(2) umfasst unter anderem „Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme“ sowie „Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen“. Unserer Einschätzung nach ist Segmentierung ein gängiger Weg, diese Punkte umzusetzen, aber die Richtlinie überlässt das Verfahren Ihnen.

Die Details finden sich in der Durchführungsverordnung (EU) 2024/2690. Punkt 6.8 des Anhangs, „Netzsegmentierung“, verlangt, dass die Einrichtungen ihre Systeme „entsprechend den Ergebnissen der Risikobewertung gemäß Nummer 2.1 in Netze oder Zonen“ segmentieren und „den Zugang zu und die Kommunikation zwischen und innerhalb von Zonen auf diejenigen beschränken, die für den Betrieb der betreffenden Einrichtungen oder für die Sicherheit erforderlich sind“. Außerdem fordert der Anhang ein getrenntes Verwaltungsnetz, getrennte Netzverwaltungskanäle und Produktivsysteme, die von Entwicklungs- und Testsystemen einschließlich der Sicherung getrennt sind.

Lesen Sie den Anwendungsbereich, bevor Sie Punkt 6.8 zitieren. Artikel 1 beschränkt die Verordnung auf DNS-Anbieter, TLD-Register, Cloud-Computing-, Rechenzentrums- und Content-Delivery-Anbieter, Managed-Service- und Managed-Security-Service-Anbieter, Online-Marktplätze, Suchmaschinen, soziale Netzwerke und Vertrauensdiensteanbieter. Für einen Hersteller oder ein Krankenhaus ist Punkt 6.8 kein bindendes Recht. Unserer Einschätzung nach ist er trotzdem der beste Maßstab, denn er ist der einzige EU-Text, der in klaren Worten beschreibt, wie eine angemessene Segmentierung aussieht.

Was ändert sich in Deutschland?

Deutschland hat Artikel 21 als § 30 des BSI-Gesetzes (BSIG) in nationales Recht umgesetzt. Absatz 1 enthält einen Satz, der für jedes Segmentierungsprogramm zählt: „Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren.“ Nach § 30 Absatz 3 hat die EU-Durchführungsverordnung für die oben genannten Einrichtungsarten Vorrang.

Für alle anderen ist die praktische deutsche Referenz der IT-Grundschutz-Baustein NET.1.1 Netzarchitektur und -design des BSI. Er fordert mindestens drei physisch getrennte Zonen (internes Netz, DMZ und Außenanbindungen) mit Firewalls an den Zonenübergängen, getrennte Netzsegmente für Clients und Server sowie eine Netzdokumentation, die „alle durchgeführten Änderungen im Netz“ enthält.

Was fordert PCI DSS zur Segmentierung?

PCI DSS schreibt Segmentierung nicht vor, bestraft aber deren Fehlen. Die Guidance on Scoping and Network Segmentation des PCI Security Standards Council (Mai 2017) stellt fest, dass die Isolierung der Cardholder Data Environment (CDE) keine PCI-DSS-Anforderung ist. Im nächsten Satz steht, dass ohne angemessene Segmentierung das gesamte Netz in den Scope des PCI-DSS-Assessments fällt. Segmentierung ist das Werkzeug, mit dem Sie Audit, Kosten und die Zahl der Systeme mit vollen PCI-Kontrollen verkleinern.

Wenn Sie Segmentierung zur Scope-Reduzierung einsetzen, ergeben sich drei Pflichten:

• Prüfung durch den Assessor: Laut derselben Guidance muss der Assessor prüfen, ob die Segmentierung ausreicht, um den Scope des Assessments zu verkleinern.
• Penetrationstests: Laut derselben Guidance müssen alle Segmentierungskontrollen mindestens jährlich per Penetrationstest geprüft werden. Für Service Provider verkürzt PCI DSS Requirement 11.4.6 das Intervall auf mindestens alle sechs Monate und nach jeder Änderung der Segmentierungsmethoden, so PCI SSC FAQ 1447 (Juni 2025).
• Jährliche Scope-Bestätigung: Mindestens einmal jährlich sollte die Einrichtung alle Standorte und Flows von Karteninhaberdaten sowie jedes mit der CDE verbundene System identifizieren und diese Dokumentation für den Assessor aufbewahren.

Die Firewall-Regeln selbst fallen unter PCI DSS Requirement 1, das wir Kontrolle für Kontrolle in unserem Leitfaden zu den PCI DSS Firewall-Anforderungen behandeln.

Welche Nachweise verlangen Prüfer?

Prüfer fragen bei beiden Regelwerken nach denselben vier Punkten: wo die Zonen liegen, warum es sie gibt, welche Flows erlaubt sind und ob Änderungen daran kontrolliert erfolgt sind. Die Tabelle ordnet die Anforderungen den entsprechenden Nachweisen im Firewall-Change-Management zu.

Quelle	Anforderung	Nachweis im Firewall-Change-Management
CIR 2024/2690, 6.8.1	Zonen folgen der Risikobewertung	Zonenmodell mit Bezug zum jeweiligen Eintrag der Risikobewertung
CIR 2024/2690, 6.8.2(e)	Nur notwendige Flows zwischen und innerhalb der Zonen	Zone-to-Zone-Flow-Matrix; jede Allow-Regel verknüpft mit einer genehmigten Anfrage und einem Business Owner
CIR 2024/2690, 6.8.2(f)(g)	Separates Administrationsnetzwerk und -kanäle	Regeln, die Management-Zugriffe nur aus der Admin-Zone erlauben; keine Ausnahmen ohne Ticket
CIR 2024/2690, 6.8.3	Überprüfung in geplanten Zeitabständen und nach wesentlichen Änderungen	Datierte Rezertifizierungen der Regeln und Reviews, die wesentliche Änderungen ausgelöst haben
BSIG § 30(1)	Einhaltung muss dokumentiert sein	Archivierte Change-Protokolle, Genehmigungen und Review-Ergebnisse
BSI NET.1.1.A2	Netzwerkdokumentation umfasst alle Änderungen	Change-Log, das mit der aktuellen Regelbasis abgeglichen wurde
PCI DSS Scoping Guidance	Segmentierung ausreichend zur Scope-Reduzierung	Regeln der CDE-Grenze, Scope-Dokumentation, jährliche Scope-Bestätigung
PCI DSS 11.4.6 (Service Provider)	Pen-Test alle sechs Monate und nach Segmentierungsänderungen	Als segmentierungsrelevant markierte Änderungen, jeweils verknüpft mit einem Re-Test

Nach unserer Erfahrung ist die letzte Zeile die häufigste Fehlerquelle. Ein Re-Test nach jeder Änderung der Segmentierungsmethoden findet nur statt, wenn der Change-Prozess weiß, welche Änderungen diese sind.

Warum ist Mikrosegmentierung ein Change-Programm und kein Projekt?

Mikrosegmentierung verwandelt einen einzelnen Perimeter in hunderte von Zonengrenzen. Jede Grenze besteht aus Firewall-Regeln, die sich ändern, solange sich die dahinterliegenden Applikationen ändern. Der initiale Rollout ist ein Projekt. Alles danach ist Change-Management: neue Applikationen, neue Flows, abgeschaltete Server, temporäre Ausnahmen, die wieder entfernt werden müssen.

Beide Frameworks verankern diese dauerhafte Pflicht. Punkt 6.8.3 der Durchführungsverordnung fordert eine Überprüfung „in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken“. Für Service Provider knüpft PCI den Re-Test an Änderungen der Segmentierung. Nach unserer Erfahrung stimmt ein Segmentierungsprogramm, das nicht im Change-Prozess verankert ist, genau am Tag des Audits, für das es gebaut wurde, und weicht ab dem nächsten Tag davon ab. Unser Beitrag zur Policy-Drift-Erkennung zeigt, wie Sie diese Abweichung erkennen.

Wie betreibt man Mikrosegmentierung als Change-Programm?

Gehen Sie in Phasen vor und lassen Sie jede Phase eigene Nachweise erzeugen. Die folgende Reihenfolge empfehlen wir für Umgebungen, die NIS2, PCI DSS oder beides erfüllen müssen.

Phase	Aktivität	Erzeugter Nachweis
1. Flows erfassen	Traffic-Logs sammeln oder neue Segment-Regeln im Monitor-Modus betreiben, um die tatsächliche Kommunikation zu sehen	Flow-Inventar mit Datum und Quelle
2. Zonen definieren	Zonen aus der Risikobewertung und dem Asset-Inventar ableiten; Owner pro Zone benennen	Zonenmodell mit Bezug zur Risikobewertung
3. Regeln entwerfen	Allowlist pro Zonenpaar, formuliert als Anfragen mit Owner, Zweck und (bei temporären Regeln) Ablaufdatum	Genehmigte Anfragen, Flow-Matrix
4. Gestuft erzwingen	Zonen einzeln von Monitor auf Block umschalten, inklusive getestetem Rollback	Change-Records mit Implementierungs- und Verifizierungsschritten
5. Änderungen taggen	Jede spätere Änderung an einer Zonengrenze als segmentierungsrelevant markieren	Filterbare Change-Historie
6. Testen	Penetrationstests der Segmentierung nach Zeitplan und nach getaggten Änderungen	Testberichte, verknüpft mit Change-IDs
7. Rezertifizieren	Owner bestätigen oder entfernen die Regeln in ihrer Zone in festen Intervallen	Unterzeichnete Rezertifizierungsergebnisse

Phase 5 kostet fast nichts, spart aber den meisten Aufwand beim Audit. Ein Feld im Change-Ticket („berührt Zonengrenze: ja/nein“) reicht aus, um die Liste der Änderungen für einen PCI-Re-Test (Service Provider) oder ein NIS2-Review zu erstellen. Phase 7 entspricht dem Prozess, den wir im Leitfaden zur Rezertifizierung von Firewall-Regeln beschreiben, angewandt auf die einzelnen Zonen.

Was will der Prüfer am Prüfungstag sehen?

Am Prüfungstag greift der Prüfer eine Regel heraus und verfolgt sie zurück: Welches Zonenpaar wird verbunden, wer hat sie angefordert, wer hat sie genehmigt, wann wurde sie implementiert, wurde sie verifiziert und wann hat der Owner sie zuletzt bestätigt? Wenn Sie dies für eine beliebige Regel innerhalb weniger Minuten beantworten können, sind die Nachweise in Ordnung. Unser Leitfaden zu NIS2-Firewall-Nachweisen listet den vollständigen Datensatz für Artikel 21 auf.

Welche Fehler zerstören die Segmentierungsnachweise?

Fehler bei den Nachweisen sind selten technischer Natur. Es sind Lücken zwischen dem realen Netzwerk und der Dokumentation. Diese fünf Fälle treten immer wieder auf:

• VLANs ohne Filterung: Ein VLAN trennt Broadcast-Domänen, nicht den Traffic. Wenn das Routing zwischen VLANs keine Firewall-Policy hat, existieren die Zonen nur auf dem Diagramm.
• Management-Pfade, die Zonen überbrücken: Ein Jump-Host oder Monitoring-Server, der jede Zone erreicht, macht die Segmentierung zunichte. NET.1.1 sagt es deutlich: Das Überbrücken von Netzsegmenten muss ausgeschlossen werden.
• Temporäre Regeln, die bleiben: Rollout-Wochenenden produzieren oft weite „temporäre“ Regeln. Ohne Ablaufdatum im Change-Record werden diese permanent.
• Nicht getaggte Änderungen: Wenn niemand auflisten kann, welche Änderungen seit dem letzten Test die CDE-Grenze berührt haben, kann der Re-Test für Service Provider nicht nachgewiesen werden.
• Einmalig erstellte Dokumentation: Ein Zonendiagramm aus dem Rollout-Projekt ist nur bis zur ersten Änderung aktuell. Gleichen Sie es bei jedem Review mit der Regelbasis ab.

Industrielle Netzwerke bringen zusätzliche Einschränkungen mit sich, wie Legacy-Protokolle und Wartungsfenster, die man in Jahren misst. Unser Beitrag zur OT/IT-Segmentierungsarchitektur behandelt diesen Fall separat.

Benötigen Sie einen Dienstleister für Mikrosegmentierung?

Externe Hilfe bei der Flow-Analyse und beim Tooling kann sinnvoll sein. Das Zonenmodell und die Change-Genehmigungen sollten unserer Einschätzung nach aber in Ihrem Team bleiben. Ein Dienstleister kann Flows schneller mappen und Erfahrung mit Plattformen einbringen. Er kann jedoch nicht entscheiden, welche Business-Flows notwendig sind. Genau diese Entscheidung müssen Sie unter NIS2 und PCI DSS begründen.

Wenn Sie einen Anbieter beauftragen, sollten drei Punkte im Vertrag stehen: Das Flow-Inventar und das Zonenmodell werden in einem für Sie wartbaren Format übergeben, jede erstellte Regel durchläuft Ihren Change-Prozess und die Übergabe umfasst den oben genannten Nachweissatz. Ein Zero-Trust-Programm wirft dieselbe Frage für die Änderungssteuerung insgesamt auf, wie wir in Zero Trust ersetzt Firewall Change Management nicht zeigen.

Nächster Schritt

Segmentierung ist nur so belastbar wie die Change-Protokolle dahinter. Prüfen Sie, ob Ihre Dokumentation standhält, wenn ein Auditor eine einzelne Regel bis zu ihrer Genehmigung zurückverfolgt. Der kostenlose NIS2 Readiness Check führt durch die Nachweise, die ein Firewall-Change-Prozess liefern muss, einschließlich jener, von denen ein Segmentierungsprogramm abhängt.