# Protezione dell'infrastruttura
La protezione dell'infrastruttura include metodologie di controllo, ad esempio la difesa avanzata, necessarie per soddisfare le best practice e gli obblighi normativi oppure organizzativi. L'utilizzo di queste metodologie è fondamentale per il successo delle operazioni continue nel cloud.
La protezione dell'infrastruttura è una parte cruciale di un programma di sicurezza delle informazioni. Assicura infatti che sistemi e servizi all'interno del carico di lavoro siano protetti contro gli accessi accidentali e non autorizzati e contro le potenziali vulnerabilità. Ad esempio, definirai dei limiti di attendibilità (quali i limiti di rete e account), la configurazione e la manutenzione della sicurezza del sistema (includendo argomenti come hardening, minimizzazione e applicazione di patch), l'autenticazione e le autorizzazioni del sistema operativo (prendendoti cura di utenti, chiavi e livelli di accesso) e altri punti appropriati di applicazione delle policy (quali firewall di applicazioni Web e/o gateway API).
**Regioni, zone di disponibilità, zone locali AWS e AWS Outposts**
Assicurati di conoscere regioni, zone di disponibilità, [zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) e [AWS Outposts](https://aws.amazon.com/outposts/), i componenti dell'infrastruttura globale AWS sicura.
AWS presenta il concetto di regione, ossia una sede fisica nel mondo dove riuniamo i data center. Ogni gruppo di data center logici viene definito zona di disponibilità (AZ). Ciascuna regione AWS si compone di numerose AZ isolate e fisicamente separate all'interno di un'area geografica. Se hai requisiti di residenza dei dati puoi scegliere la regione AWS vicina alla sede desiderata. Mantieni il controllo completo e la proprietà della regione in cui i dati sono fisicamente posizionati e questo può essere utile per soddisfare i requisiti di residenza dei dati e di conformità a livello regionale. Ciascun AZ dispone di fonti energetiche, sistemi di raffreddamento e sicurezza fisica indipendenti. In caso di suddivisione di un'applicazione in più AZ, aumentano isolamento e protezione da problematiche come interruzioni dell'alimentazione, fulmini, tornado, terremoti e altro ancora. Le AZ sono fisicamente separate da qualsiasi altra AZ da una distanza significativa (molti chilometri), sebbene siano tutte entro i 100 km (60 miglia) le une dalle altre. Tutte le AZ in una regione AWS sono interconnesse con una larghezza di banda elevata e una rete a bassa latenza, usano una fibra metropolitana dedicata e completamente ridondante con un throughput elevato e rete a bassa latenza tra le AZ. Tutto il traffico tra le AZ è crittografato. I clienti AWS focalizzati sull'alta disponibilità possono progettare le proprie applicazioni in modo da eseguirle in più AZ e raggiungere una tolleranza ai guasti ancora più elevata. AWS Le regioni soddisfano i più elevati livelli di sicurezza, conformità e protezione dei dati.
Le zone locali AWS posizionano i servizi AWS di calcolo, archiviazione, database e di altro tipo più vicino agli utenti. Le zone locali AWS semplificano l'esecuzione di applicazioni complesse che richiedono latenze di millisecondi a una sola cifra ai propri utenti finali, come la creazione di contenuti di media e intrattenimento, giochi in tempo reale, simulazioni di giacimenti, automazione di progettazione elettronica e machine learning. Ogni posizione di una zona locale AWS è un'estensione di una regione AWS, dove puoi eseguire applicazioni sensibili alla latenza, utilizzando servizi AWS come Amazon EC2, Amazon VPC, Amazon EBS, Amazon File Storage ed Elastic Load Balancing in prossimità geografica agli utenti finali. AWS Le zone locali offrono una connessione sicura e con larghezza di banda elevata tra i carichi di lavoro locali e quelli in esecuzione nella regione AWS, consentendoti di connetterti con facilità alla gamma completa dei servizi regionali tramite le stesse API e gli stessi set di strumenti.
AWS Outposts porta servizi nativi, infrastruttura e modelli operativi AWS praticamente in ogni data center, spazio in co-locazione o struttura on-premises. Puoi usare gli stessi strumenti, le stesse API e le stesse infrastrutture AWS nelle sedi on-premises e nel cloud AWS per offrire un'esperienza ibrida realmente coerente. AWS Outposts è progettato per ambienti connessi e può essere utilizzato per supportare carichi di lavoro che devono rimanere on-premises a causa della bassa latenza o delle esigenze di elaborazione dei dati in locale.
In AWS, ci sono diversi approcci alla protezione dell'infrastruttura. Le seguenti sezioni illustrano come utilizzare questi approcci.
**Topics**
+ [Protezione delle reti](protecting-networks.md)
+ [Protezione delle risorse di calcolo](protecting-compute.md)
# 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)
# Protezione delle risorse di calcolo
Le risorse di calcolo includono istanze EC2, container, funzioni AWS Lambda, servizi di database, dispositivi IoT e altro ancora. Ciascuno di questi tipi di risorse di calcolo richiede approcci di sicurezza diversi. Tuttavia, condividono strategie comuni da prendere in considerazione: difesa in profondità, gestione delle vulnerabilità, riduzione della superficie di attacco, automazione di configurazione e operatività ed esecuzione di attività a distanza. In questa sezione troverai linee guida generali per la protezione di risorse di calcolo per servizi chiave. Per ciascun servizio AWS utilizzato, è importante verificare i suggerimenti di sicurezza specifici nella documentazione del servizio.
**Topics**
+ [SEC06-BP01 Gestione delle vulnerabilità](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Fornitura di dati di calcolo a partire da immagini rinforzate](sec_protect_compute_hardened_images.md)
+ [SEC06-BP03 Riduzione della gestione manuale e dell'accesso interattivo](sec_protect_compute_reduce_manual_management.md)
+ [SEC06-BP04 Convalida l'integrità del software](sec_protect_compute_validate_software_integrity.md)
+ [SEC06-BP05 Automatizzazione della protezione delle risorse di calcolo](sec_protect_compute_auto_protection.md)
# SEC06-BP01 Gestione delle vulnerabilità
Scansiona e correggi di frequente le vulnerabilità del codice, delle dipendenze e dell'infrastruttura per proteggerti da nuove minacce.
**Risultato desiderato:** disponi di una soluzione che analizza continuamente il carico di lavoro alla ricerca di vulnerabilità del software, potenziali difetti ed esposizione involontaria della rete. Hai definito processi e procedure per identificare, assegnare priorità e correggere queste vulnerabilità in base a criteri di valutazione del rischio. Inoltre, hai implementato la gestione automatizzata delle patch per le istanze di calcolo. Il programma di gestione delle vulnerabilità è integrato nel ciclo di vita di sviluppo del software, con soluzioni per la scansione del codice sorgente durante la pipeline CI/CD.
**Anti-pattern comuni:**
+ Assenza di un programma di gestione delle vulnerabilità.
+ Esecuzione di patch di sistema senza considerare gravità o prevenzione del rischio.
+ Utilizzo di software che ha superato la data di fine vita (EOL) prevista dal fornitore.
+ Implementazione del codice in produzione prima di aver analizzato i problemi di sicurezza.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
La gestione delle vulnerabilità è un aspetto fondamentale per mantenere un ambiente cloud sicuro e affidabile. Implica un processo completo che include scansioni di sicurezza, identificazione e definizione delle priorità dei problemi e operazioni di applicazione delle patch per risolvere le vulnerabilità identificate. L'automazione svolge un ruolo fondamentale in questo processo perché facilita la scansione continua dei carichi di lavoro alla ricerca di potenziali problemi ed esposizione involontaria della rete, nonché le operazioni di correzione.
Il [modello di responsabilità condivisa di AWS](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html) è un concetto fondamentale alla base della gestione delle vulnerabilità. Secondo questo modello, AWS è responsabile della protezione dell'infrastruttura sottostante, compresi hardware, software, reti e strutture in cui vengono eseguiti i servizi AWS. D'altra parte, l'utente è responsabile della protezione dei dati, delle configurazioni di sicurezza e delle attività di gestione associate a servizi come le istanze Amazon EC2 e gli oggetti Amazon S3.
AWS offre una gamma di servizi utili per i programmi di gestione delle vulnerabilità. [Amazon Inspector](https://aws.amazon.com/inspector/) analizza continuamente i carichi di lavoro AWS alla ricerca di vulnerabilità del software e accessi involontari alla rete, mentre [Gestione patch di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) aiuta a gestire l'applicazione delle patch sulle istanze Amazon EC2. Questi servizi possono essere integrati con [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), un servizio di gestione del livello di sicurezza nel cloud che automatizza i controlli di sicurezza di AWS, centralizza gli avvisi di sicurezza e fornisce una visione completa del livello di sicurezza di un'organizzazione. Inoltre, [Sicurezza di Amazon CodeGuru](https://aws.amazon.com/codeguru/) utilizza l'analisi statica del codice per identificare potenziali problemi nelle applicazioni Java e Python durante la fase di sviluppo.
Incorporando pratiche di gestione delle vulnerabilità nel ciclo di vita dello sviluppo software, puoi affrontare in modo proattivo le vulnerabilità prima che vengano introdotte negli ambienti di produzione, riducendo così il rischio di eventi di sicurezza e riducendo al minimo il potenziale impatto delle vulnerabilità.
### Passaggi dell'implementazione
1. **Comprendi il modello di responsabilità condivisa:** consulta il modello di responsabilità condivisa di AWS per comprendere le tue responsabilità in materia di protezione dei carichi di lavoro e dei dati nel cloud. AWS è responsabile della protezione dell'infrastruttura cloud sottostante, mentre tu sei responsabile della protezione delle applicazioni, dei dati e dei servizi che utilizzi.
1. **Implementa la scansione delle vulnerabilità:** configura un servizio di scansione delle vulnerabilità, come Amazon Inspector, per scansionare automaticamente le istanze di calcolo (ad esempio, macchine virtuali, container o funzioni serverless) alla ricerca di vulnerabilità software, potenziali difetti ed esposizione involontaria della rete.
1. **Stabilisci processi di gestione delle vulnerabilità:** definisci processi e procedure per identificare, assegnare priorità e correggere le vulnerabilità. Ciò può includere la pianificazione di scansioni periodiche delle vulnerabilità, la definizione di criteri di valutazione dei rischi e l'individuazione di tempistiche di correzione in base alla gravità della vulnerabilità.
1. **Configura la gestione delle patch:** utilizza un servizio di gestione delle patch per automatizzare il processo di applicazione delle patch alle istanze di calcolo, sia per i sistemi operativi che per le applicazioni. Puoi configurare il servizio affinché scansioni le istanze alla ricerca di patch mancanti e installi automaticamente le patch in base a una pianificazione. Prendi in considerazione Gestione patch di AWS Systems Manager per fornire questa funzionalità.
1. **Configura la protezione contro i malware:** implementa meccanismi per rilevare eventuali software dannosi nel tuo ambiente. Ad esempio, puoi utilizzare strumenti come [Amazon GuardDuty](https://aws.amazon.com/guardduty/) per analizzare e rilevare eventuali malware, nonché per notificarne la presenza nei volumi EC2 ed EBS. GuardDuty può anche scansionare gli oggetti appena caricati su Amazon S3 alla ricerca di potenziali malware o virus e intervenire per isolarli prima che vengano inseriti nei processi a valle.
1. **Integra la scansione delle vulnerabilità nelle pipeline CI/CD:** se utilizzi una pipeline CI/CD per l'implementazione delle applicazioni, integra gli strumenti di scansione delle vulnerabilità nella pipeline. Strumenti come Sicurezza di Amazon CodeGuru e le opzioni open source consentono di scansionare il codice sorgente, le dipendenze e gli artefatti alla ricerca di potenziali problemi di sicurezza.
1. **Configura un servizio di monitoraggio della sicurezza:** configura un servizio di monitoraggio della sicurezza, come AWS Security Hub CSPM, per ottenere una visione completa del tuo livello di sicurezza su più servizi cloud. Il servizio deve raccogliere gli esiti in materia di sicurezza da varie origini e presentarli in un formato standardizzato per facilitare la definizione delle priorità e la correzione.
1. **Implementa test di penetrazione delle applicazioni web**: se la tua applicazione è un'applicazione web e la tua organizzazione dispone delle competenze necessarie o può usufruire di assistenza esterna, valuta la possibilità di implementare dei test di penetrazione delle applicazioni web per identificare potenziali vulnerabilità nella tua applicazione.
1. **Automatizza con l'infrastructure as code**: utilizza strumenti di infrastructure as code (IaC), come [AWS CloudFormation](https://aws.amazon.com/cloudformation/), per automatizzare l'implementazione e la configurazione delle risorse, inclusi i servizi di sicurezza menzionati in precedenza. Questa pratica consente di creare un'architettura delle risorse più coerente e standardizzata per più account e ambienti.
1. **Monitora e migliora continuamente**: monitora continuamente l'efficacia del programma di gestione delle vulnerabilità e apporta i miglioramenti necessari. Esamina gli esiti di sicurezza, valuta l'efficacia delle operazioni di correzione e adatta di conseguenza i tuoi processi e strumenti.
## Risorse
**Documenti correlati:**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Panoramica sulla sicurezza di AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf)
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Improved, Automated Vulnerability Management for Cloud Workloads with a New Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)
**Video correlati:**
+ [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY)
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)
# SEC06-BP02 Fornitura di dati di calcolo a partire da immagini rinforzate
Riduci le opportunità di accesso involontario agli ambienti di runtime implementandoli da immagini rafforzate. Acquisisci dipendenze di runtime, come immagini di container e librerie di applicazioni, solo da registri affidabili e verifica le loro firme. Crea i tuoi registri privati per archiviare immagini e librerie attendibili da utilizzare nei tuoi processi di compilazione e implementazione.
**Risultato desiderato:** l'allocazione delle risorse di calcolo avviene a partire da immagini di base rinforzate. Le dipendenze esterne, ad esempio immagini dei container e librerie di applicazioni, vengono recuperate solo da registri attendibili e ne vengono verificate le firme. Queste sono archiviate in registri privati a cui i processi di compilazione e implementazione possono fare riferimento. Scansiona e aggiorna con regolarità immagini e dipendenze per proteggerti da eventuali vulnerabilità scoperte di recente.
**Anti-pattern comuni:**
+ Acquisizione di immagini e librerie da registri attendibili, ma senza verificarne la firma o eseguire scansioni delle vulnerabilità prima di metterle in uso.
+ Rafforzamento delle immagini, ma senza test regolari per individuare nuove vulnerabilità o aggiornarle alla versione più recente.
+ Installazione o non rimozione di pacchetti software non necessari durante il ciclo di vita previsto dell'immagine.
+ Affidamento esclusivo alle patch per mantenere aggiornate le risorse di calcolo di produzione. La sola applicazione di patch può comunque far sì che nel tempo le risorse di calcolo si allontanino dallo standard rafforzato. L'applicazione delle patch può inoltre non essere in grado di rimuovere le minacce informatiche che un attore pericoloso potrebbero aver installato durante un evento di sicurezza.
**Vantaggi dell'adozione di questa best practice:** il rafforzamento delle immagini favorisce la riduzione del numero di percorsi disponibili nell'ambiente di runtime, che possono consentire l'accesso non intenzionale a utenti o servizi non autorizzati. Inoltre, può ridurre l'ambito dell'impatto in caso di accesso involontario.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Per rafforzare i tuoi sistemi, occorre partire dalle versioni più recenti dei sistemi operativi, delle immagini dei container e delle librerie delle applicazioni. Applica le patch ai problemi noti. Riduci al minimo il sistema rimuovendo applicazioni, servizi, driver dei dispositivi, utenti predefiniti e altre credenziali non necessari. Adotta qualsiasi altra azione necessaria, come la disabilitazione delle porte, per creare un ambiente che disponga solo delle risorse e delle capacità necessarie per i carichi di lavoro. Da questa linea di base è possibile installare software, agenti o altri processi necessari per scopi quali il monitoraggio del carico di lavoro o la gestione delle vulnerabilità.
[È possibile ridurre l'onere del rafforzamento dei sistemi utilizzando le linee guida fornite da fonti attendibili, come le guide tecniche per l'implementazione della sicurezza del [Center for Internet Security](https://www.cisecurity.org/) (CIS) e della Defense Information Systems Agency (DISA). STIGs](https://public.cyber.mil/stigs/) Ti consigliamo di iniziare con una [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) pubblicata da AWS o da un APN partner e utilizzare AWS [EC2Image Builder](https://aws.amazon.com/image-builder/) per automatizzare la configurazione in base a una combinazione appropriata di CIS controlli e. STIG
Sebbene siano disponibili immagini rinforzate e ricette di EC2 Image Builder che applicano CIS i consigli DISA STIG o, è possibile che la loro configurazione impedisca il corretto funzionamento del software. In questa situazione, è possibile partire da un'immagine di base non protetta, installare il software e quindi applicare i CIS controlli in modo incrementale per testarne l'impatto. Per qualsiasi CIS controllo che impedisca l'esecuzione del software, verifica se invece riesci a implementare i consigli più dettagliati sulla protezione avanzata in un. DISA Tieni traccia dei diversi CIS controlli e DISA STIG configurazioni che riesci ad applicare con successo. Utilizzateli per definire di conseguenza le vostre ricette di rafforzamento delle EC2 immagini in Image Builder.
[Per i carichi di lavoro containerizzati, le immagini rinforzate di Docker sono disponibili nell'archivio pubblico [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) (). ECR](https://gallery.ecr.aws/docker) È possibile utilizzare EC2 Image Builder per rafforzare le immagini dei contenitori. AMIs
Analogamente ai sistemi operativi e alle immagini dei contenitori, è possibile ottenere pacchetti di codice (o *librerie*) da archivi pubblici, tramite strumenti come pip, npm, Maven e. NuGet Ti consigliamo di gestire i pacchetti di codice integrando repository privati, ad esempio all'interno di [AWS CodeArtifact](https://aws.amazon.com/codeartifact/), con repository pubblici affidabili. Questa integrazione può gestire il recupero, l'archiviazione e la conservazione dei pacchetti per te. up-to-date I processi di creazione delle applicazioni possono quindi ottenere e testare la versione più recente di questi pacchetti insieme all'applicazione, utilizzando tecniche come Software Composition Analysis (SCA), Static Application Security Testing (SAST) e Dynamic Application Security Testing (DAST).
[Per i carichi di lavoro serverless che utilizzano AWS Lambda, semplifica la gestione delle dipendenze dei pacchetti utilizzando i livelli Lambda.](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) Usa i livelli Lambda per configurare un set di dipendenze standard condivise tra diverse funzioni in un archivio autonomo. È possibile creare e gestire i livelli tramite il relativo processo di compilazione, in modo da garantire la permanenza delle funzioni in modo centralizzato. up-to-date
## Passaggi dell'implementazione
+ Rafforzamento del sistema operativo. Utilizzate immagini di base provenienti da fonti attendibili come base per costruire il vostro hardenedAMIs. Usa [EC2Image Builder](https://aws.amazon.com/image-builder/) per personalizzare il software installato sulle tue immagini.
+ Rafforzamento delle risorse containerizzate. Configura le risorse containerizzate in modo che rispettino le best practice in materia di sicurezza. Quando utilizzi i contenitori, implementa [la scansione delle ECR immagini](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) nella tua pipeline di creazione e, su base regolare, nel tuo archivio di immagini da cercare CVEs nei contenitori.
+ Quando si utilizza l'implementazione serverless con AWS Lambda, utilizza i livelli [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) per separare il codice delle funzioni dell'applicazione e le librerie dipendenti condivise. Configura la [firma del codice](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) per Lambda così da garantire l'esecuzione del solo codice attendibile nelle funzioni Lambda.
## Risorse
**Best practice correlate:**
+ [OPS05-BP05 Esegui la gestione delle patch](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html)
**Video correlati:**
+ [Approfondimento sulla sicurezza AWS Lambda](https://www.youtube.com/watch?v=FTwsMYXWGB0)
**Esempi correlati:**
+ [STIGCompatibile con la compilazione rapida con Image AMI Builder EC2](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/)
+ [Building better container images](https://aws.amazon.com/blogs/containers/building-better-container-images/)
+ [Using Lambda layers to simplify your development process](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/)
+ [Sviluppa e distribuisci AWS Lambda livelli utilizzando Serverless Framework](https://github.com/aws-samples/aws-serverless-lambda-layers)
+ [Creazione di una pipeline end-to-end AWS DevSecOps CI/CD con strumenti e software open source SCA SAST DAST](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
# SEC06-BP03 Riduzione della gestione manuale e dell'accesso interattivo
Utilizza l'automazione per eseguire attività di implementazione, configurazione, manutenzione e investigazione, laddove possibile. Quando l'automazione non è disponibile, considera l'accesso manuale alle risorse di calcolo in caso di procedure di emergenza o in ambienti sicuri (sandbox).
**Risultato desiderato:** acquisizione mediante script programmatici e documenti di automazione (runbook) delle azioni autorizzate sulle tue risorse di calcolo. Questi runbook vengono avviati in automatico, attraverso i sistemi di rilevamento delle modifiche, o manualmente, quando è necessario il giudizio umano. L'accesso diretto alle risorse di calcolo è disponibile solo in situazioni di emergenza, quando l'automazione non è disponibile. Tutte le attività manuali vengono inserite in un log e in un processo di revisione per migliorare in modo continuo le capacità di automazione.
**Anti-pattern comuni:**
+ Accesso interattivo alle istanze Amazon EC2 con protocolli come SSH o RDP.
+ Mantenimento degli accessi dei singoli utenti, come `/etc/passwd` o gli utenti locali di Windows.
+ Condivisione di una password o chiave privata per accedere a un'istanza tra più utenti.
+ Installazione del software e creazione o aggiornamento manuali dei file di configurazione.
+ Aggiornamento o applicazione di patch manuale al software.
+ Accesso a un'istanza per risolvere i problemi.
**Vantaggi dell'adozione di questa best practice:** l'esecuzione di azioni automatizzate favorisce la riduzione del rischio operativo legato a modifiche non intenzionali ed errori di configurazione. Abolire l'uso di Secure Shell (SSH) e Remote Desktop Protocol (RDP) per l'accesso interattivo significa ridurre la portata dell'accesso alle risorse di calcolo. In tal modo si elimina un percorso comune per le azioni non autorizzate. Acquisire le attività di gestione delle risorse di calcolo in documenti di automazione e script di programmazione significa definire e sottoporre ad audit l'intero ambito delle attività autorizzate a un livello di dettaglio granulare.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
L'accesso a un'istanza è un approccio classico all'amministrazione del sistema. Dopo aver installato il sistema operativo del server, gli utenti in genere accedono manualmente per configurare il sistema e installare il software desiderato. Nel corso del ciclo di vita del server, gli utenti possono accedere per eseguire aggiornamenti del software, applicare patch, modificare le configurazioni e risolvere i problemi.
L'accesso manuale comporta tuttavia una serie di rischi. Richiede un server che ascolti le richieste, come un servizio SSH o RDP, in grado di fornire un potenziale percorso di accesso non autorizzato. Inoltre, aumenta il rischio di errore umano associato all'esecuzione di operazioni manuali. Le conseguenze possono essere incidenti sul carico di lavoro, danneggiamento o distruzione dei dati o altri problemi di sicurezza. L'accesso umano richiede inoltre protezioni contro la condivisione delle credenziali, creando ulteriori costi di gestione.
Per mitigare questi rischi, è possibile implementare una soluzione di accesso remoto basata su agenti, come [AWS Systems Manager](https://aws.amazon.com/systems-manager/). AWS Systems Manager L'agente (SSM Agent) avvia un canale crittografato, pertanto non si avvale dell'ascolto di richieste esterne. Per [stabilire questo canale su un endpoint VPC](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html), valuta il ricorso alla configurazione di SSM Agent.
Systems Manager offre un controllo granulare delle modalità di interazione con le istanze gestite. Sei tu a definire le automazioni da eseguire, chi può eseguirle e quando possono essere eseguite. Systems Manager è in grado di applicare patch, installare software e apportare modifiche alla configurazione senza accesso interattivo all'istanza. Systems Manager può inoltre fornire l'accesso a una shell (interprete di comandi) remota e registrare ogni comando richiamato e il relativo output durante la sessione nei log e in [Amazon S3](https://aws.amazon.com/s3/). [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) registra le invocazioni delle API di Systems Manager per l'ispezione.
### Passaggi dell'implementazione
1. [Installa AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) (SSM Agent) sulle istanze Amazon EC2. Verifica se SSM Agent è incluso e avviato in automatico nell'ambito della configurazione AMI di base.
1. Verifica che i ruoli IAM associati ai profili dei tuoi profili delle istanze EC2 includano la [policy IAM gestita](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) di `AmazonSSMManagedInstanceCore`.
1. Disabilita SSH, RDP e altri servizi di accesso remoto in esecuzione sulle tue istanze. Puoi farlo eseguendo script configurati nella sezione dei dati utente dei tuoi modelli di avvio o creando AMI personalizzate con strumenti come EC2 Image Builder.
1. Verifica che le regole di ingresso del gruppo di sicurezza applicabili alle tue istanze EC2 non consentano l'accesso sulla porta 22/tcp (SSH) o sulla porta 3389/tcp (RDP). Implementa il rilevamento e l'invio di avvisi su gruppi di sicurezza non configurati correttamente utilizzando servizi come AWS Config.
1. Definisci automazioni, runbook ed esegui comandi appropriati in Systems Manager. Utilizza le policy IAM per definire chi può eseguire queste azioni e le condizioni in base alle quali sono consentite. Testa in modo approfondito queste automazioni in un ambiente non di produzione. Richiama queste automazioni quando necessario, invece di accedere in modo interattivo all'istanza.
1. Utilizza [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) per fornire un accesso interattivo alle istanze, quando necessario. Attiva la creazione di log delle attività di sessione per mantenere un audit trail in [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) o [Amazon S3](https://aws.amazon.com/s3/).
## Risorse
**Best practice correlate:**
+ [REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html)
**Esempi correlati:**
+ [Replacing SSH access to reduce management and security overhead with AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/)
**Strumenti correlati:**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
**Video correlati:**
+ [Controlling User Session Access to Instances in AWS Systems Manager Session Manager](https://www.youtube.com/watch?v=nzjTIjFLiow)
# SEC06-BP04 Convalida l'integrità del software
Utilizza la verifica crittografica per convalidare l'integrità degli artefatti software (comprese le immagini) utilizzati dal tuo carico di lavoro. La firma crittografica del software è una tutela contro le modifiche non autorizzate eseguite negli ambienti di calcolo.
**Risultato desiderato:** ottenimento di tutti gli artefatti da fonti attendibili. I certificati del sito Web del fornitore sono convalidati. Gli artefatti scaricati vengono verificati a livello crittografico tramite le relative firme. Il tuo software è firmato e verificato a livello crittografico dai tuoi ambienti di elaborazione.
**Anti-pattern comuni:**
+ Affidarsi a siti Web di fornitori attendibili per ottenere artefatti software, ma ignorare gli avvisi di scadenza dei certificati. Download senza confermare la validità dei certificati.
+ Convalida dei certificati dei siti Web dei fornitori, ma senza verificare a livello crittografico gli artefatti scaricati da questi siti Web.
+ Affidarsi esclusivamente a digest o hash per convalidare l'integrità del software. Gli hash stabiliscono che gli artefatti non sono stati modificati rispetto alla versione originale, ma non ne convalidano l'origine.
+ Mancata firma di software, codice o librerie di proprietà, anche se utilizzati solo per le proprie implementazioni.
**Vantaggi dell'adozione di questa best practice:** la convalida dell'integrità degli artefatti da cui dipende il carico di lavoro consente di prevenire l'ingresso di malware negli ambienti di calcolo. La firma del software aiuta a proteggerti dall'esecuzione non autorizzata nei tuoi ambienti di calcolo. Proteggi la catena di approvvigionamento del software firmando e verificando il codice.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Immagini del sistema operativo, immagini dei container e artefatti del codice sono spesso distribuiti con controlli di integrità disponibili, ad esempio attraverso un digest o un hash. Questi permettono ai client di verificare l'integrità elaborando il proprio hash del payload e verificando che sia uguale a quello pubblicato. Sebbene questi controlli aiutino a verificare l'assenza di manomissioni del payload, non ne convalidano la provenienza dalla fonte originale (la sua *provenienza*). La verifica della provenienza richiede un certificato rilasciato da un'autorità attendibile per firmare digitalmente l'artefatto.
Se utilizzi un software o artefatti scaricati nel tuo carico di lavoro, controlla se il fornitore offre una chiave pubblica per la verifica della firma digitale. Ecco alcuni esempi di come AWS fornisce una chiave pubblica e le istruzioni di verifica per il software che pubblichiamo:
+ [EC2Image Builder: verifica la firma del download di installazione AWS TOE](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html)
+ [AWS Systems Manager: verifica della firma dell'agente SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html)
+ [Amazon CloudWatch: verifica della firma del pacco dell' CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html)
Incorpora la verifica della firma digitale nei processi utilizzati per ottenere e rafforzare le immagini, come discusso in [SEC06-BP02](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html) Provision compute from hardened images.
È possibile utilizzare [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) per la gestione della verifica delle firme, nonché del ciclo di vita di firma del codice per il tuo software e i tuoi artefatti. [AWS Lambda](https://aws.amazon.com/lambda/) e [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) offrono entrambi integrazioni con Signer per verificare le firme di codice e immagini. Utilizzando gli esempi nella sezione Risorse, puoi incorporare Signer nelle tue pipeline di integrazione e distribuzione continua (CI/CD) per automatizzare la verifica delle firme e la firma del tuo codice e delle tue immagini.
## Risorse
**Documenti correlati:**
+ [Cryptographic Signing for Containers](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/)
+ [Le migliori pratiche per proteggere la pipeline di creazione delle immagini dei container utilizzando AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/)
+ [Annuncio della firma di Container Image con AWS Signer Amazon EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/)
+ [Configurazione della firma del codice per AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)
+ [Best practices and advanced patterns for Lambda code signing](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/)
+ [Firma del codice tramite CA AWS Certificate Manager privata e chiavi AWS Key Management Service asimmetriche](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
**Esempi correlati:**
+ [Automatizza la firma del codice Lambda con Amazon e CodeCatalyst AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/)
+ [Firma e convalida OCI degli artefatti con AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/)
**Strumenti correlati:**
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)
+ [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)
+ [AWS Key Management Service](https://aws.amazon.com/kms/)
+ [AWS CodeArtifact](https://aws.amazon.com/codeartifact/)
# SEC06-BP05 Automatizzazione della protezione delle risorse di calcolo
Automatizza le operazioni di protezione delle risorse di calcolo per ridurre la necessità di intervento umano. Usa la scansione automatica per rilevare potenziali problemi all’interno delle tue risorse di calcolo e rimedia con risposte programmatiche automatiche o operazioni di gestione del parco. Incorpora l’automazione nei tuoi processi CI/CD per implementare carichi di lavoro affidabili con dipendenze aggiornate.
**Risultato desiderato:** tutte le scansioni e le applicazioni di patch alle risorse di calcolo avvengono per mezzo di sistemi automatizzati. Utilizzi la verifica automatica per controllare che immagini e dipendenze del software provengano da origini attendibili e non siano state manomesse. Il controllo dei carichi di lavoro avviene in automatico per verificare la presenza di dipendenze aggiornate, così come la relativa firma per stabilire l’affidabilità negli ambienti di calcolo AWS. Le correzioni automatiche vengono avviate al rilevamento di risorse non conformi.
**Anti-pattern comuni:**
+ Adozione della pratica dell’infrastruttura immutabile, senza però disporre di una soluzione di patch di emergenza o di sostituzione dei sistemi di produzione.
+ Utilizzo dell’automazione per correggere le risorse non correttamente configurate, ma senza un meccanismo di annullamento manuale. Possono verificarsi situazioni in cui è necessario modificare i requisiti e sospendere le automazioni fino a quando non si modificano.
**Vantaggi dell’adozione di questa best practice:** riduzione del rischio di accessi alle risorse di calcolo e relativi utilizzi non autorizzati mediante l’automazione. Contribuisce a evitare che le configurazioni errate si diffondano negli ambienti di produzione e a rilevare e correggere tali configurazioni nel caso in cui si verifichino. L’automazione aiuta anche a rilevare l’accesso non autorizzato delle risorse di calcolo e il loro utilizzo, riducendo i tempi di risposta. In questo modo è possibile ridurre la portata complessiva dell’impatto del problema.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
È possibile applicare le automazioni descritte nelle pratiche del pilastro della sicurezza per proteggere le risorse di calcolo. [SEC06-BP01 Gestione delle vulnerabilità](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html) illustra come utilizzare [Amazon Inspector](https://aws.amazon.com/inspector/) nelle pipeline CI/CD e per la scansione continua degli ambienti di runtime alla ricerca di vulnerabilità ed esposizioni comuni (CVE) note. Puoi utilizzare [AWS Systems Manager](https://aws.amazon.com/systems-manager/) per applicare patch o eseguire nuove implementazioni da nuove immagini tramite runbook automatizzati in modo da mantenere il tuo parco di calcolo aggiornato con software e librerie più recenti. Utilizza queste tecniche per ridurre la necessità di processi manuali e l’accesso interattivo alle tue risorse di elaborazione. Consulta [SEC06-BP03 Riduzione della gestione manuale e dell’accesso interattivo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html) per scoprire di più.
L’automazione contribuisce anche all’implementazione di carichi di lavoro affidabili, come illustrato in [SEC06-BP02 Provisioning di calcolo da immagini rafforzate](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html) e [SEC06-BP04 Convalida dell’integrità del software](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html). Puoi utilizzare servizi come [EC2 Image Builder](https://aws.amazon.com/image-builder/), [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html), [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) e [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) per scaricare, verificare, costruire e archiviare immagini e dipendenze di codice rafforzate e approvate. Oltre a Inspector, ognuno di questi può svolgere un ruolo nel processo CI/CD, in modo che il carico di lavoro arrivi in produzione solo quando è confermato che le sue dipendenze sono aggiornate e provengono da origini affidabili. Il carico di lavoro è inoltre firmato in modo che gli ambienti di calcolo AWS, come [AWS Lambda](https://aws.amazon.com/lambda/) e [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), possano verificare l’assenza di manomissioni prima di consentirne l’esecuzione.
Oltre a questi controlli preventivi, è possibile utilizzare l’automazione nei controlli investigativi anche per le risorse di calcolo. Ad esempio, [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) offre lo standard [NIST 800-53 Rev. 5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html) che include controlli come le [[EC2.8] EC2 le istanze devono utilizzare Instance Metadata Service versione 2 (IMDSv2).](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8). IMDSv2 utilizza le tecniche di autenticazione della sessione, il blocco delle richieste che contengono un’intestazione X-Forwarded-For HTTP e un TTL di rete pari a 1 per bloccare il traffico proveniente da origini esterne al fine di recuperare informazioni sull’istanza EC2. Questo controllo in Security Hub CSPM può rilevare quando le istanze EC2 utilizzano IMDSv1 e avviare una riparazione automatizzata. Scopri di più su rilevamento e riparazioni automatiche in [SEC04-BP04 Avvio della riparazione delle risorse non conformi](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html).
### Passaggi dell’implementazione
1. Automatizza la creazione di AMI rafforzate, conformi e consolidate con [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html). È possibile produrre immagini che incorporano i controlli dei benchmark del Center for Internet Security (CIS) o gli standard della Security Technical Implementation Guide (STIG) dalle immagini di base di AWS e dei partner APN.
1. Automatizza la gestione delle configurazioni. Applica e convalida in automatico le configurazioni sicure nelle risorse di calcolo utilizzando un servizio o uno strumento di gestione della configurazione.
1. Gestione automatizzata della configurazione tramite [AWS Config](https://aws.amazon.com/config/)
1. Gestione automatizzata del livello di sicurezza e conformità tramite [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)
1. Automatizza applicazione delle patch o sostituzione delle istanze Amazon Elastic Compute Cloud (Amazon EC2). AWS Gestione patch di Systems Manager automatizza il processo di applicazione di patch alle istanze gestite con aggiornamenti correlati alla sicurezza e di altro tipo. Gestione patch consente di applicare patch sia per i sistemi operativi sia per le applicazioni
1. [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
1. Automatizza la scansione delle risorse di calcolo alla ricerca di vulnerabilità ed esposizioni comuni (CVE) e integra le soluzioni di scansione della sicurezza nella tua pipeline di compilazione.
1. [Amazon Inspector](https://aws.amazon.com/inspector/)
1. [Scansione delle immagini ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)
1. Prendi in considerazione Amazon GuardDuty per il rilevamento automatico di malware e minacce al fine di proteggere le risorse di calcolo. GuardDuty può anche identificare potenziali problemi in caso di richiamo di una funzione [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) nel tuo ambiente AWS.
1. [Amazon GuardDuty](https://aws.amazon.com/guardduty/)
1. Prendi in considerazione le soluzioni dei partner AWS. AWS I partner offrono prodotti leader nel settore che sono equivalenti, identici o si integrano ai controlli esistenti negli ambienti on-premises. Questi prodotti integrano i servizi AWS esistenti per permettere di implementare un’architettura di sicurezza completa e un’esperienza più fluida nel cloud e negli ambienti on-premises.
1. [Sicurezza dell’infrastruttura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security)
## Risorse
**Best practice correlate:**
+ [SEC01-BP06 Implementazione automatizzata dei controlli di sicurezza standard](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html)
**Documenti correlati:**
+ [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/)
**Video correlati:**
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)