Infrastruttura OU - Account di rete - AWSGuida prescrittiva

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à.

Infrastruttura OU - Account di rete

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

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


      Servizi di sicurezza per l'account di rete

L'account di rete gestisce il gateway tra l'applicazione e Internet in generale. È importante proteggere l'interfaccia bidirezionale. L'account di rete isola i servizi, la configurazione e il funzionamento di rete 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 il minimo privilegio 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, è possibile 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 le protezioni 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 esulino dall'ambito di questo documento, consigliamo queste tre opzioni per la connettività di rete tra i vari account: peering VPC PrivateLink, 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 una connettività bidirezionale completa tra i VPC. I VPC che si trovano in account e regioni AWS separati possono anche essere raggruppati insieme. Su larga scala, quando si hanno da decine a centinaia di VPC, l'interconnessione con il peering si traduce in una rete da centinaia a migliaia di connessioni peering, che possono essere difficili 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 ciascuna connessione).

  • AWS PrivateLink ‒ PrivateLink fornisce connettività privata tra VPC, servizi e applicazioni. Puoi creare un'applicazione nel VPC e configurarla come servizio PrivateLink basato su (denominato servizio endpoint). 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 si utilizza PrivateLink, il traffico di servizio non passa attraverso una rete indirizzabile pubblicamente. Da utilizzare PrivateLink quando si dispone di una configurazione client-server in cui si desidera concedere a uno o più VPC consumer l'accesso unidirezionale a un servizio o a una serie di istanze specifici 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 alta disponibilità e scalabilità. 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 della tua 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 in entrata (ingresso)

Il VPC in entrata è progettato per 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 (in 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 traffico NAT, endpoint VPC specifici per i servizi AWS e l'hosting di endpoint API esterni in questo VPC. I log di flusso di questo VPC vengono acquisiti e archiviati nell'account Log Archive.

Ispezione VPC

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 quanto riguarda l'AWS SRA, assicurati che tutto il traffico tra i VPC di ispezione 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 facilmente ispezioni stateful, prevenzione e rilevamento delle intrusioni e filtri web per proteggere le tue reti virtuali su AWS. Per ulteriori informazioni sulla configurazione del Network Firewall, consulta il post del blog di 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 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 dello use case e del modello di distribuzione, la sottorete del firewall potrebbe 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 firewall per l'ispezione. 

Network Firewall rende l'attività del firewall visibile in tempo reale tramite le CloudWatch metriche di Amazon e offre una maggiore visibilità del traffico di rete inviando i log ad Amazon Simple Storage Service (Amazon S3) e Amazon Kinesis Data Firehose. CloudWatch 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 forniti esternamente da fornitori terzi o piattaforme open source. 

In AWS SRA, Network Firewall viene utilizzato all'interno dell'account di rete perché la funzionalità del servizio incentrata sul controllo di 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 di Network Firewall in tutta l'organizzazione. (Per i dettagli, consulta le politiche di AWS Network Firewall nella documentazione di AWS.) Quando si configura Firewall Manager, viene creato 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 aggiornata automaticamente a valle dei Network Firewall distribuiti. 

  • 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 il Network Firewall viene implementato in singoli VPC.

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

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

  • Come best practice, non utilizzare la sottorete Network Firewall per distribuire 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 caratteristica 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 affidabili e verificare di disporre di controlli di rete appropriati su tutti i percorsi di rete.

Network Access Analyzer utilizza algoritmi di ragionamento automatico per analizzare i percorsi di rete che un pacchetto può seguire tra le risorse di una rete AWS e produce risultati per percorsi che corrispondono all'ambito di accesso alla rete definito dall'utente. 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 Amazon Inspector Network Reachability 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 attentamente monitorato. In AWS SRA, Network Access Analyzer viene utilizzato all'interno dell'account di rete per aiutare a identificare accessi involontari alla rete, identificare 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 del design
  • Network Access Analyzer è una funzionalità di Amazon VPC e può essere utilizzato in qualsiasi account AWS dotato di un VPC. Gli amministratori di rete possono ottenere ruoli IAM multiaccount ristretti per convalidare che i percorsi di rete approvati siano applicati all'interno di ogni account AWS.

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 connesse interne. Con ACM, puoi richiedere rapidamente un certificato, distribuirlo su risorse AWS integrate con ACM, come i load balancer Elastic Load Balancing, CloudFront le distribuzioni Amazon e le API su Amazon API Gateway e lasciare che ACM gestisca i rinnovi dei certificati. 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 si utilizza ACM per gestire i certificati, le chiavi private dei certificati sono protette e archiviate in modo sicuro utilizzando una crittografia avanzata e le migliori pratiche di gestione delle chiavi. Con ACM non ci sono costi aggiuntivi per la fornitura di certificati pubblici e ACM gestisce il processo di rinnovo.

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 CloudFront documentazione

Considerazione del design
  • Per i certificati rivolti verso l'esterno, ACM deve risiedere nello stesso account delle risorse per le quali fornisce certificati. I certificati non possono essere condivise sugli account.

AWS WAF

AWS WAF è un firewall per le applicazioni Web che consente agli utenti di monitorare le richieste HTTP e HTTPS inoltrate a una CloudFront distribuzione Amazon API, a un'API REST di Amazon API Gateway, a Application Load Balancer o a un'API GraphQL di AWS AppSync GraphQL. AWS WAF consente inoltre di controllare l'accesso ai propri contenuti. A seconda delle condizioni che vengono specificate, ad esempio gli indirizzi IP da cui hanno origine le richieste o i valori delle stringhe di query, il servizio fronted risponde alle richieste con il contenuto richiesto o con un codice di stato HTTP 403 (Forbidden).

In AWS SRA, AWS WAF viene utilizzato nell'account di rete, perché protegge CloudFront. 

Considerazioni di natura progettuale
  • CloudFront fornisce funzionalità che migliorano la funzionalità di AWS WAF e fanno sì che i due servizi funzionino meglio insieme. 

  • Puoi utilizzare AWS WAF, AWS Firewall Manager e AWS Shield insieme per creare una soluzione di sicurezza completa. Inizia con AWS WAF. Puoi automatizzare e quindi semplificare la gestione di AWS WAF utilizzando Firewall Manager. Shield Advanced offre funzionalità aggiuntive oltre ad AWS WAF, come il supporto dedicato del Distributed Denial of Service (DDoS) Response Team (DRT) e la reportistica avanzata. Se desideri un controllo granulare sulla protezione che viene aggiunta alle tue risorse, AWS WAF da solo è la scelta giusta. Se desideri utilizzare AWS WAF su più account, accelerare la configurazione di AWS WAF o automatizzare la protezione di nuove risorse, usa Firewall Manager con AWS WAF. Infine, se possiedi siti Web ad alta visibilità o sei comunque soggetto a frequenti eventi dannosi DDoS, puoi prendere in considerazione l'acquisto delle funzionalità aggiuntive fornite da AWS Shield Advanced.

Amazon Route 53

Amazon Route 53 è un servizio Web DNS (Domain Name System) 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 alle tue istanze EC2, ai bucket S3, CloudFront alle distribuzioni e ad altre risorse AWS. La natura distribuita dei nostri server DNS aiuta a garantire che gli utenti finali siano indirizzati alla tua applicazione in modo coerente. Funzionalità come il flusso di traffico della Route 53 e il controllo del routing consentono di migliorare l'affidabilità con un failover semplicemente configurato per reindirizzare gli utenti verso una posizione alternativa se l'endpoint dell'applicazione principale non è disponibile. Route 53 Resolver fornisce DNS ricorsivo per VPC e reti locali su AWS Direct Connect o AWS managed VPN.

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

Il firewall DNS Route 53 Resolver fornisce protezione per le richieste DNS in uscita dai VPC. Queste richieste vengono instradate tramite Route 53 Resolver 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 istanza EC2 pubblici o privati. 

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

Considerazione del design
  • Con DNS Firewall e AWS Network Firewall è possibile utilizzare entrambi filtri dei nomi di dominio, ma per diversi tipi di traffico. È 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 diversi.

    • 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 sia per il traffico a livello di rete che di applicazione, ma non dispone di visibilità sulle query eseguite da Route 53 Resolver.

Amazon CloudFront

Amazon CloudFront è una rete sicura per la distribuzione dei contenuti (CDN) che fornisce protezione sia a livello di rete che a livello di applicazione. Puoi distribuire contenuti, API o applicazioni utilizzando certificati SSL/TLS e le funzionalità SSL avanzate vengono abilitate automaticamente. Puoi usare AWS Certificate Manager (ACM) per creare un certificato TLS personalizzato e applicare le comunicazioni HTTPS tra i visualizzatori e CloudFront, come descritto in precedenza nella sezione ACM. È inoltre possibile richiedere che le comunicazioni tra CloudFront e l'origine personalizzata implementino la end-to-end crittografia in transito. Per questo scenario, dovrai installare un certificato TLS sul tuo server di origine. Se l'origine è un sistema di bilanciamento del carico ELB, è possibile utilizzare un certificato generato da ACM o un certificato convalidato da una CA di terze parti e importato in ACM. Se gli endpoint del sito Web del bucket S3 sono l'origine, non è possibile configurare CloudFront per l'utilizzo di HTTPS con l'origine perché Amazon S3 non supporta HTTPS per gli endpoint del sito Web. (Tuttavia, puoi comunque richiedere HTTPS tra visualizzatori e CloudFront.) Per tutte le altre origini che supportano l'installazione di certificati HTTPS, devi utilizzare un certificato firmato da una CA di terze parti affidabile. 

Quando utilizzi CloudFront come CDN, puoi limitare l'accesso ai contenuti utilizzando queste funzionalità:

  • Utilizzando URL firmati e cookie firmati, puoi supportare l'autenticazione tramite token per limitare l'accesso solo ai visitatori autenticati.

  • Utilizzando la funzionalità di restrizione geografica, è possibile impedire agli utenti in specifiche aree geografiche di accedere al contenuto che stai distribuendo CloudFront.

  • È possibile utilizzare la funzione Origin Access Identity (OAI) per limitare l'accesso a un bucket S3 da cui è accessibile solo da CloudFront. 

In AWS SRA, Amazon CloudFront viene utilizzato all'interno dell'account di rete, poiché questo account fornisce l'infrastruttura di rete necessaria per la comunicazione dei carichi di lavoro all'esterno di AWS. 

Considerazioni di natura progettuale
  • CloudFront, AWS Shield, AWS WAF e Amazon Route 53 collaborano perfettamente per creare un perimetro di sicurezza flessibile e stratificato contro diversi tipi di eventi non autorizzati, inclusi attacchi DDoS a livello di rete e applicazioni. CloudFront fornisce funzionalità che migliorano la funzionalità di AWS WAF e fanno sì che le due funzionino meglio insieme. Per ulteriori informazioni, consulta Come AWS WAF funziona con CloudFront le funzionalità di Amazon nella documentazione di AWS. 

  • Quando distribuisci contenuti web tramite una CDN, ad esempio CloudFront, una buona pratica è impedire che le richieste degli spettatori aggirino il CDN e accedano direttamente ai tuoi contenuti di origine. Per ulteriori informazioni, consulta il post Come migliorare la sicurezza di Amazon CloudFront Origin con AWS WAF e AWS Secrets Manager

  • Potresti anche valutare un'architettura distribuita in cui tutta l'infrastruttura di rete necessaria per la comunicazione dei carichi di lavoro all'esterno di AWS risiede localmente all'interno dell'account dell'applicazione. Ciò semplifica l'architettura e il routing della rete e contribuirebbe a ridurre i costi non richiedendo costi di ingresso/uscita tra account. In un'architettura distribuita, è necessario applicare una forte supervisione della sicurezza per esercitare controlli di sicurezza per tutti i percorsi di rete.

AWS Shield

AWS Shield è un servizio di protezione DDoS gestito che protegge le applicazioni eseguite su AWS. Shield fornisce un rilevamento sempre attivo e mitigazioni automatiche in linea che riducono al minimo i tempi di inattività e la latenza delle applicazioni, quindi non è necessario coinvolgere AWS Support per beneficiare della protezione DDoS. 

In AWS SRA, AWS Shield Advanced è configurato per proteggere Route 53 e CloudFront.  

Considerazione del design
  • Esistono due livelli di Shield: Shield Standard e Shield Advanced. Tutti i clienti AWS beneficiano delle protezioni automatiche di Shield Standard senza costi aggiuntivi. Shield Standard fornisce protezione contro gli eventi infrastrutturali più comuni e frequenti (layer 3 e 4). Shield Standard utilizza il filtraggio deterministico dei pacchetti e lo shaping del traffico basato sulle priorità per mitigare automaticamente gli attacchi di base a livello di rete. Shield Advanced offre mitigazioni automatiche più sofisticate per eventi non autorizzati rivolti alle tue applicazioni in esecuzione su risorse protette di Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator e Route 53. Shield Advanced registra le metriche che puoi monitorare in Amazon CloudWatch. (Per ulteriori informazioni, consulta le metriche e gli allarmi di AWS Shield Advanced nella documentazione di AWS.) Se possiedi siti Web ad alta visibilità o sei comunque soggetto a frequenti attacchi DDoS, puoi prendere in considerazione le funzionalità aggiuntive fornite da Shield Advanced.

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 offre un luogo 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 la portata 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 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 in base all'ID dell'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 la RAM AWS, 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 politiche delle risorse IAM. Se la RAM AWS viene utilizzata per condividere risorse esterne all'organizzazione AWS, 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.

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'AWS SRA è 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 raggiungere la separazione dei compiti. Per ulteriori informazioni sulla condivisione VPC, consulta il post sul blog AWS VPC sharing: un nuovo approccio a più account e gestione dei VPC e il white paper sull'infrastruttura di rete AWS

Considerazione del design
  • Sebbene AWS RAM as a service sia distribuito solo all'interno dell'account di rete nell'AWS SRA, in genere viene distribuito in più di un account. Ad esempio, puoi centralizzare la gestione del 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 del 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 unaCA 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.