CloudFront mit WAF und Lambda@Edge

AWS WAF (Web Application Firewall) filtert und überwacht HTTP-/HTTPS-Anfragen, die Ihre CloudFront-Distribution erreichen. Indem Sie Ihrer Distribution eine WAF-Web ACL zuordnen, können Sie häufige Web-Exploits wie SQL-Injection, Cross-Site-Scripting (XSS), schädliche Bots und Angriffe aus den OWASP Top 10 blockieren, bevor sie Ihren Origin erreichen.

WAF arbeitet am CloudFront-Edge. Dadurch werden schädliche Anfragen am nächstgelegenen Edge-Standort abgewiesen, anstatt Ihren ALB oder Anwendungsserver zu erreichen. Das reduziert die Last auf Ihrem Backend und stoppt Angriffe näher am Angreifer.

Eine WAF-Web-ACL enthält geordnete Regeln und Regelgruppen, die jeweils Anfrageattribute abgleichen und eine Aktion ausführen (Allow, Block, Count, CAPTCHA). Die Regeln werden in Prioritätsreihenfolge ausgewertet; die Aktion der ersten passenden Regel wird angewendet.

AWS stellt verwaltete Regelgruppen bereit – vorgefertigte Regelsätze, die von AWS und Anbietern im AWS Marketplace gepflegt werden. Das AWS Managed Rules - Core Rule Set deckt die OWASP Top 10 ohne Konfiguration ab. AWS aktualisiert verwaltete Regelgruppen, sobald neue Bedrohungen auftreten, wodurch Ihr Betriebsaufwand sinkt.

Ratenbasierte Regeln in WAF zählen die Anfragen jeder Quell-IP-Adresse innerhalb eines Zeitfensters von 5 Minuten. Überschreitet eine IP-Adresse den Schwellenwert (z. B. 2.000 Anfragen in 5 Minuten), blockiert WAF weitere Anfragen dieser IP-Adresse, bis die Rate wieder sinkt. Ratenbasierte Regeln schützen vor Brute-Force-Angriffen, Credential-Stuffing und einfachen DDoS-Scraping-Angriffen.

AWS WAF Bot Control ist eine verwaltete Regelgruppe, die Datenverkehr in Kategorien einteilt: verifizierte Bots (Googlebot, Bingbot), Scraper, Überwachungstools und menschlicher Datenverkehr. Sie können pro Kategorie unterschiedliche Aktionen konfigurieren – Suchmaschinen-Bots zulassen, unbekannte Bots mit CAPTCHA überprüfen und bösartige Scraper blockieren.

Der Geltungsbereich von WAF-Web-ACLs ist entweder CLOUDFRONT (global, für die Verwendung mit CloudFront) oder REGIONAL (für die Verwendung mit ALB, API Gateway, AppSync oder Cognito User Pools in einer bestimmten Region). CloudFront-Scoped-WAF-ACLs müssen unabhängig vom Ursprungsort des Datenverkehrs in der Region us-east-1 erstellt werden, da CloudFront von dieser Region aus verwaltet wird.

Dies ist ein wichtiger Prüfungsfallstrick: Wenn Sie eine WAF-Web-ACL in eu-west-1 erstellen und versuchen, sie CloudFront zuzuordnen, schlägt die Zuordnung fehl. Erstellen Sie CloudFront-WAF-ACLs immer in us-east-1.

Lambda@Edge ermöglicht es Ihnen, Node.js- oder Python-Lambda-Funktionen als Reaktion auf CloudFront-Ereignisse an CloudFront-Edge-Standorten auszuführen. Die Funktionen werden innerhalb von Millisekunden nach der Anfrage des Benutzers ausgeführt, ohne den Datenverkehr zur Verarbeitung an eine zentrale Region zurückzuleiten.

Lambda@Edge-Funktionen werden in der Region us-east-1 bereitgestellt, aber automatisch weltweit auf alle CloudFront-Edge-Standorte repliziert. Dadurch wird Ihr Code so nah wie möglich am Benutzer ausgeführt. So können Sie Personalisierung, Authentifizierung und A/B-Tests am Edge mit minimaler zusätzlicher Latenz umsetzen.

Lambda@Edge-Funktionen können CloudFront-Anfragen und -Antworten an vier Punkten im Lebenszyklus abfangen:

• Viewer Request: nachdem CloudFront die Anfrage vom Betrachter erhalten hat, aber vor der Cache-Prüfung – für Authentifizierung, Weiterleitungen und die Manipulation von Headern
• Origin Request: nach einem Cache Miss, aber vor der Weiterleitung an den Origin – für URL-Umschreibungen und benutzerdefinierte Header zum Origin
• Origin Response: nach dem Empfang der Antwort vom Origin, aber vor ihrer Speicherung im Cache – zum Hinzufügen von Sicherheits-Headern und Ändern der Antwort
• Viewer Response: bevor CloudFront die Antwort an den Betrachter sendet – zum Hinzufügen oder Ändern von Antwort-Headern

AWS bietet zwei Edge-Computing-Optionen mit unterschiedlichen Vor- und Nachteilen:

• CloudFront Functions: Ausführung in weniger als einer Millisekunde, nur JavaScript, äußerst geringe Kosten (etwa ein Sechstel des Preises), nur bei den Ereignissen Viewer Request und Viewer Response, Rechenzeitlimit von 1 ms, kein Zugriff auf VPC oder Netzwerk
• Lambda@Edge: bis zu 30 Sekunden Ausführungszeit (Viewer) bzw. 30 Sekunden (Origin), Node.js oder Python, alle vier Auslösepunkte, kann Netzwerkanfragen stellen und auf Anfrage- bzw. Antworttext zugreifen

Verwenden Sie CloudFront Functions für einfache Header-Manipulation, URL-Normalisierung und die Berechnung des Cache-Schlüssels. Verwenden Sie Lambda@Edge für komplexe Logik, die Netzwerkanfragen, längere Berechnungen oder Verarbeitung auf Origin-Seite erfordert.

Häufige Lambda@Edge-Muster in der SAA-C03-Prüfung:

• JWT-Validierung am Edge: Eine Viewer-Request-Funktion validiert einen Authorization-Header; nicht autorisierte Anfragen erhalten 401, ohne den Origin zu erreichen
• A/B-Tests: Viewer Request weist Benutzer der Gruppe A oder B zu (über ein Cookie) und ändert die Anfrage, um /a/page.html oder /b/page.html abzurufen
• URL-Umschreibung: Origin Request schreibt benutzerfreundliche URLs in die tatsächlichen Dateipfade in S3 um
• Dynamische Bildgrößenänderung: Origin Request erstellt eine Anfrage an eine Lambda-Funktion zur Bildverarbeitung; Origin Response speichert das skalierte Bild im Cache
• HTTP-Sicherheits-Header: Viewer Response fügt CSP-, HSTS- und X-Frame-Options-Header ein

Lambda@Edge unterliegt im Vergleich zu Standard-Lambda mehreren Einschränkungen:

• Funktionen müssen in der Region us-east-1 liegen
• Keine VPC-Unterstützung (kein Zugriff auf Ressourcen in einer VPC)
• Keine Umgebungsvariablen (Konfiguration in den Funktionscode einbetten oder beim Kaltstart aus dem Parameter Store abrufen)
• Lambda Layers können nicht verwendet werden
• Timeout für Viewer-Ereignisse: 5 Sekunden; Timeout für Origin-Ereignisse: 30 Sekunden
• Limit für die Größe des Deployment-Pakets: 1 MB (Viewer-Ereignisse) / 50 MB (Origin-Ereignisse)

Aufgrund dieser Einschränkungen eignet sich Lambda@Edge nicht für lang laufende Berechnungen, VPC-abhängige Vorgänge oder Funktionen, die pro Deployment eine dynamische Konfiguration benötigen.

WAF und Lambda@Edge übernehmen unterschiedliche Sicherheitsaufgaben und ergänzen sich:

• WAF: blockiert signaturbasierte Angriffe (SQL-Injection, XSS, bekannte Angreifer und übermäßige Anfrageraten) – verwaltete Regeln behandeln häufige Angriffe automatisch
• Lambda@Edge: benutzerdefinierte Sicherheitslogik für Geschäftsanforderungen (JWT-Validierung, Sitzungsprüfungen und Überprüfung von Zugriffstoken) – flexibel, erfordert jedoch Entwicklungsaufwand

Eine Architektur nach dem Prinzip der Tiefenverteidigung: Der WAF blockiert zunächst bekannte Angriffsmuster; Lambda@Edge validiert die Authentifizierung auf Geschäftsebene; signierte URLs und Cookies von CloudFront beschränken den Inhaltszugriff; OAC hält S3 privat. Jede Ebene verhindert unabhängig eine andere Angriffsklasse.

Überwachen Sie Ihre Edge-Sicherheitsebene mit diesen Tools:

• WAF-Logs: Aktivieren Sie die vollständige Anforderungsprotokollierung für S3, CloudWatch Logs oder Kinesis Firehose, um zu sehen, welche Regeln zutreffen und welcher Datenverkehr blockiert wird
• WAF-Metriken: BlockedRequests, AllowedRequests und CountedRequests pro Regel in CloudWatch
• Lambda@Edge-Logs: CloudWatch-Logs-Gruppen werden in jeder Region erstellt, in der die Funktion ausgeführt wird; verwenden Sie CloudWatch Insights, um regionsübergreifend Abfragen auszuführen
• CloudFront-Echtzeitprotokolle: Streamen Sie Zugriffsprotokolle zur sofortigen Analyse an Kinesis (im Gegensatz zu Standardzugriffsprotokollen, die alle paar Minuten gesammelt werden)

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: AWS WAF blockiert häufige Webangriffe am CloudFront-Edge mithilfe verwalteter und benutzerdefinierter Regelgruppen, Lambda@Edge führt weltweit benutzerdefinierten Code an vier CloudFront-Triggerpunkten aus und CloudFront Functions ermöglichen eine Ausführung im Submillisekundenbereich für einfache Logik auf Viewer-Seite. WAF-ACLs für CloudFront müssen in us-east-1 erstellt werden. Als Nächstes beschäftigen wir uns mit Application Load Balancers, Network Load Balancers und Gateway Load Balancers.