CloudFront con WAF e Lambda@Edge

AWS WAF (Web Application Firewall) filtra e monitora le richieste HTTP/HTTPS che raggiungono la distribuzione CloudFront. Collegando una Web ACL WAF alla distribuzione, è possibile bloccare gli exploit web comuni, tra cui SQL injection, cross-site scripting (XSS), bot dannosi e attacchi OWASP Top 10, prima che raggiungano l'origine.

WAF opera sul nodo edge di CloudFront: le richieste dannose vengono quindi rifiutate nel punto edge più vicino, anziché raggiungere il vostro ALB o server applicativo. Questo riduce il carico sul backend e blocca gli attacchi più vicino all'autore.

Una Web ACL WAF contiene regole e gruppi di regole ordinati, che verificano gli attributi delle richieste ed eseguono un'azione, come Allow, Block, Count o CAPTCHA. Le regole vengono valutate in ordine di priorità; viene applicata l'azione della prima regola corrispondente.

AWS fornisce gruppi di regole gestiti, cioè set di regole predefiniti gestiti da AWS e dai venditori di AWS Marketplace. L'AWS Managed Rules - Core Rule Set copre OWASP Top 10 senza alcuna configurazione. AWS aggiorna i gruppi di regole gestiti quando emergono nuove minacce, riducendo il carico operativo.

Le regole basate sulla frequenza di WAF contano le richieste provenienti da ciascun IP sorgente in una finestra di 5 minuti. Se un IP supera la soglia, ad esempio 2.000 richieste in 5 minuti, WAF blocca le richieste successive da quell'IP finché la frequenza non diminuisce. Le regole basate sulla frequenza difendono da attacchi brute force, credential stuffing e semplici attacchi DDoS di scraping.

AWS WAF Bot Control è un gruppo di regole gestito che classifica il traffico in categorie: bot verificati, come Googlebot e Bingbot, scraper, strumenti di monitoraggio e traffico umano. È possibile configurare azioni diverse per ogni categoria: consentire i bot dei motori di ricerca, sottoporre i bot sconosciuti a una verifica CAPTCHA e bloccare gli scraper dannosi.

Le Web ACL WAF hanno ambito CLOUDFRONT, globale e utilizzabile con CloudFront, oppure REGIONAL, utilizzabile con ALB, API Gateway, AppSync o Cognito User Pools in una Region specifica. Le ACL WAF con ambito CloudFront devono essere create nella Region us-east-1, indipendentemente dal luogo di origine del traffico, perché CloudFront è gestito da quella Region.

Questo è un importante dettaglio d'esame: se create una Web ACL WAF in eu-west-1 e provate ad associarla a CloudFront, l'associazione non riesce. Create sempre le ACL WAF di CloudFront in us-east-1.

Lambda@Edge consente di eseguire funzioni Lambda Node.js o Python nei nodi edge di CloudFront in risposta agli eventi di CloudFront. Le funzioni vengono eseguite entro pochi millisecondi dalla richiesta dell'utente, senza instradare il traffico verso una Region centrale per l'elaborazione.

Le funzioni Lambda@Edge vengono distribuite nella Region us-east-1, ma replicate automaticamente in tutti i nodi edge di CloudFront a livello globale. Il codice viene quindi eseguito il più vicino possibile all'utente, consentendo personalizzazione, autenticazione e test A/B sul nodo edge con un sovraccarico minimo in termini di latenza.

Le funzioni Lambda@Edge possono intercettare richieste e risposte di CloudFront in quattro punti del ciclo di vita:

• Viewer Request: dopo che CloudFront riceve la richiesta dal visualizzatore e prima del controllo della cache; utile per autenticazione, reindirizzamenti e manipolazione degli header
• Origin Request: dopo un cache miss e prima dell'inoltro all'origine; utile per riscrittura degli URL e header personalizzati verso l'origine
• Origin Response: dopo aver ricevuto la risposta dall'origine e prima di memorizzarla nella cache; utile per aggiungere header di sicurezza e modificare la risposta
• Viewer Response: prima che CloudFront invii la risposta al visualizzatore; utile per aggiungere o modificare gli header della risposta

AWS offre due opzioni di elaborazione edge, con compromessi differenti:

• CloudFront Functions: esecuzione in meno di un millisecondo, solo JavaScript, costo estremamente ridotto, circa 1/6 del prezzo, esecuzione solo durante gli eventi Viewer Request e Viewer Response, limite di 1 ms per l'elaborazione e nessun accesso a VPC o alla rete
• Lambda@Edge: fino a 30 secondi di esecuzione per Viewer e 30 secondi per Origin, Node.js o Python, tutti e quattro i punti di attivazione, possibilità di effettuare richieste di rete e accesso ai corpi delle richieste e delle risposte

Utilizzate CloudFront Functions per semplici manipolazioni degli header, normalizzazione degli URL e calcolo della chiave di cache. Utilizzate Lambda@Edge per la logica complessa che richiede chiamate di rete, elaborazioni più lunghe o attività sul lato origine.

Modelli comuni di Lambda@Edge nell'esame SAA-C03:

• Convalida JWT sul nodo edge: la funzione Viewer Request convalida un header Authorization; le richieste non autorizzate restituiscono 401 senza raggiungere l'origine
• Test A/B: Viewer Request assegna gli utenti al gruppo A o B tramite un cookie e modifica la richiesta per recuperare /a/page.html o /b/page.html
• Riscrittura degli URL: Origin Request riscrive gli URL leggibili nei percorsi effettivi dei file in S3
• Ridimensionamento dinamico delle immagini: Origin Request crea una richiesta verso una Lambda di elaborazione delle immagini; Origin Response memorizza nella cache l'immagine ridimensionata
• Header di sicurezza HTTP: Viewer Response inserisce gli header CSP, HSTS e X-Frame-Options

Lambda@Edge presenta diverse limitazioni rispetto a Lambda standard:

• Le funzioni devono trovarsi nella Regione us-east-1
• Nessun supporto per VPC (non è possibile accedere alle risorse in una VPC)
• Nessuna variabile d'ambiente (incorpori la configurazione nel codice della funzione oppure la recuperi da Parameter Store durante l'avvio a freddo)
• Non è possibile utilizzare Lambda Layers
• Timeout per gli eventi viewer: 5 secondi; timeout per gli eventi origin: 30 secondi
• Limite delle dimensioni del pacchetto di deployment: 1 MB (eventi viewer) / 50 MB (eventi origin)

Queste limitazioni rendono Lambda@Edge inadatto per elaborazioni di lunga durata, operazioni che dipendono da una VPC o funzioni che richiedono una configurazione dinamica per ogni deployment.

WAF e Lambda@Edge svolgono ruoli di sicurezza diversi e complementari:

• WAF: blocco degli attacchi basato su firme (SQL injection, XSS, attori malevoli noti, limitazione della frequenza)—le regole gestite gestiscono automaticamente gli attacchi comuni
• Lambda@Edge: logica di sicurezza personalizzata a livello aziendale (convalida JWT, controlli della sessione, verifica dei token di accesso)—è flessibile, ma richiede attività di sviluppo

Un'architettura di difesa in profondità: WAF blocca innanzitutto i pattern di attacco noti; Lambda@Edge convalida l'autenticazione a livello aziendale; gli URL e i cookie firmati di CloudFront limitano l'accesso ai contenuti; OAC mantiene privato S3. Ogni livello previene indipendentemente una diversa categoria di attacchi.

Monitori il livello di sicurezza edge con questi strumenti:

• Log WAF: abiliti la registrazione completa delle richieste in S3, CloudWatch Logs o Kinesis Firehose per vedere quali regole corrispondono alle richieste e quale traffico viene bloccato
• Metriche WAF: BlockedRequests, AllowedRequests, CountedRequests per ogni regola in CloudWatch
• Log Lambda@Edge: i gruppi di log di CloudWatch Logs vengono creati in ogni Regione in cui viene eseguita la funzione; utilizzi CloudWatch Insights per eseguire query tra più Regioni
• CloudFront Real-Time Logs: trasmetta i log di accesso a Kinesis per un'analisi immediata (a differenza dei log di accesso standard, raccolti in batch ogni pochi minuti)

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che: AWS WAF blocca gli attacchi web comuni all'edge di CloudFront utilizzando gruppi di regole gestiti e personalizzati, Lambda@Edge esegue codice personalizzato in quattro punti di attivazione di CloudFront a livello globale e CloudFront Functions offre un'esecuzione inferiore al millisecondo per la logica semplice lato viewer. Le ACL WAF per CloudFront devono essere create in us-east-1. Ora esamineremo gli Application, Network e Gateway Load Balancer.