# Protezione delle reti
Gli utenti, sia appartenenti alla tua forza lavoro che i tuoi clienti, possono essere ovunque. Devi abbandonare i modelli tradizionali che si fidano di qualunque persona e di qualsiasi cosa acceda alla tua rete. Quando adotti il principio di applicare la sicurezza a qualsiasi livello, stai impiegando un approccio [Zero Trust](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/). La sicurezza Zero Trust è un modello in cui i componenti di applicazioni o microservizi sono considerati discreti tra loro e nessun componente o microservizio si fida di altri.
L'attenta pianificazione e la gestione della progettazione della rete costituiscono la base del modo in cui fornisci isolamento e limiti per le risorse all'interno del carico di lavoro. Poiché molte risorse nel carico di lavoro operano in un VPC ed ereditano le proprietà di sicurezza, è fondamentale che la progettazione sia supportata da meccanismi di ispezione e protezione basati sull'automazione. Allo stesso modo, per i carichi di lavoro che operano al di fuori di un VPC, utilizzando esclusivamente servizi edge e/o serverless, le best practice si applicano in un approccio più semplificato. Consulta il documento [AWS Well-Architected Serverless Applications Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) per istruzioni specifiche sulla sicurezza serverless.
**Topics**
+ [SEC05-BP01 Creazione di livelli di rete](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Controllo del traffico a tutti i livelli](sec_network_protection_layered.md)
+ [SEC05-BP03 Implementare la protezione basata sull'ispezione](sec_network_protection_inspection.md)
+ [SEC05-BP04 Automatizza la protezione della rete](sec_network_auto_protect.md)
# SEC05-BP01 Creazione di livelli di rete
Segmenta la topologia di rete in diversi livelli basati su raggruppamenti logici dei componenti del carico di lavoro in base alla sensibilità dei dati e ai requisiti di accesso. Distingui tra i componenti che richiedono l’accesso in entrata da Internet, come gli endpoint Web pubblici, e quelli che necessitano solo di un accesso interno, come i database.
**Risultato desiderato:** i livelli della rete rientrano in un approccio di difesa approfondito e integrale alla sicurezza che integra l’autenticazione delle identità e la strategia di autorizzazione dei carichi di lavoro. I livelli sono implementati in base alla sensibilità dei dati e ai requisiti di accesso, con meccanismi adeguati in termini di flusso e controllo del traffico.
**Anti-pattern comuni:**
+ Creazione di tutte le risorse in un VPC o una sottorete unica.
+ Creazione dei livelli di rete senza considerare i requisiti di sensibilità dei dati, il comportamento dei componenti o la loro funzionalità.
+ Utilizzo di VPC e sottoreti come impostazioni predefinite per tutte le considerazioni relative al livello di rete senza considerare come i servizi gestiti da AWS influenzino la tua topologia.
**Vantaggi dell’adozione di questa best practice:** la definizione di livelli di rete è il primo passo per limitare i percorsi superflui lungo la rete, in particolare quelli che conducono a sistemi e dati critici. In tal modo gli attori non autorizzati avranno più difficoltà ad accedere alla rete e a navigare verso altre risorse al suo interno. I livelli di rete discreti riducono l’ambito di analisi dei sistemi di ispezione, ad esempio per il rilevamento delle intrusioni o la prevenzione del malware. Di conseguenza, si riduce il potenziale di falsi positivi e il sovraccarico di elaborazione non necessario.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Quando si progetta l’architettura di un carico di lavoro, è comune separare i componenti in diversi livelli in base alle rispettive responsabilità. Ad esempio, un’applicazione Web può avere un livello di presentazione, uno di applicazione e uno di dati. È possibile adottare un approccio simile quando progetti la tua topologia di rete. I controlli di rete sottostanti possono contribuire a far rispettare i requisiti di accesso ai dati del carico di lavoro. Ad esempio, in un’architettura di applicazioni Web a tre livelli, puoi archiviare i file statici del livello di presentazione su [Amazon S3](https://aws.amazon.com/s3/) e distribuirli da una rete di distribuzione di contenuti (CDN), come [Amazon CloudFront.](https://aws.amazon.com/cloudfront/) Il livello di applicazione può avere endpoint pubblici che un [Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) distribuisce in una sottorete pubblica [Amazon VPC](https://aws.amazon.com/vpc/) (simile a una zona demilitarizzata o DMZ), con servizi di backend implementati in sottoreti private. Il livello dati che funge da host per risorse come database e file system condivisi può risiedere in sottoreti private diverse dalle risorse del livello applicativo. In corrispondenza di ciascuno di questi limiti di livello (CDN, sottorete pubblica, sottorete privata), è possibile implementare controlli che consentano solo al traffico autorizzato di attraversarli.
Analogamente alla modellazione dei livelli di rete in base allo scopo funzionale dei componenti del carico di lavoro, occorre prendere in considerazione anche la sensibilità dei dati elaborati. Utilizzando l’esempio dell’applicazione Web, mentre tutti i servizi del carico di lavoro possono risiedere all’interno del livello di applicazione, servizi diversi possono elaborare dati con livelli di sensibilità differenti. In questo caso, la divisione del livello di applicazione utilizzando più sottoreti private, diversi VPC nello stesso Account AWS o persino VPC diversi in diversi Account AWS per ciascun livello di sensibilità dei dati può essere adeguata in base ai requisiti di controllo.
Un’ulteriore considerazione per i livelli di rete consiste nella coerenza del comportamento dei componenti del carico di lavoro. Continuando con l’esempio, nel livello di applicazione possono essere presenti servizi che accettano input dagli utenti finali o integrazioni di sistemi esterni intrinsecamente più rischiosi rispetto agli input di altri servizi. A titolo esemplificativo, si possono citare il caricamento di file, l’esecuzione di script di codice, la scansione di e-mail e così via. La collocazione di questi servizi nel proprio livello di rete contribuisce a creare un limite di isolamento più forte attorno a essi e può evitare che il loro comportamento unico crei falsi positivi in termini di allarmi nei sistemi di ispezione.
Nell’ambito della progettazione, prendi in considerazione in che modo l’utilizzo dei servizi AWS gestiti influenza la topologia di rete. Scopri in che modo servizi come [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) semplificano l’interoperabilità dei componenti del carico di lavoro tra i livelli di rete. In caso di utilizzo di [AWS Lambda](https://aws.amazon.com/lambda/), esegui l’implementazione nelle sottoreti VPC, salvo in presenza di motivazioni contrarie specifiche. Determina dove si trovano gli endpoint VPC e semplifica con [AWS PrivateLink](https://aws.amazon.com/privatelink/) il rispetto delle policy di sicurezza che limitano l’accesso ai gateway Internet.
### Passaggi dell’implementazione
1. Rivedi l’architettura del carico di lavoro. Raggruppa in modo logico componenti e servizi in base alle funzioni che svolgono, alla sensibilità dei dati elaborati e al loro comportamento.
1. Per i componenti che rispondono alle richieste provenienti da Internet, prendi in considerazione l'utilizzo di bilanciatori del carico o altri proxy per fornire endpoint pubblici. Esamina il trasferimento dei controlli di sicurezza utilizzando servizi gestiti, come CloudFront, [Gateway Amazon API](https://aws.amazon.com/api-gateway/), Elastic Load Balancing e [AWS Amplify](https://aws.amazon.com/amplify/) per l'hosting di endpoint pubblici.
1. I componenti in esecuzione in ambienti di calcolo, come istanze Amazon EC2, container [AWS Fargate](https://aws.amazon.com/fargate/) o funzioni Lambda, vanno implementati in sottoreti private, basate sui tuoi gruppi sin dal primo passaggio.
1. Per servizi AWS completamente gestiti, come [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Kinesis](https://aws.amazon.com/kinesis/) o [Amazon SQS](https://aws.amazon.com/sqs/), prendi in considerazione l’utilizzo degli endpoint VPC come impostazione predefinita per l’accesso tramite indirizzi IP privati.
## Risorse
**Best practice correlate:**
+ [REL02 Come si pianifica la topologia di rete?](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)
+ [PERF04-BP01 In che modo la rete influisce sulle prestazioni](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html)
**Video correlati:**
+ [AWS re:Invent 2023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4)
**Esempi correlati:**
+ [Esempi di VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html)
+ [Access container applications privately on Amazon ECS by using AWS Fargate, AWS PrivateLink, and a Network Load Balancer](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)
+ [Serve static content in an Amazon S3 bucket through a VPC by using Amazon CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html)
# SEC05-BP02 Controllo del traffico a tutti i livelli
All'interno dei livelli della rete, utilizza un'ulteriore segmentazione per limitare il traffico solo ai flussi necessari per ogni carico di lavoro. In primo luogo, concentrati sul controllo del traffico tra Internet o altri sistemi esterni verso un carico di lavoro e il tuo ambiente (traffico *nord-sud*). Quindi, esamina i flussi tra diversi componenti e sistemi (traffico *est-ovest*).
**Risultato desiderato:** solo i flussi di rete necessari ai componenti dei tuoi carichi di lavoro possono comunicare tra loro e con i rispettivi client e con qualsiasi altro servizio da cui dipendono. La tua progettazione tiene conto di considerazioni come l'ingresso e l'uscita pubblici rispetto a quelli privati, la classificazione dei dati, le normative regionali e i requisiti di protocollo. Laddove possibile, preferisci flussi punto a punto rispetto al peering di rete come parte della progettazione secondo il *principio del privilegio minimo*.
**Anti-pattern comuni:**
+ Adozione di un approccio alla sicurezza della rete basato sul perimetro e controllare il flusso di traffico solo al confine dei livelli di rete.
+ Si presume che tutto il traffico all'interno di un livello di rete sia autenticato e autorizzato.
+ Applicazione dei controlli al traffico in ingresso o a quello in uscita, ma non a entrambi.
+ Affidamento esclusivo per l'autenticazione e l'autorizzazione del traffico ai componenti del carico di lavoro e ai controlli di rete.
**Vantaggi dell'adozione di questa best practice:** questa pratica consente di ridurre il rischio di movimenti non autorizzati all'interno della rete e aggiunge un ulteriore livello di autorizzazione ai carichi di lavoro. Eseguendo il controllo del flusso di traffico, è possibile limitare la portata dell'impatto di un incidente di sicurezza e velocizzare il rilevamento e la risposta.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Se da un lato i livelli di rete aiutano a stabilire i limiti dei componenti del carico di lavoro che presentano una funzione, un livello di sensibilità dei dati e un comportamento simili, dall'altro è possibile creare un livello di controllo del traffico molto più granulare utilizzando tecniche per segmentare ulteriormente i componenti all'interno di questi livelli, seguendo il principio del privilegio minimo. All'interno di AWS, i livelli di rete vengono definiti principalmente mediante sottoreti, in base agli intervalli di indirizzi IP, all'interno di un Amazon VPC. I livelli possono anche essere definiti utilizzando diversi VPC, ad esempio per raggruppare gli ambienti di microservizi per dominio aziendale. Se utilizzi più VPC, media l'instradamento utilizzando un [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). Sebbene ciò fornisca il controllo del traffico a Livello 4 (intervalli di porte e indirizzi IP) utilizzando gruppi di sicurezza e tabella di routing, puoi ottenere un ulteriore controllo utilizzando ulteriori servizi, come [AWS PrivateLink](https://aws.amazon.com/privatelink/), il [firewall DNS del risolutore Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html), [AWS Network Firewall](https://aws.amazon.com/network-firewall/) e [AWS WAF](https://aws.amazon.com/waf/).
Esamina e fai un inventario di flusso di dati e requisiti di comunicazione dei tuoi carichi di lavoro in termini di parti che avviano la connessione, porte, protocolli e livelli di rete. Valuta i protocolli disponibili per la creazione di connessioni e la trasmissione di dati in modo da selezionare quelli conformi ai tuoi requisiti di protezione (ad esempio, HTTPS anziché HTTP). Acquisisci questi requisiti sia ai limiti delle tue reti sia all'interno di ogni livello. Una volta identificati questi requisiti, esplora le opzioni per consentire il flusso del traffico richiesto solo in ciascun punto di connessione. È bene partire con i *gruppi di sicurezza* all'interno del VPC, in quanto collegabili a risorse che utilizzano un'interfaccia di rete elastica (ENI), come istanze Amazon EC2, attività Amazon ECS, pod Amazon EKS o database Amazon RDS. A differenza di un firewall Livello 4, un gruppo di sicurezza può avere una regola che consente il traffico da un altro gruppo di sicurezza in base al suo identificatore, riducendo al minimo gli aggiornamenti quando le risorse all'interno del gruppo cambiano nel tempo. Puoi anche filtrare il traffico utilizzando le regole in entrata e in uscita utilizzando i gruppi di sicurezza.
Quando il traffico si sposta tra i VPC, è comune utilizzare il peering VPC per il routing semplice o AWS Transit Gateway per il routing complesso. Questi approcci agevolano i flussi di traffico tra l'intervallo di indirizzi IP delle reti di origine e di destinazione. Tuttavia, se il tuo carico di lavoro richiede solo flussi di traffico tra componenti specifici in diversi VPC, prendi in considerazione l'utilizzo di una connessione punto a punto utilizzando [AWS PrivateLink](https://aws.amazon.com/privatelink/). A tal fine, individua quale servizio dovrebbe agire come produttore e quale dovrebbe agire come consumatore. Implementa un bilanciatore del carico compatibile per il produttore, attiva PrivateLink di conseguenza, quindi accetta una richiesta di connessione da parte del consumatore. Al servizio del produttore viene dunque assegnato un indirizzo IP privato dal VPC del consumatore, utilizzabile dallo stesso per effettuare richieste successive. Questo approccio riduce la necessità di eseguire il peer-to-peer delle reti. Includi i costi per l'elaborazione dei dati e il bilanciamento del carico come parte della valutazione PrivateLink.
Sebbene i gruppi di sicurezza e PrivateLink agevolino il controllo del flusso tra i componenti dei carichi di lavoro, un'altra considerazione importante riguarda come controllare a quali domini DNS le risorse possono accedere (se presenti). A seconda della configurazione DHCP dei tuoi VPC, puoi prendere in considerazione due diversi servizi AWS a tal scopo. La maggior parte dei consumatori utilizza il servizio DNS predefinito del risolutore Route 53 (chiamato anche server Amazon DNS o AmazonProvidedDNS) disponibile per i VPC all'indirizzo \$12 del relativo intervallo CIDR. Con questo approccio, puoi creare regole DNS Firewall e associarle al tuo VPC per determinare quali azioni intraprendere per gli elenchi di domini che fornisci.
Se non stai utilizzando il risolutore Route 53 o se desideri integrare il Resolver con funzionalità di ispezione e controllo del flusso più approfondite oltre al filtro di dominio, prendi in considerazione l'implementazione di un AWS Network Firewall. Questo servizio ispeziona i singoli pacchetti utilizzando regole stateless o stateful per determinare se negare o consentire il traffico. Puoi adottare un approccio simile per filtrare il traffico Web in entrata verso i tuoi endpoint pubblici utilizzando AWS WAF. Per ulteriori indicazioni su questi servizi, consulta [SEC05-BP03 Implementazione della protezione basata sulle ispezioni](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html).
### Passaggi dell'implementazione
1. Identifica i flussi di dati necessari tra i componenti dei tuoi carichi di lavoro.
1. Applica più controlli con un approccio di difesa approfondita per il traffico in entrata e in uscita, incluso l'uso di gruppi di sicurezza e tabelle di routing.
1. Usa i firewall per definire un controllo granulare sul traffico di rete in entrata, in uscita e attraverso i tuoi VPC, come il firewall DNS del risolutore Route 53, AWS Network Firewall e AWS WAF. Prendi in considerazione l'utilizzo di [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) per configurare e gestire a livello centrale le regole del firewall in tutta l'organizzazione.
## Risorse
**Best practice correlate:**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html)
+ [SEC09-BP02 Applicazione della crittografia dei dati in transito](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html)
**Documenti correlati:**
+ [Security best practices for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+ [AWS Network Optimization Tips](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Guidance for Network Security on AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/)
+ [Secure your VPC's outbound network traffic in the Cloud AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html)
**Strumenti correlati:**
+ [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)
**Video correlati:**
+ [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
+ [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)
+ [AWS re:Inforce 2023: Firewalls and where to put them](https://www.youtube.com/watch?v=lTJxWAiQrHM)
# SEC05-BP03 Implementare la protezione basata sull'ispezione
Imposta i punti di ispezione del traffico tra i livelli di rete per verificare che i dati in transito corrispondano a categorie e schemi previsti. Analizza i flussi di traffico, i metadati e i modelli per identificare, rilevare e rispondere agli eventi in modo più efficace.
**Risultato desiderato:** ispezione e autorizzazione del traffico che attraversa i livelli di rete. Le decisioni di autorizzazione e rifiuto si basano su regole esplicite, informazioni sulle minacce e deviazioni dai comportamenti di base. Le protezioni diventano più severe man mano che il traffico si avvicina ai dati sensibili.
**Anti-pattern comuni:**
+ Affidamento esclusivo alle regole del firewall basate su porte e protocolli. Mancato sfruttamento di sistemi intelligenti.
+ Creazione di regole del firewall basate su specifici modelli di minaccia attuali, soggetti a modifiche.
+ Ispezione solo del traffico che transita da una sottorete privata a una pubblica o da una sottorete pubblica a Internet.
+ Mancata visione di base del traffico di rete da confrontare per individuare eventuali anomalie di comportamento.
**Vantaggi dell'adozione di questa best practice:** i sistemi di ispezione ti consentono di creare regole intelligenti, come consentire o negare il traffico solo in presenza di determinate condizioni all'interno dei dati di traffico. Approfitta dei set di regole gestiti AWS e dei partner, basati sulle più recenti informazioni sulle minacce, man mano che il panorama delle minacce cambia nel tempo. In questo modo si riduce l'onere di mantenere le regole e di ricercare gli indicatori di compromissione, riducendo il potenziale di falsi positivi.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
[Ottieni un controllo preciso sul traffico di rete stateful e stateless utilizzando AWS Network Firewall o altri [firewall](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls) e [sistemi di prevenzione delle intrusioni](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) () Marketplace AWS che puoi implementare dietro un Gateway Load Balancer (IPS). GWLB](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/)AWS Network Firewall [supporta le specifiche open source compatibili con Suricata per proteggere il carico di lavoro.](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) IPS
Sia le soluzioni dei AWS Network Firewall fornitori che utilizzano un GWLB supportano diversi modelli di implementazione dell'ispezione in linea. Ad esempio, è possibile eseguire l'ispezione su VPC base individuale, centralizzarla o implementarla in un modello ibrido in cui il traffico est-ovest attraversa un'ispezione VPC e l'ingresso di Internet viene ispezionato di conseguenza. VPC VPC Un'altra considerazione è se la soluzione supporti l'unwrapping Transport Layer Security (TLS), che consente un'ispezione approfondita dei pacchetti per i flussi di traffico avviati in entrambe le direzioni. Per ulteriori informazioni e dettagli approfonditi su queste configurazioni, consulta la [AWS Network Firewall Best Practice guide](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/).
[Se utilizzate soluzioni che eseguono out-of-band ispezioni, come l'analisi pcap dei dati a pacchetto provenienti da interfacce di rete che funzionano in modalità promiscua, potete configurare il mirroring del traffico. VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) Il traffico in mirroring viene conteggiato ai fini della larghezza di banda disponibile delle interfacce ed è soggetto agli stessi costi di trasferimento dati del traffico non in mirroring. È possibile verificare se le versioni virtuali di questi dispositivi sono disponibili su [Marketplace AWS](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking), che possono supportare la distribuzione in linea dietro a. GWLB
Per i componenti che effettuano transazioni tramite protocolli HTTP basati su protocolli basati, proteggi la tua applicazione dalle minacce comuni con un firewall per applicazioni Web ()WAF. [AWS WAF](https://aws.amazon.com/waf)è un firewall per applicazioni Web che ti consente di monitorare e bloccare le richieste HTTP (S) che corrispondono alle tue regole configurabili prima di inviarle ad Amazon API Gateway CloudFront, Amazon AWS AppSync o un Application Load Balancer. Prendi in considerazione l'ispezione approfondita dei pacchetti quando valuti l'implementazione del firewall delle tue applicazioni Web, poiché alcuni richiedono l'interruzione TLS prima dell'ispezione del traffico. Per iniziare AWS WAF, puoi utilizzare [Regole gestite da AWS](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group)in combinazione con le tue integrazioni partner o utilizzare le integrazioni dei [partner](https://aws.amazon.com/waf/partners/) esistenti.
Puoi gestire centralmente AWS WAF AWS Shield Advanced AWS Network Firewall, e i gruppi di VPC sicurezza Amazon in tutta la tua AWS organizzazione con [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/).
## Passaggi dell'implementazione
1. Determina se puoi disciplinare le regole di ispezione in modo ampio, ad esempio attraverso un'ispezioneVPC, o se hai bisogno di un approccio più granulare. VPC
1. Per soluzioni di ispezione in linea:
1. Se lo utilizzi AWS Network Firewall, crea regole, politiche firewall e il firewall stesso. Una volta configurati questi elementi, puoi indirizzare il [traffico verso l'endpoint del firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) per consentire l'ispezione.
1. Se utilizzi un'appliance di terze parti con un Gateway Load Balancer GWLB (), distribuisci e configura l'appliance in una o più zone di disponibilità. Quindi, crea il tuo servizio endpointGWLB, l'endpoint e configura il routing per il tuo traffico.
1. Per out-of-band le soluzioni di ispezione:
1. Attiva il mirroring VPC del traffico sulle interfacce in cui è necessario rispecchiare il traffico in entrata e in uscita. Puoi utilizzare EventBridge le regole di Amazon per richiamare una AWS Lambda funzione per attivare il mirroring del traffico sulle interfacce quando vengono create nuove risorse. Indirizza le sessioni di mirroring del traffico al Network Load Balancer davanti all'appliance che elabora il traffico.
1. Per soluzioni di traffico Web in entrata:
1. Per configurare AWS WAF, inizia configurando una lista di controllo degli accessi Web (web). ACL Il Web ACL è una raccolta di regole con un'azione predefinita (ALLOWoDENY) elaborata in serie che definisce il modo in cui l'utente WAF gestisce il traffico. Puoi creare regole e gruppi personalizzati o utilizzare gruppi di regole AWS gestiti nel tuo WebACL.
1. Una volta configurato ACL il Web, associalo a una AWS risorsa (come un Application Load Balancer, un API Gateway REST API o una CloudFront distribuzione) per iniziare a proteggere il traffico Web. ACL
## Risorse
**Documenti correlati:**
+ [What is Traffic Mirroring?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)
+ [Implementing inline traffic inspection using third-party security appliances](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html)
+ [AWS Network Firewall architetture di esempio con routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html)
+ [Architettura di ispezione centralizzata con AWS Gateway Load Balancer e AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
**Esempi correlati:**
+ [Best practices for deploying Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [TLSconfigurazione di ispezione per il traffico in uscita crittografato e AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/)
**Strumenti correlati:**
+ [Marketplace AWS IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips)
# SEC05-BP04 Automatizza la protezione della rete
Automatizza l'implementazione delle protezioni di rete utilizzando DevOps pratiche come *infrastructure as* code (IaC) e pipeline CI/CD. Queste pratiche possono aiutare a tenere traccia delle modifiche apportate alle protezioni di rete attraverso un sistema di controllo delle versioni, a ridurre i tempi di implementazione delle modifiche e a rilevare se le protezioni di rete si allontanano dalla configurazione desiderata.
**Risultato desiderato:** definizione delle protezioni di rete con modelli e relativo inserimento in un sistema di controllo delle versioni. In caso di nuove modifiche, vengono avviate pipeline automatiche che ne orchestrano test e implementazione. I controlli delle policy e altri test statici sono in atto per convalidare le modifiche prima dell'implementazione. L'implementazione delle modifiche avviene in un ambiente di staging per convalidare il funzionamento previsto dei controlli. Anche l'implementazione negli ambienti di produzione avviene in automatico una volta approvati i controlli.
**Anti-pattern comuni:**
+ Affidamento ai singoli team del carico di lavoro la definizione dell'intero stack di rete, delle protezioni e delle automazioni. Mancata pubblicazione degli aspetti standard dello stack di rete e delle protezioni in modo centralizzato per consentire ai team del carico di lavoro di utilizzarli.
+ Affidamento a un team di rete centrale per definire tutti gli aspetti della rete, delle protezioni e delle automazioni. Mancata delega degli aspetti specifici del carico di lavoro dello stack di rete e delle protezioni al team di quel carico di lavoro.
+ Individuazione del giusto equilibrio tra centralizzazione e delega tra un team di rete e i team del carico di lavoro, ma mancata applicazione di standard di test e implementazione coerenti nei modelli IaC e nelle pipeline CI/CD. Mancata acquisizione delle configurazioni richieste negli strumenti che controllano l'aderenza dei modelli.
**Vantaggi dell'adozione di questa best practice:** l'utilizzo di modelli per definire le protezioni di rete consente di tracciare le modifiche e confrontarle nel tempo con un sistema di controllo delle versioni. L'uso dell'automazione per testare e implementare le modifiche crea standardizzazione e prevedibilità, aumentando le possibilità di una corretta implementazione e riducendo le configurazioni manuali ripetitive.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Una serie di controlli di protezione della rete descritti in [SEC05-BP02 Controllo dei flussi di traffico all'interno dei livelli di rete e SEC 05-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html) [Implementazione della protezione basata sull'ispezione sono inclusi sistemi di regole gestite che possono essere aggiornati automaticamente in base](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html) alle più recenti informazioni sulle minacce. [https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html) Utilizza i [gruppi di regole AWS Network Firewall gestite](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html) per rimanere aggiornato sugli elenchi di domini con scarsa reputazione e sulle firme delle minacce.
Oltre alle regole gestite, ti consigliamo di utilizzare DevOps procedure per automatizzare la distribuzione delle risorse di rete, delle protezioni e delle regole specificate. Puoi acquisire queste definizioni in [AWS CloudFormation](https://aws.amazon.com/cloudformation/) o in un altro strumento *Infrastructure as Code* (IaC) di tua scelta, trasferirle in un sistema di controllo delle versioni e implementarle mediante pipeline CI/CD. Utilizzate questo approccio DevOps per ottenere i vantaggi tradizionali della gestione dei controlli di rete, come rilasci più prevedibili, test automatizzati con strumenti come [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)e rilevamento degli scostamenti tra l'ambiente distribuito e la configurazione desiderata.
In base alle decisioni prese nell'ambito di [SEC05-BP01 Create network layer](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html), potreste avere un approccio di gestione centralizzato alla creazione VPCs dedicato ai flussi di ingresso, uscita e ispezione. [Come descritto nella [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture), è possibile definirli VPCs in un account dedicato all'infrastruttura di rete.](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) È possibile utilizzare tecniche simili per definire centralmente l'VPCsutilizzo dei carichi di lavoro in altri account, i relativi gruppi di sicurezza, le AWS Network Firewall distribuzioni, le regole di Route 53 Resolver e le configurazioni del DNS firewall e altre risorse di rete. Puoi condividere queste risorse con gli altri tuoi account con [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html). Grazie a questo approccio, puoi semplificare test e implementazione automatici dei controlli di rete nell'account di rete, con una sola destinazione da gestire. Puoi farlo in un modello ibrido, in cui distribuisci e condividi determinati controlli centralmente e deleghi altri controlli ai singoli team del carico di lavoro e ai rispettivi account.
## Passaggi dell'implementazione
1. Stabilisci quali aspetti della rete e delle protezioni sono definiti a livello centrale e quali possono essere gestiti dai tuoi team del carico di lavoro.
1. Crea ambienti per testare e implementare le modifiche alla tua rete e alle relative protezioni. Ad esempio, utilizza un account Network Testing e uno Network Production.
1. Determina come archivierai e manterrai i tuoi modelli in un sistema di controllo delle versioni. Archivia i modelli centrali in un repository distinto da quello dei carichi di lavoro, mentre i modelli dei carichi di lavoro possono essere archiviati in repository specifici per quel carico di lavoro.
1. Crea pipeline CI/CD per testare e implementare modelli. Definisci i test per verificare che non ci siano configurazioni errate e che i modelli siano conformi agli standard aziendali.
## Risorse
**Best practice correlate:**
+ [SEC01-BP06 Automatizza l'implementazione dei controlli di sicurezza standard](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls)
**Documenti correlati:**
+ [AWS Security Reference Architecture - Network account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
**Esempi correlati:**
+ [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/)
+ [NetDevSecOpsper modernizzare le AWS implementazioni di rete](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/)
+ [Integrazione di test e report AWS CloudFormation di sicurezza AWS Security Hub CSPMAWS CodeBuild](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/)
**Strumenti correlati:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag)