Im November 2020 hat AWS die "AWS Network Firewall" angekündigt. Bei dieser wachsenden Zahl an Firewalls verliert man schnell den Überblick – dieser Beitrag soll für Klarheit sorgen.
Wir beginnen mit einem Vergleich der AWS Firewalls und ähnlicher Netzwerk-Schutzsysteme, ihrer jeweiligen Einsatzszenarien sowie der Angriffe, vor denen sie schützen, und der Regeln, mit denen sie Bedrohungen erkennen.
Im Anschluss zeigen wir die typischen Anwendungsfälle anhand einer Geschichte – passend zum Wachstum Ihrer Anwendung und ihrer steigenden geschäftlichen Bedeutung.
Wann welcher AWS Firewall-Service zum Einsatz kommt
Wir starten ganz unten – auf der untersten Infrastrukturebene – und arbeiten uns nach oben. Genau so sollten Sie auch Ihre Verteidigung aufbauen.
Security Groups
Security Groups schützen Elastic Network Interfaces, die in der Regel an EC2-Instanzen, aber auch an andere Services wie RDS oder Lambda in einer VPC angebunden sind. Sie schützen beispielsweise vor unautorisierten SSH-Verbindungen und blockieren Zugriffe anhand von Quell- und Ziel-Ports sowie IP-Bereichen. Definieren Sie Security Groups immer dann, wenn Sie Instanzen erstellen, und gewähren Sie nur den minimal notwendigen Zugriff.
Network ACLs
Network ACLs schützen Subnetze, etwa vor unautorisierten Datenbankzugriffen, die nicht vom Backend-Server stammen. Wie Security Groups blockieren sie Zugriffe anhand von Quell- und Ziel-Ports sowie IP-Bereichen. NACLs sollten Sie definieren, sobald Sie Ihre Systeme funktional in Subnetze aufteilen – also typischerweise bei der Definition Ihrer Tiers. Mit NACLs dürfen Subsysteme entsprechend ihrer Rolle in der Architektur auf andere zugreifen, sofern die Subnetze entsprechend strukturiert sind.
Kubernetes Network Policies
Kubernetes Network Policies schützen Anwendungen im Elastic Kubernetes Service. Wie Security Groups und NACLs blockieren sie Zugriffe anhand von Quell- und Ziel-Ports sowie IP-Bereichen. Darüber hinaus können sie auch Kubernetes-Labels nutzen und so eine feingranulare, funktionale Zugriffskontrolle ermöglichen. Definieren Sie diese Network Policies bei allen Kubernetes-Setups, die über die einfachsten Service-Konstellationen hinausgehen.
Network Firewalls
Network Firewalls schützen sämtliche Netzwerke einer Organisation – etwa vor Trojaner-Bots, die Daten exfiltrieren. Sie blockieren Zugriffe anhand standardisierter, herunterladbarer Regelsätze. Wie bei Security Groups und NACLs umfassen diese Regelsätze Signaturen, die durch Quell- und Ziel-Ports sowie IP-Bereiche definiert sind. Zusätzlich beherrschen sie Deep Packet Inspection und können so auch nach Domains, URLs und Protokollen filtern (sofern TLS vor der Network Firewall terminiert wird). Setzen Sie Network Firewalls dann ein, wenn Sie organisationsweit konsistente Richtlinien für Intrusion Detection und Protection benötigen.
AWS Shield Standard
AWS Shield Standard schützt Web-Apps und APIs vor DDoS-Angriffen. Es blockiert Zugriffe anhand von HTTP(S)-Verkehrsmustern, einschließlich Häufigkeit und Quelle der Aufrufe. Aktivieren Sie AWS Shield Standard für jede öffentliche Web-App mit geschäftlicher Relevanz. (Es ist kostenlos und für einige Ressourcen standardmäßig aktiviert.)
AWS Shield Advanced
AWS Shield Advanced bietet dasselbe wie Standard, ergänzt um umfangreicheres Monitoring, eine Kostenerstattung bei Angriffen und – am wichtigsten – ein erfahrenes Operations-Team aus echten Menschen. AWS Shield Advanced lohnt sich für geschäftskritische Web-Apps, sofern die Mehrkosten gegenüber Standard im richtigen Verhältnis stehen.
Web Application Firewall
Die Web Application Firewall (WAF) schützt Web-Apps vor Cross-Site Scripting, SQL Injection, Insecure Direct Object References und weiteren Bedrohungen aus der OWASP-Liste. Sie erkennt und blockiert Zugriffe anhand von Signaturen, die durch Muster in Headern oder im Body von HTTP(S)-Anfragen definiert sind. Eine WAF empfiehlt sich, solange Sie bekannte Schwachstellen Ihrer Anwendung noch beheben, wenn Sie verwundbare Anwendungen einsetzen, deren Code Sie nicht kontrollieren, oder wenn Sie bei minimalen Schwachstellen einfach auf Nummer sicher gehen wollen.
Instanzen mit Security Groups, Subnetze mit NACLs, eine Multi-Network-Organisation mit Network Firewall. AWS Shield gegen DDoS und WAF schützen die Eintrittspunkte.
Eine Geschichte über Firewalls
Um zu zeigen, wie Sie mit dem Wachstum Ihrer Anwendung verschiedene Firewalls einführen, hier eine Geschichte mit typischen Anwendungsfällen.
Pat hat gerade angefangen, eine Web-Anwendung für ihr Startup zu entwickeln. Sie ist etwas altmodisch und entscheidet sich für einen einfachen Proof of Concept auf einer einzigen EC2-Instanz. Sie richtet eine Security Group als Firewall auf Instanzebene ein, die nur Zugriffe auf den Ports 80 und 443 zulässt – damit HTTP/S-Anfragen durchkommen – sowie auf Port 22 für den IP-Bereich ihres Büros, damit sie die Instanz per SSH administrieren kann. Damit hat sie die Instanz vor Angreiferzugriffen auf anderen Ports als 80 oder 443 geschützt und jeglichen SSH-Zugriff von nicht autorisierten IP-Adressen blockiert.
Ihr Proof of Concept ist in dieser frühen Phase bereits gegen viele Angriffstypen geschützt. Doch je komplexer Netzwerk und Anwendung werden und je größer ihre geschäftliche Bedeutung wird, desto mehr Verteidigungsschichten braucht sie.
Um vom einfachen Proof of Concept zu einer robusten n-Tier-Anwendung zu kommen, richtet sie eine Datenbank ein und trennt Frontend- und Backend-Server. Jedes Tier bekommt ein eigenes Subnetz. Sie konfiguriert Network Access Control Lists (NACLs) als Firewall am Subnetz-Eingang, sodass HTTP/S-Anfragen das Frontend-Subnetz erreichen, das Frontend auf das Backend zugreifen darf, das Backend auf die Datenbank – und sonst nichts.
Skalierbarkeit hat ihre Grenzen. Und selbst wenn die Anwendung unter Last weiterläuft, würde ein DDoS-Angriff die Kosten in die Höhe treiben. Deshalb führt sie AWS Shield Standard ein, das kostenlos ist. Das ist ein angemessener DDoS-Schutz. Viel später, wenn die Anwendung stark gewachsen ist und eine wichtige Einnahmequelle darstellt, könnten sich auch die Mehrkosten von AWS Shield Advanced lohnen. Das Advanced-Produkt bietet vor allem ein erfahrenes Operations-Team von AWS – ein nützlicher Hinweis auf das Wesen von Security generell: Die Bedrohung geht von klugen Köpfen aus, die ständig neue Angriffswege finden, und deshalb brauchen Sie ebenso kluge Köpfe, die jederzeit den richtigen Verteidigungsweg finden.
Pat portiert die Anwendung zur einfacheren Orchestrierung und Verwaltung auf den Elastic Kubernetes Service. Hier legt die Kubernetes Network Policy fest, welche Kubernetes-Services andere Services kontaktieren dürfen, und ermöglicht so eine feingranularere funktionale Zugriffskontrolle als mit Subnetzen.
Penetrationstests der Anwendung decken eine Reihe von Schwachstellen aus der OWASP-Liste auf, darunter Insecure Direct Object References, Cross-Site Scripting und SQL Injection. Pat und das Entwicklungsteam ergänzen daher die AWS Web Application Firewall und priorisieren parallel die nötigen Fixes sowie langfristige Security-Maßnahmen im Entwicklungsteam.
Schließlich kommt der große Tag: Exit! Das Startup wird von einem großen Konzern übernommen. Die Anwendung wird Teil eines größeren Application Portfolios, das Netzwerk Teil einer komplexen Infrastruktur mit mehreren VPCs und On-Premises-Netzwerken, die von verschiedenen Organisationseinheiten verwaltet werden. Um all das geschützt zu halten, hat der Konzern organisationsweit konsistente Netzwerkrichtlinien vorgegeben. Die AWS Network Firewall kommt hinzu, um Zugriffe anhand standardisierter Regelsätze für Ports, IP-Adressen, Domains, URLs und Protokolle einzuschränken. Sie schützt nicht nur vor denselben Angriffen wie Security Groups und Network ACLs, sondern erkennt und verhindert auch das Eindringen von Trojaner-Bots oder menschlichen Hackern, die Code im Netzwerk ausführen und Daten manipulieren oder exfiltrieren.
Große Organisationen brauchen einen zentralen Ansatz, um ihre Ressourcen und Richtlinien zu verwalten – ein System ist nur so stark wie sein schwächstes Glied. Der AWS Firewall Manager kommt ins Spiel, um Network Firewalls, WAFs und andere Systeme zu verwalten und einen organisationsweit konsistenten Schutz sicherzustellen.
Ich hoffe, das schafft Klarheit im Firewall-Dschungel von AWS. Wenn Sie Fragen haben, stellen Sie sie gerne in den Kommentaren.
— —
Vielen Dank an meinen Kollegen Dr. Artem Shchodro für seine wertvollen Anmerkungen.