Netzwerksegmentierung on‑prem und in der Cloud: VLANs, Firewalls, Security Groups und Best‑Practices

Netzwerksegmentierung ist eine der effektivsten Maßnahmen, um Angriffsflächen zu reduzieren, Ausbreitung von Vorfällen zu begrenzen und Betriebsabläufe sauber zu trennen. Das Wort Netzwerksegmentierung bezeichnet den bewussten Aufbau von logischen oder physischen Zonen im Netzwerk, in denen Geräte, Dienste und Nutzer nur kontrolliert miteinander kommunizieren dürfen. In Unternehmen bedeutet das typischerweise eine Kombination aus VLANs (Virtual LANs), Router/Layer‑3‑Zonen, Firewalls sowie cloud‑spezifischen Mechanismen wie Security Groups oder Network ACLs. Dieser Artikel erklärt praxisnah, wie Sie Segmentierung on‑prem und in der Cloud entwerfen, umsetzen, testen und sicher betreiben.

Grundbegriffe kurz und prägnant

Bevor es an Konfiguration und Rollout geht, kurz die wichtigsten Begriffe im selben Absatz verständlich zuordnen:

• VLAN (Virtual Local Area Network): Logische Trennung auf Layer‑2 (Datenlink). VLANs isolieren Broadcast‑Domänen auf Switch‑Ports, erfordern Routing (Layer‑3) für Inter‑VLAN‑Kommunikation.
• Firewall: Gerät oder Software, die Traffic nach Regeln erlaubt oder ablehnt. Kann stateful (verbindungsorientiert) oder stateless sein.
• Security Group: Cloud‑Konstrukt (z. B. AWS/Azure) zur Gruppierung von Regeln; meist stateful und an Instanzen gebunden.
• Network ACL: Cloud‑ oder On‑Prem‑Regelwerk, das meist stateless arbeitet und auf Subnetz‑/Netzwerkebene wirkt.
• Mikrosegmentierung: Feingranulare Steuerung von Verbindungen bis auf Prozess‑ oder Host‑Ebene (z. B. via Host‑Firewall, iptables/nftables oder eBPF‑Policies).

Netzwerksegmentierung: Grundprinzipien und Ziele

Gute Segmentierung folgt klaren, operationalen Zielen: Angriffsausbreitung begrenzen, sensible Daten isolieren, Netzlastverteilung verbessern, operationelle Verantwortlichkeiten trennen. Die Prinzipien lauten:

• Least privilege: Nur die minimal erforderlichen Verbindungen erlauben.
• Trust zoning: Netzbereiche nach Vertrauensstufe (z. B. DMZ, App‑Tier, DB‑Tier) strukturieren.
• Logging und Monitoring: Alle Zonen‑Grenzen sollten nachvollziehbar protokollieren.
• Automatisierung: Policies als Code (IaC), Review‑Pipelines und Testautomatisierung verhindern Drift und Fehlkonfigurationen.

On‑Prem: VLANs praktisch gestalten und betreiben

VLANs sind die klassische Methode für on‑prem Segmentierung. Ein VLAN fasst Ports zusammen und bildet eine eigene Broadcast‑Domäne; Routing zwischen VLANs erfolgt per Router oder L3‑Switch (Inter‑VLAN‑Routing).

Voraussetzungen und Planung

Wichtige Voraussetzungen: Trunk‑fähige Switches (IEEE 802.1Q) für VLAN‑Durchreichung, ein konsistenter IP‑Adressplan, dokumentierte VLAN‑IDs und Namenskonventionen, sowie Routing‑Policy am L3‑Gateway. Ohne sauberen IP‑Plan entsteht schnell Overlap, falsch platzierte Gateways oder Broadcast‑Stürme.

Beispiel: VLAN an einem Switch anlegen (Cisco IOS)

Konfiguration eines Trunk‑Ports und eines Access‑Ports:

configure terminal
vlan 10
 name VLAN-APP
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
interface GigabitEthernet1/0/2
 switchport mode access
 switchport access vlan 10
end
write memory

Warum das funktioniert: Trunk überträgt mehrere VLANs zwischen Switches; Access‑Ports stecken in genau einem VLAN. Wann es scheitert: fehlende Trunk‑Config am Gegenstück, unterschiedliche native VLANs oder MTU‑Probleme (bei Stimme/VLAN‑Tagging beachten).

Linux‑Host als Router / VLAN‑Interface

Für kleine Standorte oder Testumgebungen kann ein Linux‑Gateway VLAN‑Interfaces direkt behandeln:

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev eth0.10
ip link set eth0.10 up
sysctl -w net.ipv4.ip_forward=1

Risiko: Performance‑Limits und fehlende Hardware‑Offload‑Unterstützung auf Commodity‑Hosts. Für produktive Lasten empfehlen sich L3‑Switches oder dedizierte Router/Firewalls.

Cloud‑Konzepte: Security Groups, NACLs und Routing

In Public Clouds wie AWS, Azure oder Google Cloud gibt es andere primitive Bausteine. Security Groups (SG) sind typische, an Instanzen gebundene, meist stateful Regeln. Network ACLs (NACL) arbeiten auf Subnetzebene und sind oft stateless, d. h. sie benötigen separate Regeln für In/Out.

Stateful vs. stateless kurz erklärt

Stateful bedeutet, die Firewall merkt sich Verbindungen (z. B. eine erlaubte TCP‑Verbindung erlaubt anschließend Return‑Traffic). Stateless behandelt jede Richtung unabhängig und ist deshalb detailreicher zu pflegen. In AWS sind SGs stateful; NACLs sind stateless. In Azure sind NSGs (Network Security Groups) stateful.

Beispiel: Security Group anlegen (AWS CLI)

aws ec2 create-security-group --group-name zammad-app-sg --description "Zammad App SG" --vpc-id vpc-123abc
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 5432 --source-group sg-0dbonly

Die letzte Regel zeigt ein wichtiges Muster: DB‑Port (5432) nur von der Application‑SG erlauben. So verhindern Sie direkte Internet‑Zugriffe auf Datenbanken.

Firewalls strategisch einsetzen: Zonen, Regeln, Logging

Segmentierung funktioniert am besten mit klaren Zonen: Perimeter/DMZ, App‑Tier, Datenbank‑Tier, Management. Firewalls setzen die Policy an den Zonenübergängen durch. Wichtige Punkte:

• Regeln nach Funktionsbedarf, nicht nach IP: Gruppieren Sie Dienste, nicht einzelne Hosts.
• Default‑Deny: Perimeter‑Regelwerk standardmäßig ablehnend, nur explizit erlaubte Flows zulassen.
• Protokoll‑ und Port‑Beschränkung: Nur die nötigen Protokolle öffnen (z. B. HTTPS statt HTTP, Applikations‑Proxies, mTLS).
• Logging und Retention: Firewall‑Logs zentral sammeln (SIEM), um Anomalien zu erkennen.

Beispiel: Minimaler nftables‑Input‑Chain (Host‑Firewall)

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0 ; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input tcp dport 22 ct state new limit rate 10/second accept
nft add rule inet filter input drop

Warum das funktioniert: Einfache Default‑Deny‑Strategie mit Erlaubnis für etablierte Verbindungen und notwendige Dienste. Wann es scheitert: Fehlende Logging‑Regeln, die Konsole (SSH) zu offen lassen oder Regeln in falscher Reihenfolge platzieren.

Best‑Practices: Design, Automatisierung und Betrieb

Konkrete Richtlinien, die in Projekten immer wieder den Unterschied machen:

1. Tagging‑ und Namenskonventionen: Nutzen Sie konsistente Tags in der Cloud (z. B. environment, role, owner) und eine VLAN‑Namensstruktur on‑prem (z. B. VLAN-APP-10).
2. Policy as Code: Firewalls und Security Groups über IaC (Terraform, ARM, CloudFormation) verwalten, inklusive Code‑Review und Testing.
3. Change‑Control: Jede Policyänderung durchläuft automatisierte Tests (Connectivity‑Smoke, Regression) und eine Rollback‑Option.
4. Least‑Privilege und explizite Regeln: Keine offenen 0.0.0.0/0‑Regeln außer wenn wirklich nötig.
5. Monitoring & Alerts: Anomalien wie plötzliche Peaks in East‑West‑Traffic oder ungewöhnliche Port‑Scans alarmieren.
6. Dokumentation: IP‑Plan, VLAN‑Map, Firewall‑Matrix (Wer darf wen erreichen?) aktuell halten.

Migrations- und Rollout‑Plan: Schritt für Schritt

Bei Migration von flachen Netzen zu segmentierten Landschaften empfiehlt sich ein garantierter Rollback‑Pfad. Eine exemplarische Sequenz:

1. Analyse: Aktuelle Flows mit NetFlow/sFlow, tcpdump und Service‑Dependencies aufnehmen.
2. Design: Zonen and Services‑Map erstellen, Ports und Endpoints dokumentieren.
3. Automatisiert ausrollen: IaC Templates erzeugen, Dry‑Run, Review und Staging‑Deploy.
4. Canary: Segmentierung in einem kleinen Subset anwenden und beobachten.
5. Produktivrollout: Phasenweiser Cutover mit Monitoring und Notfall‑Rollback.

Wichtige Testbefehle

Verwenden Sie diese Befehle systematisch, um Connectivity und Regeln zu prüfen:

# Verbindungstest TCP (Netcat)
nc -vz 192.168.10.5 5432

# Paketmitschnitt (z. B. DB‑Traffic)
tcpdump -i eth0 -n 'host 192.168.10.5 and port 5432'

# Firewall‑Rules anzeigen
nft list ruleset

# Route/Next‑Hop prüfen
ip route show

# Traceroute für Pfaddiagnose
traceroute -n 10.0.0.5

# HTTP‑Check
curl -v --connect-timeout 5 https://app.example.local/health

Monitoring, Logging und Drift‑Detection

Segmentierung ist nur so gut wie ihre Überwachung. Zentrale Erfordernisse:

• Flow‑Logging: Aktivieren Sie NetFlow/sFlow auf Switches und VPC Flow Logs in Clouds, um East‑West‑Traffic zu analysieren.
• Firewall Logs: Strukturierte Logs (JSON) in ein SIEM leiten, um Korrelationen zu ermöglichen.
• Drift Detection: Vergleichen Sie laufend aktuelle Configs mit IaC‑State (z. B. Terraform plan in CI). Cloud‑Tools wie AWS Config oder Azure Policy können unmanaged Changes melden.

Beispiel: VPC Flow Logs aktivieren und einfache CloudWatch Logs Insights‑Query für ungewöhnliche Quell‑IPs:

# VPC Flow Logs (Kurzbefehls-Beispiel - CLI)
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-123abc --traffic-type ALL --log-group-name /aws/vpc/flowlogs --deliver-logs-permission-arn arn:aws:iam::123456:role/flowlogs-role

# CloudWatch Logs Insights Beispielabfrage
fields @timestamp, srcAddr, dstAddr, action | filter action = 'REJECT' | stats count() by srcAddr | sort @timestamp desc

Performance, MTU und Latenz beachten

Segmentierung kann Seiteneffekte auf Latenz und MTU haben. Tagged‑Frames erhöhen Paketgröße; bei VPNs oder Overlay‑Netzen (z. B. VXLAN) addieren sich Header. Prüfen Sie MTU‑Einstellungen entlang des Pfads und messen Sie Latenz/Throughput vor und nach Änderungen.

Messwerkzeuge und Beispielbefehle:

# MTU prüfen
ip link show dev eth0

# Latenz und Durchsatz messen (iperf3)
iperf3 -c 10.0.0.5 -p 5201 --parallel 4 --time 30

Microsegmentierung, Host‑Firewall und eBPF

Wenn Layer‑2/3 nicht ausreichen oder Multimandantenbetrieb verlangt wird, hilft Mikrosegmentierung: Hostbasiert via nftables/iptables, agentenbasiert (z. B. bereichsspezifische Agents) oder moderne Ansätze mit eBPF, das hochperformante Paketfilter in den Kernel bringt. Vorteil: sehr feingranulare Kontrolle; Nachteil: höhere Komplexität und Betriebslast.

Zammad‑spezifische Betriebs‑ und Troubleshooting‑Ergänzungen

Für Zammad‑Installationen konkretisieren Sie Ihre Segmentierung anhand folgender Punkte:

• Liste der minimalen Ports: Web (80/443), Postgres (5432), Elasticsearch (9200), Redis (6379).
• Sicherung der Adminwege: SSH/Management nur in Management‑Zone, 2FA für Webadmin‑Accounts und IP‑Beschränkungen für Admin‑Panels.
• Health‑Checks und Playbooks: Einfache Health‑Endpoints prüfen Web, DB‑Connections, Index‑Health von Elasticsearch.

Troubleshooting‑Sequenz bei Erreichbarkeitsproblemen:

1. Firewalls/Security Groups prüfen (Logs auf ACCEPT/REJECT).
2. Netzwerkpfad testen (traceroute, tcpdump auf App‑Host).
3. Applikationslogs prüfen (Zammad Rails Logs, Postgres Logs, Elasticsearch Logs).
4. Rollback auf vorherige Security‑Group/Firewall‑Version, falls Connectivity nachweislich durch Policy verursacht wurde.

Beispiel: Terraform‑Snippet für Security Group (Cloud‑Policy as Code)

resource "aws_security_group" "zammad_app" {
  name        = "zammad_app_sg"
  description = "App SG für Zammad"
  vpc_id      = var.vpc_id

  ingress {
    description = "Web"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description     = "DB Access aus App SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.zammad_db.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "zammad_app_sg"
  }
}

Wichtig: Legen Sie Versionierung, CI Prüfungen (terraform plan) und automatisierte Approvals fest, um driftfreie Ausrollungen sicherzustellen.

Operationales Runbook und Rückfallstrategie

Ein präzises Runbook reduziert Stress im Incident. Kernpunkte:

• Schnelltest‑Befehle (Connectivity, Logs, Health‑Checks).
• Snapshot/Backup IDs und Zeitpunkt dokumentiert.
• Rollback‑Befehl oder IaC‑Revert‑Playbook, inklusive Ansprechpartner und Eskalationskette.
• Kommunikationsplan: Statusupdates an betroffene Teams und Maintenance‑Fenster.

Checkliste vor dem Produktivstart

• IP‑Plan und VLAN‑Map final und im Team verteilt.
• IaC Templates erstellt, Review abgeschlossen, automatisierte Tests grün.
• Backup/Snapshot vor Rollout erstellt.
• Monitoring (Flows, Firewall‑Logs) aktiv und Alert‑Schwellen gesetzt.
• Rollback‑Playbook dokumentiert und getestet.
• Dokumentation der Regeln und Zuständigkeiten vorhanden.

Fazit

Netzwerksegmentierung ist ein fortlaufendes, nicht einmaliges Projekt. Der beste Ansatz kombiniert solide Designprinzipien (Least‑Privilege, Trust Zoning), Automatisierung (Policy as Code) und ein klares Test‑ und Rollback‑Procedere. On‑prem‑VLANs und Cloud‑Security‑Groups ergänzen sich häufig und müssen in der Praxis als zusammenhängendes Policy‑Set verstanden werden. Bei prozessnahen digitalen Unternehmenslösungen wie Zammad zahlt sich eine saubere Segmentierung: geringere Angriffsfläche, eindeutige Verantwortlichkeiten und reproduzierbare Rollouts. Starten Sie klein (Canary), messen Sie Flows und automatisieren Sie die Policy‑Verteilung — so werden Segmentierungsprojekte beherrschbar und nachhaltig.