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à.
UO dell'infrastruttura - Account di rete
| Influenza il futuro della AWS Security Reference Architecture (AWS SRA) rispondendo a un breve sondaggio |
Il diagramma seguente illustra i servizi AWS di sicurezza configurati nell'account di rete.
L'account di rete gestisce il gateway tra l'applicazione e Internet in generale. È importante proteggere quell'interfaccia bidirezionale. L'account di rete isola i servizi di rete, la configurazione e il funzionamento dai carichi di lavoro, dalla sicurezza e da altre infrastrutture delle singole applicazioni. Questa disposizione non solo limita la connettività, le autorizzazioni e il flusso di dati, ma supporta anche la separazione dei compiti e il privilegio minimo per i team che devono operare in questi account. Suddividendo il flusso di rete in cloud privati virtuali in entrata e in uscita separati (VPCs), è possibile proteggere l'infrastruttura e il traffico sensibili da accessi indesiderati. La rete in entrata è generalmente considerata a maggior rischio e merita routing, monitoraggio e mitigazione appropriati dei potenziali problemi. Questi account dell'infrastruttura erediteranno i guardrail di autorizzazione dall'account di gestione dell'organizzazione e dall'unità organizzativa dell'infrastruttura. 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 AWS PrivateLink VPC e. AWS Transit Gateway Le considerazioni importanti da fare nella scelta tra queste opzioni sono le norme operative, i budget e le esigenze specifiche di larghezza di banda.
-
Peering VPC ‒ Il modo più semplice per connetterne due VPCs è utilizzare il peering VPC. Una connessione consente la connettività bidirezionale completa tra. VPCs VPCs che si trovano in account separati e Regioni AWS possono anche essere collegati tra loro. Su larga scala, quando ne hai da decine a centinaia VPCs, l'interconnessione con il peering produce una rete di centinaia o migliaia di connessioni peering, il 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 VPCs è controllato e protetto e il numero di connessioni da connettere è inferiore VPCs a 10 (per consentire la gestione individuale di ogni connessione).
-
AWS PrivateLink
‒ PrivateLink fornisce connettività privata tra VPCs servizi e applicazioni. Puoi creare la tua applicazione nel tuo VPC e configurarla come un servizio PrivateLink basato su tecnologia (denominato servizio endpoint). Altri AWS principali 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 si utilizza PrivateLink, il traffico del servizio non attraversa una rete instradabile pubblicamente. Utilizzalo PrivateLink quando disponi di una configurazione client-server in cui desideri fornire a uno o più consumatori l'accesso VPCs 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 dei due VPCs hanno indirizzi IP sovrapposti, perché PrivateLink utilizza interfacce di rete elastiche all'interno del VPC del client in modo che non vi siano conflitti IP con il provider di servizi. -
AWS Transit Gateway
‒ Transit Gateway offre un hub-and-spoke design per la connessione VPCs e le reti locali come servizio completamente gestito senza la necessità di effettuare il provisioning di appliance virtuali. AWS gestisce l'elevata disponibilità e scalabilità. Un gateway di transito è una risorsa regionale e può collegarne migliaia VPCs all'interno della stessa Regione AWS. È possibile collegare la connettività ibrida (VPN e AWS Direct Connect connessioni) a un singolo gateway di transito, consolidando e controllando così l'intera configurazione di routing AWS dell'organizzazione 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 in ingresso (ingress)
Il VPC in entrata è destinato ad accettare, ispezionare e instradare le connessioni di rete avviate dall'esterno dell'applicazione. A seconda delle specifiche dell'applicazione, puoi aspettarti di vedere una traduzione degli indirizzi di rete, ovvero una Network Address Translation (NAT) in questo VPC. I log di flusso di questo VPC vengono acquisiti e archiviati nell'account Log Archive.
VPC in uscita (egress)
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 traffico NAT, endpoint VPC Servizio AWS specifici 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 offre un approccio semplificato e centrale per la gestione delle ispezioni tra VPCs (nella stessa o in diverse Regioni AWS), Internet e reti locali. Per l' AWS SRA, assicuratevi che tutto il traffico intercorrente VPCs passi attraverso il VPC di ispezione ed evitate di utilizzare il VPC di ispezione per qualsiasi altro carico di lavoro.
AWS Network Firewall
AWS Network Firewall
Utilizzi un firewall in base alla zona di disponibilità nel tuo VPC. Per ogni zona di disponibilità, scegli una sottorete per ospitare l'endpoint firewall che filtra il traffico. L'endpoint 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 implementazione, la sottorete del firewall può essere pubblica o privata. Il firewall è completamente trasparente per il flusso di traffico e non esegue la traduzione degli indirizzi di rete, ovvero il 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 instradato attraverso questa sottorete del firewall per l'ispezione.
Network Firewall rende visibile l'attività del firewall in tempo reale attraverso i CloudWatch parametri di Amazon e offre una maggiore visibilità del traffico di rete inviando i log ad Amazon Simple Storage Service (Amazon S3) e Amazon Data CloudWatch Firehose. Network Firewall è interoperabile con l'approccio alla sicurezza esistente, comprese le tecnologie dei partner.AWS
Nell' AWS SRA, 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 Utilizzo AWS Network Firewall delle politiche in Firewall Manager nella AWS documentazione.) Quando si configura Firewall Manager, viene creato automaticamente un firewall con set di regole negli account e VPCs specificate dall'utente. Inoltre, distribuisce 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 firewall di Firewall di rete implementati.
-
Con Firewall di rete sono disponibili diversi modelli di implementazione
. Il modello più adatto varia a seconda dei requisiti e del caso d'uso. Considerare i seguenti esempi: -
Un modello di distribuzione distribuito in cui Network Firewall viene distribuito in singoli VPCs utenti.
-
Un modello di implementazione centralizzato in cui Firewall di rete viene implementato in un VPC centralizzato per il traffico est-ovest (da VPC a VPC) o nord-sud (uscita e ingresso Internet, on-premise).
-
Un modello di implementazione combinato in cui Firewall di rete 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 di Firewall di rete per implementare qualsiasi altro servizio. Questo perché Firewall di rete non è in grado di ispezionare il traffico proveniente da origini o destinazioni all'interno della sottorete del firewall.
Strumento di analisi degli accessi alla rete
Strumento di analisi degli accessi alla rete è una funzionalità di Amazon VPC che identifica gli accessi di rete non intenzionali alle tue risorse. Strumento di analisi degli accessi alla rete può essere utilizzato per convalidare la segmentazione della rete, identificare 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 automatizzato per analizzare i percorsi di rete che un pacchetto può percorrere tra le risorse di una AWS rete e produce risultati per i percorsi che corrispondono all'ambito di accesso alla rete definito. Strumento di analisi degli accessi alla rete 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 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 della AWS comprovable security initiative
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' AWS SRA, Network Access Analyzer viene utilizzato all'interno dell'account di rete per aiutare a identificare accessi involontari alla rete, identificare le risorse accessibili a Internet tramite gateway Internet e verificare che i controlli di rete appropriati, come i firewall di rete e i gateway NAT, siano presenti su tutti i percorsi di rete tra risorse e gateway Internet.
Considerazione di natura progettuale
Network Access Analyzer è una funzionalità di Amazon VPC e può essere utilizzata in Account AWS qualsiasi ambiente che disponga di un VPC. Gli amministratori di rete possono avvalersi di ruoli IAM ben definiti e trasversali tra account per verificare che i percorsi di rete approvati vengano applicati all'interno di ciascuno di essi. Account AWS
AWS RAM
AWS Resource Access Manager
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. I responsabili 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 AWS RAM viene utilizzato per condividere risorse all'esterno AWS dell'organizzazione, viene avviato un processo di invito. Il destinatario deve accettare l'invito prima di concedere l'accesso alle risorse. Ciò fornisce controlli ed equilibri aggiuntivi.
AWS RAM viene richiamato e gestito dal proprietario della risorsa, nell'account in cui viene distribuita la risorsa condivisa. Un caso d'uso comune AWS RAM illustrato nell' AWS SRA è che gli amministratori di rete condividano sottoreti VPC e gateway di transito con l'intera organizzazione. AWS
Ciò offre la possibilità di disaccoppiare le funzioni di gestione della rete Account AWS e aiuta a raggiungere la separazione delle mansioni. Per ulteriori informazioni sulla condivisione VPC, consulta il AWS post del blog Condivisione VPC: un nuovo approccio alla gestione di più account e VPC e al
Considerazione di natura progettuale
Sebbene AWS RAM il servizio sia distribuito solo all'interno dell'account di rete nell' AWS SRA, in genere viene distribuito in più di un account. Ad esempio, è possibile centralizzare la gestione del data lake su un singolo account di data lake e quindi condividere le risorse del catalogo AWS Lake Formation dati (database e tabelle) con altri account dell'organizzazione. AWS Per ulteriori informazioni, consulta la AWS Lake Formation
documentazione e il post AWS sul blog Condividi in modo sicuro i tuoi dati durante Account AWS
Accesso verificato da AWS
Accesso verificato da AWS
Accesso verificato supporta due modelli applicativi aziendali comuni: interni e rivolti a Internet. Accesso verificato si integra con le applicazioni tramite Application Load Balancer o interfacce di rete elastiche. Se utilizzi un Application Load Balancer, Verified Access richiede un load balancer interno. Poiché Verified Access supporta AWS WAF a livello di istanza, un'applicazione esistente con AWS WAF integrazione con un Application Load Balancer può spostare le policy dal load balancer all'istanza Verified Access. Un'applicazione aziendale è rappresentata come un endpoint di Accesso verificato. Ogni endpoint è associato a un gruppo di Accesso verificato ed eredita la policy di accesso per il gruppo. Un gruppo di Accesso verificato è una raccolta di endpoint di Accesso verificato e una policy di Accesso verificato a livello di gruppo. I gruppi semplificano la gestione delle policy e consentono agli amministratori IT di impostare criteri di base. I proprietari delle applicazioni possono definire ulteriormente policy granulari in base alla sensibilità dell'applicazione.
Nell' AWS SRA, l'accesso verificato è ospitato all'interno dell'account di rete. Il team IT centrale imposta configurazioni gestite centralmente. Ad esempio, potrebbero collegare provider affidabili come provider di identità (ad esempio Okta) e provider di attendibilità dei dispositivi (ad esempio, Jamf), creare gruppi e determinare la policy a livello di gruppo. Queste configurazioni possono quindi essere condivise con decine, centinaia o migliaia di account di carico di lavoro utilizzando. AWS RAM Ciò consente ai team applicativi di gestire gli endpoint sottostanti che gestiscono le loro applicazioni senza sovraccaricare gli altri team. AWS RAM offre un modo scalabile per sfruttare Verified Access per le applicazioni aziendali ospitate in diversi account di carico di lavoro.
Considerazione di natura progettuale
Puoi raggruppare gli endpoint per applicazioni che hanno requisiti di sicurezza simili per semplificare l'amministrazione delle policy e quindi condividere il gruppo con gli account delle applicazioni. Tutte le applicazioni del gruppo condividono la policy di gruppo. Se un'applicazione del gruppo richiede una policy specifica a causa di un caso limite, è possibile applicare una policy a livello di applicazione per quell'applicazione.
Amazon VPC Lattice
Amazon VPC Lattice
VPC Lattice si integra con AWS RAM per consentire la condivisione di servizi e reti di servizi. AWS SRA rappresenta un'architettura distribuita in cui sviluppatori o proprietari di servizi creano servizi VPC Lattice nel proprio account Application. I proprietari dei servizi definiscono gli ascoltatori, le regole di routing e i gruppi di destinazione insieme alle policy di autenticazione. Quindi condividono i servizi con altri account e li associano alle reti di servizi VPC Lattice. Queste reti vengono create dagli amministratori di rete nell'account di rete e condivise con l'account dell'applicazione. Gli amministratori di rete configurano le policy di autenticazione e il monitoraggio a livello di rete del servizio. Gli amministratori associano VPCs i servizi VPC Lattice a una o più reti di servizi. Per una panoramica dettagliata di questa architettura distribuita, consulta il post del AWS blog Crea una connettività multi-VPC multi-account sicura per le tue applicazioni con Amazon VPC
Considerazioni di natura progettuale
-
A seconda del modello operativo di servizio o della visibilità della rete di servizi dell'organizzazione, gli amministratori di rete possono condividere le proprie reti di servizi e dare ai proprietari dei servizi il controllo necessario per associare i propri servizi e a queste reti di servizi. VPCs In alternativa, i proprietari dei servizi possono condividere i propri servizi e gli amministratori di rete possono associare i servizi alle reti di servizi.
-
Un client può inviare richieste ai servizi associati a una rete di servizi solo se il client si trova in un VPC associato alla stessa rete di servizi. Il traffico client che attraversa una connessione peering VPC o un gateway di transito viene negato.
Sicurezza edge
La sicurezza edge prevede generalmente tre tipi di protezione: distribuzione sicura dei contenuti, protezione a livello di rete e di applicazione e mitigazione della denial of service (S) distribuita. DDo Contenuti come dati, video, applicazioni APIs 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 cookie firmati e URLs firmati e autenticazione tramite token. La sicurezza a livello di applicazione dovrebbe essere progettata per controllare il traffico dei bot, bloccare schemi di attacco comuni come iniezione SQL o scripting cross-site (XSS) e fornire visibilità del traffico Web. A livello perimetrale, la mitigazione DDo S fornisce un importante livello di difesa che garantisce la disponibilità continua delle operazioni e dei servizi aziendali cruciali. Le applicazioni APIs devono essere protette dai flood SYN, dai flood UDP o da altri attacchi di riflessione e devono essere dotate 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 alla periferia della rete. AWS Amazon CloudFront, AWS Certificate Manager (ACM) e Amazon Route 53 collaborano per contribuire a creare un perimetro di sicurezza flessibile e stratificato. AWS Shield AWS WAF Con CloudFront APIs, i contenuti o le applicazioni possono essere distribuiti tramite HTTPS utilizzando TLSv1 .3 per crittografare e proteggere la comunicazione tra client di visualizzazione e. CloudFront Puoi utilizzare ACM per creare un certificato SSL personalizzato
Amazon CloudFront
Amazon CloudFront
CloudFront offre diverse opzioni per proteggere e limitare l'accesso ai tuoi contenuti. Ad esempio, può limitare l'accesso alla tua origine Amazon S3 utilizzando cookie firmati URLs e firmati. Per ulteriori informazioni, consulta Configurare l'accesso sicuro e limitare l'accesso ai contenuti nella CloudFront documentazione.
L' AWS SRA illustra le CloudFront distribuzioni centralizzate nell'account di rete perché si allineano al modello di rete centralizzato implementato utilizzando. AWS Transit Gateway Implementando e gestendo CloudFront le distribuzioni nell'account di rete, si ottengono i vantaggi dei controlli centralizzati. Puoi gestire tutte le CloudFront distribuzioni in un unico posto, il che semplifica il controllo degli accessi, 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 unico account centralizzato.
La dashboard CloudFront di sicurezza offre AWS WAF visibilità e controlli direttamente nella distribuzione. CloudFront Ottieni visibilità sulle principali tendenze di sicurezza della tua applicazione, sul traffico consentito e bloccato e sull'attività dei bot. Puoi utilizzare strumenti investigativi come analizzatori visivi dei log e controlli di blocco integrati per isolare i modelli di traffico e bloccare il traffico senza interrogare i log o scrivere regole di sicurezza.
Considerazioni di natura progettuale
-
In alternativa, è possibile eseguire la distribuzione CloudFront come parte dell'applicazione nell'account dell'applicazione. In questo scenario, il team dell'applicazione prende decisioni come 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, è possibile beneficiare di quote di servizio aggiuntive. Come altro vantaggio, puoi utilizzare la configurazione intrinseca e automatizzata CloudFront di Origin Access Identity (OAI) e Origin Access Control (OAC) per limitare l'accesso alle origini di Amazon S3.
-
Quando distribuisci contenuti web tramite un CDN, ad esempio CloudFront, devi impedire agli spettatori di aggirare il CDN e accedere direttamente ai tuoi contenuti di origine. Per ottenere questa restrizione di accesso all'origine, potete utilizzare CloudFront e aggiungere intestazioni personalizzate e AWS WAF verificare le intestazioni prima di inoltrare le richieste all'origine personalizzata. Per una spiegazione dettagliata di questa soluzione, consulta il post del blog AWS sulla sicurezza How to enhance Amazon CloudFront Origin Security with AWS WAF and 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 load balancer.
AWS WAF
AWS WAF
AWS WAF utilizza le liste di controllo degli accessi Web (ACLs) per proteggere un insieme 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
AWS WAF fornisce una serie di regole intelligenti gestite a più livelli per bot comuni e mirati e la protezione dall'acquisizione di account (ATP). Quando utilizzi i gruppi di regole ATP e il rilevamento dei bot ti viene addebitata una quota di abbonamento e una commissione per l'ispezione del traffico. Pertanto, consigliamo di monitorare il traffico e decidere poi cosa utilizzare. Puoi utilizzare le dashboard di gestione dei bot e acquisizione degli account disponibili gratuitamente sulla AWS WAF console per monitorare queste attività e quindi decidere se è necessario un gruppo di regole intelligente di livello. AWS WAF
Nell' AWS SRA, AWS WAF è integrato con l'account di CloudFront rete. In questa configurazione, l'elaborazione delle AWS WAF regole 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'ingresso del traffico dannoso nella rete principale.
Puoi inviare AWS WAF log completi a un bucket S3 nell'account Log Archive configurando l'accesso tra account al bucket S3. Per ulteriori informazioni, consulta l'articolo di re:POST su questo argomento.AWS
Considerazioni di natura progettuale
-
In alternativa alla distribuzione AWS WAF centralizzata nell'account di rete, alcuni casi d'uso sono meglio soddisfatti mediante la distribuzione 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 API Gateway davanti alle tue applicazioni web. Se decidete di effettuare la distribuzione AWS WAF in ogni account dell'Applicazione, utilizzate AWS Firewall Manager per gestire AWS WAF le regole di questi account dall'account Security Tooling centralizzato.
-
È inoltre possibile aggiungere AWS WAF regole generali a CloudFront livello e AWS WAF regole aggiuntive specifiche dell'applicazione in una risorsa regionale come Application Load Balancer o il gateway API.
AWS Shield
AWS Shield
Puoi utilizzare la funzionalità di mitigazione automatica Shield Advanced application layer DDo S per configurare Shield Advanced in modo che risponda automaticamente agli attacchi del livello applicativo (livello 7) contro le tue CloudFront distribuzioni protette, i sistemi di bilanciamento del carico Elastic Load Balancing (Elastic Load Balancing) (Application, Network e Classic), le zone ospitate di Amazon Route 53, gli indirizzi IP Amazon Elastic e gli acceleratori standard. EC2 AWS Global Accelerator Quando abiliti questa funzionalità, Shield Advanced genera automaticamente AWS WAF regole personalizzate per mitigare gli attacchi DDo S. Shield Advanced ti dà anche accesso al 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 S attivo DDo. Se desideri che SRT monitori in modo proattivo le tue risorse protette e ti contatti durante un tentativo DDo S, valuta la possibilità di abilitare la funzione di coinvolgimento proattivo.
Considerazioni di natura progettuale
-
Se hai carichi di lavoro gestiti da risorse connesse a Internet nell'account dell'applicazione, come un Application Load Balancer o un Network Load CloudFront Balancer, configura Shield Advanced nell'account Application e aggiungi tali risorse alla protezione Shield. Puoi AWS Firewall Manager utilizzarle 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 tariffe di Shield Data Transfer Out (DTO)
per due risorse. -
Shield Advanced registra i parametri che puoi monitorare in Amazon CloudWatch. (Per ulteriori informazioni, consulta Monitoring with Amazon CloudWatch nella AWS documentazione.) Imposta CloudWatch allarmi per ricevere notifiche SNS al tuo centro di sicurezza quando viene rilevato un evento DDo S. In caso di sospetto evento DDo S, contatta il team di AWS Enterprise Support
compilando un ticket di supporto e assegnandogli la massima priorità. Il team di Supporto Enterprise 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 (ACM)
AWS Certificate Manager
ACM viene utilizzato nell'account di rete 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 di natura progettuale
Per i certificati diretti all'esterno, ACM deve trovarsi nello stesso account delle risorse per le quali fornisce i certificati. I certificati non possono essere condivisi tra account.
Amazon Route 53
Amazon Route 53
Puoi utilizzare Route 53 come servizio DNS per mappare i nomi di dominio alle tue EC2 istanze, ai bucket S3, alle distribuzioni e ad altre risorse. CloudFront AWS La natura distribuita dei server AWS DNS aiuta a garantire che gli utenti finali vengano indirizzati alla tua applicazione in modo coerente. Funzionalità come il controllo del flusso di traffico e del routing della Route 53 aiutano a migliorare l'affidabilità. Se l'endpoint dell'applicazione principale diventa non disponibile, puoi configurare il failover per reindirizzare gli utenti verso una posizione alternativa. Route 53 Resolver fornisce DNS ricorsivo per il tuo VPC e le tue reti locali tramite o VPN gestita. AWS Direct Connect AWS
Utilizzando il servizio IAM con Route 53, ottieni un controllo dettagliato su chi può aggiornare i tuoi dati DNS. È possibile abilitare la firma DNSSEC (DNS Security Extensions) per consentire ai risolutori DNS di accertarsi che una risposta DNS provenga da Route 53 e che non sia stata manomessa.
Route 53 Resolver DNS Firewall offre protezione per le richieste DNS in uscita provenienti da... VPCs Queste richieste vengono instradate tramite il risolutore Route 53 per la risoluzione dei nomi di 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 le richieste di risoluzione alle risorse in zone ospitate private (condivise o locali), inclusi i nomi degli endpoint VPC. Può anche bloccare le richieste di nomi di istanze pubbliche o private. EC2
I risolutori Route 53 vengono creati di default come parte di ogni VPC. Nell' AWS SRA, Route 53 viene utilizzata nell'account di rete principalmente per la funzionalità DNS Firewall.
Considerazione di natura progettuale
DNS Firewall ed AWS Network Firewall entrambi offrono il filtraggio dei nomi di dominio, ma per diversi tipi di traffico. È possibile utilizzare DNS Firewall e Network Firewall insieme per configurare il filtraggio basato sul dominio per il traffico a livello di applicazione su due diversi percorsi di rete:
-
DNS Firewall fornisce il filtro per le query DNS in uscita che passano attraverso il Route 53 Resolver dalle applicazioni interne al tuo. VPCs È inoltre possibile configurare DNS Firewall per inviare risposte personalizzate per le query a nomi di dominio bloccati.
-
Firewall di rete fornisce filtri sia per il traffico a livello di rete che di applicazione, ma non dispone di visibilità sulle query eseguite dal risolutore Route 53.