Netzwerktrennung

Aufteilung von Netzwerken in isolierte Zonen zur Eindämmung von Angriffen und zum Schutz kritischer Systeme.

Was ist Netzwerktrennung?

Netzwerktrennung (auch Netzwerksegmentierung genannt) ist die Praxis, ein Computernetzwerk in kleinere, isolierte Teilnetzwerke aufzuteilen. Jedes Segment fungiert als eigene Netzwerkzone mit kontrollierten Zugangspunkten, wodurch eingeschränkt wird, welche Systeme miteinander kommunizieren können.

Dieser architektonische Ansatz folgt dem Prinzip des Least Privilege (Minimale Rechtevergabe) - Systeme haben nur Netzwerkzugriff auf die Ressourcen, die sie unbedingt benötigen. Wenn ein Angreifer ein Segment kompromittiert, kann er sich nicht ohne Weiteres lateral in andere Teile des Netzwerks bewegen.

Wesentliche Vorteile

  • Eindämmung: Sicherheitsverletzungen bleiben auf ein Segment beschränkt
  • Reduzierte Angriffsfläche: Weniger Systeme sind erreichbar
  • Besseres Monitoring: Anomalien sind leichter zu erkennen
  • Compliance: Von vielen Sicherheitsstandards gefordert
  • Performance: Reduziert Broadcast-Traffic

Warum Netzwerktrennung kritisch ist

Ohne Netzwerktrennung

  • Ein kompromittiertes System = gesamtes Netzwerk gefährdet
  • Ransomware breitet sich schnell über alle Systeme aus
  • Angreifer bewegen sich mühelos lateral
  • Keine Eindämmung von Sicherheitsverletzungen
  • Schwierige Erkennung von Eindringlingen

Reale Angriffe

  • Colonial Pipeline (2021): Ransomware breitete sich von IT zu OT aus
  • Target (2013): HVAC-Lieferantenzugang führte zu POS-Breach
  • NotPetya (2017): Verbreitung über flache Netzwerke weltweit
  • Maersk (2017): 300 Mio. $ Verlust durch laterale Bewegung

Mit korrekter Segmentierung

  • Angriffe auf einzelne Zone beschränkt
  • Kritische Systeme vom allgemeinen Netzwerk isoliert
  • Defense in Depth erreicht
  • Klare Sicherheitsgrenzen
  • Einfachere Incident Response

Regulatorische Anforderungen

Netzwerktrennung wird von wichtigen Sicherheitsframeworks gefordert oder dringend empfohlen.

BDEW Whitepaper

Abschnitt 4.4.2 - Sichere Netzwerkstruktur

Der Bundesverband der Energie- und Wasserwirtschaft (BDEW) schreibt Netzwerktrennung für kritische Infrastrukturen vor. Wesentliche Anforderungen umfassen:

  • Trennung von Büro-IT und Prozessleitsystemen (OT)
  • DMZ-Zonen für externe Kommunikation
  • Firewalls zwischen allen Netzwerksegmenten
  • Strikte Zugangskontrolle an Segmentgrenzen
  • Überwachung des segmentübergreifenden Traffics

Zitat BDEW 4.4.2: "Die Netzwerkstruktur muss so gestaltet sein, dass verschiedene Sicherheitszonen voneinander getrennt werden. Die Kommunikation zwischen den Zonen muss kontrolliert und überwacht werden."

BDEW Sicherheitsrichtlinien →

BSI IT-Grundschutz

NET.1.1 - Netzarchitektur und -design

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) definiert Netzwerktrennung als fundamentale Sicherheitsmaßnahme. Wesentliche Anforderungen:

  • NET.1.1.A1: Netzwerk sollte in Sicherheitszonen aufgeteilt werden
  • NET.1.1.A4: Klare Dokumentation der Netzwerktopologie
  • NET.1.1.A13: Mikro-Segmentierung für Hochsicherheitsbereiche
  • Schutz von Management-Netzwerken
  • Isolation von Entwicklung und Produktion

BSI NET.1.1.A1: "Das Netz MUSS in Sicherheitszonen oder Sicherheitssegmente aufgeteilt werden. Die Sicherheitszonen MÜSSEN durch geeignete Mechanismen (z. B. Firewalls) voneinander getrennt werden."

BSI IT-Grundschutz →

Was passiert ohne Netzwerktrennung?

Die Konsequenzen fehlender oder mangelhafter Netzwerksegmentierung.

Risiken und Konsequenzen

Technische Risiken

  • Laterale Bewegung: Angreifer können sich frei im Netzwerk bewegen, sobald sie einen Einstiegspunkt gefunden haben
  • Ransomware-Verbreitung: Schadsoftware kann sich ungehindert auf alle erreichbaren Systeme ausbreiten
  • Datenexfiltration: Zugriff auf sensible Daten von jedem kompromittierten Gerät
  • Privilege Escalation: Einfacherer Zugang zu privilegierten Systemen

Geschäftliche Konsequenzen

  • Produktionsausfall: OT-Systeme können von Büro-IT aus angegriffen werden
  • Compliance-Verstöße: Verletzung von BDEW, BSI und branchenspezifischen Anforderungen
  • Reputationsschaden: Datenlecks und Serviceausfälle beschädigen das Kundenvertrauen
  • Finanzielle Verluste: Wiederherstellungskosten, Bußgelder und Betriebsunterbrechungen

Umsetzung in Signando REST

Wie wir die Prinzipien der Netzwerktrennung in unserer API-Gateway-Architektur anwenden.

4 Isolierte NATS-Instanzen

Signando REST verwendet vier vollständig isolierte NATS JetStream-Instanzen. Jede Instanz läuft in ihrem eigenen Netzwerksegment ohne direkte Kommunikation zwischen ihnen:

  • NATS 1: DMZ-facing, empfängt nicht vertrauenswürdige Client-Requests
  • NATS 2: Interne Clean Zone, nur validierte Requests
  • NATS 3: Backend-facing, empfängt nicht vertrauenswürdige Responses
  • NATS 4: Interne Clean Zone, nur validierte Responses

Warum das wichtig ist

Selbst wenn ein Angreifer eine Komponente kompromittiert, kann er nicht:

  • Auf validierte Daten in Clean Zones zugreifen
  • Bösartige Requests ins Backend einschleusen
  • Daten über denselben Kanal exfiltrieren
  • Sich lateral zu anderen Verarbeitungsstufen bewegen

Dies ist Netzwerktrennung auf Anwendungsebene - in Übereinstimmung mit BDEW- und BSI-Empfehlungen für Defense in Depth.

Architektur-Übersicht (Beispiel)

┌─────────────────────────────────────────────────────────────────────┐
│                         DEMILITARISIERTE ZONE                       │
│  ┌─────────────┐    ┌─────────────┐           ┌─────────────┐       │
│  │   Client    │───▶│  Frontend   │──────────▶│   NATS 1    │       │
│  │  (extern)   │◀───│             │◀┐ Resp.   │   (Dirty)   │       │
│  └─────────────┘    └─────────────┘ │         └──────┬──────┘       │
│                                     │                │              │
├─────────────────────────────────────┼────────────────┼──────────────┤
│              VALIDIERUNGSZONE       │                │              │
│                                     │ ┌────────────────┐            │
│                                     │ │   Validator    │◄───────────┘
│                                     │ │   (OpenAPI)    │
│                                     │ └───────┬────────┘
│                                     │         │
│                                     │ ┌───────▼────────┐
│                                     │ │    NATS 2      │
│                                     │ │   (Clean)      │
│                                     │ └───────┬────────┘
├─────────────────────────────────────┼─────────┼─────────────────────┤
│              INTERNE ZONE           │ ┌───────▼────────┐            │
│                                     │ │    Backend     │            │
│                                     │ │    System      │            │
│                                     │ └───────┬────────┘            │
│                                     │         │                     │
│                                     │ ┌───────▼────────┐            │
│                                     │ │    NATS 3      │            │
│                                     │ │   (Dirty)      │            │
│                                     │ └───────┬────────┘            │
├─────────────────────────────────────┼─────────┼─────────────────────┤
│           RESPONSE-VALIDIERUNG      │ ┌───────▼────────┐            │
│                                     │ │   Validator    │            │
│                                     │ │   (OpenAPI)    │            │
│                                     │ └───────┬────────┘            │
│                                     │         │                     │
│                                     │ ┌───────▼────────┐            │
│                                     │ │    NATS 4      │            │
│                                     │ │   (Clean)      │            │
│                                     │ └───────┬────────┘            │
│                                     │         │                     │
│                                     └─────────┘                     │
└─────────────────────────────────────────────────────────────────────┘

Physische Umsetzung der Netzwerktrennung

Echte Netzwerktrennung erfordert mehr als nur logische Konfiguration. Je nach Sicherheitsanforderung gibt es verschiedene Implementierungsstufen:

1. Logische Trennung (Basis)

  • Verschiedene IP-Subnetze: Jede Zone erhält ein eigenes Subnetz (z.B. 10.1.0.0/24, 10.2.0.0/24)
  • VLANs: Virtuelle LANs auf demselben Switch, aber logisch getrennt
  • Firewall-Regeln: Strikte Regeln zwischen den Subnetzen

⚠️ Schwachstelle: Ein kompromittierter Switch oder VLAN-Hopping kann die Trennung umgehen.

2. Physische Trennung (Empfohlen)

  • Separate Netzwerkkarten: Jede Zone über eigene NIC angebunden
  • Getrennte Kabel: Keine gemeinsame Verkabelung zwischen Zonen
  • Eigene Switches pro Zone: Kein gemeinsamer Switch zwischen Sicherheitszonen

✅ Vorteil: Physische Isolation verhindert softwarebasierte Angriffe auf die Trennung.

3. Hardware für Multi-Port-Gateways

Für die Implementierung von Netzwerktrennungspunkten eignen sich spezielle Appliances mit mehreren physischen Netzwerkanschlüssen:

Protectli Vault

Kompakte, lüfterlose Geräte mit 4-6 Intel-Netzwerkports. Ideal für Firewalls und Segmentierungs-Gateways. Unterstützt pfSense, OPNsense oder Linux.

  • 4-6 separate Gigabit-Ethernet-Ports
  • Jeder Port = eigenes physisches Netzwerk
  • Keine interne Switch-Fabric
Industrielle Gateways

Für kritische Infrastrukturen (KRITIS) gemäß BDEW-Anforderungen werden oft gehärtete Industrie-PCs eingesetzt:

  • Hutschienenmontage für Schaltschränke
  • Erweiterte Temperaturbereiche
  • Redundante Netzteile

Signando REST Deployment-Beispiel

Bei einem typischen Signando REST Deployment mit 4 NATS-Instanzen:

  • NIC 1 (eth0): DMZ - Frontend empfängt Client-Requests
  • NIC 2 (eth1): NATS 1 (Dirty) - Unvalidierte Requests
  • NIC 3 (eth2): NATS 2 (Clean) - Validierte Requests zum Backend
  • NIC 4 (eth3): NATS 3 (Dirty) - Unvalidierte Backend-Responses
  • NIC 5 (eth4): NATS 4 (Clean) - Validierte Responses zur DMZ

Ein 6-Port Protectli Vault oder vergleichbares Gerät kann alle Zonen physisch trennen, ohne dass ein gemeinsamer Switch benötigt wird.

Netzwerktrennung implementieren

Erfahren Sie, wie Signando REST eingebaute Netzwerkisolation für Ihre API-Infrastruktur bietet.

Architektur ansehenBeratung anfordern