CloudFront med WAF og Lambda@Edge

AWS WAF (Web Application Firewall) filtrerer og overvåger HTTP/HTTPS-anmodninger, der når din CloudFront-distribution. Ved at knytte en WAF-Web ACL til din distribution kan du blokere almindelige webudnyttelser – SQL-injektion, cross-site scripting (XSS), skadelige bots og OWASP Top 10-angreb – før de når din oprindelse.

WAF fungerer ved CloudFronts edge-lokation, hvilket betyder, at skadelige anmodninger afvises ved den nærmeste edge-lokation i stedet for at nå din ALB eller applikationsserver. Det reducerer belastningen på din backend og stopper angreb tættere på angriberen.

En WAF Web ACL indeholder ordnede regler og regelgrupper, som hver matcher anmodningsattributter og udfører en handling (Allow, Block, Count, CAPTCHA). Reglerne evalueres i prioritetsrækkefølge, og handlingen for den første matchende regel anvendes.

AWS stiller administrerede regelgrupper til rådighed – forudbyggede regelsæt, der vedligeholdes af AWS og sælgere på AWS Marketplace. AWS Managed Rules - Core Rule Set dækker OWASP Top 10 uden konfiguration. AWS opdaterer administrerede regelgrupper, når nye trusler opstår, hvilket reducerer din driftsbyrde.

Hastighedsbaserede regler i WAF tæller anmodninger fra hver kilde-IP-adresse over et vindue på 5 minutter. Hvis en IP-adresse overskrider tærsklen (f.eks. 2.000 anmodninger pr. 5 minutter), blokerer WAF yderligere anmodninger fra den pågældende IP-adresse, indtil hastigheden falder. Hastighedsbaserede regler beskytter mod brute force, credential stuffing og simple DDoS-scrapingangreb.

AWS WAF Bot Control er en administreret regelgruppe, der klassificerer trafik i kategorier: bekræftede bots (Googlebot, Bingbot), scrapingværktøjer, overvågningsværktøjer og menneskelig trafik. Du kan konfigurere forskellige handlinger pr. kategori – tillade søgemaskiners bots, udfordre ukendte bots med CAPTCHA og blokere skadelige scrapingværktøjer.

WAF Web ACL'er har enten omfanget CLOUDFRONT (globalt, til brug med CloudFront) eller REGIONAL (til brug med ALB, API Gateway, AppSync eller Cognito User Pools i en bestemt Region). CloudFront-omfattede WAF-ACL'er skal oprettes i us-east-1 Region, uanset hvor trafikken kommer fra, fordi CloudFront administreres fra denne Region.

Dette er en vigtig eksamensfælde: Hvis du opretter en WAF Web ACL i eu-west-1 og forsøger at knytte den til CloudFront, mislykkes tilknytningen. Opret altid CloudFront-WAF-ACL'er i us-east-1.

Lambda@Edge giver dig mulighed for at køre Lambda-funktioner i Node.js eller Python ved CloudFronts edge-lokationer som reaktion på CloudFront-hændelser. Funktionerne kører inden for millisekunder efter brugerens anmodning uden at dirigere trafikken tilbage til en central Region til behandling.

Lambda@Edge-funktioner implementeres i us-east-1 Region, men replikeres automatisk til alle CloudFronts edge-lokationer globalt. Det betyder, at din kode udføres så tæt på brugeren som muligt, hvilket muliggør personalisering, godkendelse og A/B-test ved edge-lokationen med minimal ekstra latenstid.

Lambda@Edge-funktioner kan opfange CloudFront-anmodninger og -svar på fire punkter i livscyklussen:

• Viewer Request: efter CloudFront modtager anmodningen fra seeren og før cachekontrol – bruges til godkendelse, omdirigeringer og ændring af headere
• Origin Request: efter et cache-miss og før videresendelse til oprindelsen – bruges til omskrivning af URL'er og brugerdefinerede headere til oprindelsen
• Origin Response: efter modtagelse af svaret fra oprindelsen og før det caches – bruges til at tilføje sikkerhedsheadere og ændre svaret
• Viewer Response: før CloudFront sender svaret til seeren – bruges til at tilføje eller ændre svarheadere

AWS tilbyder to muligheder for edge-beregning med forskellige afvejninger:

• CloudFront Functions: udførelse på under et millisekund, kun JavaScript, ekstremt lave omkostninger (~1/6 af prisen), kører kun ved hændelserne Viewer Request og Viewer Response, grænse på 1 ms beregningstid og ingen VPC-/netværksadgang
• Lambda@Edge: op til 30 sekunders (Viewer) / 30 sekunders (Origin) udførelsestid, Node.js eller Python, alle fire udløsende punkter, kan foretage netværksanmodninger og har adgang til anmodnings- og svarlegemer

Brug CloudFront Functions til enkel ændring af headere, normalisering af URL'er og beregning af cache-nøgler. Brug Lambda@Edge til kompleks logik, der kræver netværkskald, længere beregning eller behandling på oprindelsessiden.

Almindelige Lambda@Edge-mønstre på SAA-C03-eksamen:

• Validering af JWT ved edge-lokationen: Viewer Request-funktionen validerer en Authorization-header; uautoriserede anmodninger returnerer 401 uden at ramme oprindelsen
• A/B-test: Viewer Request tildeler brugere til gruppe A eller B (via en cookie) og ændrer anmodningen, så den henter /a/page.html eller /b/page.html
• Omskrivning af URL'er: Origin Request omskriver læsevenlige URL'er til de faktiske filstier i S3
• Dynamisk ændring af billedstørrelse: Origin Request konstruerer en anmodning til en Lambda til billedbehandling; Origin Response cacher billedet i den ændrede størrelse
• HTTP-sikkerhedsheadere: Viewer Response indsætter CSP-, HSTS- og X-Frame-Options-headere

Lambda@Edge har flere begrænsninger sammenlignet med standard-Lambda:

• Funktioner skal være i regionen us-east-1
• Ingen understøttelse af VPC (kan ikke få adgang til ressourcer i en VPC)
• Ingen miljøvariabler (indlejr konfigurationen i funktionskoden, eller hent den fra Parameter Store ved kold opstart)
• Kan ikke bruge Lambda Layers
• Timeout for viewer-hændelser: 5 sekunder; timeout for origin-hændelser: 30 sekunder
• Grænse for størrelsen på implementeringspakken: 1 MB (viewer-hændelser) / 50 MB (origin-hændelser)

Disse begrænsninger gør Lambda@Edge uegnet til langvarige beregninger, operationer der afhænger af en VPC, eller funktioner der kræver dynamisk konfiguration for hver implementering.

WAF og Lambda@Edge har forskellige sikkerhedsroller og supplerer hinanden:

• WAF: signaturbaseret blokering af angreb (SQL-injektion, XSS, kendte angribere, hastighedsbegrænsning)—administrerede regler håndterer almindelige angreb automatisk
• Lambda@Edge: sikkerhed baseret på tilpasset forretningslogik (JWT-validering, sessionskontrol, kontrol af adgangstokens)—fleksibelt, men kræver udviklingsarbejde

En arkitektur med forsvar i dybden: WAF blokerer først kendte angrebsmønstre; Lambda@Edge validerer godkendelse på forretningsniveau; signerede CloudFront-URL'er/-cookies begrænser adgangen til indhold; OAC holder S3 privat. Hvert lag forhindrer uafhængigt en forskellig type angreb.

Overvåg dit sikkerhedslag ved kanten med disse værktøjer:

• WAF-logge: aktivér fuld logning af forespørgsler til S3, CloudWatch Logs eller Kinesis Firehose for at se, hvilke regler der matches, og hvilken trafik der blokeres
• WAF-metrikker: BlockedRequests, AllowedRequests, CountedRequests pr. regel i CloudWatch
• Lambda@Edge-logge: CloudWatch Logs-grupper oprettes i hver region, hvor funktionen udføres; brug CloudWatch Insights til at forespørge på tværs af regioner
• CloudFront Real-Time Logs: stream adgangslogge til Kinesis for øjeblikkelig analyse (i modsætning til standardadgangslogge, som samles hvert par minutter)

I denne lektion lærte du, at AWS WAF blokerer almindelige webangreb ved CloudFront-kanten ved hjælp af administrerede og tilpassede regelsæt, at Lambda@Edge kører tilpasset kode ved fire CloudFront-udløsningspunkter globalt, og at CloudFront Functions tilbyder udførelse på under et millisekund til enkel logik på viewer-siden. WAF-ACL'er til CloudFront skal oprettes i us-east-1. Næste gang undersøger vi Application-, Network- og Gateway Load Balancers.