Security Domains: Segmentierung nach Services, Kunden und Betriebsrollen

Security Domains sind im Telco- und Provider-Umfeld das Fundament, um Services, Kunden und Betriebsrollen sicher und zugleich skalierbar zu betreiben. In vielen Netzen wird „Segmentierung“ noch immer als nachträgliche Firewall-Regel verstanden. In der Praxis ist Segmentierung jedoch eine Topologie- und Governance-Entscheidung: Welche Systeme dürfen prinzipiell miteinander sprechen? Wo liegen die Trust Boundaries? Welche Failure Domains entstehen, wenn ein Segment kompromittiert wird? Und wie verhindern Sie, dass Wachstum zu Policy-Wildwuchs führt? Gerade Provider-Netze haben eine besondere Herausforderung: Sie betreiben nicht nur eine interne IT, sondern gleichzeitig eine Multi-Tenant-Serviceplattform. Das bedeutet, dass Segmentierung drei Achsen gleichzeitig abdecken muss: Services (z. B. Internet, L3VPN, EVPN, DDoS, DNS), Kunden (Mandantentrennung, Wholesale, Enterprise) und Betriebsrollen (NOC, Engineering, Security, Field Ops, Automatisierung). Ein professionelles Security-Domain-Design übersetzt diese Achsen in wiederholbare Blueprints: VRFs/VLANs/Overlays, Policies, Identity & Access, Jump-Zones, Control-Plane-Schutz und Observability. Ziel ist ein Netz, das „by design“ weniger Angriffsfläche bietet, Incidents lokalisiert, auditierbar bleibt und sich mit tausenden Services/Endpunkten betreiben lässt – ohne dass jede Änderung ein Risikoereignis wird.

Warum Segmentierung in Provider-Netzen anders gedacht werden muss

Provider-Netze sind nicht nur groß, sondern auch heterogen: Access, Metro, Core, PoPs, DCs, DCI, Peering, Service-Edges. Gleichzeitig existieren zahlreiche Produktlinien und Kundenprofile. Wenn Segmentierung hier nicht topologisch geplant ist, entstehen zwei Extreme: Entweder das Netz ist zu offen (hohes Risiko, große Blast Radius), oder es ist so restriktiv, dass Betrieb und Automatisierung ausweichen müssen (Shadow-IT, Workarounds, OPEX-Explosion). Security Domains sind der Mittelweg: klare Zonen mit klaren Regeln, in denen Wachstum durch Templates statt durch Einzelfallregeln erfolgt.

• Multi-Tenancy: Kunden müssen voneinander isoliert sein – auch bei gemeinsamen Transportpfaden.
• Service-Vielfalt: Unterschiedliche Services haben unterschiedliche Threat-Modelle und Verfügbarkeitsanforderungen.
• Rollen & Prozesse: Betrieb benötigt Zugriff, aber kontrolliert, identitätsbasiert und auditierbar.
• Failure Domains: Ein Incident darf nicht automatisch netzweit eskalieren.

Leitprinzip: Security Domains sind Trust Boundaries mit Betriebsvertrag

Jede Domain hat eine definierte Funktion, definierte erlaubte Kommunikationsbeziehungen und definierte Betriebsrollen. Dadurch wird Segmentierung nicht zu einem starren Verbot, sondern zu einem kontrollierten, dokumentierten Modell mit klaren Ausnahmen.

Die drei Achsen der Segmentierung: Services, Kunden, Betriebsrollen

In Telco-Designs ist es hilfreich, Segmentierung als dreidimensionales Modell zu betrachten. Wer nur nach Kunden segmentiert, vermischt häufig kritische Plattformdienste und Managementpfade. Wer nur nach Services segmentiert, übersieht Mandantenisolation. Wer nur nach Rollen segmentiert, vergisst die Service-Failure-Domains. Ein gutes Modell kombiniert alle drei Achsen.

• Service-Domänen: Trennung von Plattformdiensten (DNS, DDoS, Auth), Datentransport (Core), Kundendiensten (L3VPN/EVPN) und externen Kanten (Peering).
• Kunden-Domänen: Mandantentrennung über VRFs/EVPN/Policies; klare Regeln für Shared Services und Exits.
• Betriebsrollen-Domänen: NOC/Engineering/Security/Automation/Field Ops mit unterschiedlichen Privilegien und Zugriffspfaden.

Ein praktisches Modell: „Wer“ darf „was“ in „welcher“ Domain?

Segmentierung wird deutlich einfacher, wenn Sie sie als Policy-Frage formulieren: Identität (Rolle) + Zielzone (Domain) + erlaubter Zweck (Service) + erlaubte Protokolle. Dadurch wird aus „vielen ACLs“ ein konsistentes Policy-Framework.

Service-Domänen: Trennung nach Funktion und Risiko

Service-Domänen bilden die funktionale Struktur des Provider-Netzes ab. Sie verhindern, dass ein kompromittierter Dienst automatisch Zugriff auf andere Dienste oder auf Management erhält. Außerdem helfen sie bei Availability Engineering: Kritische Plattformdienste werden in eigene Domains gelegt, damit Wartungen und Incidents nicht zu Kaskaden führen.

• Core Transport Domain: Transport/Underlay, möglichst service-agnostisch, „langweilig“ und stabil.
• Service Edge Domain: PEs/Service-Edges, an denen Kunden- und Servicezustände terminieren.
• Platform Services Domain: DNS, NTP/PTP-Server, PKI/AAA, Monitoring/Telemetry, Logging/SIEM.
• Security Services Domain: DDoS-Mitigation, Scrubbing, Firewall/Inspection, Threat Intelligence Ingest.
• External Edge Domain: Peering/Transit/IX, Partner-Interconnects, Internet-Exits.

Designregel: Plattformdienste nie „mit Kundenverkehr“ mischen

DNS, PKI, AAA, Logging und Telemetry sind betriebs- und securitykritisch. Wenn diese Dienste in derselben Domain wie Kunden- oder Internetverkehr liegen, steigen Angriffsfläche und Incident-Risiko deutlich. Eine separate Platform Services Domain ist in Provider-Umgebungen ein starker Standard.

Kunden-Domänen: Multi-Tenant-Isolation ohne Variantenexplosion

Mandantentrennung ist das Herz eines Provider-Netzes. Die Herausforderung ist, Isolation zu garantieren und gleichzeitig Produkte skalierbar zu halten. Das gelingt, wenn Sie nicht jede Kundeninstanz als Sonderfall behandeln, sondern mit Serviceklassen-Templates arbeiten: Standard, Premium, Wholesale, Internet-onramp etc. Jede Klasse hat klare Policies und klare Exits.

• L3VPN/VRF: Klassische, saubere Isolation auf L3-Ebene; gut skalierbar, klar auditierbar.
• EVPN Multi-Tenant: L2/L3-Services mit kontrolliertem Control Plane; Scope-Regeln verhindern L2-Explosion.
• Shared Services: DNS/Proxy/Monitoring als definierte „Shared“ Domains, nicht als „irgendwo erreichbar“.
• Internet Exits: Klare Egress-Domänen, in denen NAT/Firewall/DDoS/Policy zentral und kontrolliert wirken.

VRF-Sprawl verhindern: Service-VRFs statt Customer-VRFs, wo möglich

Wenn jedes kleine Produktdetail eine neue VRF erzeugt, explodieren Control-Plane-State und Policies. Ein bewährter Ansatz ist: Service-VRFs pro Produktklasse und klare Regeln, wann wirklich eine Customer-VRF nötig ist. Das reduziert OPEX und senkt Risiko.

Betriebsrollen-Domänen: Zugriff sicher machen, ohne Betrieb zu blockieren

Telco-Betrieb erfordert Zugriff – aber nicht jeder Zugriff ist gleich. NOC benötigt Monitoring und standardisierte Aktionen, Engineering benötigt Change-Tools und tiefere Diagnostik, Security benötigt Forensikzugriff, Field Ops benötigt begrenzte, standortbezogene Zugriffe. Ohne Rollenmodell entstehen entweder zu breite Admin-Rechte oder Workarounds, die Security umgehen. Rollen-Domänen strukturieren genau das.

• NOC Domain: Beobachten, standardisierte Runbooks, begrenzte Schreibrechte, starke Audit-Spuren.
• Engineering Domain: Change-orientierte Zugriffe über kontrollierte Toolchains, versionierte Policies.
• Security Domain: SIEM/IR-Tooling, Threat Hunting, isolierte Forensikzugriffe.
• Automation Domain: Orchestrierung, Secrets, CI/CD für Network-as-Code; streng abgesichert.
• Field Ops Domain: Minimalzugriff, zeitlich begrenzt, geofenced oder standortbezogen, stark protokolliert.

Jump-Zones als verbindlicher Zugangspunkt

Die meisten Provider profitieren von einem klaren Muster: Admins greifen nicht direkt auf Geräte oder Management-VRFs zu, sondern über Jump-Zones/Bastions. Dadurch sind MFA, Session Recording, RBAC und Policy Enforcement zentral kontrollierbar, während das eigentliche Managementnetz minimal und geschlossen bleibt.

Topologische Umsetzung: VRFs, Zonen, Overlays und Kontrollkanten

Security Domains müssen technisch abgebildet werden. In Provider-Netzen geschieht das typischerweise durch eine Kombination aus VRFs (L3-Segmentierung), VLANs/Bridge Domains (L2-Segmentierung), EVPN/Overlays (skalierbare Mandantenfähigkeit) und klaren Kontrollkanten (Gateways/Firewalls/Policy Points). Entscheidend ist, dass die Abbildung wiederholbar ist.

• VRFs als Primärwerkzeug: Services und Rollen werden in VRFs modelliert, mit kontrollierten Route-Leaks.
• Policy Points: Zentral definierte Übergänge (Firewalls, Service Gateways, Inspection) statt „verteilter Wildwuchs“.
• Overlays gezielt: EVPN dort, wo L2 benötigt wird; L3-Grenzen als Default.
• Kontrollierte Leaks: Import/Export-Regeln sind Teil des Blueprints, nicht ad-hoc pro Kunde.

Ein sicheres Leak-Pattern: „Hub-and-Spoke“ für Shared Services

Viele Provider nutzen ein Hub-and-Spoke-Pattern: Kunden-VRFs (Spokes) dürfen definierte Shared Services (Hub) erreichen, aber nicht untereinander. So entstehen klare Security Domains mit minimalen Regeln, statt unzählige VRF-zu-VRF-Ausnahmen.

Policy-Design: Least Privilege, Guardrails und Ausnahmen als kontrollierte Events

Segmentierung scheitert selten an fehlender Technik, sondern an Policy-Disziplin. In großen Netzen ist die wichtigste Frage: Wie verhindern Sie, dass jede Ausnahme zur dauerhaften Regel wird? Der Schlüssel ist Policy-as-Code: versionierte Templates, Reviews, Tests, Wellen-Rollouts und klare Rollbacks. Zusätzlich braucht es Guardrails wie Max-Prefix, Rate-Limits und Control-Plane-Policing, damit Fehler oder Angriffe nicht netzweit wirken.

• Least Privilege: Nur die minimal notwendigen Verbindungen erlauben, pro Domain und Rolle.
• Guardrails: Max-Prefix, Limits, Rate-Limits, Quarantäne für flappende oder kompromittierte Segmente.
• Ausnahmen steuern: Owner, Begründung, Testplan, Rollback, idealerweise Ablaufdatum.
• Wellen-Rollouts: Änderungen in kleinen Schritten ausrollen, Blast Radius kontrollieren.

Warum „weniger Regeln“ oft sicherer ist

Ein überkomplexes Regelwerk ist schwer auditierbar und fehleranfällig. Besser ist ein klares Domain-Modell mit wenigen erlaubten Pfaden, die immer gleich funktionieren. Komplexität wandert dann in Templates und Tests – nicht in unübersichtliche Ausnahmelisten.

Security Domains und Control-Plane: Schutz der Netzsteuerung

In Provider-Netzen ist die Control Plane ein Hochwertziel. Segmentierung muss deshalb auch Control-Plane-Schutz einschließen: Managementzugriffe getrennt, Control-Plane-Traffic geschützt, Nachbarschaften kontrolliert, und kritische Dienste wie AAA/PKI/DNS/NTP redundant und isoliert. Ziel ist, dass ein Angriff oder eine Fehlkonfiguration nicht Routing-Stürme oder großflächige Serviceausfälle auslöst.

• Management-Isolation: Management-VRF/OOB getrennt von Kunden- und Internetverkehr.
• Control-Plane Policing: Schutz vor volumetrischen Ereignissen und Missbrauch von Routing-/Managementprotokollen.
• RR/IGP-Schutz: Routenhygiene, Filter, Limits, stabile RR-Topologie als Security- und Availability-Faktor.
• Timing/DNS/NTP: Plattformdienste als separate Domain, mit restriktiven Zugriffsregeln.

Security und Availability sind gekoppelt

Viele Security-Maßnahmen erhöhen Verfügbarkeit, weil sie Fehlverhalten begrenzen. Umgekehrt ist ein instabiles Netz schwer zu sichern, weil Betriebsteams zu Workarounds greifen. Ein gutes Domain-Design reduziert beides: Angriffsfläche und Betriebsdruck.

Observability und Auditability: Domains müssen überprüfbar sein

Segmentierung ist nur dann vertrauenswürdig, wenn Sie nachweisen können, dass sie wirkt. Dazu gehören Flow-Logs an Policy Points, Telemetry über erlaubte/gebrochene Pfade, Identity-Logs aus Jump-Zones und Change-Evidenz aus Policy-as-Code. In Telco-Umgebungen ist diese Nachweisbarkeit besonders wertvoll, weil mehrere Teams und oft auch regulatorische Anforderungen beteiligt sind.

• Flow Visibility: Logs/Telemetry an Gateways/Firewalls, die Domain-Übergänge kontrollieren.
• Identity Logs: Wer hat wann worauf zugegriffen (MFA, Session Recording, RBAC)?
• Change Traceability: Versionierte Policies, Review-Protokolle, Rollout-Historie.
• Incident Korrelation: Domain-Events mit Routing-/Service-Events verknüpfen, um Root Cause zu finden.

Evidence-by-Design: Segmentierung als messbares Sicherheitsmerkmal

Wenn Sie Domain-Übergänge, Zugriffe und Changes systematisch protokollieren, wird Segmentierung auditierbar. Das reduziert nicht nur Compliance-Aufwand, sondern verbessert Incident Response, weil Sie schneller erkennen, welche Domain betroffen ist und welche Pfade genutzt wurden.

Typische Fallstricke bei Security Domains in Provider-Netzen

• Zu große Domains: Ein Incident wirkt netzweit – Lösung: Domänen nach Topologie/Region schneiden, klare Borders.
• Management gemischt mit Produktion: Angriffsfläche steigt – Lösung: Management-VRF/OOB, Jump-Zones, minimal Routing.
• Unkontrollierte Route-Leaks: Kunden sehen plötzlich interne Netze – Lösung: strikt definierte Import/Export-Templates.
• Zu viele Ausnahmen: Policies werden unübersichtlich – Lösung: wenige Blueprints, Ausnahmen streng steuern.
• Keine Observability: Segmentierung kann nicht bewiesen werden – Lösung: Flow-/Identity-/Change-Logs verpflichtend.
• Security blockiert Betrieb: Teams umgehen Controls – Lösung: praktikable Jump-Zones, klare Rollen und Prozesse.

Praktische Leitlinien: Segmentierung nach Services, Kunden und Betriebsrollen

• Service-Domänen definieren: Core Transport, Service Edge, Platform Services, Security Services, External Edge.
• Kunden isolieren: VRF/EVPN als Standard, Shared Services über Hub-and-Spoke statt VRF-Mesh.
• Betriebsrollen trennen: NOC/Engineering/Security/Automation/Field Ops mit RBAC/ABAC und Jump-Zones.
• Trust Boundaries klar: Marking, Managementzugriff, Route-Leaks und Exits nur an definierten Kanten.
• Policy-as-Code etablieren: Templates, Reviews, Tests, Wellen-Rollouts, Rollback-Kriterien.
• Guardrails einbauen: Max-Prefix, Rate-Limits, Control-Plane-Policing, Quarantäne-Patterns.
• Domains klein halten: Regionen/PoPs als natürliche Failure Domains, keine globalen „Flachzonen“.
• Observability verpflichtend: Flow Visibility, Identity Logs, Change Traceability und Event-Korrelation.