Amazon VPC: isolamento e controllo del traffico

Amazon VPC è la rete virtuale isolata dove collochi le risorse. Il primo criterio di design è la segmentazione in subnet: le risorse che non devono ricevere traffico da Internet (database, application server) vanno in private subnet, senza route verso l’Internet Gateway; per il traffico in uscita usi un NAT Gateway in una public subnet, mentre le risorse esposte (load balancer) stanno in public subnet.

Il controllo del traffico avviene su due livelli. I security group sono stateful e operano a livello di ENI: ammettono solo regole di allow, valutano tutte le regole, e il traffico di ritorno è automaticamente consentito. Le network ACL sono stateless e operano a livello di subnet: ammettono regole di allow e deny, valutate in ordine numerico (dalla più bassa), e richiedono regole esplicite anche per il traffico di ritorno (ephemeral ports). Regola pratica: usa i security group come strumento primario; ricorri alle network ACL quando serve un blocco esplicito (es. negare un IP malevolo) o una difesa a livello di subnet.

VPC endpoint: gateway vs interface

I VPC endpoint permettono di raggiungere servizi AWS mantenendo il traffico sulla rete AWS, senza passare da Internet. Esistono due tipi. Il gateway endpoint serve solo Amazon S3 e Amazon DynamoDB: si aggiunge come voce nella route table e non ha costi aggiuntivi. L’interface endpoint (AWS PrivateLink) serve la maggior parte degli altri servizi: crea una ENI con IP privato nella subnet, con un costo orario e per dati trasferiti. Criterio d’esame: se lo scenario chiede accesso privato a S3/DynamoDB da private subnet senza NAT, la risposta è gateway endpoint; per gli altri servizi (o per esporre un servizio proprio via PrivateLink), interface endpoint.

Protezione perimetrale: WAF e Shield

AWS WAF opera a livello applicativo (layer 7): filtra richieste HTTP/HTTPS con regole contro SQL injection, XSS, rate-based rules e managed rule groups. Si integra con Amazon CloudFront, Application Load Balancer, Amazon API Gateway e AppSync. AWS Shield protegge dai DDoS: Shield Standard è gratuito e automatico (layer 3/4); Shield Advanced è a pagamento e aggiunge protezioni avanzate, la cost protection sugli scale-out causati da attacchi e l’accesso al team di risposta. Distinzione chiave: WAF blocca traffico applicativo malevolo (le “richieste”), Shield mitiga i volumi DDoS.

Encryption, segreti e S3 sicuro

AWS KMS gestisce le chiavi di encryption. Distingui le AWS managed keys (gestite dal servizio) dalle customer managed keys, dove controlli key policy, rotation e permessi. KMS abilita l’envelope encryption ed è integrato con quasi tutti i servizi (S3, EBS, RDS); per scenari multi-region servono le multi-region keys.

AWS Secrets Manager custodisce credenziali e supporta la rotation automatica, con integrazione nativa per i database RDS. Se serve rotation automatica gestita, è Secrets Manager; se bastano parametri o config anche cifrati ma senza rotation integrata, SSM Parameter Store (SecureString) costa meno.

Per Amazon S3 la sicurezza si costruisce a strati: Block Public Access (a livello di account e di bucket) impedisce esposizioni accidentali e prevale sulle policy permissive; le bucket policy definiscono chi accede e con quali condizioni (es. limitare l’accesso a uno specifico VPC endpoint con aws:sourceVpce, o richiedere TLS). L’encryption at-rest si ottiene con SSE-S3 o SSE-KMS, quest’ultima quando servono audit e controllo granulare via CloudTrail.

Trappole tipiche d’esame

  • Bloccare un singolo IP malevolo → network ACL: i security group non hanno regole di deny; per negare esplicitamente un indirizzo serve una NACL con regola deny.
  • Accesso privato a S3 da private subnet senza costi → gateway endpoint: l’interface endpoint funziona ma è a pagamento; per S3/DynamoDB il gateway endpoint è gratuito e sufficiente.
  • Rotation automatica delle credenziali DB → Secrets Manager: Parameter Store SecureString cifra ma non gestisce la rotation nativa.
  • Il bucket S3 resta accessibile nonostante una policy restrittiva → Block Public Access: verifica prima queste impostazioni, che sovrascrivono policy e ACL permissive.
  • Proteggere un’app web da SQL injection/XSS → AWS WAF, non Shield: Shield mitiga i DDoS volumetrici, non filtra il payload applicativo.
  • Controllo e audit delle chiavi di encryption → SSE-KMS con customer managed key: SSE-S3 cifra ma non offre key policy dedicata né tracciamento per-chiave via CloudTrail.