Mikrosegmentierung

Mikrosegmentierung ist die feingranulare Netzwerktrennung auf Workload-Ebene. Während klassische Segmentierung (VLANs, Firewalls) das Netz in große Zonen aufteilt, kontrolliert Mikrosegmentierung die Kommunikation zwischen einzelnen Systemen, Anwendungen oder Containern. Sie ist ein zentrales Element der Zero-Trust-Architektur.

Mikrosegmentierung vs. klassische Segmentierung

Vergleich: VLAN vs. Mikrosegmentierung

Klassische VLAN-Segmentierung:
  Client-VLAN (10.0.10.0/24)
    → Workstation-01
    → Workstation-02
    → Workstation-03

  Server-VLAN (10.0.20.0/24)
    → Web-Server
    → App-Server
    → DB-Server
    → File-Server

  Firewall: Client-VLAN → Server-VLAN: erlaubt (SMB, RDP, HTTP)
  Problem: Workstation-01 kompromittiert → erreicht ALLE Server im Server-VLAN!

Mikrosegmentierung:
  Jede VM hat eigene Policy:
    Workstation-01 → darf: File-Server:445 (SMB), Web-Server:443
                   → darf NICHT: DB-Server, App-Server direkt
    Web-Server     → darf: App-Server:8080
                   → darf NICHT: DB-Server direkt!
    App-Server     → darf: DB-Server:5432
                   → darf NICHT: Internet direkt
    DB-Server      → darf: eingehend von App-Server:5432
                   → darf NICHT: ausgehend irgendetwas!

  Ergebnis: Kompromittierter Web-Server → KANN App-Server nur über 8080
            Kein SMB, kein RDP, kein Portscan möglich!

Implementierungstechnologien

Mikrosegmentierung technisch:

1. Host-basierte Firewall (einfachster Einstieg):
   → Windows Defender Firewall: Regeln pro System konfigurieren
   → iptables/nftables (Linux): host-level Firewall
   → Zentrale Verwaltung: SCCM, Ansible, Puppet
   → Skalierungsproblem: 1000 Systeme = 1000 Firewalls verwalten

2. Software-Defined Networking (SDN):
   VMware NSX:
     → Mikrosegmentierung für VMware-Umgebungen
     → "Distributed Firewall": Regeln auf vNIC-Ebene
     → Zentrale Policy-Verwaltung für alle VMs
     → Automatische Segmentierung neuer VMs durch Tagging

   Illumio / Guardicore:
     → Agenten-basiert: auf jedem Workload installiert
     → Automatisches Application Dependency Mapping
     → Policy empfehlen auf Basis von Kommunikationsmustern
     → Gut für Cloud + On-Premises + Container

3. Kubernetes Network Policies:
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-frontend-to-backend
   spec:
     podSelector:
       matchLabels:
         app: backend
     ingress:
     - from:
       - podSelector:
           matchLabels:
             app: frontend
       ports:
       - protocol: TCP
         port: 8080
     egress:
     - to:
       - podSelector:
           matchLabels:
             app: database
       ports:
       - protocol: TCP
         port: 5432

4. eBPF-basierte Segmentierung (Cilium):
   → Layer-7 Policies: HTTP-Pfad, Methode, Header
   → Beispiel: Backend darf nur GET /api/products vom Frontend
   → Extrem performant: im Linux-Kernel, kein Proxy
   → Kubernetes-nativ

Automatisches Policy-Design:
  Problem: Wie weiß ich welche Kommunikation normal ist?
  Lösung: Discovery-Phase
    1. Mikrosegmentierungs-Tool im "Learn"-Modus
    2. Beobachtet normalen Traffic (2-4 Wochen)
    3. Generiert empfohlene Policies automatisch
    4. Admin reviewt und aktiviert
  → Werkzeuge: Illumio Illuminate, VMware NSX Intelligence

Einsatzgebiete und Prioritäten

Wo Mikrosegmentierung am wichtigsten ist:

Höchste Priorität:
  1. Datenbank-Server:
     → Nur vom App-Server erreichbar, auf spezifischem Port
     → Kein direkter Zugriff von Workstations!
     → Kein ausgehender Traffic von DB (kein C2-Callback!)

  2. Domain Controller / Active Directory:
     → Nur LDAP (389/636), Kerberos (88), DNS (53) von bekannten Systemen
     → Keine direkten Admin-Sessions von normalen Workstations
     → Jump-Host als einziger Weg zu DCs

  3. Backup-Server:
     → Nur Backup-Agent-Traffic eingehend (spezifische Ports)
     → KEIN ausgehender Traffic zu Internet
     → Kein Zugriff von kompromittierten Workstations auf Backup!
     → Ransomware kann Backups nicht verschlüsseln!

  4. Produktionssysteme / OT:
     → Vollständige Isolation von Office-Netz
     → Nur definierte Kommunikation zu HMI/SCADA

Mittlere Priorität:
  5. Entwicklungs- vs. Produktionsumgebung:
     → Entwickler-PCs dürfen nicht auf Produktionsdatenbanken zugreifen
  6. Cloud-Workloads:
     → Security Groups (AWS), NSGs (Azure) als Mikrosegmentierung

Messung des Sicherheitsgewinns:
  → Blast Radius eines kompromittierten Systems: wie viele andere Systeme erreichbar?
  Vorher: 1 kompromittierter Server → 250 weitere direkt erreichbar
  Nachher: 1 kompromittierter Server → 5 weitere direkt erreichbar (nur App-Abhängigkeiten)
  → Reduktion des Blast Radius um 98%!