Netzwerksegmentierung und Mikrosegmentierung für Zero Trust

Netzwerksegmentierung verhindert Lateral Movement - die größte Gefahr nach dem Initial Access. Wer einmal im Netz ist, kann sich unbegrenzt bewegen wenn keine Segmentierung existiert. Dieser Guide zeigt den Weg von der VLAN-Basis bis zur Zero-Trust-Mikrosegmentierung.

Warum Segmentierung entscheidend ist

Das Problem ohne Segmentierung (Flat Network)

• Angreifer gelangt auf einen Rechner (Phishing)
• Lateral Movement: sofort Zugriff auf alle 500 anderen Rechner
• Keine Firewall zwischen Workstations und Servern
• Ransomware breitet sich in Minuten aus

Reale Schäden:

• Notpetya 2017: startete auf einem System → verschlüsselte in 90 Minuten 40.000 Maersk-Rechner weltweit
• Colonial Pipeline 2021: Ransomware auf Bürounetz → Sicherheitsbedenken für OT → Pipeline abgeschaltet

Mit Segmentierung

• Phishing-Opfer: Workstation im User-VLAN
• Angreifer sieht: nur andere Workstations (im gleichen VLAN)
• Firewall blockiert: Workstation → Server-VLAN (kein Lateral Movement!)
• Domain Controller: nur aus IT-VLAN erreichbar
• Schaden: begrenzt auf ein Segment

VLAN-Konzept: Layer-2-Segmentierung

Typische VLAN-Struktur für Mittelstand

VLAN	Funktion	Subnetz
VLAN 10	Server (Production)	192.168.10.0/24
VLAN 20	Server (Development)	192.168.20.0/24
VLAN 30	Users (Standard)	192.168.30.0/24
VLAN 40	Users (Management/IT)	192.168.40.0/24
VLAN 50	IoT/Drucker/Geräte	192.168.50.0/24
VLAN 60	WLAN-Gäste	192.168.60.0/24
VLAN 70	VoIP	192.168.70.0/24
VLAN 80	Backup-Systeme	192.168.80.0/24
VLAN 90	Management (Netz-Geräte)	192.168.90.0/24
VLAN 100	OT/ICS (falls vorhanden)	10.10.0.0/24

Firewall-Regeln zwischen VLANs

Von → Nach	Regel
Users → Server	Spezifische Ports! (443/HTTPS, 445/SMB wenn nötig)
Users → Users	DENY ALL (Workstation zu Workstation blockiert!)
IoT → Server	DENY ALL (Drucker braucht keine AD-Verbindung!)
Gäste → intern	DENY ALL + nur Internet-Zugang
Backup → Server	Nur Backup-Ports (VSS, VEEAM-Agent)
Management → alle	Restricted (nur IT-Admins!)

Cisco-Konfigurationsbeispiel

interface GigabitEthernet0/1
  description "User Workstation Port"
  switchport mode access
  switchport access vlan 30
  spanning-tree portfast
  storm-control broadcast level 20
  ip dhcp snooping limit rate 15

interface GigabitEthernet0/24
  description "Trunk zu Firewall"
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30,40,50,60,70,80,90,100

DMZ-Architektur

DMZ-Konzept

Der klassische Aufbau lautet: Internet → Außen-Firewall → DMZ → Innen-Firewall → Internes Netz. Die DMZ ist öffentlich erreichbar, aber vom internen Netz isoliert.

In der DMZ (öffentlich erreichbar, aber isoliert):

• Web-Server (HTTPS 443)
• Mail-Gateway (SMTP 25, IMAPS 993)
• VPN-Concentrator
• Reverse Proxy / WAF
• Jump Server (Bastion Host für externe Admins)

Regel-Grundsatz:

• Internet → DMZ: nur spezifische Ports
• DMZ → Intern: nur das nötigste (DB-Verbindung, LDAP)
• Intern → DMZ: Admin-Zugriff (aus IT-VLAN!)
• Internet → Intern: NIEMALS direkt!

Bastion Host / Jump Server

• Einziger Einstiegspunkt für externe Admin-Zugänge
• Sehr stark gehärtet (nur SSH/RDP, keine anderen Dienste)
• MFA: immer!
• Logging: alle Sessions aufgezeichnet (PAM-Integration)
• Session-Timeouts: 15 Minuten Inaktivität

In AWS bietet EC2 Instance Connect eine elegante Lösung: Ein temporärer SSH-Public-Key wird für 60 Sekunden auf die Instanz hochgeladen - kein dauerhaft hinterlegter Schlüssel ist notwendig. Nach Ablauf der 60 Sekunden ist der Key ungültig.

Mikrosegmentierung

Traditionell vs. Mikrosegmentierung

Traditionelle Segmentierung arbeitet auf VLAN- und Subnet-Ebene: Alle Server in VLAN 10 können miteinander kommunizieren. Ein Web-Server kann den Datenbank-Server ansprechen, aber auch den Backup-Server - ob das gewollt ist, bleibt unkontrolliert.

Mikrosegmentierung arbeitet auf Workload-Ebene: Jeder Server darf nur explizit erlaubte Verbindungen aufbauen. Der Web-Server darf ausschließlich Port 3306 auf dem spezifischen Datenbank-Server erreichen. Alles andere wird geblockt (Default-Deny).

Implementierungsansätze

Host-based Firewall (Basis): Windows Firewall bzw. iptables/nftables auf jedem Server. Der Nachteil: Bei 1.000 Servern entstehen 1.000 individuelle Regelsätze, die zentral kaum zu verwalten sind.

VMware NSX (Software-Defined Networking): Mikrosegmentierung direkt im Hypervisor. Jede VM erhält eine Distributed Firewall. Policies werden zentral verwaltet und überall durchgesetzt - ohne Änderungen an der physischen Netzwerkinfrastruktur.

Illumio Core: Agentbasiert (Linux/Windows). Das System mappt automatisch, welche Workloads miteinander kommunizieren, und visualisiert diese Abhängigkeiten. Policies werden über Labels definiert - Role (web/db/app/backup), App (ecommerce/erp/crm), Environment (prod/staging/dev) und Location (dc1/aws/azure). Eine Policy wie "web (prod) darf mit db (prod) auf Port 5432 kommunizieren - alles andere geblockt" lässt sich damit präzise und skalierbar umsetzen.

Kubernetes NetworkPolicy (Container)

Standardmäßig können alle Pods in einem Kubernetes-Cluster miteinander kommunizieren. Eine NetworkPolicy schränkt das ein:

# Standard: alle Pods können miteinander reden (unsicher!)
# NetworkPolicy: Default-Deny + Whitelist
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}       # Alle Pods
  policyTypes:
    - Ingress
    - Egress
# Dann: spezifische Policies für erlaubte Verbindungen

Cloud-Netzwerksegmentierung

AWS VPC Design

Eine bewährte 3-Tier-Architektur in AWS trennt Public Subnets (für Load Balancer und NAT Gateways), Private Subnets (App-Tier) und Database Subnets (DB-Tier) jeweils über mehrere Availability Zones. Das VPC umspannt z.B. 10.0.0.0/16, wobei Public Subnets aus 10.0.1-2.0/24, App-Subnets aus 10.0.11-12.0/24 und DB-Subnets aus 10.0.21-22.0/24 bestehen.

Security Groups (Firewall):

• ALB-SG: nur Port 443 vom Internet
• App-SG: nur Port 8080 vom ALB (keine direkte Internet-Verbindung!)
• DB-SG: nur Port 5432 von der App-SG (keine Internet-Verbindung!)

VPC Flow Logs protokollieren den gesamten Netzwerkverkehr und ermöglichen Anomalieerkennung: Verbindungen von der App-Tier direkt ins Internet oder aus dem DB-Subnet in öffentliche Netze sind klare Alarmsignale.

Azure Virtual Network (VNet)

# Network Security Groups (NSG) an Subnets:
az network nsg create --name "app-nsg" --resource-group myrg

az network nsg rule create \
  --nsg-name "app-nsg" \
  --name "allow-from-lb" \
  --priority 100 \
  --source-address-prefixes "10.0.1.0/24" \
  --destination-port-ranges "8080" \
  --access Allow

az network nsg rule create \
  --nsg-name "app-nsg" \
  --name "deny-all-inbound" \
  --priority 4096 \
  --access Deny --direction Inbound

Häufige Segmentierungsfehler

Das AWARE7-Penetrationstester-Team findet diese Fehler regelmäßig:

Fehler 1: Drucker im gleichen VLAN wie Server

• Drucker haben oft schwache Credentials
• Angreifer kompromittiert Drucker → Zugriff auf Server-VLAN!
• Fix: IoT-VLAN mit Default-Deny nach Server

Fehler 2: Flat WLAN-Netz ohne Gäste-Trennung

• Gäste-WLAN und Firmen-WLAN im gleichen Segment
• Gast kann auf Dateiserver zugreifen
• Fix: komplett getrenntes VLAN + kein Internetzugang auf Corp-Resources

Fehler 3: Domain Controller für alle erreichbar

• DC sollte nur aus IT-VLAN + Server-VLANs erreichbar sein
• Häufig: alle VLANs haben Zugriff auf DC (Port 88, 389, 636, 445)
• Kerberoasting von jedem Workstation-VLAN möglich!

Fehler 4: Backup-System im gleichen Segment wie Produktion

• Ransomware verschlüsselt Produktion → springt auf Backup
• Fix: Backup-VLAN isoliert, kein direkter Zugriff von Prod auf Backup

Fehler 5: Management-Netz ohne Segmentierung

• IPMI/iDRAC/iLO auf gleichem VLAN wie Users
• Management-Interfaces direkt erreichbar → volle Server-Kontrolle!
• Fix: dediziertes Management-VLAN, nur aus IT-VLAN erreichbar

Fehler 6: Alte Regeln nie entfernt

• Firewall-Regeln akkumulieren über Jahre
• "Only for testing" von 2018 steht noch drin
• Regelwerk-Audit: mindestens jährlich!