Microservices laufen häufig in privaten Subnetzen einer Amazon Virtual Private Cloud (VPC), um sie zu isolieren und vor direktem Zugriff aus dem Internet zu schützen. Für den externen Zugriff auf Microservices haben sich zwei Ansätze etabliert:
- Private Link: Ein Networking-Feature, das private VPC-Ressourcen über Interface-Endpoints sicher an das API Gateway anbindet, ohne sie im öffentlichen Internet preiszugeben. Der Traffic bleibt dabei vollständig im AWS-Netzwerk.
- HTTP Integration (Internet-facing): Das API Gateway leitet Anfragen an öffentlich erreichbare HTTP-Endpunkte weiter – etwa an einen internet-facing Application Load Balancer (ALB) –, sodass Services über einen öffentlichen Endpunkt erreichbar sind.
Im Folgenden geht es darum, den zweiten Ansatz abzusichern – einen internet-facing ALB hinter einem API Gateway. Konkret zeigen wir, wie sich der direkte Zugriff auf den öffentlichen ALB unterbinden lässt, sodass vertrauenswürdige Clients ausschließlich über das API Gateway mit der Anwendung kommunizieren.
Die Ausgangslage
Wird ein internet-facing ALB per HTTP Integration hinter einem API Gateway konfiguriert, ist der ALB öffentlich erreichbar. Vertrauenswürdige Clients greifen zwar über das API Gateway auf die Anwendung zu, doch dieses Setup birgt ein erhebliches Sicherheitsrisiko: Der öffentliche Endpunkt des ALB lässt sich direkt ansprechen – und umgeht damit sämtliche Sicherheitsmechanismen des API Gateway.
Aus dieser Lücke ergeben sich gleich mehrere Angriffsvektoren. Wer Sicherheit und Integrität seiner Anwendung gewährleisten will, muss den direkten Zugriff auf den ALB konsequent unterbinden. Erst wenn der gesamte Traffic über das API Gateway läuft, lassen sich zentrale Schutzmechanismen wie Request-Validierung, Throttling, Authentifizierung und Autorisierung wirksam durchsetzen. Fehlen diese Schutzschichten, können Angreifer Schwachstellen ausnutzen, Authentifizierungen umgehen und Backend-Services mit Last überfluten – bis hin zu Denial-of-Service-Angriffen (DoS).
AWS bietet hierfür zwar eine Lösung mit REST API Gateway und AWS Web Application Firewall (WAF), die Anfragen ohne einen bestimmten Header blockiert. Dieser Weg bringt allerdings zusätzliche Komplexität und Kosten mit sich. Für Szenarien mit höheren Sicherheitsanforderungen – etwa Schutz vor SQL-Injection, Cross-Site-Scripting (XSS) oder Bot-Mitigation – bleibt AWS WAF selbstverständlich ein leistungsstarkes Werkzeug.
In diesem Beitrag stellen wir eine schlankere und günstigere Alternative vor. Mit Custom Headers und ALB-Rule-Conditions erreichen Sie dasselbe Sicherheitsniveau – ganz ohne AWS WAF. Die Methode funktioniert nahtlos mit REST- wie auch HTTP-API-Gateways und senkt den operativen Aufwand spürbar.
**Lösungsansatz**
Der Ansatz macht AWS WAF überflüssig, indem er die Content-basierten Routing-Funktionen des ALB nutzt. Die Lösung besteht aus drei Schritten:
- Im API Gateway wird ein Custom Header samt Wert zu jeder HTTP-Anfrage hinzugefügt.
- Die ALB-Regeln werden so konfiguriert, dass sie diesen Header validieren. Nur Anfragen mit dem korrekten Header und Wert greifen auf die gewünschten ALB-Regeln; alle anderen landen bei der Default-Rule.
- Die Default-Rule wird so eingestellt, dass sie einen HTTP-Fehlercode wie 403 Forbidden zurückgibt.
Hier ein High-Level-Überblick über die Architektur:
Ablauf einer HTTP-Anfrage.
**Schritt-für-Schritt-Implementierung**
Schritt 1: Custom Header im API Gateway definieren
Bei einem HTTP API Gateway passen Sie die an die ALB-Integration gesendeten Anfragen über Parameter Mappings an.
- Öffnen Sie die API-Gateway-Konsole.
- Navigieren Sie zu Ihrer HTTP API.
- Wechseln Sie im Bereich "Integrations" zu "Manage Integrations".
- Legen Sie ein Parameter Mapping an, das den Custom Header samt Wert ergänzt.
Konfiguration des Parameter Mappings.
Bei einem REST-basierten API Gateway folgen Sie diesem Link, um einen benutzerdefinierten HTTP-Header zu ergänzen.
Schritt 2: ALB-Regeln konfigurieren
- Öffnen Sie die ALB-Konfiguration in der EC2-Konsole.
- Für jede Listener-Regel (außer der Default-Rule):
- Fügen Sie eine AND-Bedingung hinzu.
- Wählen Sie "HTTP header" als Bedingungstyp.
- Tragen Sie Header-Namen und erwarteten Wert ein.
3. Stellen Sie die Default-Rule so ein, dass sie eine HTTP-Fehlerantwort zurückgibt (z. B. 403 Forbidden).
Bedingungen und Aktionen der ALB-Regel.
Mehr zum Content-basierten Routing auf dem ALB lesen Sie in diesem Blogartikel von AWS.
Schritt 3: Konfiguration testen
- Schicken Sie eine Anfrage ohne den Custom Header an den ALB. Prüfen Sie, ob die Default-Rule greift und die Fehlerantwort ausgeliefert wird.
- Schicken Sie eine Anfrage über das API Gateway. Prüfen Sie, ob sie an die Anwendung weitergeleitet wird.
**Fazit**
Die vorgestellte Lösung vereinfacht die Architektur, da sie ohne AWS WAF auskommt. Über die integrierten Content-basierten Routing-Funktionen des ALB lässt sich der direkte Zugriff auf Ihren Application Load Balancer sicher und effizient unterbinden.
Sie möchten mehr erfahren oder interessieren sich für unsere Services? Sprechen Sie uns gern an – Sie erreichen uns hier.