Cloud Network Security: Underlay/Overlay-Mapping mit OSI

Cloud Network Security wird oft so behandelt, als bestünde sie hauptsächlich aus Security Groups, Firewalls und ein paar Routenregeln. In der Praxis ist das zu kurz gedacht, denn Cloud-Netzwerke sind fast immer als Zusammenspiel aus Underlay (physische Provider-Infrastruktur) und Overlay (virtuelle, mandantenfähige Netzschicht) umgesetzt. Genau hier entsteht ein typisches Missverständnis: Teams modellieren Risiken und Kontrollen nur auf Basis dessen, was sie im Portal konfigurieren können, und übersehen die Schichten darunter – oder sie erwarten klassische „On-Prem-L2-Probleme“ an Stellen, an denen das Cloud-Overlay diese Angriffsflächen anders löst. Ein sauberes Underlay/Overlay-Mapping mit OSI hilft, Verantwortlichkeiten zu trennen, Security-Kontrollen korrekt zu platzieren und Telemetrie zielgerichtet zu sammeln. Dieser Artikel erklärt Cloud Network Security mit einem OSI-basierten Modell: Welche OSI-Schichten gehören typischerweise zum Provider-Underlay, welche zum Kunden-Overlay, wo liegen die realen Angriffspfade und wie lassen sich Kontrollen so designen, dass sie sowohl Security als auch Betrieb und Fehlersuche (Troubleshooting) unterstützen.

Underlay vs. Overlay: Was bedeutet das in Cloud-Umgebungen?

Im einfachsten Bild ist das Underlay die physische Infrastruktur des Cloud-Providers: Rechenzentren, Glasfaser, Switches, Router, physische Hosts, DDoS-Backbone und die interne Steuerungsebene (Control Plane). Das Overlay ist die virtuelle Netzebene, die Kunden nutzen: VPC/VNet, Subnetze, virtuelle Router, Security Groups, Network ACLs, Load Balancer, Private Endpoints und oft auch Container-Overlays (z. B. VXLAN/Geneve in Kubernetes- oder SDN-Implementierungen).

Wichtig ist die Konsequenz: In der Cloud haben Sie typischerweise keinen direkten Zugriff auf Underlay-Layer-1/2-Details, aber Sie sind trotzdem für Security-Auswirkungen verantwortlich, die sich aus der Zusammensetzung ergeben. Provider übernehmen physische Sicherheit und Isolation auf Underlay-Ebene; Kunden sind verantwortlich für die korrekte Konfiguration und Absicherung des Overlays und der Workloads. Für einen realistischen Überblick lohnt es sich, die Shared-Responsibility-Modelle der großen Anbieter zu lesen, z. B. AWS Shared Responsibility Model oder Microsoft Shared Responsibility in Azure.

OSI als „Übersetzer“: Wo liegt Underlay, wo liegt Overlay?

OSI ist kein Cloud-Design-Standard, aber ein sehr praktischer Übersetzer zwischen Teams (Netzwerk, Security, Plattform, SRE). Das Ziel ist nicht akademische Genauigkeit, sondern ein belastbares Mapping für Kontrollen und Evidence.

• Layer 1–2 (Physical/Data Link): In Public Clouds fast vollständig Underlay. Sie können Isolation und Zugriff kaum direkt prüfen, sondern müssen auf Provider-Controls, Zertifizierungen und Architekturprinzipien vertrauen.
• Layer 3 (Network): Häufig geteilt. Virtuelle Routing-Instanzen, Route Tables, Subnetze und virtuelle Gateways sind Overlay; physisches Routing/Backbone ist Underlay.
• Layer 4 (Transport): Meist Overlay/Workload-nah. Security Groups/NSGs, NACLs, stateful/stateless Filtering und Load-Balancer-Listener greifen hier.
• Layer 5–7 (Session/Presentation/Application): Fast immer kundenseitig (Overlay/Workload). Hier sitzen mTLS, Service Mesh, AuthN/AuthZ, WAF/API-Gateways, App-Policies, Secrets, IAM und Observability.

Dieses Mapping ist besonders hilfreich, wenn Sie klären müssen, ob ein Problem „Netzwerk“ ist oder „Policy/Identity“. OSI hilft, Hypothesen zu strukturieren und verhindert, dass man an der falschen Stelle debuggt oder kontrolliert.

Layer 1 im Cloud-Kontext: Physische Realität ohne direkten Zugriff

Auf Layer 1 sehen Kunden typischerweise keine Kabel, keine Switchports, keine optischen Pegel – und trotzdem existieren reale Risiken: Ausfälle, Fehlverkabelung, Firmware-Probleme, physische Angriffe, Störungen durch Shared Infrastructure. Cloud Network Security bedeutet hier, Vertrauen durch Nachweise zu ersetzen: Zertifizierungen, Audit-Berichte, Vertragsklauseln, Region/Zone-Strategien und technische Resilienz.

• Resilienz-Design: Multi-AZ (und bei Bedarf Multi-Region) reduziert Underlay-Impact auf Verfügbarkeit.
• Provider-Transparenz: Status- und Incident-Kommunikation ist Teil Ihrer Sicherheitslage (z. B. Auswirkung auf Monitoring und IR).
• Kryptografie als Sicherheitsanker: Wenn Sie Underlay nicht kontrollieren, wird Verschlüsselung (z. B. mTLS, IPsec, KMS) zur primären Sicherheitsgrenze.

Layer 2: Warum viele klassische LAN-Angriffe in der Cloud anders aussehen

Auf On-Prem-Layer-2 denkt man an ARP-Spoofing, MAC-Flooding, VLAN-Hopping oder Rogue DHCP. In vielen Cloud-VPCs sind solche Angriffe zwischen Instanzen in derselben Subnetz-Domäne oft nicht in der klassischen Form möglich oder deutlich erschwert, weil Provider L2 stark virtualisieren, East-West-Isolation anders umsetzen und DHCP/ARP-Funktionen kontrolliert bereitstellen. Das heißt jedoch nicht, dass Layer 2 irrelevant ist – es verschiebt sich nur die Fragestellung.

Die praxisrelevante Frage auf Layer 2

Statt „Kann jemand ARP fälschen?“ lautet die Frage häufig: Welche Nachbarschafts- und Broadcast-Mechanismen existieren überhaupt im Overlay? Wie werden Neighbor Discovery (IPv6), Address Resolution oder DHCP im virtuellen Netzwerk umgesetzt? Welche Limits (z. B. Anti-Spoofing) setzt der Provider, und wo muss ich in meinem Overlay zusätzliche Kontrollen ergänzen (z. B. durch Host-Firewalls oder Service Mesh)? Anbieter-Dokumentation liefert oft die entscheidenden Rahmenbedingungen, z. B. AWS VPC Concepts oder Google Cloud VPC Overview.

Layer 3: Overlay-Routing als Sicherheitsgrenze und häufige Fehlerquelle

Layer 3 ist in Cloud-Umgebungen einer der wichtigsten Hebel für Security, weil hier die Reichweite von Kommunikation festgelegt wird: Welche Netze sind direkt erreichbar? Wo gibt es NAT? Welche privaten/veröffentlichten Pfade existieren? Route Tables, virtuelle Router, Transit Gateways, Peering und Private Link/Endpoints formen den tatsächlichen Blast Radius.

• Route-Table-Governance: Unbeabsichtigte 0.0.0.0/0-Routen oder falsche Assoziationen zwischen Subnetzen führen zu „silent exposure“.
• Peering/Transit-Sprawl: Je mehr Verbindungen, desto mehr unbeabsichtigte Pfade. Ohne klare Topologie entstehen laterale Bewegungswege.
• Ingress/Egress-Design: Zentraler Egress (z. B. über NAT/Firewall) kann Visibility verbessern, aber auch Single Points of Failure schaffen.
• Private Endpoints: Reduzieren Public Exposure, erzeugen aber neue Policy-Punkte (DNS, Routing, IAM, Logging).

Ein gutes Underlay/Overlay-Mapping beantwortet hier: Welche Teile sind virtuell und kontrollierbar (Overlay), und welche Teile sind Provider-Backbone (Underlay)? Für Security-Design bedeutet das: Ihre Kontrollen müssen an den Overlay-Knoten sitzen, an denen Sie wirklich Policies erzwingen können.

Layer 4: State, Filtering und die Illusion „Firewall = Security“

Layer 4 ist der Bereich, in dem viele Teams „Firewall-Regeln“ erwarten. In der Cloud ist das Filtering oft verteilt: Security Groups/NSGs sind meist stateful, Network ACLs häufig stateless. Dazu kommen Load Balancer, Managed Firewalls und Host-Firewalls. Die größte Falle ist, dass Teams die Semantik dieser Bausteine verwechseln und dadurch Löcher oder Ausfälle erzeugen.

Stateful vs. Stateless im Underlay/Overlay-Kontext

Stateful Filtering (z. B. Security Groups) ist betrieblich komfortabel, kann aber bei sehr großen Systemen zu Engpässen führen, wenn Verbindungszustände (State Tables) ausufern oder Timeouts falsch gewählt sind. Stateless Filtering (z. B. NACLs) ist deterministischer, aber fehleranfälliger bei komplexen Rückpfaden. Die Architekturentscheidung sollte nicht ideologisch sein, sondern an Use Cases hängen: East-West-Isolation, Egress Control, Third-Party-Access, Incident Containment.

• East-West-Minimierung: Workloads sollten nur die Ports sprechen dürfen, die sie tatsächlich benötigen.
• Egress-Policy: Ausgehender Traffic ist in Incident-Phasen oft kritischer als eingehender.
• Managed Load Balancer: Listener/Target-Groups sind Teil der Angriffsfläche (z. B. offene Ports, falsche Health-Checks, Protokollmischungen).

Layer 5–7: Wo Zero Trust in der Cloud wirklich greift

Wenn Underlay nicht kontrollierbar ist, müssen die harten Sicherheitsgrenzen näher an Identität und Anwendung liegen. Auf Layer 5–7 setzen Sie Kontrollen um, die nicht vom Netzwerkvertrauen leben: mTLS, starke Authentisierung, fein granulare Autorisierung, API-Policies, WAF-Regeln, Ratenbegrenzung, Token-Lifetimes, Device Posture und Workload Identity. Das ist der Bereich, in dem Zero-Trust-Prinzipien operativ werden – nicht als Buzzword, sondern als Engineering-Ansatz.

• mTLS/Service Mesh: Verschlüsselt und authentisiert Service-zu-Service-Traffic unabhängig vom Netzwerkpfad.
• WAF/API Gateway: Erzwingt Layer-7-Policies an einem kontrollierten Eintrittspunkt, inkl. Logging.
• Workload Identity statt statischer Secrets: Reduziert Secret-Sprawl und erleichtert Rotation.
• Policy-as-Code: Netzwerk- und App-Policies versionieren, testen und reviewen.

Für strukturierte Zero-Trust-Orientierung eignet sich die Referenz von NIST SP 800-207 (Zero Trust Architecture), weil sie Bausteine wie Policy Engine, Policy Enforcement und kontinuierliche Bewertung klar trennt.

Overlay-in-Overlay: Container-Netzwerke und die zweite Virtualisierungsschicht

In modernen Umgebungen liegt oft ein weiteres Overlay über dem Cloud-Overlay: Kubernetes CNI, Service Mesh, virtuelle Pod-Netze, Network Policies. Dadurch entstehen zusätzliche Sicherheitsgrenzen – und zusätzliche Missverständnisse. Ein häufiges Problem ist, dass Teams nur eine Ebene kontrollieren und die andere unbewacht lassen.

Praktische Mapping-Frage

Wenn ein Pod eine Verbindung aufbaut: Welche Policies greifen zuerst – Kubernetes NetworkPolicy, Host-Firewall, Security Group, NACL, Route Table, NAT, Gateway? Eine saubere Dokumentation dieses Pfads ist Security-Arbeit, weil sie erklärt, wo Sie effektiv blocken und wo Sie verlässlich loggen können.

• Kubernetes NetworkPolicy: App-nahe Segmentierung, aber abhängig von CNI-Fähigkeiten und korrekter Policy-Pflege.
• Service Mesh Policies: Stärker auf Identität/Service ausgerichtet, oft besser für Zero-Trust-Muster.
• Cloud Controls: Bleiben wichtig als „äußere“ Boundary und zur Reduktion des Blast Radius.

MTU, Encapsulation und Security: Warum Underlay-Details plötzlich operativ werden

Underlay/Overlay ist nicht nur ein Sicherheits-, sondern auch ein Performance- und Stabilitätsthema. Encapsulation (z. B. VXLAN/Geneve/IPsec) verursacht Overhead. Wenn MTU nicht sauber gemanagt ist, entstehen Fragmentierung, Retransmits und schwer zu diagnostizierende Timeouts. Security-relevant wird das, weil „mysteriöse“ Netzwerkprobleme oft zu Ausnahmen führen („temporär Inspection aus“, „temporär Policy lockern“), die später bleiben.

Ein vereinfachtes Overhead-Modell lässt sich so ausdrücken (Beispiel: Baseline-Payload plus zusätzlicher Encapsulation-Overhead):

$\mathrm{MTU}\ge \mathrm{Payload}+\mathrm{Overhead}$

Praktisch heißt das: Wenn Ihr Overlay-Overhead steigt (z. B. durch zusätzliche Tunnel oder IPsec), muss entweder die effektive Payload sinken (MSS-Clamping) oder die Underlay-MTU ausreichend groß sein. Das ist keine rein technische Optimierung, sondern ein Stabilitätsfaktor, der Security-Ausnahmen verhindert.

Telemetrie und Evidence: Welche Daten pro OSI-Schicht wirklich helfen

Cloud Network Security scheitert selten an „fehlenden Logs“, sondern an Logs ohne Kontext. Underlay ist meist nur als Provider-Status oder abstrakte Metrik sichtbar, Overlay und Workload liefern hingegen detailreiche Telemetrie. Ziel ist, diese Daten so zu verbinden, dass IR und Troubleshooting nicht im Blindflug stattfinden.

• Layer 3: Flow Logs (z. B. VPC/VNet Flow Logs), Route-Änderungen, Peering/Transit-Events, NAT-Gateway-Metriken.
• Layer 4: Security-Group/NSG-Allow/Deny (wenn verfügbar), Firewall-Logs, Load-Balancer-Connection-Metriken.
• Layer 7: WAF/API-Gateway-Logs, App-Access-Logs, Auth-Events (OIDC/OAuth), Request-IDs, Trace-IDs.
• Identity-Context: IAM-Änderungen, Rollenannahme, Service Accounts, Workload Identity, Schlüsselrotation.

Als praxisnahe Quelle für AWS-spezifische Observability und Security-Logging-Strukturen kann die Dokumentation zu VPC Flow Logs hilfreich sein; für Azure bietet sich als Einstieg Azure Network Watcher an.

Kontrollpunkte richtig platzieren: Wo blocken, wo nur beobachten?

Ein häufiger Fehler ist, alles an einem Ort erzwingen zu wollen. In der Cloud ist Security erfolgreicher, wenn Sie mehrere kontrollierbare Boundaries kombinieren: grobe Reduktion des Blast Radius auf L3/L4, starke Identitäts- und App-Kontrollen auf L7, sowie konsistente Telemetrie über alle Ebenen.

• Blocken auf L3/L4: Wenn Kommunikation grundsätzlich nicht stattfinden soll (z. B. Produktionsdatenbank nur aus App-Subnetzen).
• Steuern auf L7: Wenn die Kommunikation erlaubt ist, aber nur unter Bedingungen (AuthZ, Token-Scopes, Ratenlimits).
• Beobachten auf mehreren Ebenen: Flow Logs zeigen „dass“, L7-Logs zeigen „was“ und „wer“.

Typische Risiko-Muster beim Underlay/Overlay-Mapping

Wer Cloud Network Security ernsthaft betreibt, sollte diese Muster in Reviews und Threat Models explizit prüfen. Sie sind in realen Umgebungen deutlich häufiger als „exotische“ Angriffe.

• Falsche Trust-Annahmen: „Intern ist sicher“ – obwohl interne Pfade durch Peering/Transit wachsen.
• Unkontrollierter Egress: Datenabfluss geschieht meist ausgehend, nicht eingehend.
• DNS als Steuerungsebene: Private Endpoints, Service Discovery und Split-Horizon-DNS sind oft der versteckte Single Point of Failure.
• Policy-Drift: Ausnahmen, temporäre Routen und „Schnellfixes“ bleiben dauerhaft.
• Overlay-Komplexität: Mehrere Overlays (Cloud + Container + Mesh) erzeugen Lücken zwischen Teams.
• Unzureichende Identity-Verknüpfung: Ohne IAM-Kontext sind Netzwerklogs nur halbe Evidence.

Praktische Checkliste: Underlay/Overlay-Mapping als wiederholbarer Prozess

Damit Underlay/Overlay-Mapping nicht nur ein Whiteboard bleibt, sollte es als Prozess etabliert werden – z. B. als Bestandteil von Architektur-Reviews, Changes und Incident-Postmortems.

• Topologie dokumentieren: VPC/VNet, Subnetze, Route Tables, Gateways, Peering/Transit, zentrale Egress-Pfade.
• Boundaries definieren: Welche Zonen dürfen miteinander sprechen? Welche Protokolle/Ports? Welche Apps?
• Kontrollpunkte zuordnen: Wo wird blockiert (L3/L4), wo autorisiert (L7), wo geloggt (Flow/WAF/App)?
• Identity-Mapping erzwingen: Jede relevante Netzwerkänderung muss einem Owner, Ticket und IAM-Event zuordenbar sein.
• Failure Modes testen: MTU/Encapsulation, DNS-Ausfall, Gateway-Failover, Log-Lücken, Policy-Drift.
• Regelmäßige Reviews: Peering/Transit-Sprawl, offene Security Groups, alte Routen, nicht mehr benötigte Endpoints.

Warum dieses Mapping Security und Betrieb gleichzeitig verbessert

Cloud Network Security wird dann produktionsreif, wenn sie nicht gegen Betrieb arbeitet, sondern ihn stabilisiert. Underlay/Overlay-Mapping mit OSI reduziert Reibung, weil es eindeutige Zuständigkeiten schafft: Underlay-Risiken werden durch Resilienz, Kryptografie und Provider-Nachweise adressiert; Overlay-Risiken durch saubere Segmentierung, Filtering, Identity-Kontrollen und belastbares Logging. Gleichzeitig verbessert das Mapping die Fehlersuche, weil es klar macht, welche Hypothesen auf welcher OSI-Schicht geprüft werden müssen. Wer diese Struktur konsequent nutzt, erreicht in der Praxis weniger Ausnahmen, weniger „mysteriöse“ Netzprobleme und eine deutlich bessere IR-Fähigkeit – weil Evidence nicht zufällig entsteht, sondern geplant.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.