Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Riduzione della superficie di attacco
Un'altra considerazione importante quando si progetta una AWS soluzione è limitare le opportunità che un utente malintenzionato ha di prendere di mira l'applicazione. Questo concetto è noto come riduzione della *superficie di attacco.* Le risorse che non sono esposte a Internet sono più difficili da attaccare, il che limita le opzioni a disposizione di un utente malintenzionato per prendere di mira la disponibilità dell'applicazione.
Ad esempio, se non vi aspettate che gli utenti interagiscano direttamente con determinate risorse, assicuratevi che tali risorse non siano accessibili da Internet. Analogamente, non accettate il traffico proveniente da utenti o applicazioni esterne su porte o protocolli che non sono necessari per la comunicazione.
Nella sezione seguente, vengono AWS fornite le migliori pratiche per aiutarvi a ridurre la superficie di attacco e limitare l'esposizione dell'applicazione a Internet.
# AWS Risorse offuscanti (,,) BP1 BP4 BP5
In genere, gli utenti possono utilizzare un'applicazione in modo rapido e semplice senza richiedere che AWS le risorse siano completamente esposte a Internet.
# Gruppi di sicurezza e rete ACLs (BP5)
Amazon Virtual Private Cloud (AmazonVPC) consente di effettuare il provisioning di una sezione logicamente isolata della Cloud AWS quale è possibile avviare AWS risorse in una rete virtuale definita dall'utente.
I gruppi di sicurezza e la rete ACLs sono simili in quanto consentono di controllare l'accesso alle AWS risorse all'interno dell'aziendaVPC. Tuttavia, i gruppi di sicurezza consentono di controllare il traffico in entrata e in uscita a livello di istanza, mentre la rete ACLs offre funzionalità simili a livello di VPC sottorete. Non sono previsti costi aggiuntivi per l'utilizzo dei gruppi di sicurezza o della rete. ACLs
È possibile scegliere se specificare i gruppi di sicurezza all'avvio di un'istanza o associare l'istanza a un gruppo di sicurezza in un secondo momento. Tutto il traffico Internet verso un gruppo di sicurezza viene negato implicitamente a meno che non si crei una regola *di* autorizzazione per consentire il traffico.
Ad esempio, se hai EC2 istanze Amazon dietro un Elastic Load Balancer, non è necessario che le istanze stesse siano accessibili pubblicamente e dovrebbero essere solo private. IPs È possibile invece fornire a Elastic Load Balancer l'accesso alle porte listener di destinazione richieste utilizzando una regola del gruppo di sicurezza che consente l'accesso a 0.0.0.0/0 (per evitare problemi di tracciamento della connessione, vedere la nota seguente) insieme a una Network Access Control List (NACL) sulla sottorete del gruppo di destinazione per consentire solo agli intervalli IP di Elastic Load Balancing di comunicare con le istanze. Ciò garantisce che il traffico Internet non possa comunicare direttamente con le tue EC2 istanze Amazon, il che rende più difficile per un utente malintenzionato conoscere e influenzare la tua applicazione.
Quando crei una reteACLs, puoi specificare sia le regole di autorizzazione che quelle di rifiuto. Ciò è utile se desideri negare esplicitamente determinati tipi di traffico alla tua applicazione. Ad esempio, è possibile definire indirizzi IP (come CIDR intervalli), protocolli e porte di destinazione a cui viene negato l'accesso all'intera sottorete. Se l'applicazione viene utilizzata solo per il TCP traffico, è possibile creare una regola per negare tutto il UDP traffico o viceversa. Questa opzione è utile per rispondere agli DDoS attacchi perché consente di creare regole personalizzate per mitigare l'attacco quando si conosce l'origine IPs o un'altra firma.
Se sei abbonato AWS Shield Advanced, puoi registrare gli indirizzi IP elastici come risorse protette. DDoSgli attacchi contro gli indirizzi IP elastici che sono stati registrati come risorse protette vengono rilevati più rapidamente, il che può comportare tempi di mitigazione più rapidi. Quando viene rilevato un attacco, i sistemi di DDoS mitigazione leggono la rete ACL che corrisponde all'indirizzo IP elastico mirato e la applicano ai confini della AWS rete, anziché a livello di sottorete. Ciò riduce in modo significativo il rischio di impatto derivante da una serie di attacchi a livello di infrastruttura. DDoS
Per ulteriori informazioni sulla configurazione dei gruppi di sicurezza e della rete ACLs per ottimizzare DDoS la resilienza, consulta [Come prepararsi DDoS agli attacchi riducendo la superficie di attacco](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/).
Per ulteriori informazioni sull'utilizzo di Shield Advanced con indirizzi IP elastici come risorse protette, consulta la procedura di [sottoscrizione a AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html).
# Proteggere la propria origine (BP1,BP5)
Se utilizzi Amazon CloudFront con un'origine interna alla tuaVPC, potresti voler assicurarti che solo la tua CloudFront distribuzione possa inoltrare le richieste alla tua origine. Con Edge-to-Origin Request Headers, puoi aggiungere o sostituire il valore delle intestazioni di richiesta esistenti quando inoltri le richieste all'origine. CloudFront Puoi utilizzare le *Origin Custom Headers*, ad esempio l'`X-Shared-Secret`intestazione, per verificare da che le richieste inviate all'origine siano state inviate. CloudFront
Per maggiori informazioni sulla protezione dell'origine con Origin *Custom Headers, consulta [Aggiungere](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) intestazioni personalizzate* alle [richieste di origine e [Limitazione](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) dell'accesso agli Application Load Balancers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html).
Per una guida sull'implementazione di una soluzione di esempio per ruotare automaticamente il valore di *Origin Custom Headers* per la restrizione di accesso all'origine, consulta [How to enhance Amazon CloudFront origin security with and Secrets AWS WAF Manager](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/).
In alternativa, puoi utilizzare una [AWS Lambda](https://aws.amazon.com/lambda/)funzione per aggiornare automaticamente le regole del tuo gruppo di sicurezza in modo da consentire solo il traffico. CloudFront Ciò migliora la sicurezza della tua origine contribuendo a garantire che gli utenti malintenzionati non possano aggirare CloudFront e AWS WAF accedere alla tua applicazione web.
Per ulteriori informazioni su come proteggere la tua origine aggiornando automaticamente i gruppi di sicurezza e l'`X-Shared-Secret`intestazione, consulta [Come aggiornare automaticamente i tuoi gruppi di sicurezza per Amazon CloudFront e AWS WAF utilizzando AWS Lambda](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/).
Tuttavia, la soluzione prevede una configurazione aggiuntiva e il costo di esecuzione delle funzioni Lambda. Per semplificare questa operazione, abbiamo ora introdotto un [elenco AWS di prefissi gestiti per CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) limitare il HTTPS traffico in HTTP entrata/alle origini solo dagli indirizzi IP rivolti all' CloudFrontorigine. AWS-gli elenchi di prefissi gestiti vengono creati e gestiti da AWS e sono disponibili per l'uso senza costi aggiuntivi. Puoi fare riferimento all'elenco dei prefissi gestiti CloudFront nelle regole del gruppo di sicurezza (AmazonVPC), nelle tabelle di routing delle subnet, nelle regole comuni dei gruppi di sicurezza e in qualsiasi altra AWS risorsa che può utilizzare un elenco di [prefissi gestiti](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html). AWS Firewall Manager
Per ulteriori informazioni sull'utilizzo di AWS-managed prefix list per Amazon CloudFront, consulta [Limita l'accesso alle tue origini utilizzando l'elenco di prefissi AWS-managed](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/) per Amazon. CloudFront
**Nota**
Come discusso in altre sezioni di questo documento, affidarsi a gruppi di sicurezza per proteggere la propria origine può aggiungere il [tracciamento delle connessioni dei gruppi di sicurezza come potenziale ostacolo](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) durante un'ondata di richieste. A meno che non siate in grado di filtrare le richieste dannose CloudFront utilizzando una politica di memorizzazione nella cache che abiliti la memorizzazione nella cache, potrebbe essere meglio affidarsi alle Origin *Custom Headers, discusse in precedenza, per verificare che le richieste inviate all'origine* provengano da gruppi di sicurezza, anziché utilizzare gruppi di sicurezza. CloudFront L'utilizzo di un'intestazione di richiesta personalizzata con una regola del listener Application Load Balancer impedisce la limitazione dovuta ai limiti di tracciamento che possono influire sulla creazione di nuove connessioni a un sistema di bilanciamento del carico, permettendo così ad Application Load Balancer di scalare in base all'aumento del traffico in caso di attacco. DDoS
# Protezione degli endpoint () API BP4
Quando è necessario esporre un file API al pubblico, esiste il rischio che il API frontend venga preso di mira da un attacco. DDoS Per contribuire a ridurre il rischio, puoi utilizzare [Amazon API Gateway come accesso](https://aws.amazon.com/api-gateway/) alle applicazioni in esecuzione su Amazon EC2 o AWS Lambda altrove. Utilizzando Amazon API Gateway, non sono necessari server propri per il API frontend e si possono offuscare altri componenti dell'applicazione. Rendendo più difficile il rilevamento dei componenti dell'applicazione, puoi contribuire a evitare che tali AWS risorse vengano prese di mira da un attacco. DDoS
Quando usi Amazon API Gateway, puoi scegliere tra due tipi di API endpoint. La prima è l'opzione predefinita: API endpoint ottimizzati per i bordi a cui si accede tramite una distribuzione Amazon. CloudFront Tuttavia, la distribuzione viene creata e gestita da API Gateway, quindi non ne hai il controllo. La seconda opzione consiste nell'utilizzare un API endpoint regionale a cui si accede dallo stesso Regione AWS in cui REST API è distribuito il tuo. AWS consiglia di utilizzare il secondo tipo di endpoint e di associarlo alla propria CloudFront distribuzione Amazon. Questo ti dà il controllo sulla CloudFront distribuzione Amazon e la possibilità di utilizzarla AWS WAF per la protezione a livello di applicazione. Questa modalità fornisce l'accesso a una capacità di DDoS mitigazione scalabile su tutta la rete AWS perimetrale globale.
Quando usi Amazon CloudFront e AWS WAF con Amazon API Gateway, configura le seguenti opzioni:
+ Configura il comportamento della cache per le tue distribuzioni per inoltrare tutte le intestazioni all'endpoint regionale API Gateway. In questo modo, CloudFront tratterà il contenuto come dinamico e salterà la memorizzazione nella cache del contenuto.
+ Proteggi il tuo API gateway dall'accesso diretto configurando la distribuzione per includere l'intestazione personalizzata di origine x-api-key, impostando il valore della [APIchiave](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) in Gateway. API
+ Proteggi il backend dal traffico in eccesso configurando limiti standard o di burst rate per ogni metodo utilizzato. REST APIs
Per ulteriori informazioni sulla creazione APIs con Amazon API Gateway, consulta [Amazon API Gateway Getting](https://aws.amazon.com/api-gateway/getting-started/) [Started](https://aws.amazon.com/api-gateway/getting-started/).