Infrastructure OU — Account di rete

Influenza il future della AWS Security Reference Architecture (AWSSRA) partecipando a un breve sondaggio.

Il diagramma seguente illustra i servizi di sicurezza AWS configurati nell'account di rete. 

L'account di rete gestisce il gateway tra l'applicazione e la rete Internet in generale. È importante proteggere tale interfaccia bidirezionale. L'account di rete isola i servizi di rete, la configurazione e il funzionamento dai carichi di lavoro delle singole applicazioni, dalla sicurezza e da altre infrastrutture. Questa disposizione non solo limita la connettività, le autorizzazioni e il flusso di dati, ma supporta anche la separazione dei compiti e la riduzione dei privilegi per i team che devono operare in questi account. Suddividendo il flusso di rete in cloud privati virtuali (VPC) separati in entrata e in uscita, puoi proteggere l'infrastruttura e il traffico sensibili da accessi indesiderati. La rete in entrata è generalmente considerata a rischio più elevato e merita un routing, un monitoraggio e una potenziale mitigazione dei problemi. Questi account di infrastruttura erediteranno i guardrail di autorizzazione dall'account Org Management e dall'unità organizzativa Infrastructure. I team di rete (e sicurezza) gestiscono la maggior parte dell'infrastruttura di questo account.

Architettura di rete

Sebbene la progettazione e le specifiche della rete non rientrino nell'ambito di questo documento, consigliamo queste tre opzioni per la connettività di rete tra i vari account: peering VPCPrivateLink, AWS e AWS Transit Gateway. Considerazioni importanti nella scelta tra queste sono le norme operative, i budget e le esigenze specifiche di larghezza di banda. 

• Peering VPC ‒ Il modo più semplice per connettere due VPC consiste nell'utilizzare il peering VPC. Una connessione consente la connettività bidirezionale completa tra i VPC. I VPC che si trovano in account e regioni AWS separati possono anche essere collegati tra loro. Su larga scala, quando hai decine o centinaia di VPC, interconnettendoli con il peering si ottiene una rete di centinaia o migliaia di connessioni peering, che può essere difficile da gestire e scalare. Il peering VPC viene utilizzato al meglio quando le risorse di un VPC devono comunicare con le risorse di un altro VPC, l'ambiente di entrambi i VPC è controllato e protetto e il numero di VPC da connettere è inferiore a 10 (per consentire la gestione individuale di ogni connessione).

• AWS PrivateLink ‒ PrivateLink fornisce connettività privata tra VPC, servizi e applicazioni. Puoi creare un'applicazione nel VPC e configurarla come servizio endpoint. PrivateLink Altri responsabili AWS possono creare una connessione dal proprio VPC al servizio endpoint utilizzando un endpoint VPC di interfaccia o un endpoint Gateway Load Balancer a seconda del tipo di servizio. Quando lo usiPrivateLink, il traffico di servizio non passa attraverso una rete indirizzabile pubblicamente. Utilizzalo PrivateLink quando disponi di una configurazione client-server in cui desideri fornire a uno o più VPC consumer un accesso unidirezionale a un servizio o a un set di istanze specifico nel VPC del provider di servizi. Questa è anche una buona opzione quando client e server nei due VPC hanno indirizzi IP sovrapposti, poiché PrivateLink utilizza interfacce di rete elastiche all'interno del VPC client in modo che non vi siano conflitti IP con il fornitore di servizi. 

• AWS Transit Gateway ‒ Transit Gateway offre un hub-and-spoke design per connettere VPC e reti locali come servizio completamente gestito senza richiedere il provisioning di appliance virtuali. AWS gestisce disponibilità e scalabilità elevate. Un gateway di transito è una risorsa regionale e può connettere migliaia di VPC all'interno della stessa regione AWS. Puoi collegare la tua connettività ibrida (connessioni VPN e AWS Direct Connect) a un unico gateway di transito, consolidando e controllando così l'intera configurazione di routing dell'organizzazione AWS in un unico posto. Un gateway di transito risolve la complessità legata alla creazione e alla gestione di più connessioni peering VPC su larga scala. È l'impostazione predefinita per la maggior parte delle architetture di rete, ma esigenze specifiche in termini di costi, larghezza di banda e latenza potrebbero rendere il peering VPC più adatto alle tue esigenze.

VPC (ingresso) in entrata

Il VPC in entrata è destinato ad accettare, ispezionare e indirizzare le connessioni di rete avviate all'esterno dell'applicazione. A seconda delle specifiche dell'applicazione, puoi aspettarti di vedere una traduzione degli indirizzi di rete (NAT) in questo VPC. I log di flusso di questo VPC vengono acquisiti e archiviati nell'account Log Archive.

VPC in uscita (uscita)

Il VPC in uscita è destinato a gestire le connessioni di rete avviate dall'interno dell'applicazione. A seconda delle specifiche dell'applicazione, puoi aspettarti di vedere NAT di traffico, endpoint VPC specifici del servizio AWS e hosting di endpoint API esterni in questo VPC. I log di flusso di questo VPC vengono acquisiti e archiviati nell'account Log Archive.

VPC di ispezione

Un VPC di ispezione dedicato fornisce un approccio semplificato e centrale per la gestione delle ispezioni tra VPC (nella stessa o in diverse regioni AWS), Internet e reti locali. Per l'AWS SRA, assicurati che tutto il traffico tra i cloud privati virtuali passi attraverso il VPC di ispezione ed evita di utilizzare il VPC di ispezione per qualsiasi altro carico di lavoro.

AWS Network Firewall

AWS Network Firewall è un servizio firewall di rete gestito e altamente disponibile per il tuo VPC. Ti consente di implementare e gestire senza problemi l'ispezione stateful, la prevenzione e il rilevamento delle intrusioni e il filtraggio web per proteggere le tue reti virtuali su AWS. Per ulteriori informazioni sulla configurazione di Network Firewall, consulta il post sul blog AWS Network Firewall — New Managed Firewall Service in VPC.

Utilizzi un firewall in base alla zona di disponibilità nel tuo VPC. Per ogni zona di disponibilità, scegli una sottorete per ospitare l'endpoint del firewall che filtra il traffico. L'endpoint del firewall in una zona di disponibilità può proteggere tutte le sottoreti all'interno della zona ad eccezione della sottorete in cui si trova. A seconda del caso d'uso e del modello di distribuzione, la sottorete del firewall può essere pubblica o privata. Il firewall è completamente trasparente al flusso di traffico e non esegue Network Address Translation (NAT). Conserva l'indirizzo di origine e di destinazione. In questa architettura di riferimento, gli endpoint del firewall sono ospitati in un VPC di ispezione. Tutto il traffico dal VPC in entrata e verso il VPC in uscita viene indirizzato attraverso questa sottorete del firewall per l'ispezione. 

Network Firewall rende l'attività del firewall visibile in tempo reale tramite i CloudWatch parametri Amazon e offre una maggiore visibilità del traffico di rete inviando i log ad Amazon Simple Storage Service (Amazon S3) e Amazon Kinesis Data CloudWatch Firehose. Network Firewall è interoperabile con il tuo approccio alla sicurezza esistente, comprese le tecnologie dei partner AWS. Puoi anche importare set di regole Suricata esistenti, che potrebbero essere stati scritti internamente o provenienti esternamente da fornitori di terze parti o piattaforme open source. 

Nell'SRA di AWS, il Network Firewall viene utilizzato all'interno dell'account di rete perché la funzionalità del servizio incentrata sul controllo della rete è in linea con l'intento dell'account. 

Considerazioni di natura progettuale

• AWS Firewall Manager supporta Network Firewall, quindi puoi configurare e distribuire centralmente le regole del Network Firewall in tutta l'organizzazione. (Per i dettagli, consulta le politiche di AWS Network Firewall nella documentazione di AWS.) Quando configuri Firewall Manager, crea automaticamente un firewall con set di regole negli account e nei VPC specificati. Inoltre, implementa un endpoint in una sottorete dedicata per ogni zona di disponibilità che contiene sottoreti pubbliche. Allo stesso tempo, qualsiasi modifica al set di regole configurato centralmente viene automaticamente aggiornata a valle sui Network Firewall implementati. 

• Sono disponibili diversi modelli di distribuzione con Network Firewall. Il modello giusto varia a seconda del caso d'uso e dei requisiti. Considerare i seguenti esempi:

  • Un modello di distribuzione distribuito in cui Network Firewall viene distribuito in singoli VPC.

  • Un modello di implementazione centralizzato in cui Network Firewall viene implementato in un VPC centralizzato per il traffico est-ovest (da VPC a VPC) o nord-sud (in uscita e in ingresso da Internet, locale).

  • Un modello di implementazione combinato in cui Network Firewall viene implementato in un VPC centralizzato per il traffico est-ovest e un sottoinsieme del traffico nord-sud.

• Come best practice, non utilizzare la sottorete Network Firewall per implementare altri servizi. Questo perché Network Firewall non è in grado di ispezionare il traffico proveniente da fonti o destinazioni all'interno della sottorete del firewall.

Network Access Analyzer

Network Access Analyzer è una funzionalità di Amazon VPC che identifica l'accesso di rete non intenzionale alle risorse. È possibile utilizzare Network Access Analyzer per convalidare la segmentazione della rete, identificare le risorse accessibili da Internet o accessibili solo da intervalli di indirizzi IP attendibili e verificare di disporre di controlli di rete appropriati su tutti i percorsi di rete.

Network Access Analyzer utilizza algoritmi di ragionamento automatizzati per analizzare i percorsi di rete che un pacchetto può percorrere tra le risorse di una rete AWS e produce risultati per i percorsi che corrispondono all'ambito di accesso alla rete definito. Network Access Analyzer esegue un'analisi statica di una configurazione di rete, il che significa che nessun pacchetto viene trasmesso nella rete come parte di questa analisi.

Le regole di raggiungibilità della rete di Amazon Inspector forniscono una funzionalità correlata. I risultati generati da queste regole vengono utilizzati nell'account dell'applicazione. Sia Network Access Analyzer che Network Reachability utilizzano la tecnologia più recente dell'iniziativa AWS Provable Security e applicano questa tecnologia con diverse aree di interesse. Il pacchetto Network Reachability si concentra specificamente sulle istanze EC2 e sulla loro accessibilità a Internet. 

L'account di rete definisce l'infrastruttura di rete critica che controlla il traffico in entrata e in uscita dall'ambiente AWS. Questo traffico deve essere monitorato attentamente. Nell'SRA di AWS, Network Access Analyzer viene utilizzato all'interno dell'account di rete per identificare accessi non intenzionali alla rete, identificare le risorse accessibili a Internet tramite gateway Internet e verificare che i controlli di rete appropriati come firewall di rete e gateway NAT siano presenti su tutti i percorsi di rete tra risorse e gateway Internet. 

Considerazione sul design

• Network Access Analyzer è una funzionalità di Amazon VPC e può essere utilizzata in qualsiasi account AWS dotato di un VPC. Gli amministratori di rete possono ottenere ruoli IAM interaccount con un ambito ristretto per verificare che i percorsi di rete approvati siano applicati all'interno di ciascun account AWS.

AWS RAM

AWS Resource Access Manager (AWS RAM) ti aiuta a condividere in modo sicuro le risorse AWS che crei in un account AWS con altri account AWS. AWS RAM fornisce una posizione centrale per gestire la condivisione delle risorse e standardizzare questa esperienza tra gli account. Ciò semplifica la gestione delle risorse sfruttando al contempo l'isolamento amministrativo e di fatturazione e riduce l'ambito dei vantaggi di contenimento dell'impatto offerti da una strategia multi-account. Se il tuo account è gestito da AWS Organizations, AWS RAM ti consente di condividere le risorse con tutti gli account dell'organizzazione o solo con gli account all'interno di una o più unità organizzative (OU) specificate. Puoi anche condividere con account AWS specifici tramite ID account, indipendentemente dal fatto che l'account faccia parte di un'organizzazione. Puoi anche condividere alcuni tipi di risorse supportati con ruoli e utenti IAM specificati.

AWS RAM consente di condividere risorse che non supportano le policy basate sulle risorse IAM, come le sottoreti VPC e le regole Route 53. Inoltre, con AWS RAM, i proprietari di una risorsa possono vedere quali responsabili hanno accesso alle singole risorse che hanno condiviso. Le entità IAM possono recuperare direttamente l'elenco delle risorse condivise con loro, cosa che non possono fare con le risorse condivise dalle policy delle risorse IAM. Se la RAM AWS viene utilizzata per condividere risorse all'esterno dell'organizzazione AWS, viene avviata una procedura di invito. Il destinatario deve accettare l'invito prima di concedere l'accesso alle risorse. Ciò fornisce controlli ed equilibri aggiuntivi.

La RAM AWS viene richiamata e gestita dal proprietario della risorsa, nell'account in cui viene distribuita la risorsa condivisa. Un caso d'uso comune della RAM AWS illustrato nell'SRA di AWS è che gli amministratori di rete condividano sottoreti VPC e gateway di transito con l'intera organizzazione AWS. Ciò consente di disaccoppiare le funzioni di gestione dell'account AWS e della rete e aiuta a separare i compiti. Per ulteriori informazioni sulla condivisione VPC, consulta il post del blog AWS. Condivisione di VPC: un nuovo approccio a più account e gestione VPC e il white paper sull'infrastruttura di rete AWS. 

Considerazione sul design

• Sebbene la RAM AWS as a service sia distribuita solo all'interno dell'account di rete in AWS SRA, in genere viene distribuita in più di un account. Ad esempio, puoi centralizzare la gestione dei data lake su un singolo account data lake e quindi condividere le risorse del catalogo dati di AWS Lake Formation (database e tabelle) con altri account della tua organizzazione AWS. Per ulteriori informazioni, consulta la documentazione di AWS Lake Formation e il post sul blog AWS Condividi in modo sicuro i tuoi dati tra account AWS utilizzando AWS Lake Formation. Inoltre, gli amministratori della sicurezza possono utilizzare la RAM AWS per seguire le best practice quando creano una CA privata AWS gerarchia. Le CA possono essere condivise con terze parti esterne, che possono emettere certificati senza avere accesso alla gerarchia delle CA. Ciò consente alle organizzazioni di origine di limitare e revocare l'accesso di terze parti.

Sicurezza Edge

La sicurezza dell'edge comporta generalmente tre tipi di protezione: distribuzione sicura dei contenuti, protezione a livello di rete e applicazione e mitigazione degli attacchi DDoS (Distributed Denial of Service). Contenuti come dati, video, applicazioni e API devono essere distribuiti in modo rapido e sicuro, utilizzando la versione consigliata di TLS per crittografare le comunicazioni tra gli endpoint. Il contenuto dovrebbe inoltre avere restrizioni di accesso tramite URL firmati, cookie firmati e autenticazione tramite token. La sicurezza a livello di applicazione deve essere progettata per controllare il traffico dei bot, bloccare i modelli di attacco più comuni come SQL injection o cross-site scripting (XSS) e fornire visibilità sul traffico web. All'edge, la mitigazione degli attacchi DDoS fornisce un importante livello di difesa che garantisce la disponibilità continua di operazioni e servizi aziendali cruciali. Le applicazioni e le API devono essere protette da inondazioni SYN, UDP o altri attacchi di riflessione e disporre di una mitigazione in linea per bloccare gli attacchi di base a livello di rete.

AWS offre diversi servizi per contribuire a fornire un ambiente sicuro, dal cloud principale all'edge della rete AWS. AmazonCloudFront, AWS Certificate Manager (ACM), AWS Shield, AWS WAF e Amazon Route 53 collaborano per contribuire a creare un perimetro di sicurezza flessibile e a più livelli. Con AmazonCloudFront, i contenuti, le API o le applicazioni possono essere distribuiti tramite HTTPS utilizzando TLSv1.3 per crittografare e proteggere la comunicazione tra i client di visualizzazione e. CloudFront Puoi utilizzare ACM per creare un certificato SSL personalizzato e distribuirlo gratuitamente su una CloudFront distribuzione. ACM gestisce automaticamente il rinnovo dei certificati. AWS Shield è un servizio di protezione DDoS gestito che aiuta a salvaguardare le applicazioni eseguite su AWS. Fornisce rilevamento dinamico e mitigazioni automatiche in linea che riducono al minimo i tempi di inattività e la latenza delle applicazioni. AWS WAF ti consente di creare regole per filtrare il traffico web in base a condizioni specifiche (indirizzi IP, intestazioni e body HTTP o URI personalizzati), attacchi web comuni e bot pervasivi. Route 53 è un servizio Web DNS altamente scalabile e disponibile. Route 53 collega le richieste degli utenti alle applicazioni Internet eseguite su AWS o in locale. L'AWS SRA adotta un'architettura di ingresso di rete centralizzata utilizzando AWS Transit Gateway, ospitato all'interno dell'account di rete, quindi anche l'infrastruttura di sicurezza edge è centralizzata in questo account.

Amazon CloudFront

Amazon CloudFront è una rete di distribuzione di contenuti (CDN) sicura che fornisce una protezione intrinseca contro i comuni tentativi di DDoS a livello di rete e di trasporto. Puoi distribuire contenuti, API o applicazioni utilizzando i certificati TLS e le funzionalità TLS avanzate vengono abilitate automaticamente. Puoi utilizzare ACM per creare un certificato TLS personalizzato e applicare le comunicazioni HTTPS tra gli utenti eCloudFront, come descritto più avanti nella sezione ACM. Puoi inoltre richiedere che le comunicazioni tra CloudFront e la tua origine personalizzata implementino la crittografia end-to-end durante il transito. In questo scenario, è necessario installare un certificato TLS sul server di origine. Se la tua origine è un sistema di bilanciamento del carico elastico, puoi utilizzare un certificato generato da ACM o un certificato convalidato da un'autorità di certificazione (CA) di terze parti e importato in ACM. Se gli endpoint del Gateway S3 fungono da origineCloudFront, non è possibile configurare CloudFront per l'utilizzo di HTTPS, perché Amazon S3 non supporta HTTPS per gli endpoint del sito Web. Tuttavia, è ancora possibile richiedere HTTPS tra gli utenti eCloudFront. Per tutte le altre origini che supportano l'installazione di certificati HTTPS, devi utilizzare un certificato firmato da un'autorità di terze parti affidabile.

CloudFrontoffre diverse opzioni per proteggere e limitare l'accesso ai contenuti. Ad esempio, può limitare l'accesso all'origine Amazon S3 utilizzando URL e cookie firmati. Per ulteriori informazioni, vedere Configurazione dell'accesso sicuro e limitazione dell'accesso ai contenuti della CloudFront documentazione.

L'SRA di AWS illustra CloudFront le distribuzioni centralizzate nell'account di rete perché sono in linea con il modello di rete centralizzato implementato utilizzando Transit Gateway. Implementando e gestendo CloudFront le distribuzioni nell'account Network, si ottengono i vantaggi dei controlli centralizzati. Puoi gestire tutte le CloudFront distribuzioni in un'unica posizione, il che semplifica il controllo dell'accesso, la configurazione delle impostazioni e il monitoraggio dell'utilizzo su tutti gli account. Inoltre, puoi gestire i certificati ACM, i record DNS e la CloudFront registrazione da un account centralizzato.

Considerazioni di natura progettuale

• In alternativa, è possibile eseguire la distribuzione CloudFront come parte dell'applicazione nell'account dell'applicazione. In questo scenario, il team applicativo prende decisioni quali la modalità di CloudFront distribuzione delle distribuzioni, determina le politiche di cache appropriate e si assume la responsabilità della governance, del controllo e del monitoraggio delle distribuzioni. CloudFront Distribuendo CloudFront le distribuzioni su più account, puoi beneficiare di quote di servizio aggiuntive. Come altro vantaggio, puoi utilizzare la configurazione intrinseca e automatica CloudFront dell'identità di accesso all'origine (OAI) e del controllo dell'accesso all'origine (OAC) per limitare l'accesso alle origini di Amazon S3.

• Quando distribuisci contenuti web tramite un CDN, ad esempioCloudFront, devi impedire agli spettatori di bypassare il CDN e accedere direttamente ai tuoi contenuti di origine. Per ottenere questa restrizione di accesso all'origine, puoi utilizzare CloudFront AWS WAF per aggiungere intestazioni personalizzate e verificare le intestazioni prima di inoltrare le richieste alla tua origine personalizzata. Per una spiegazione dettagliata di questa soluzione, consulta il post sul blog sulla sicurezza di AWS Come migliorare la sicurezza di Amazon CloudFront Origin con AWS WAF e AWS Secrets Manager. Un metodo alternativo consiste nel limitare solo l'elenco dei CloudFront prefissi nel gruppo di sicurezza associato all'Application Load Balancer. Ciò contribuirà a garantire che solo una CloudFront distribuzione possa accedere al sistema di bilanciamento del carico,

AWS WAF

AWS WAF è un firewall per applicazioni Web che aiuta a proteggere le applicazioni Web da exploit Web come vulnerabilità e bot comuni che potrebbero influire sulla disponibilità delle applicazioni, compromettere la sicurezza o consumare risorse eccessive. Può essere integrato con una CloudFront distribuzione Amazon, un'API GraphQL di Amazon API Gateway, un Application Load Balancer, un'API AppSync GraphQL di o un pool di utenti Amazon Cognito e il servizio AWS App Runner.

AWS WAF utilizza elenchi di controllo degli accessi web (ACL) per proteggere un set di risorse AWS. Un ACL Web è un insieme di regole che definisce i criteri di ispezione e un'azione associata da intraprendere (bloccare, consentire, contare o eseguire il controllo dei bot) se una richiesta Web soddisfa i criteri. AWS WAF fornisce una serie di regole gestite che forniscono protezione contro le vulnerabilità delle applicazioni più comuni. Queste regole sono curate e gestite da AWS e dai partner AWS. AWS WAF offre anche un potente linguaggio di regole per la creazione di regole personalizzate. Puoi utilizzare regole personalizzate per scrivere criteri di ispezione adatti alle tue esigenze particolari. Gli esempi includono restrizioni IP, restrizioni geografiche e versioni personalizzate di regole gestite che si adattano meglio al comportamento specifico dell'applicazione.

AWS WAF fornisce una serie di regole intelligenti gestite a livello per bot comuni e mirati e protezione dall'acquisizione di account (ATP). Ti vengono addebitati un canone di abbonamento e un costo per l'ispezione del traffico quando utilizzi il controllo dei bot e i gruppi di regole ATP. Pertanto, ti consigliamo di monitorare prima il traffico e poi decidere cosa utilizzare. Puoi utilizzare le dashboard di gestione dei bot e acquisizione degli account disponibili gratuitamente sulla console AWS WAF per monitorare queste attività e quindi decidere se hai bisogno di un gruppo di regole AWS WAF di livello intelligente.

In AWS SRA, AWS WAF è integrato CloudFront nell'account di rete. In questa configurazione, l'elaborazione delle regole WAF avviene nelle edge location anziché all'interno del VPC. Ciò consente di filtrare il traffico dannoso più vicino all'utente finale che ha richiesto il contenuto e aiuta a limitare l'accesso del traffico dannoso alla rete principale.

Puoi inviare log AWS WAF completi a un bucket S3 nell'account Log Archive configurando l'accesso tra account al bucket S3. Per ulteriori informazioni, consulta l'articolo di AWS Re:Post su questo argomento.

Considerazioni di natura progettuale

• In alternativa alla distribuzione centralizzata di AWS WAF nell'account di rete, alcuni casi d'uso sono meglio soddisfatti implementando AWS WAF nell'account dell'applicazione. Ad esempio, puoi scegliere questa opzione quando distribuisci le tue CloudFront distribuzioni nel tuo account Application o disponi di Application Load Balancer rivolti al pubblico o se utilizzi Amazon API Gateway davanti alle tue applicazioni web. Se decidi di distribuire AWS WAF in ogni account dell'applicazione, utilizza AWS Firewall Manager per gestire le regole AWS WAF in questi account dall'account Security Tooling centralizzato.

• Puoi anche aggiungere regole AWS WAF generali a CloudFront livello e regole AWS WAF aggiuntive specifiche dell'applicazione in una risorsa regionale come Application Load Balancer o il gateway API.

AWS Shield

AWS Shield è un servizio di protezione DDoS gestito che protegge le applicazioni eseguite su AWS. Esistono due livelli di Shield: Shield Standard e Shield Advanced. Shield Standard offre a tutti i clienti AWS protezione dagli eventi infrastrutturali più comuni (livelli 3 e 4) senza costi aggiuntivi. Shield Advanced fornisce mitigazioni automatiche più sofisticate per eventi non autorizzati che prendono di mira le applicazioni su zone protette di Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), AmazonCloudFront, AWS Global Accelerator e Route 53. Se possiedi siti Web ad alta visibilità o sei soggetto a frequenti attacchi DDoS, puoi prendere in considerazione le funzionalità aggiuntive fornite da Shield Advanced.

È possibile utilizzare la funzionalità automatica di mitigazione degli attacchi DDoS a livello di applicazione di Shield Advanced per configurare Shield Advanced in modo che risponda automaticamente agli attacchi a livello di applicazione (livello 7) contro le CloudFront distribuzioni protette e gli Application Load Balancer. Quando abiliti questa funzionalità, Shield Advanced genera automaticamente regole AWS WAF personalizzate per mitigare gli attacchi DDoS. Shield Advanced ti consente anche di accedere all'AWS Shield Response Team (SRT). Puoi contattare SRT in qualsiasi momento per creare e gestire mitigazioni personalizzate per la tua applicazione o durante un attacco DDoS attivo. Se desideri che SRT monitori in modo proattivo le tue risorse protette e ti contatti durante un tentativo di attacco DDoS, valuta la possibilità di attivare la funzione di coinvolgimento proattivo.

Considerazioni di natura progettuale

• Se hai carichi di lavoro gestiti da risorse con accesso a Internet nell'account dell'Applicazione, come Amazon, Application Load Balancer o Network Load BalancerCloudFront, configura Shield Advanced nell'account Applications e aggiungi tali risorse alla protezione Shield. Puoi usare AWS Firewall Manager per configurare queste opzioni su larga scala.

• Se nel flusso di dati sono presenti più risorse, ad esempio una CloudFront distribuzione davanti a un Application Load Balancer, utilizza solo la risorsa entry-point come risorsa protetta. In questo modo non dovrai pagare due volte le commissioni di Shield Data Transfer Out (DTO) per due risorse.

• Shield Advanced registra le metriche che puoi monitorare su AmazonCloudWatch. (Per ulteriori informazioni, consulta le metriche e gli allarmi di AWS Shield Advanced nella documentazione AWS.) Configura gli CloudWatch allarmi per ricevere notifiche SNS al tuo centro di sicurezza quando viene rilevato un evento DDoS. In caso di sospetto evento DDoS, contatta il team di AWS Enterprise Support compilando un ticket di assistenza e assegnandogli la massima priorità. Il team di Support aziendale includerà lo Shield Response Team (SRT) nella gestione dell'evento. Inoltre, puoi preconfigurare la funzione AWS Shield Engagement Lambda per creare un ticket di supporto e inviare un'e-mail al team SRT.

AWS Certificate Manager

AWS Certificate Manager (ACM) ti consente di fornire, gestire e distribuire certificati TLS pubblici e privati da utilizzare con i servizi AWS e le risorse interne connesse. Con ACM, puoi richiedere rapidamente un certificato, distribuirlo su risorse AWS integrate in ACM, come i sistemi di bilanciamento del carico Elastic Load Balancing, le CloudFront distribuzioni Amazon e le API su Amazon API Gateway, e lasciare che ACM gestisca i rinnovi dei certificati. Quando richiedi certificati pubblici ACM, non è necessario generare una key pair o una richiesta di firma del certificato (CSR), inviare una CSR a un'autorità di certificazione (CA) o caricare e installare il certificato quando viene ricevuto. ACM offre anche la possibilità di importare certificati TLS emessi da CA di terze parti e distribuirli con i servizi integrati ACM. Quando utilizzi ACM per gestire i certificati, le chiavi private dei certificati vengono protette e archiviate in modo sicuro utilizzando le migliori pratiche di crittografia e gestione delle chiavi. Con ACM non sono previsti costi aggiuntivi per la fornitura di certificati pubblici e ACM gestisce il processo di rinnovo.

ACM viene utilizzato nell'account Network per generare un certificato TLS pubblico, che a sua volta viene utilizzato dalle CloudFront distribuzioni per stabilire la connessione HTTPS tra i visualizzatori e. CloudFront Per ulteriori informazioni, consulta la documentazione relativa ad CloudFront.

Considerazione sul design

• Per i certificati rivolti all'esterno, ACM deve risiedere nello stesso conto delle risorse per le quali fornisce i certificati. I certificati non possono essere condivise sugli account.

Amazon Route 53

Amazon Route 53 è un servizio Web DNS altamente scalabile e disponibile. Puoi utilizzare Route 53 per eseguire tre funzioni principali: registrazione dominio, routing DNS e controllo dell'integrità.

Puoi usare Route 53 come servizio DNS per mappare i nomi di dominio su istanze EC2, bucket S3, CloudFront distribuzioni e altre risorse AWS. La natura distribuita dei server DNS AWS aiuta a garantire che gli utenti finali vengano indirizzati alla tua applicazione in modo coerente. Funzionalità come il flusso di traffico della Route 53 e il controllo del routing aiutano a migliorare l'affidabilità. Se l'endpoint dell'applicazione principale non è più disponibile, puoi configurare il failover per reindirizzare gli utenti a una posizione alternativa. Route 53 Resolver fornisce DNS ricorsivo per VPC e reti locali su AWS Direct Connect o VPN gestita da AWS.

Utilizzando il servizio AWS Identity and Access Management (IAM) con Route 53, ottieni un controllo granulare su chi può aggiornare i tuoi dati DNS. Puoi abilitare la firma DNSSEC (DNS Security Extensions) per consentire ai resolver DNS di verificare che una risposta DNS proviene da Route 53 e non è stata manomessa.

Route 53 Resolver DNS Firewall fornisce protezione per richieste DNS in uscita dai VPC. Queste richieste vengono passate tramite Route 53 Resolver per la risoluzione dei nomi dominio. Un uso principale delle protezioni DNS Firewall è quello di aiutare a prevenire l'esfiltrazione DNS dei dati. Con DNS Firewall, è possibile monitorare e controllare i domini su cui le applicazioni possono eseguire query. Puoi negare l'accesso ai domini che sai essere non validi e consentire il passaggio di tutte le altre query. In alternativa, è possibile rifiutare l'accesso a tutti i domini ad eccezione di quelli che consideri esplicitamente attendibili. È possibile utilizzare DNS Firewall anche per bloccare richieste di risoluzione alle risorse in zone ospitate private (condivise o locali), inclusi i nomi degli endpoint VPC. Può anche bloccare richieste di nomi istanza EC2 pubblici o privati.

I resolver Route 53 vengono creati di default come parte di ogni VPC. Nell'SRA di AWS, la Route 53 viene utilizzata nell'account di rete principalmente per la funzionalità del firewall DNS. 

Considerazione sul design

• Con DNS Firewall e AWS Network Firewall offrono entrambi filtri dei nomi dominio, ma per tipi di traffico differenti. È possibile utilizzare DNS Firewall e Network Firewall insieme per configurare il filtro basato su dominio per il traffico a livello di applicazione su due percorsi di rete differenti.

  • DNS Firewall fornisce filtri per le query DNS in uscita che passano attraverso Route 53 Resolver dalle applicazioni all'interno dei VPC. È inoltre possibile configurare DNS Firewall per inviare risposte personalizzate per le query a nomi di dominio bloccati.

  • Network Firewall fornisce filtri per il traffico sia a livello di rete che di applicazione, ma non dispone di visibilità sulle query eseguite da Route 53 Resolver.