Difesa perimetrale: AWS WAF e Shield

AWS WAF opera come layer 7 filter e si associa a CloudFront, Application Load Balancer, API Gateway, AppSync e Cognito. L’unità di configurazione è la web ACL, che contiene rule con azione Allow, Block, Count o CAPTCHA. Un web ACL valutato su CloudFront protegge globalmente all’edge; associato a un ALB agisce a livello regionale. Ricorda che il resource type deve corrispondere allo scope: le web ACL per CloudFront usano lo scope CLOUDFRONT (regione us-east-1), quelle per ALB/API Gateway usano scope REGIONAL.

Tre pattern ricorrono nelle domande. I managed rule group (AWS Managed Rules come Core rule set, SQL database, Known bad inputs, IP reputation) coprono OWASP e minacce comuni senza scrivere regole custom: si aggiornano da soli. Le rate-based rule contano le richieste per IP di origine in una finestra mobile e bloccano quando si supera la soglia: sono la difesa contro HTTP flood e credential stuffing a bassa complessità. Le custom rule con statement su header, URI, geo match o label gestiscono logica specifica. Le rule si valutano per priorità e la prima azione terminante (Allow/Block) chiude la valutazione.

AWS Shield Standard è attivo di default e gratuito, e protegge da attacchi DDoS di layer 3/4 su tutte le risorse AWS. Shield Advanced è un abbonamento a pagamento che aggiunge: mitigazione avanzata su CloudFront, ELB, Global Accelerator ed Elastic IP, l’accesso allo Shield Response Team (SRT), e soprattutto il cost protection (rimborso dei costi di scaling generati da un attacco). Include anche la creazione automatica di WAF rule via automatic application layer DDoS mitigation. Se lo scenario chiede protezione L7 gestita più garanzia economica in ambienti enterprise, la risposta è Shield Advanced, non solo WAF.

CloudFront e protezione delle origin con OAC

CloudFront non è solo cache: è un edge control point. Per proteggere un bucket S3 usato come origin, la best practice attuale è l’Origin Access Control (OAC), che sostituisce il vecchio Origin Access Identity (OAI). Con OAC il bucket resta privato (Block Public Access attivo) e la sua bucket policy concede l’accesso solo al service principal di CloudFront, tipicamente con una condition AWS:SourceArn che vincola alla specifica distribution. OAC supporta inoltre SigV4 e la crittografia SSE-KMS sull’origin, cosa che OAI non gestiva bene. Completano il quadro il viewer protocol policy (redirect-to-HTTPS), i field-level encryption per dati sensibili e la geo restriction. Domande tipiche contrappongono OAC (corretto, S3 privato) a rendere il bucket pubblico o usare solo la URL S3 (sbagliato).

Governance multi-account con Firewall Manager

AWS Firewall Manager applica policy di sicurezza centralmente su tutti gli account di una AWS Organization. Richiede AWS Organizations con all features abilitate, un delegated administrator account e AWS Config attivo. Gestisce policy per WAF (deploy della stessa web ACL su tutte le risorse taggate), Shield Advanced, security group (audit e remediation di regole troppo permissive), AWS Network Firewall e DNS Firewall. Il vantaggio d’esame è la scala: nuove risorse che nascono in qualsiasi account ereditano automaticamente la policy, colmando il gap di configurazione manuale. Se lo scenario dice “applicare la stessa regola WAF a tutti gli account, anche futuri”, la risposta è Firewall Manager, non WAF configurato account per account.

Sicurezza degli host: Systems Manager e Verified Access

AWS Systems Manager Session Manager fornisce accesso shell a istanze EC2 senza aprire la porta 22, senza bastion host e senza chiavi SSH: la connessione passa dall’SSM Agent tramite endpoint AWS, il traffico è loggato su CloudTrail/S3/CloudWatch e autorizzato via IAM. Richiede l’agent e un IAM instance profile (managed policy AmazonSSMManagedInstanceCore); per istanze in subnet private senza NAT si usano i VPC interface endpoint per SSM. Patch Manager definisce patch baseline e maintenance window per applicare aggiornamenti in modo pianificato e auditabile.

AWS Verified Access fornisce accesso applicativo zero-trust a app interne (HTTP/HTTPS e, con estensioni, TCP) senza VPN: ogni richiesta è valutata contro access policy basate su segnali di identità (trust provider come IAM Identity Center o OIDC) e sullo stato del device (integrazione con soluzioni di device trust). Se lo scenario chiede “accesso senza VPN con policy per identità e postura del dispositivo”, è Verified Access.

Trappole tipiche d’esame

  • Bloccare HTTP flood da singoli IP → rate-based rule in WAF: la managed rule generica non conta le richieste per IP; serve la rate-based rule con soglia. Shield da solo copre L3/L4, non il flood applicativo.
  • Rimborso dei costi di scaling causati da un DDoS → Shield Advanced: il cost protection è esclusivo di Advanced; Shield Standard e WAF non rimborsano nulla.
  • S3 origin privato dietro CloudFront → OAC + bucket policy con SourceArn: rendere il bucket pubblico o usare OAI sono distrattori; OAC è lo standard attuale e supporta SSE-KMS.
  • Stessa web ACL su tutti gli account presenti e futuri → Firewall Manager: configurare WAF in ogni account non copre le risorse future; Firewall Manager richiede Organizations + delegated admin + Config.
  • Accesso amministrativo a EC2 senza aprire la 22 né usare un bastion → Session Manager: l’accesso è via SSM Agent e IAM, loggato; aprire il security group sulla 22 o usare un bastion sono soluzioni meno sicure.
  • Accesso ad app interne senza VPN, valutando identità e device posture → Verified Access: un Client VPN dà connettività di rete ma non policy zero-trust per richiesta; Verified Access valuta ogni request.