Amazon ANS-C01: Sicurezza della Rete e Conformità — Guida allo studio

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Fa parte della AWS Advanced Networking Specialty ANS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Concetto fondamentale

La sicurezza di rete in AWS è stratificata: controlli perimetrali, controlli a livello di VPC, controlli a livello di host e applicazione, e monitoraggio/ispezione. Al confine del VPC si utilizzano i gruppi di sicurezza (firewall virtuali stateful, incentrati sull’host e applicati alle ENI) e le ACL di rete (filtraggio stateless a livello di sottorete, valutato in base al numero di regola) per imporre controlli di accesso generali. I gruppi di sicurezza tengono traccia dello stato della connessione, quindi un flusso di risposta stabilito viene automaticamente consentito, rendendoli ideali per permettere connessioni avviate dal client verso pod o istanze. Le NACL richiedono voci di autorizzazione esplicite in entrambe le direzioni o regole complementari per il traffico di ritorno; vengono valutate in ordine crescente di numero di regola e sono quindi appropriate per un rafforzamento generale a livello di sottorete, come l’eliminazione di interi intervalli CIDR o l’applicazione di vie di fuga effimere per liste di blocco di emergenza.

L’ispezione e l’applicazione centralizzata delle policy sono fornite da servizi gestiti e autogestiti. AWS Network Firewall può implementare protezioni stateful simili a Suricata, filtraggio basato su elenchi di domini e firme in stile prevenzione delle intrusioni (intrusion-prevention) al perimetro del VPC, con policy del firewall e gruppi di regole espliciti. Web Application Firewall (AWS WAF) è focalizzato sull’applicazione per la protezione a livello HTTP(S) e si integra con Application Load Balancer, Amazon CloudFront e API Gateway per applicare protezioni OWASP, regole basate sulla frequenza (rate-based) e controlli su header personalizzati. Le protezioni DDoS sono fornite da AWS Shield (la versione Standard è automatica e gratuita; Shield Advanced fornisce traffic engineering, protezione dei costi e integrazione con WAF per la mitigazione a livello di applicazione). Servizi di rilevamento come Amazon GuardDuty analizzano i VPC Flow Logs, i log DNS e CloudTrail per far emergere attività di ricognizione, scansioni di porte e comportamenti di istanze compromesse.

Visibilità e cattura dei pacchetti completano il modello. I VPC Flow Logs registrano i metadati dei flussi per ogni ENI e possono essere inviati a CloudWatch Logs, Amazon S3 o Kinesis Data Firehose per l’analisi con Athena. Per la cattura completa dei pacchetti (full-packet capture) o un’ispezione più approfondita, Traffic Mirroring consente di replicare (mirroring) il traffico di una ENI verso un’appliance IDS/di cattura pacchetti (un sensore EC2 con una ENI replicata o un target di un Network Load Balancer) dove vengono eseguiti strumenti come Suricata o Zeek. Insieme, questi controlli abilitano una postura di difesa in profondità (defense-in-depth) in cui prevenzione, rilevamento e analisi forense sono tutti presenti.

Servizi chiave e configurazione

Diversi servizi AWS sono centrali per la sicurezza di rete e ognuno ha specifici pattern di configurazione e API da conoscere:

• Gruppi di sicurezza (Security Groups)
• ACL di rete (Network ACLs o NACLs)
• AWS Network Firewall
• AWS WAF
• AWS Shield (Standard e Advanced)
• Amazon GuardDuty
• VPC Flow Logs
• Traffic Mirroring

I gruppi di sicurezza sono configurati per ogni ENI tramite l’API EC2 o la Console; per aggiungere una regola in ingresso (ingress) usare “aws ec2 authorize-security-group-ingress –group-id sg-123 –protocol tcp –port 443 –cidr 0.0.0.0/0”. Ricordarsi di utilizzare CIDR con il principio del privilegio minimo e di associare gruppi di sicurezza separati per i load balancer e i pod di backend per evitare regole troppo permissive. Creare le NACL tramite “aws ec2 create-network-acl” e aggiungere voci numerate con “aws ec2 create-network-acl-entry” specificando numero di regola (rule-number), azione della regola (rule-action), protocollo, intervallo di porte (port-range) e il flag di uscita (egress).

AWS Network Firewall utilizza gruppi di regole e policy del firewall associati a una risorsa firewall creata in una sottorete del VPC. Usare “aws network-firewall create-rule-group” per definire regole stateless o stateful, “aws network-firewall create-firewall-policy” per comporle e “aws network-firewall create-firewall” per implementarle (deploy). Scegliere i gruppi di regole stateful per l’ispezione consapevole del protocollo e le regole di firma compatibili con Suricata; usare le regole stateless per un throughput molto elevato e un filtraggio di primo passaggio.

AWS WAF associa una Web ACL a un ALB e può applicare corrispondenze con set di IP (IP set), corrispondenze di stringhe negli header o regole basate sulla frequenza (rate-based). Usare “aws wafv2 create-web-acl” e specificare regole che controllano gli header (ad esempio, bloccare le richieste che non contengono un header personalizzato inserito nel proprio front door fidato). AWS Shield Advanced è abilitato per account e fornisce accesso al team di risposta DDoS e protezioni aggiuntive per le risorse registrate con Shield Advanced.

Abilitare GuardDuty tramite “aws guardduty create-detector” e integrare i risultati (findings) con CloudWatch Events o EventBridge per l’automazione. Per la telemetria, creare i VPC Flow Logs tramite “aws ec2 create-flow-logs –resource-type VPC –resource-id vpc-123 –traffic-type ALL –log-destination-type cloud-watch-logs –log-group-name /aws/vpc/flowlogs”. Per la cattura dei pacchetti, usare “aws ec2 create-traffic-mirror-target”, “aws ec2 create-traffic-mirror-filter” e “aws ec2 create-traffic-mirror-session” per dirigere il traffico replicato (mirrored) verso una ENI di un’appliance o un NLB.

Pattern di progettazione e compromessi

La crittografia end-to-end con mutual TLS, in cui il load balancer non deve terminare la sessione TLS, richiede un pattern di pass-through a Livello 4. Utilizzare un Network Load Balancer (NLB) davanti ai pod di backend in modo che la sessione TLS venga negoziata direttamente con gli endpoint del servizio. In Kubernetes su EKS, implementare un Service di tipo LoadBalancer supportato da un NLB e registrare i pod come target tramite IP; l’AWS Load Balancer Controller o le annotazioni Service legacy assicurano che il tipo di target sia IP e che il protocollo del target group sia TCP. Per l’alta concorrenza tipica di gRPC e delle numerose connessioni HTTP/2 a lunga durata, l’NLB preserva gli IP di origine e impone un overhead per connessione inferiore rispetto ai proxy L7. Se è richiesta la terminazione TLS sull’ALB (ad esempio, per il routing basato su URL), è necessario terminare la sessione TLS sull’ALB utilizzando un certificato ACM e quindi inoltrare il traffico ai backend; per preservare l’IP del client, si può fare affidamento sull’header X-Forwarded-For (ALB) o utilizzare un NLB compatibile con Proxy Protocol v2 per i backend che necessitano dell’IP di origine originale a L4.

Per architetture scalabili multi-account e multi-VPC in cui sono richiesti servizi centralizzati, PrivateLink (AWS VPC Endpoint Services) è la scelta più sicura e scalabile. Esporre i servizi centrali dal VPC dei servizi condivisi come un endpoint service AWS PrivateLink. Ogni account consumer crea un interface VPC endpoint verso tale servizio; il proprietario del servizio può richiedere l’accettazione dell’endpoint e applicare controlli basati su security group sulle ENI dell’endpoint. Questo modello mantiene il traffico sulla rete AWS, evita i limiti di scalabilità del peering e fornisce una sicurezza granulare per ogni consumer. Transit Gateway con segmentazione e Network Firewall possono essere utilizzati per il transito a livello di rete e l’ispezione centralizzata, ma sono più appropriati quando è richiesta una connettività completamente instradata con policy di routing complesse, piuttosto che un isolamento per singolo servizio.

Durante la diagnosi dell’utilizzo della larghezza di banda su più VIF in Direct Connect, dare priorità innanzitutto ai metadati: abilitare e interrogare i VPC Flow Logs aggregati su S3 o CloudWatch e analizzarli tramite Athena per mappare i flussi IP a volume elevato a VPC e sottoreti specifici. Integrare i flow log con le metriche CloudWatch per le interfacce virtuali di Direct Connect e, se è necessaria un’ispezione a livello di payload o per protocolli eterogenei, implementare Traffic Mirroring per catturare i pacchetti verso un IDS basato su EC2. Traffic Mirroring è pesante e comporta dei costi; utilizzarlo solo per sessioni o finestre temporali in cui i flow log e i risultati di GuardDuty non sono sufficienti.

Errori comuni e criteri decisionali

Un errore comune è affidarsi esclusivamente ai security group per l’applicazione di un perimetro ampio, senza utilizzare NACL o Network Firewall dove è richiesta un’ispezione a livello di subnet o stateful. I security group sono per ENI e facili da gestire, ma non scalano bene come piano di controllo centralizzato per molti VPC in account diversi; utilizzare AWS Firewall Manager per centralizzare le regole di WAF e Network Firewall tra più account. Un’altra trappola è terminare il TLS a livello del load balancer senza tenere conto della conservazione dell’IP del client; ALB inserisce gli header X-Forwarded-For, ma il logging dell’applicazione deve leggere esplicitamente quell’header e deve essere stabilita una relazione di fiducia (ad esempio, solo ALB dovrebbe inviarlo). Per avere la garanzia rigorosa che solo Global Accelerator possa raggiungere un ALB, evitare di fare affidamento unicamente sul DNS; limitare invece i listener dell’ALB tramite security group agli intervalli IP pubblicati dell’accelerator (automatizzare gli aggiornamenti con il file ip-ranges.json o le managed prefix list) o, dove possibile, utilizzare un ALB solo interno e anteporgli l’endpoint dell’accelerator.

Per decidere tra PrivateLink e Transit Gateway, si deve valutare il compromesso tra la granularità a livello di servizio e il routing full-mesh. PrivateLink fornisce un controllo degli accessi per singolo servizio con filtraggio a livello di security group e scala senza causare un’esplosione delle tabelle di routing; Transit Gateway è necessario quando si ha bisogno di connettività basata su route tra molti VPC e reti on-premise e quando si richiede un’ispezione centralizzata dei pacchetti con AWS Network Firewall. Per un throughput elevato, privilegiare regole stateless di Network Firewall sul perimetro, combinate con gruppi stateful mirati per i flussi critici; l’elaborazione stateless è scalabile ma perde la consapevolezza del protocollo.

Problema pratico: scenario d’uso

Azienda: Meridian Payments — sfida: abilitare un’API di pagamento basata su gRPC su EKS che richieda mutual TLS end-to-end (nessuna terminazione TLS nel percorso), supportare migliaia di connessioni simultanee di lunga durata, l’autoscaling dei pod e l’identificazione degli IP client di origine per il logging e il rilevamento delle frodi.

1. Approccio: Distribuire un Amazon Network Load Balancer davanti al Service di EKS configurato con target type IP, in modo che le ENI dei pod siano registrate direttamente nei target group dell’NLB. Utilizzare AWS Load Balancer Controller per creare un Service supportato da NLB con annotazioni per garantire che il protocollo del target group sia TCP sulla porta 443 e che gli health check utilizzino TCP. Terminare l’mTLS sui pod di backend; configurare Istio o una libreria TLS sidecar se è necessaria una rotazione standardizzata dei certificati, utilizzando Kubernetes Secrets popolati da AWS Certificate Manager Private Certificate Authority o AWS Secrets Manager. Conservare gli IP dei client poiché NLB preserva l’IP di origine; assicurarsi che le regole di networkPolicy e dei security group dei pod di backend consentano gli intervalli di origine da NLB/client. Utilizzare HPA e Cluster Autoscaler per scalare i pod; assicurarsi che il ritardo di deregistrazione del target group sia regolato per consentire un drenaggio graduale delle connessioni (graceful connection draining).

2. Approccio di osservabilità e forense: Abilitare i VPC Flow Logs per il VPC di EKS verso CloudWatch Logs e aggregarli su S3 tramite Kinesis Firehose per la conservazione e per eseguire query con Athena, mappando i flussi a banda larga. Abilitare GuardDuty per il rilevamento di anomalie sui flussi VPC e DNS. Se è richiesta un’ispezione più approfondita dei pacchetti durante le finestre temporali di sospetta frode, creare sessioni di Traffic Mirror sulle ENI problematiche verso un sensore EC2 che esegue Suricata; gestire i filtri di mirror per catturare solo il traffico rilevante e limitare i costi.

Logica di AWS: NLB fornisce un pass-through a livello L4, quindi TLS e mTLS vengono negoziati end-to-end e il backend vede il vero IP del client, il che soddisfa il requisito che il traffico non venga decifrato da proxy intermedi e che l’analisi di logging/frode veda la fonte originale. La registrazione dei pod per IP e l’uso di AWS Load Balancer Controller si integrano con l’autoscaling di EKS. VPC Flow Logs, GuardDuty e Traffic Mirroring forniscono una visibilità graduale, dai metadati alla cattura completa dei pacchetti, per una conformità e una risposta agli incidenti scalabili ed economicamente vantaggiose.

← Bilanciamento del Carico e Gestione del Traffico · Tutti i domini · Distribuzione di Contenuti e Networking Edge →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →