# SEC 9. In che modo proteggi i dati in transito?
Proteggi i dati in transito implementando più controlli, per ridurre il rischio di accessi non autorizzati o perdita.
**Topics**
+ [SEC09-BP01 Implementazione della gestione sicura delle chiavi e dei certificati](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Applicazione della crittografia dei dati in transito](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Automatizzazione del rilevamento degli accessi indesiderati ai dati](sec_protect_data_transit_auto_unintended_access.md)
+ [SEC09-BP04 Autenticazione delle comunicazioni di rete](sec_protect_data_transit_authentication.md)
# SEC09-BP01 Implementazione della gestione sicura delle chiavi e dei certificati
I certificati Transport Layer Security (TLS) vengono utilizzati per proteggere le comunicazioni di rete e stabilire l'identità di siti web, risorse e carichi di lavoro su Internet, nonché sulle reti private.
**Risultato desiderato:** un sistema di gestione dei certificati sicuro in grado di fornire, implementare, archiviare e rinnovare i certificati in un'infrastruttura a chiave pubblica (PKI). Un meccanismo sicuro di gestione delle chiavi e dei certificati impedisce la divulgazione del materiale relativo alle chiavi private dei certificati e rinnova automaticamente il certificato su base periodica. Si integra inoltre con altri servizi per fornire comunicazioni di rete e identità sicure per le risorse delle macchine all'interno del carico di lavoro. Il materiale relativo alla chiave non dovrebbe mai essere accessibile alle identità umane.
**Anti-pattern comuni:**
+ Esecuzione di passaggi manuali durante i processi di distribuzione, implementazione o rinnovo dei certificati.
+ Attenzione insufficiente alla gerarchia delle autorità di certificazione (CA) durante la progettazione di una CA privata.
+ Utilizzo di certificati autofirmati per risorse pubbliche.
**Vantaggi dell'adozione di questa best practice: **
+ Semplificazione della gestione dei certificati attraverso la distribuzione, l'implementazione e il rinnovo automatizzati
+ Incoraggiamento dell'utilizzo della crittografia dei dati in transito con l'utilizzo di certificati TLS
+ Maggiore sicurezza e verificabilità delle operazioni di certificazione intraprese dall'autorità di certificazione
+ Organizzazione delle mansioni di gestione ai diversi livelli della gerarchia della CA
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
I carichi di lavoro moderni fanno ampio uso di comunicazioni di rete crittografate utilizzando protocolli PKI come TLS. La gestione dei certificati PKI può essere complessa, ma la fornitura, la distribuzione, l'implementazione e il rinnovo automatizzati dei certificati possono ridurre l'attrito associato alla loro gestione.
AWS fornisce due servizi per gestire i certificati PKI generici: [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) e [AWS Autorità di certificazione privata (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). ACM è il servizio principale utilizzato dai clienti per fornire, gestire e implementare certificati da utilizzare sia in carichi di lavoro di AWS pubblici che privati. ACM emette certificati utilizzando AWS Private CA e [si integra](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) con molti altri servizi AWS gestiti per fornire certificati TLS sicuri per i carichi di lavoro.
AWS Private CA consente di stabilire la propria autorità di certificazione principale o subordinata e di emettere certificati TLS tramite un'API. È possibile utilizzare questo tipo di certificati in scenari in cui si mantengono il controllo e la gestione della catena di fiducia sul lato client della connessione TLS. Oltre ai casi d'uso TLS, AWS Private CA può essere utilizzato per emettere certificati per i pod Kubernetes, gli attestati dei prodotti dei dispositivi Matter, la firma del codice e altri casi d'uso che prevedono un [modello personalizzato](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). Puoi anche utilizzare la strategia di [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) per fornire credenziali temporanee IAM ai carichi di lavoro on-premise ai quali sono stati assegnati certificati X.509 firmati dalla tua CA privata.
Oltre a ACM e AWS Private CA, [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) fornisce supporto specializzato per il provisioning, la gestione e l'implementazione di certificati PKI su dispositivi IoT. AWS IoT Core fornisce meccanismi specializzati per [l’onboarding di dispositivi IoT](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) nella tua infrastruttura a chiave pubblica su larga scala.
**Considerazioni sulla creazione di una gerarchia CA privata **
Quando è necessario stabilire una CA privata, è importante prestare particolare attenzione a progettare correttamente la gerarchia della CA fin dall'inizio. Quando si crea una gerarchia CA privata è consigliabile distribuire ogni livello della gerarchia CA su Account AWS separati. Questo passaggio intenzionale riduce l'estensione di ogni livello della gerarchia della CA, semplificando l'individuazione delle anomalie nei dati di log di CloudTrail e riducendo l'ambito di accesso o l'impatto in caso di accesso non autorizzato a uno degli account. La CA principale deve risiedere in un account separato e deve essere utilizzata solo per emettere uno o più certificati CA intermedi.
Quindi, crea una o più CA intermedie in account separati dall'account della CA principale per emettere certificati per utenti finali, dispositivi o altri carichi di lavoro. Infine, emetti certificati della tua CA principale a uso delle CA intermedie, che a loro volta emetteranno certificati per gli utenti finali o i dispositivi. Per ulteriori informazioni sulla pianificazione dell'implementazione della CA e sulla progettazione della gerarchia delle CA, inclusa la pianificazione della resilienza, la replica tra regioni, la condivisione delle CA all'interno dell'organizzazione e altro ancora, consulta [Pianificazione dell'implementazione di AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html).
### Passaggi dell'implementazione
1. Determina i servizi AWS pertinenti richiesti per il tuo caso d'uso:
+ Molti casi d'uso possono sfruttare l'infrastruttura a chiave pubblica AWS esistente utilizzando [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). ACM può essere utilizzato per implementare certificati TLS per server Web, sistemi di bilanciamento del carico o altri usi per certificati pubblicamente affidabili.
+ Considera il servizio [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) quando è necessario stabilire una gerarchia di autorità di certificazione privata o accedere a certificati esportabili. ACM può quindi essere utilizzato per emettere [molti tipi di certificati dell'entità finale](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) utilizzando AWS Private CA.
+ Per i casi d'uso in cui i certificati devono essere forniti su larga scala per dispositivi Internet delle cose (IoT) integrati, prendi in considerazione l'uso di [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html).
1. Implementa il rinnovo automatico dei certificati quando possibile:
+ utilizza [rinnovo gestito di ACM](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) per i certificati emessi da ACM insieme ai servizi AWS gestiti integrati.
1. Stabilisci percorsi di registrazione e controllo:
+ Abilita [log CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) per tenere traccia degli accessi agli account che detengono le autorità di certificazione. Prendi in considerazione la possibilità di configurare la convalida dell'integrità dei file di log in CloudTrail per verificarne l'autenticità dei dati.
+ Genera e rivedi periodicamente [rapporti di audit](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) che elencano i certificati che la tua CA privata ha emesso o revocato. Questi report possono essere esportati in un bucket S3.
+ Quando si implementa una CA privata, è inoltre necessario creare un bucket S3 per archiviare l'elenco di revoche dei certificati (CRL). Per indicazioni sulla configurazione di questo bucket S3 in base ai requisiti del carico di lavoro, consulta [Pianificazione di un elenco di revoche di certificati (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
## Risorse
**Best practice correlate:**
+ [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md)
+ [SEC08-BP01 Implementazione della gestione sicura delle chiavi](sec_protect_data_rest_key_mgmt.md)
+ [SEC09-BP04 Autenticazione delle comunicazioni di rete](sec_protect_data_transit_authentication.md)
**Documenti correlati:**
+ [Come ospitare e gestire un'intera infrastruttura di certificati privata in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/)
+ [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/)
+ [Private CA best practices](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html)
+ [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)
**Video correlati:**
+ [Activating AWS Certificate Manager Private CA (workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE)
**Esempi correlati:**
+ [Private CA workshop](https://catalog.workshops.aws/certificatemanager/en-US/introduction)
+ [Workshop sulla gestione dei dispositivi IOT](https://iot-device-management.workshop.aws/en/) (incluso il provisioning dei dispositivi)
**Strumenti correlati:**
+ [Plugin to Kubernetes cert-manager to use AWS Private CA](https://github.com/cert-manager/aws-privateca-issuer)
# SEC09-BP02 Applicazione della crittografia dei dati in transito
Applica i requisiti di crittografia definiti in base alle policy, agli obblighi normativi e agli standard dell'organizzazione per contribuire a soddisfare i requisiti organizzativi, legali e di conformità. Utilizza solo protocolli con crittografia quando trasmetti dati sensibili al di fuori del tuo cloud privato virtuale (VPC). La crittografia aiuta a mantenere la riservatezza dei dati anche quando questi transitano su reti non affidabili.
**Risultato desiderato:** tutti i dati devono essere crittografati in transito utilizzando protocolli e suite di crittografia TLS sicuri. Il traffico di rete tra le tue risorse e Internet deve essere crittografato per evitare l'accesso non autorizzato ai dati. Il traffico di rete esclusivamente all'interno dell'ambiente AWS deve essere crittografato utilizzando TLS, ove possibile. La rete interna di AWS è crittografata per impostazione predefinita e il traffico di rete all'interno di un VPC non può essere sottoposto a spoofing o sniffing, a meno che una parte non autorizzata non abbia ottenuto l'accesso alla risorsa che sta generando il traffico (come le istanze Amazon EC2 e i container Amazon ECS). Considera la possibilità di proteggere il traffico da rete a rete con una rete privata virtuale (VPN) IPsec.
**Anti-pattern comuni:**
+ Utilizzo di versioni obsolete di SSL, TLS e componenti della suite di crittografia (ad esempio, SSL v3.0, chiavi RSA a 1024 bit e crittografia RC4).
+ Autorizzazione del traffico non criptato (HTTP) verso o da risorse pubbliche.
+ Monitoraggio e sostituzione mancati dei certificati X.509 prima della scadenza.
+ Utilizzo di certificati X.509 autofirmati per TLS.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
I servizi AWS forniscono endpoint HTTPS utilizzando TLS per le comunicazioni e forniscono crittografia in transito quando comunicano con le API AWS. I protocolli non sicuri, come HTTP, possono essere sottoposti a audit e bloccati in un VPC tramite l'uso di gruppi di sicurezza. Le richieste HTTP possono essere [reindirizzate automaticamente a HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) in Amazon CloudFront o su un [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions). Hai il controllo completo sulle tue risorse informatiche per implementare la crittografia in transito nei tuoi servizi. Inoltre, puoi utilizzare la connettività VPN nel VPC da una rete esterna o [AWS Direct Connect](https://aws.amazon.com/directconnect/) per facilitare la crittografia del traffico. Verifica che i tuoi client effettuino chiamate alle API AWS utilizzando almeno TLS 1.2, poiché [AWS considererà obsoleto l'utilizzo di TLS 1.0 e 1.1 da giugno 2023](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Per requisiti particolari, in Marketplace AWS sono disponibili soluzioni di terze parti.
**Passaggi dell'implementazione**
+ **Applicazione della crittografia in transito:** i requisiti di crittografia definiti devono essere basati sugli standard e sulle best practice più recenti e consentire solo protocolli sicuri. Ad esempio, configura un gruppo di sicurezza per consentire solo il protocollo HTTPS a un Application Load Balancer o a un'istanza Amazon EC2.
+ **Configura i protocolli sicuri nei servizi edge:** [configura HTTPS con Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) e utilizza un [profilo di sicurezza appropriato per la postura di sicurezza e il caso d'uso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers).
+ **Utilizza una [VPN per la connettività esterna](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html): **valuta l'impiego di una VPN IPsec per la protezione delle connessioni punto a punto o rete a rete al fine di garantire la riservatezza e l'integrità dei dati.
+ **Configura protocolli sicuri nei sistemi di bilanciamento del carico:** seleziona una policy di sicurezza che fornisca le suite di crittografia più efficaci supportate dai client che si connetteranno all'ascoltatore. [Configurazione di un ascoltatore HTTPS per Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html).
+ **Configura protocolli sicuri in Amazon Redshift:** configura il cluster per richiedere una [connessione Secure Socket Layer (SSL) o Transport Layer Security (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html).
+ **Configura protocolli sicuri:** analizza la documentazione relativa al servizio AWS per determinare le capacità di crittografia in transito.
+ **Configura l'accesso sicuro durante il caricamento di bucket Amazon S3:** utilizza i controlli delle policy del bucket Amazon S3 per [applicare l'accesso sicuro](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) ai dati.
+ **Valuta l'utilizzo di [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** ACM consente di fornire, gestire e implementare certificati TLS pubblici da utilizzare con i servizi AWS.
+ **Valuta l'utilizzo di [AWS Autorità di certificazione privata](https://aws.amazon.com/private-ca/) per esigenze di PKI private:** AWS Private CA consente di creare gerarchie di autorità di certificazione (CA) private per emettere certificati X.509 end-entity che possono essere usati per creare canali TLS crittografati.
## Risorse
**Documenti correlati:**
+ [ Documentazione di AWS](https://docs.aws.amazon.com/index.html)
+ [Utilizzo di HTTPS con CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [Connetti il tuo VPC a reti remote utilizzando AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Configurazione di un ascoltatore HTTPS per Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [Tutorial: configurazione di SSL/TLS su Amazon Linux 2 Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [Utilizzo di SSL/TLS per crittografare una connessione a un'istanza database](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [Configurazione delle opzioni di sicurezza per le connessioni ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)
# SEC09-BP03 Automatizzazione del rilevamento degli accessi indesiderati ai dati
Usa strumenti come Amazon GuardDuty per rilevare in automatico attività o tentativi sospetti di trasferire i dati al di fuori di limiti predefiniti. Ad esempio, GuardDuty può rilevare attività di lettura di Amazon Simple Storage Service (Amazon S3) inusuale con [Exfiltration:S3/AnomalousBehavior finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#exfiltration-s3-objectreadunusual). Oltre a GuardDuty, si possono utilizzare i [Registri di flusso Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), che acquisiscono informazioni sul traffico di rete, con Amazon EventBridge per attivare il rilevamento di connessioni anomale, riuscite e negate. [Amazon S3 Access Analyzer](http://aws.amazon.com/blogs/storage/protect-amazon-s3-buckets-using-access-analyzer-for-s3) aiuta a valutare quali dati sono accessibili a chi nei bucket Amazon S3.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Automazione del rilevamento di accessi ai dati non intenzionali: utilizza uno strumento o un meccanismo di rilevamento per rilevare automaticamente i tentativi di spostamento dei dati all'esterno dei confini definiti, ad esempio, per individuare un sistema di database che copia i dati su un host sconosciuto.
+ [ Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ Valutazione di Amazon Macie: Amazon Macie è un servizio di sicurezza e privacy dei dati completamente gestito che utilizza il machine learning e il pattern matching per rilevare e proteggere i dati sensibili all'interno di AWS.
+ [ Amazon Macie ](https://aws.amazon.com/macie/)
## Risorse
**Documenti correlati:**
+ [ Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [ Amazon Macie ](https://aws.amazon.com/macie/)
# SEC09-BP04 Autenticazione delle comunicazioni di rete
Verifica l'identità delle comunicazioni utilizzando protocolli che supportano l'autenticazione, ad esempio Transport Layer Security (TLS) o IPsec.
Progetta il carico di lavoro in modo da utilizzare protocolli di rete sicuri e autenticati per le comunicazioni tra servizi, applicazioni o utenti. L'utilizzo di protocolli di rete che supportano l'autenticazione e l'autorizzazione offre un controllo più rigido sui flussi di rete e riduce l'impatto di eventuali accessi non autorizzati.
**Risultato desiderato:** un carico di lavoro con flussi di traffico del piano dati e del piano di controllo (control-plane) ben definiti tra i servizi. I flussi di traffico utilizzano protocolli di rete autenticati e crittografati laddove tecnicamente fattibile.
**Anti-pattern comuni:**
+ Flussi di traffico non crittografati o non autenticati all'interno del carico di lavoro.
+ Riutilizzo delle credenziali di autenticazione tra più utenti o entità.
+ Uso esclusivo di controlli di rete come meccanismo di controllo degli accessi.
+ Creazione di un meccanismo di autenticazione personalizzato anziché usare meccanismi di autenticazione standard del settore.
+ Flussi di traffico eccessivamente permissivi tra i componenti del servizio o altre risorse nel VPC.
**Vantaggi dell'adozione di questa best practice:**
+ Limita l'ambito dell'impatto di eventuali accessi non autorizzati a una parte del carico di lavoro.
+ Fornisce un livello più elevato di sicurezza affinché le azioni vengano eseguite solo da entità autenticate.
+ Migliora il disaccoppiamento dei servizi definendo e applicando chiaramente le interfacce di trasferimento dei dati previste.
+ Migliora il monitoraggio, la registrazione in log e la risposta agli incidenti tramite l'attribuzione delle richieste e interfacce di comunicazione ben definite.
+ Fornisce un livello elevatissimo di difesa ai carichi di lavoro combinando i controlli di rete con i controlli di autenticazione e autorizzazione.
**Livello di rischio associato alla mancata adozione di questa best practice:** basso
## Guida all'implementazione
I modelli di traffico di rete del carico di lavoro possono essere suddivisi in due categorie:
+ Il *traffico orizzontale (sinistra-destra)* rappresenta i flussi di traffico tra servizi che costituiscono un carico di lavoro.
+ Il *traffico verticale (alto-basso)* rappresenta i flussi di traffico tra il carico di lavoro e i consumatori.
Mentre crittografare il traffico verticale (alto-basso) è prassi comune, proteggere il traffico orizzontale (sinistra-destra) mediante protocolli autenticati non è così frequente. Le moderne best practice di sicurezza raccomandano che la progettazione della rete non sia l'unico elemento in grado di garantire una relazione affidabile tra due entità. Quando due servizi possono trovarsi all'interno di una rete comune, è comunque consigliabile crittografare, autenticare e autorizzare le comunicazioni tra tali servizi.
Ad esempio, le API del servizio AWS utilizzano il protocollo di firma [AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) per autenticare il chiamante, indipendentemente dalla rete da cui proviene la richiesta. Questa autenticazione garantisce che le API AWS possano verificare l'identità che ha richiesto l'azione e che tale identità possa quindi essere combinata con le policy per decidere se autorizzare o meno l'azione.
Servizi come [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) e [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) consentono di utilizzare lo stesso protocollo di firma SigV4 per aggiungere funzionalità di autenticazione e autorizzazione al traffico orizzontale (sinistra-destra) ai carichi di lavoro. Se le risorse esterne all'ambiente AWS devono comunicare con servizi che richiedono l'autenticazione e l'autorizzazione basate su SigV4, è possibile utilizzare [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) sulla risorsa AWS per acquisire credenziali AWS temporanee. Queste credenziali possono essere utilizzate per firmare richieste ai servizi che utilizzano SigV4 per autorizzare l'accesso.
Un altro meccanismo comune per l'autenticazione del traffico orizzontale (sinistra-destra) è l'autenticazione reciproca TLS (mTLS). Molte applicazioni Internet delle cose (IoT), business-to-business (B2B) e microservizi utilizzano mTLS per convalidare l'identità di entrambi i lati di una comunicazione TLS mediante l'uso di certificati X.509 lato client e lato server. Questi certificati possono essere emessi da AWS Autorità di certificazione privata (AWS Private CA). È possibile utilizzare servizi come [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) e [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) per fornire l'autenticazione mTLS per la comunicazione tra carichi di lavoro a tutti i livelli. Sebbene fornisca informazioni di autenticazione per entrambi i lati di una comunicazione TLS, mTLS non fornisce un meccanismo di autorizzazione.
Infine, OAuth 2.0 e OpenID Connect (OIDC) sono due protocolli generalmente utilizzati per controllare l'accesso ai servizi da parte degli utenti, ma stanno diventando popolari anche per il traffico a livello di servizi. API Gateway fornisce un [sistema di autorizzazione JSON Web Token (JWT)](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html), che consente ai carichi di lavoro di limitare l'accesso alle route API utilizzando JWT emessi da gestori dell'identità digitale OIDC o OAuth 2.0. Gli ambiti OAuth2 possono essere utilizzati come base per decisioni di autorizzazione essenziali, ma i controlli di autorizzazione devono comunque essere implementati a livello di applicazione. Gli ambiti OAuth2 da soli non possono supportare requisiti di autorizzazione più complessi.
### Passaggi dell'implementazione
+ **Definisci e documenta i flussi di rete del carico di lavoro:** il primo passo per implementare una strategia di difesa di alto profilo è definire i flussi di traffico del carico di lavoro.
+ Crea un diagramma del flusso di dati che definisca chiaramente come vengono trasmessi i dati tra i diversi servizi che costituiscono il carico di lavoro. Questo diagramma è il primo passo per autorizzare tali flussi nei canali di rete autenticati.
+ Nelle fasi di sviluppo e test dota il carico di lavoro di strumenti per controllare che il diagramma del flusso dei dati rifletta accuratamente il comportamento del carico di lavoro in fase di esecuzione.
+ Un diagramma del flusso dei dati può essere utile anche quando si esegue un esercizio di modellazione delle minacce, come descritto in [SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html).
+ **Definisci i controlli di rete:** considera le funzionalità AWS per stabilire controlli di rete allineati ai flussi di dati. Sebbene i confini della rete non debbano costituire l'unico elemento di controllo della sicurezza, essi forniscono un livello nella strategia di difesa di alto profilo a protezione del carico di lavoro.
+ Utilizza i [gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html) per stabilire, definire e limitare i flussi di dati tra risorse.
+ Valuta l'utilizzo di [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) per comunicare sia con AWS che con i servizi di terze parti che supportano AWS PrivateLink. I dati inviati tramite un endpoint di interfaccia AWS PrivateLink rimangono all'interno della dorsale della rete AWS e non attraversano la rete Internet pubblica.
+ **Implementa l'autenticazione e l'autorizzazione tra i servizi del carico di lavoro:** scegli il set di servizi AWS più appropriato per fornire flussi di traffico autenticati e crittografati nel carico di lavoro.
+ Valuta l'ipotesi di utilizzare [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) per la sicurezza della comunicazione tra servizi. VPC Lattice può utilizzare l'[autenticazione SigV4 combinata con le policy di autenticazione](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) per controllare l'accesso a livello di servizi.
+ Per la comunicazione tra servizi tramite mTLS, valuta l'ipotesi di utilizzare [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) o [App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html). [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) può essere utilizzato per stabilire una gerarchia di autorità di certificazione (CA) private in grado di emettere certificati da utilizzare con mTLS.
+ Quando esegui l'integrazione con servizi che utilizzano OAuth 2.0 o OIDC, considera [l'utilizzo del sistema di autorizzazione JWT da parte di API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html).
+ Per la comunicazione tra il carico di lavoro e i dispositivi IoT, considera l'utilizzo di [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html), che offre diverse opzioni per la crittografia e l'autenticazione del traffico di rete.
+ **Monitora gli accessi non autorizzati:** monitora continuamente i canali di comunicazione non intenzionali, i responsabili non autorizzati che tentano di accedere alle risorse protette e altri schemi di accesso impropri.
+ In caso di utilizzo di VPC Lattice per gestire l'accesso ai servizi, valuta la possibilità di abilitare e monitorare i [log di accesso di VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html). Questi log di accesso includono informazioni sull'entità richiedente, informazioni di rete tra cui VPC di origine e destinazione e metadati della richiesta.
+ Valuta la possibilità di abilitare i [log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) per acquisire i metadati sui flussi di rete e verificare periodicamente la presenza di anomalie.
+ Consulta il manuale [AWSSecurity Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) e la [sezione relativa alle risposte agli incidenti](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) del Pilastro di sicurezza del Framework AWS Well-Architected per ulteriori indicazioni su pianificazione, simulazione e risposte agli incidenti di sicurezza.
## Risorse
**Best practice correlate:**
+ [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC02-BP02 Utilizzo di credenziali temporanee](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**Documenti correlati:**
+ [Valutazione dei metodi di controllo degli accessi per proteggere le API Amazon API Gateway](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [Configurazione dell'autenticazione TLS reciproca per una REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [Come proteggere gli endpoint HTTP API Gateway con il sistema di autorizzazione JWT](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [Autorizzazione delle chiamate dirette ai servizi AWS mediante il provider di credenziali AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [AWS Security Incident Response Guide ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Video correlati:**
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)
**Esempi correlati:**
+ [ Workshop Amazon VPC Lattice](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Zero-Trust Episode 1 – The Phantom Service Perimeter workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)