Security group e network ACL: i due controlli di base

Il primo bivio dell’esame riguarda i due firewall nativi della VPC. Il security group opera a livello di ENI (quindi di istanza/risorsa), è stateful e contiene solo regole allow: tutto ciò che non è esplicitamente permesso è implicitamente negato, e non esiste il concetto di deny. Poiché è stateful, il traffico di ritorno di una connessione autorizzata è consentito automaticamente, senza dover aprire le porte effimere. Un dettaglio ricorrente: come source di una regola puoi indicare un altro security group (anche cross-account tramite peering/Transit Gateway), pattern ideale per micro-segmentazione tier-to-tier senza gestire CIDR.

La network ACL opera a livello di subnet, è stateless e supporta sia allow sia deny, valutati in ordine di rule number (dal più basso). Essendo stateless devi aprire esplicitamente sia il traffico in ingresso sia quello di ritorno sulle ephemeral ports. La NACL è lo strumento giusto quando serve un deny esplicito a livello di subnet, per esempio bloccare un singolo IP malevolo che un security group, privo di deny, non può fermare.

Segmentazione: subnet pubbliche e private

La segmentazione parte dalla topologia. Una subnet pubblica ha una route verso un Internet Gateway; una subnet privata raggiunge Internet in uscita solo tramite NAT Gateway (egress-only), e con Egress-Only Internet Gateway per il traffico IPv6. Collocare i database e i workload sensibili in subnet private, esponendo solo il layer di frontend o un load balancer nelle subnet pubbliche, è il principio di isolamento che l’esame premia. La combinazione tipica: NACL per il confine di subnet, security group per il controllo fine tra tier.

AWS Network Firewall

Quando serve ispezione stateful a layer 3-7 e filtraggio egress centralizzato, la risposta è AWS Network Firewall. Supporta regole basate su domini (domain allowlist/denylist), regole compatibili con la sintassi Suricata per IPS/IDS, e TLS inspection. Si distribuisce inserendo endpoint del firewall nel percorso del traffico, tipicamente in un’architettura hub-and-spoke con Transit Gateway e una subnet dedicata. È la scelta corretta quando i security group e le NACL non bastano perché occorre ispezione del contenuto o controllo dell’egress verso Internet per domini/FQDN.

Route 53 Resolver DNS Firewall

Il DNS Firewall filtra le query DNS in uscita dalla VPC risolte dal Route 53 Resolver. Serve a bloccare la risoluzione verso domini malevoli e a contrastare l’exfiltrazione dati via DNS tunneling. È complementare, non alternativo, a Network Firewall: il primo agisce sul piano DNS, il secondo sul traffico di rete. Usa domain list gestite da AWS o personalizzate, con azioni ALLOW, BLOCK o ALERT.

AWS PrivateLink permette di raggiungere servizi AWS e servizi di terze parti senza far transitare il traffico su Internet. Due tipi di endpoint:

  • Interface endpoint: crea una ENI con IP privato nella tua subnet, alimentata da PrivateLink; usato dalla maggior parte dei servizi (es. KMS, Secrets Manager, API di servizi).
  • Gateway endpoint: disponibile solo per S3 e DynamoDB, si aggancia alla route table e non ha costo orario né ENI.

Le endpoint policy sono resource-based policy che limitano quali principal e azioni possono passare per l’endpoint: sono un guardrail sul canale, non concedono da sole i permessi (l’accesso effettivo resta l’intersezione con IAM, bucket policy, ecc.). Sul lato ingresso, la condition key aws:SourceVpce (o aws:SourceVpc) in una bucket policy consente di accettare richieste solo da uno specifico endpoint, isolando i dati dall’accesso pubblico.

Trappole tipiche d’esame

  • Bloccare un singolo IP di attaccante → NACL, non security group: il security group ha solo regole allow e non può esprimere un deny; serve una NACL con deny esplicito a livello di subnet.
  • Il traffico di ritorno non passa dopo aver aperto la NACL → aprire le ephemeral ports: la NACL è stateless, quindi devi permettere esplicitamente le porte effimere in ritorno; il security group, essendo stateful, non ne ha bisogno.
  • Accedere a S3 senza uscire su Internet → Gateway endpoint (non Interface): per S3 e DynamoDB il gateway endpoint è gratuito e basato su route table; l’interface endpoint qui è la risposta-esca più costosa.
  • Impedire l’accesso al bucket se non tramite VPC → bucket policy con aws:SourceVpce: la endpoint policy da sola non nega l’accesso da altre reti; il vincolo va posto sulla resource policy del bucket.
  • Filtrare l’egress verso domini specifici a layer 7 → Network Firewall; bloccare domini DNS malevoli → DNS Firewall: i due servizi agiscono su piani diversi e vengono spesso scambiati nelle domande.
  • La endpoint policy “concede” l’accesso → falso: è un guardrail che restringe; l’accesso effettivo è l’intersezione con IAM e resource policy, e un deny esplicito prevale sempre.