Site icon bintorosoft.com

Cloud Firewalling: AWS/Azure/GCP Security Controls im Vergleich

Red Snapper

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.

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.

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.

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.

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.

Edge/L7 in AWS: AWS WAF

Für Web- und API-Schutz ist AWS WAF das Standardangebot. Einstieg: AWS WAF Dokumentation.

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.

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.

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.

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.

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.

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.

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“

Pattern: „Egress nur über kontrollierte Ausgänge“

Pattern: „Edge-WAF + interne Segmentierung“

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:

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

Praktische Checkliste: AWS/Azure/GCP Controls sinnvoll kombinieren

Outbound-Links für offizielle Dokumentation und Vertiefung

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:

Lieferumfang:

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.

 

Exit mobile version