Cloud Firewalling ist heute weit mehr als „ein paar Security Groups“: In AWS, Azure und GCP entsteht Sicherheit aus einer Kombination von verteilten L3/L4-Kontrollen (auf Workload- oder Subnetzebene), zentralen, stateful Firewall-Services, Web- und API-Schutz (WAF), DNS- und Egress-Policies sowie Governance über Richtlinien, Rollen und Protokollierung. Wer diese Bausteine sauber zusammensetzt, bekommt ein starkes Defense-in-Depth-Modell, das nicht an statischen IPs hängt, mit Autoscaling skaliert und auditierbar bleibt. Wer sie dagegen unkoordiniert nutzt, baut schnell ein Regelwerk aus Einzelfällen: überall offene 443-Regeln, unklare Ausnahmen, unzureichende Logs und keine konsistente Durchsetzung über Accounts/Subscriptions/Projekte hinweg. Dieser Artikel vergleicht Cloud Firewalling in AWS/Azure/GCP praxisnah: Welche Security Controls gibt es auf welcher Ebene, wofür eignen sie sich, wo liegen typische Fallstricke und wie wählen Sie das passende Modell für North-South- und East-West-Traffic, Mikrosegmentierung und kontrollierten Egress.
Ebenenmodell: So sollten Sie Cloud Firewalling grundsätzlich denken
Ein hilfreiches Modell ist die Aufteilung in vier Ebenen. Jede Cloud bietet dafür eigene Controls, die in der Praxis meist kombiniert werden.
- Workload-Ebene (distributed L3/L4): Regeln direkt an der VM/ENI/Interface-ähnlichen Ebene, oft stateful. Ziel: Mikrosegmentierung und Least Privilege.
- Subnetz/Netzwerk-Ebene (L3/L4, teils stateless): Kontrollen für Subnetze oder Netzsegmente. Ziel: zusätzliche Schutzschicht und grobe Guardrails.
- Zentrale Firewall-Ebene (stateful, teils L7): Managed Firewall-Services für East-West und North-South, inklusive Threat Prevention, TLS-Inspection oder URL-/Domain-Filter (je nach Plattform).
- Edge/L7-Ebene (WAF/DDoS/Bot): Schutz für Web/HTTP(S) und APIs nahe am Entry Point, häufig mit Rate Limiting, Bot-Management und Managed Rules.
Erfolg entsteht, wenn Sie pro Traffic-Typ festlegen, welche Ebene „führend“ ist: Mikrosegmentierung eher Workload/Netzwerk-Policies, Internet-Exposition eher WAF/Edge, Egress eher Proxy/DNS/Egress-Firewall und Governance über zentrale Policy-Verwaltung.
AWS: Security Groups, NACLs, AWS Network Firewall, WAF und DNS Firewall
AWS setzt stark auf den „Building Blocks“-Ansatz: Sie kombinieren Security Groups (workloadnah), Network ACLs (subnetznah), zentralen Stateful Firewall-Service (AWS Network Firewall), Webschutz (AWS WAF) und DNS-Kontrollen (Route 53 Resolver DNS Firewall). Das Modell ist flexibel, erfordert aber klare Architekturentscheidungen.
Workload-Ebene in AWS: Security Groups
Security Groups sind die Standardkontrolle für VMs/ENIs in AWS. Sie eignen sich besonders für Mikrosegmentierung, weil sie an Workloads hängen und nicht an Subnetze. In der Praxis sollten Sie Security Groups als „Primär-Firewall“ für Ost-West-Kommunikation zwischen Applikationstiers verstehen: Web→App, App→DB, Monitoring→Agents, Admin→Bastion.
- Stärken: Sehr nah am Workload, gut skalierbar, typischerweise stateful, ideal für serviceorientierte Allow-Listen.
- Typische Fehler: „All 443“ zwischen allen Tiers, große, wiederverwendete Gruppen ohne Ownership, fehlende Egress-Restriktion.
Subnetz-Ebene in AWS: Network ACLs
Network ACLs kontrollieren Traffic auf Subnetzebene. Sie sind eine zusätzliche Schicht, aber nicht der beste Ort für feingranulare App-Policies. Für die Grundlagen und Eigenschaften von NACLs ist die AWS-Dokumentation ein guter Einstieg: Network ACLs in Amazon VPC.
- Stärken: Guardrail-Schicht, z. B. „blocke bekannte bad ports“ an Subnetzen, einfache harte Grenzen.
- Typische Fehler: Zu viele Regeln, die eigentlich in Security Groups gehören; fehlende Dokumentation, schweres Troubleshooting.
Zentrale Firewall in AWS: AWS Network Firewall
AWS Network Firewall ist ein managed, stateful Firewall- und IDS/IPS-Service für VPCs. Er eignet sich besonders für zentrale Ingress/Egress-Pfade, Transit-Architekturen und East-West-Inspektion über zentrale Routingpunkte. Einstieg: AWS Network Firewall Dokumentation.
- Stärken: Stateful Inspection, zentraler Durchsetzungspunkt, skalierbar, gut für VPC-/Transit-orientierte Architekturen.
- Best Practice: Network Firewall dort einsetzen, wo Traffic ohnehin geroutet wird (z. B. über Transit Gateway/Inspection VPC), nicht als Ersatz für Security Groups.
DNS-Kontrolle in AWS: Route 53 Resolver DNS Firewall
DNS ist ein häufiger Umgehungspfad und zugleich ein starker Sensor. Route 53 Resolver DNS Firewall filtert ausgehende DNS-Abfragen über den VPC Resolver. Einstieg: DNS Firewall in Route 53 Resolver.
- Stärken: Domain-basierte Blockierung, Sinkhole-/Response-Optionen, gute Ergänzung zu Egress-Strategien.
- Typische Fehler: Kein Resolver-Enforcement (Clients nutzen externe Resolver), fehlende Ausnahmelogik, keine Rezertifizierung von Allow-Listen.
Edge/L7 in AWS: AWS WAF
Für Web- und API-Schutz ist AWS WAF das Standardangebot. Einstieg: AWS WAF Dokumentation.
- Stärken: Schutz gegen typische Web-Exploits und Bots, Managed Rules, Rate Limiting, Integration mit AWS-Edge-Services.
- Typische Fehler: WAF als Ersatz für Netzwerksegmentierung; fehlende Log-Integration ins SIEM; zu aggressive Regeln ohne Tuning.
Azure: NSG/ASG, Azure Firewall (Standard/Premium) und WAF
Azure verfolgt ebenfalls ein Ebenenmodell, unterscheidet aber stärker zwischen „verteilten“ Kontrollen (Network Security Groups) und dem zentralen Firewall-Service (Azure Firewall). Besonders relevant ist Azure Firewall Premium, wenn Sie TLS-Inspection, IDPS und URL-Kategorien benötigen.
Workload- und Subnetz-Ebene in Azure: Network Security Groups
NSGs sind Azure’s Standardkontrolle für Ingress/Egress auf Subnetz- und NIC-Ebene. Einstieg: Übersicht über Azure Netzwerksicherheitsgruppen.
- Stärken: Grundsegmentierung in VNets, klare Inbound/Outbound-Rules, gut für Mikrosegmentierung in Kombination mit Applikationsgruppierung.
- Praxis-Hinweis: Kombinieren Sie NSGs mit einer klaren Subnetz- und Applikationsstruktur, sonst werden Regeln schnell unübersichtlich.
Zentrale Firewall in Azure: Azure Firewall (Standard/Premium)
Azure Firewall ist der managed, zentrale Firewall-Service. Premium erweitert um TLS-Inspection, IDPS und URL-Filtering/Webkategorien. Einstieg: Azure Firewall Premium Features.
- Stärken: Zentraler Enforcement-Punkt, geeignet für Hub-and-Spoke, kontrollierten Egress, East-West-Inspektion über zentrale Pfade.
- Premium-Mehrwert: TLS-Inspection und IDPS sind besonders relevant für hochregulierte Umgebungen und für „C2 über HTTPS“-Erkennung.
- Typische Fehler: Zu viel Traffic ohne Kapazitäts- und Routingplanung über die Firewall ziehen; TLS-Inspection ohne klare Exclusions und Datenschutz-Governance.
Edge/L7 in Azure: Web Application Firewall
Für Webschutz ist Azure WAF typischerweise an Application Gateway oder Front Door angebunden (je nach Architektur). Das Muster ist ähnlich wie in AWS/GCP: L7-Schutz am Entry Point, L3/L4-Kontrollen im Netzwerk, plus zentrale Firewall für Egress/Inspection.
GCP: VPC Firewall Rules, hierarchische Firewall Policies und Cloud Armor
Google Cloud setzt stark auf VPC Firewall Rules als Basis und ergänzt diese zunehmend durch hierarchische und zentrale Firewall-Policy-Modelle, die über mehrere VPCs und Regionen hinweg konsistent wirken. Für Web/Edge-Schutz ist Cloud Armor die zentrale Komponente.
Basis in GCP: VPC Firewall Rules
VPC Firewall Rules sind die Standardkontrolle in GCP für L3/L4-Verkehr. Einstieg: VPC Firewall Rules in Google Cloud.
- Stärken: Zentrale Regeln pro VPC, gute Basis für Segmentierung, klare Komponenten (Protokoll, Ports, Quellen/Ziele).
- Typische Fehler: Übermäßige Nutzung von breit gefassten Regeln, unklare Targeting-Strategie, fehlende Governance über viele Projekte hinweg.
Governance/Scale in GCP: Hierarchical Firewall Policies
Für größere Organisationen ist die Hierarchie entscheidend: Policies sollen über Projekte/Netzwerke hinweg konsistent durchsetzbar sein. Einstieg: Hierarchical Firewall Policies.
- Stärken: Zentrale Durchsetzung über die Ressourcenhierarchie, bessere Kontrolle als rein projektlokale Regeln, geeignet für globale Guardrails.
- Praxis-Hinweis: Nutzen Sie hierarchische Policies für „Muss“-Regeln (No-Go-Pfade, Mindeststandards) und VPC-Regeln für applikationsnahe Details.
Edge/L7 in GCP: Cloud Armor
Cloud Armor ist der Edge-Schutz für Web-Backends und unterstützt Allow/Deny, Rate Limiting und weiterführende Richtlinienkonzepte (inklusive hierarchischer Policies). Einstieg: Cloud Armor Security Policies sowie Hierarchische Sicherheitsrichtlinien in Cloud Armor.
- Stärken: Edge-nahe Durchsetzung, reduziert Last auf VPC/Backends, gute Grundlage für Bot-/Abuse- und Layer-7-Schutz.
- Typische Fehler: WAF ohne saubere Logging-/Tuning-Schleifen; fehlende Abgrenzung zwischen Edge-Rate-Limits und Netzwerk-Rate-Limits.
Direktvergleich: Welche Controls decken welche Anforderungen ab?
Ein sinnvoller Vergleich fokussiert nicht auf Produktnamen, sondern auf Fähigkeiten. Die folgende Einordnung hilft bei der Auswahl.
- Mikrosegmentierung (Workload-nah):
- AWS: Security Groups (serviceorientiert, workloadnah)
- Azure: NSGs (Subnetz/NIC), kombiniert mit Applikations-/Team-Struktur
- GCP: VPC Firewall Rules mit klarer Zieldefinition, ergänzt durch hierarchische Policies für Standards
- Zentrale Inspektion (stateful, optional L7):
- AWS: AWS Network Firewall als zentraler Inspection-Service
- Azure: Azure Firewall, Premium für TLS-Inspection/IDPS (siehe Premium Features)
- GCP: Policy-basierte zentrale Modelle (Firewall Policies) plus ergänzende Security-Produkte je Architektur
- Web-/API-Schutz am Edge (WAF):
- AWS: AWS WAF (Dokumentation)
- Azure: Azure WAF an Gateway-/Edge-Komponenten
- GCP: Cloud Armor (Überblick)
- DNS-basierte Egress-Kontrolle:
- AWS: Route 53 Resolver DNS Firewall (Dokumentation)
- Azure/GCP: DNS-Kontrollen meist über Resolver-Design, Policies und Security-Services; in der Praxis oft kombiniert mit Proxy/SSE
- Organisationweite Guardrails:
- AWS: Zentralisierung typischerweise über Accounts/Organizations plus zentrale Policy-/Firewall-Architektur
- Azure: Governance über Subscriptions/Management Groups plus zentrale Firewall/Hubs
- GCP: Hierarchische Policies über Resource Hierarchy (Firewall Policies)
Architekturpatterns, die in allen drei Clouds funktionieren
Unabhängig vom Cloud-Provider sind bestimmte Muster in der Praxis besonders stabil und gut zu betreiben.
Pattern: „Workload Allowlisting + zentraler Inspection Hub“
- Workload: Feingranulare Allow-Listen (Security Groups/NSGs/VPC Rules) für East-West.
- Hub: Zentraler Firewall-/Inspection-Pfad für North-South und ausgewählte East-West-Pfade (z. B. Shared Services, Partner).
- Mehrwert: Mikrosegmentierung bleibt nah an der App, zentrale Kontrolle bleibt dort, wo Routing ohnehin konzentriert ist.
Pattern: „Egress nur über kontrollierte Ausgänge“
- DNS Enforcement: Nur definierte Resolver, Domain-Filter (wo verfügbar) und Logging.
- HTTP(S) über Proxy/SWG/SSE: Direkte 443-Verbindungen aus kritischen Zonen minimieren, um C2 und Exfil zu erschweren.
- Allowlisting für Server: Updates/APIs/Partnerziele explizit; kein generisches „Internet für Server“.
Pattern: „Edge-WAF + interne Segmentierung“
- Edge: WAF/Rate Limiting/Bot-Controls vor Web-Backends.
- Innen: Strikte East-West-Policies zwischen Web/App/DB und klare Admin-Pfade.
- Mehrwert: Web-Angriffe werden früh gefiltert, selbst erfolgreiche Initial-Access-Versuche treffen auf begrenzte Lateralmovement-Flächen.
Logging und Detection: Cloud Firewalling ist nur so gut wie die Telemetrie
Ein häufiger Grund für Sicherheitslücken ist nicht „fehlende Regeln“, sondern fehlende Sichtbarkeit. In Cloud-Umgebungen sollten Sie von Anfang an festlegen, welche Events Sie für Incident Response benötigen:
- Policy-Entscheidungen: Allow/Deny mit Rule-ID/Rule-Name, Quell-/Zielkontext, Zonen/Segmente.
- NAT-Attribution: Pre-/Post-NAT und Ports, damit externe Ziele intern zugeordnet werden können.
- Threat-Events: IDS/IPS/WAF-Events mit Severity, Signatur/Rule-ID, Action.
- Admin/Audit: Wer hat Regeln geändert? Wann? Unter welcher Change-ID?
Die technische Umsetzung unterscheidet sich je Cloud, aber das Prinzip bleibt gleich: Normalisierung ins SIEM, klare Retention, Data-Quality-KPIs und Runbooks für High-Signal Alerts.
Typische Fehlannahmen beim Cloud Firewalling
- „Security Groups/NSGs reichen immer“: Für Mikrosegmentierung ja, für zentrale Inspection, Egress-Kontrolle und Governance meist nicht.
- „WAF ersetzt Netzwerksegmentierung“: WAF schützt HTTP(S), aber nicht Lateralmovement, Admin-Pfade oder nicht-webbasierte Protokolle.
- „Egress ist nicht so wichtig“: C2 und Exfil laufen fast immer nach außen; kontrollierter Egress ist einer der stärksten Sicherheitshebel.
- „IP-Blocklisten lösen Cloud-Abuse“: In Cloud/CDN-Welten sind Domain-/Kategorie- und identitätsbasierte Policies oft präziser als IP-Blocklisten.
- „Governance kommt später“: Ohne Policy-Hierarchien, Naming-Standards und Ownership entsteht schnell Rule Sprawl.
Praktische Checkliste: AWS/Azure/GCP Controls sinnvoll kombinieren
- 1) Ebenenmodell festlegen: Workload (micro) vs. zentral (inspection) vs. edge (WAF) vs. DNS/Egress.
- 2) Mikrosegmentierung definieren: Tier-Modelle (web/app/db), Admin-Isolation, No-Go-Zonen.
- 3) Egress-Strategie bauen: DNS Enforcement, Proxy/SWG für HTTP(S), Allowlisting für Server-Workloads.
- 4) Zentrale Inspection nur dort, wo es Sinn ergibt: Hub-and-Spoke/Transit-Architektur, Shared Services, Partnerpfade.
- 5) Edge schützen: WAF/Rate Limiting/Bot-Controls vor Internet-exponierten Backends.
- 6) Governance etablieren: Naming, Tags/Labels, Ownership, Rezertifizierung, Change-Workflows.
- 7) Telemetrie sichern: Allow/Deny, NAT, Threat/WAF-Events, Admin-Audit; SIEM-Normalisierung und Retention.
- 8) Regelmäßig testen: Purple-Team- oder Attack-Simulationen, um Coverage und Signalqualität zu validieren.
Outbound-Links für offizielle Dokumentation und Vertiefung
- AWS Network Firewall Dokumentation
- Route 53 Resolver DNS Firewall
- Amazon VPC Network ACLs
- AWS WAF Dokumentation
- Azure Network Security Groups (NSG)
- Azure Firewall Premium Features (TLS-Inspection/IDPS)
- Google Cloud VPC Firewall Rules
- Google Cloud Hierarchical Firewall Policies
- Google Cloud Armor Security Policies
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.
