Proteggi e isola i carichi di lavoro altamente sensibili con un'enclave sicura
Questa guida mostra come creare un'architettura cloud completa per carichi di lavoro sensibili nei settori della sicurezza nazionale, della difesa e delle forze dell'ordine nazionali. Utilizzando un'architettura multi-account su AWS, è possibile portare a termine le proprie missioni tenendo al sicuro i dati e i carichi di lavoro sensibili. Questa guida è progettata per consentire di soddisfare requisiti di sicurezza e conformità rigorosi e unici, affrontando la gestione centralizzata delle identità e degli accessi, la governance, la sicurezza dei dati, la registrazione completa e la progettazione e segmentazione della rete in linea con i vari framework di sicurezza statunitensi.
Nota: [Disclaimer]
Diagramma dell'architettura
-
Panoramica
-
Account di gestione dell'organizzazione
-
Account di sicurezza
-
Account dell'infrastruttura
-
Account di applicazione, community, team o gruppo (sensibili)
-
Panoramica
-
Questo diagramma dell'architettura fornisce una panoramica su come configurare carichi di lavoro completi e multi-account con requisiti di sicurezza e conformità unici. Per maggiori dettagli su come implementare questa guida, apri le altre schede.
Fase 1
Un'organizzazione in AWS Organizations con più account, guidata da policy di controllo dei servizi (SCP): l'organizzazione raggruppa più account AWS separati, controllati da un'unica entità cliente. Gli account AWS separati forniscono un completo isolamento del piano di controllo e del piano dati tra i carichi di lavoro o gli ambienti, come se fossero di proprietà di clienti AWS diversi.Fase 2
L'account di gestione viene utilizzato per creare l'organizzazione. Dall'account di gestione dell'organizzazione, è possibile effettuare le seguenti operazioni:- Creare account nell'organizzazione e gestire le policy per tutte le unità organizzative.
- Unire le seguenti unità organizzative all'organizzazione:
- Unità organizzativa di sicurezza
- Unità organizzativa di infrastruttura
- Unità organizzativa dell'applicazione sensibile
Ogni unità organizzativa avrà uno o più account membri o unità organizzative annidate per progetto.
Fase 3
L'unità organizzativa dell'applicazione avrà diverse unità organizzative annidate dedicate alla distribuzione delle applicazioni e alla gestione del ciclo di vita, e comprende quanto segue:- Unità organizzativa di sviluppo
- Unità organizzativa di test
- Unità organizzativa di produzione
- Unità organizzativa condivisa
Inoltre, le unità operative sandbox possono essere fornite anche come carichi di lavoro non sensibili.
-
Account di gestione dell'organizzazione
-
Questo diagramma dell'architettura mostra come un'organizzazione può raggruppare più account, tutti controllati da un'unica entità cliente. Segui i passaggi indicati in questo diagramma dell'architettura per implementare la parte di questa guida relativa all'account di gestione dell'organizzazione.
Fase 1
Un'organizzazione con più account: l'organizzazione raggruppa più account AWS separati, controllati da un'unica entità cliente. Ciò consolida la fatturazione, raggruppa gli account utilizzando le unità organizzative e facilita l'implementazione dei controlli preventivi di un'organizzazione tramite SCP.Fase 2
Controlli di sicurezza preventivi: questi controlli, implementati dalle SCP, proteggono l'architettura, impediscono la disattivazione del guardrail e bloccano i comportamenti indesiderati degli utenti. Le SCP forniscono un meccanismo di guardrail utilizzato principalmente per negare specifiche o intere categorie di operazioni API a livello di account AWS, unità organizzativa o organizzazione. Queste possono essere utilizzate per garantire che i carichi di lavoro siano implementati solo nelle regioni AWS previste o per negare l'accesso a servizi AWS specifici.
Fase 3
Automazione: l'automazione assicura che i guardrail siano applicati in modo coerente quando l'organizzazione aggiunge nuovi account AWS man mano che vengono coinvolti nuovi team e carichi di lavoro. Corregge la deviazione della conformità e fornisce guardrail nell'account dell'organizzazione principale.
Fase 4
Crittografia: il Servizio AWS di gestione delle chiavi (AWS KMS) con chiavi gestite dal cliente crittografa i dati archiviati a riposo utilizzando la crittografia convalidata FIPS 140-2, sia nei bucket Amazon Simple Storage Service (Amazon S3), nei volumi Amazon Elastic Block Store (Amazon EBS), nei database Amazon Relational Database Service (Amazon RDS) o in altri servizi di archiviazione AWS. Protegge i dati in transito utilizzando TLS 1.2 o versioni successive.Fase 5
Autenticazione unica: funzionalità di AWS Identity and Access Management (IAM), il Centro identità IAM viene utilizzato per fornire l'assunzione centralizzata del ruolo IAM negli account AWS in tutta l'organizzazione per i principali autorizzati. Le identità esistenti di un'organizzazione possono provenire da un archivio esistente di identità Active Directory (AD) di un cliente o da un altro gestore dell'identità digitale di terze parti.AWS facilita l'applicazione dell'autenticazione a più fattori tramite app di autenticazione, chiavi di sicurezza e autenticatori integrati, supportando l'autenticazione e i dispositivi WebAuthn, FIDO2 e Universal 2nd Factor (U2F).
-
Account di sicurezza
-
Questo diagramma dell'architettura mostra come configurare in modo centralizzato una raccolta completa di log tra servizi e account AWS. Segui i passaggi indicati in questo diagramma dell'architettura per implementare la parte di questa guida relativa agli account di sicurezza.
Fase 1
Registrazione centralizzata: questa architettura prevede la raccolta e la centralizzazione completa dei log tra i servizi e gli account AWS. I log di AWS CloudTrail funzionano a livello di organizzazione per fornire la completa verificabilità del piano di controllo in tutto l'ambiente cloud.Amazon CloudWatch Logs, un servizio di registrazione AWS nativo del cloud, viene utilizzato per acquisire un'ampia gamma di log, tra cui i log del sistema operativo e delle applicazioni, i log dei flussi VPC e i log del sistema dei nomi di dominio, che vengono quindi centralizzati e resi disponibili soltanto al personale di sicurezza preposto.
Fase 2
Monitoraggio centralizzato della sicurezza: la deviazione della conformità e le minacce alla sicurezza vengono rilevate nell'organizzazione AWS del cliente attraverso l'implementazione automatica di diversi tipi di controlli di sicurezza investigativi. Ciò include l'attivazione di una moltitudine di servizi di sicurezza AWS in ogni account dell'organizzazione.Questi servizi di sicurezza includono Amazon GuardDuty, Centrale di sicurezza AWS, AWS Config, Gestione dei firewall AWS, Amazon Macie, Sistema di analisi degli accessi IAM e allarmi CloudWatch. Il controllo e la visibilità devono essere delegati nell'ambiente multi-account a un unico account centrale per gli strumenti di sicurezza, per una facile visibilità a livello di organizzazione di tutti gli esiti della sicurezza e della deviazione della conformità.
Fase 3
Accesso di sola visualizzazione e ricercabilità: all'account di sicurezza viene fornito un accesso di sola visualizzazione in tutta l'organizzazione (incluso l'accesso alla console CloudWatch di ciascun account) per facilitare le indagini durante un incidente.
L'accesso di sola visualizzazione è diverso dall'accesso di sola lettura in quanto non fornisce alcun accesso ai dati. È disponibile un componente aggiuntivo opzionale per utilizzare il pacchetto completo di log centralizzati e renderli disponibili per la ricerca, fornendo correlazione e dashboard di base.
-
Account dell'infrastruttura
-
Questo diagramma dell'architettura mostra come si costruisce un ambiente di rete centralizzato e isolato con i cloud privati virtuali (VPC). Segui i passaggi indicati in questo diagramma dell'architettura per implementare la parte di questa guida relativa agli account dell'infrastruttura.
Fase 1
Rete centralizzata e isolata: i VPC creati tramite Amazon Virtual Private Cloud (Amazon VPC) vengono utilizzati per creare un isolamento del piano dati tra i carichi di lavoro, centralizzati in un account di rete condiviso. La centralizzazione facilita una netta segregazione delle mansioni e l'ottimizzazione dei costi.Fase 2
Connettività mediata: la connettività agli ambienti on-premises, l'uscita da Internet, le risorse condivise e le API AWS sono mediate in un punto centrale di ingresso e uscita tramite l'uso di AWS Transit Gateway, VPN sito-sito AWS, firewall di nuova generazione e AWS Direct Connect (ove applicabile).Fase 3
Opzioni alternative: l'architettura VPC centralizzata non è adatta a tutti i clienti. Per i clienti meno attenti all'ottimizzazione dei costi, esiste l'opzione dei VPC basati su account locali interconnessi tramite Transit Gateway nell'account centrale di rete condivisa.
In entrambe le opzioni, l'architettura prevede lo spostamento degli endpoint delle API pubbliche di AWS nello spazio di indirizzi VPC privato del cliente, utilizzando endpoint centralizzati per garantire l'efficienza dei costi.
Fase 4
Ispezione centralizzata dell'Infrastructure-as-a-Service (IaaS) in ingresso e in uscita: è comune vedere requisiti di ingresso e uscita centralizzati per i carichi di lavoro basati su IaaS. L'architettura fornisce questa funzionalità, in modo che i clienti possano decidere se i servizi di ispezione dei firewall di ingresso e uscita nativi di AWS, come Firewall di rete AWS, AWS AWS WAF oppure Application Load Balancer tramite Elastic Load Balancing (ELB), soddisfano le loro esigenze.In caso contrario, i clienti possono potenziare tali funzionalità con dispositivi firewall di terze parti. L'architettura consente di iniziare con un firewall AWS e di passare a un firewall di terze parti o di utilizzare una combinazione di tecnologie firewall di ingresso e di uscita.
-
Account di applicazione, community, team o gruppo (sensibili)
-
Questo diagramma dell'architettura mostra come configurare la segmentazione e la separazione tra carichi di lavoro appartenenti a diverse fasi del ciclo di vita dello sviluppo del software o tra diversi ruoli IT amministrativi. Segui i passaggi indicati in questo diagramma dell'architettura per implementare la parte di questa guida relativa agli account di applicazione, community, team o gruppo.
Fase 1
Segmentazione e separazione: l'architettura non si limita a fornire una forte segmentazione e separazione tra carichi di lavoro appartenenti a diverse fasi del ciclo di vita dello sviluppo del software o tra diversi ruoli IT amministrativi (ad esempio tra rete, firewall di ingresso e uscita e carichi di lavoro).Offre inoltre una solida architettura di suddivisione in zone della rete, che microsegmenta l'ambiente racchiudendo ogni istanza o componente in un firewall stateful nell'hardware di AWS Nitro System, insieme a servizi come ELB e AWS WAF.
Fase 2
Tutti i flussi di rete sono strettamente regolamentati, impedendo lo spostamento laterale tra le applicazioni, i livelli all'interno di un'applicazione e i nodi in un livello di un'applicazione, a meno che non sia esplicitamente consentito. Inoltre, viene impedito il routing tra Sviluppo, Test e Produzione con suggerimenti per un'architettura di integrazione e distribuzione continue, allo scopo di consentire l'agilità degli sviluppatori e facilitare la promozione del codice tra ambienti con le opportune approvazioni.
Principi di Well-Architected
Il framework AWS Well-Architected consente di valutare i pro e i contro delle decisioni prese durante il processo di creazione di sistemi nel cloud. I sei principi del framework consentono di apprendere le best practice architetturali per la progettazione e il funzionamento di sistemi affidabili, sicuri, efficienti, convenienti e sostenibili. Grazie allo strumento AWS Well-Architected, disponibile gratuitamente nella Console di gestione AWS, puoi rivedere i tuoi carichi di lavoro rispetto a queste best practice rispondendo a una serie di domande per ciascun principio.
Il diagramma dell'architettura sopra riportato è un esempio di una soluzione creata tenendo conto delle best practice Well-Architected. Per essere completamente Well-Architected, dovresti seguire il maggior numero possibile di best practice.
-
Eccellenza operativa
Questa guida si avvale di Organizations con stack e configurazioni AWS CloudFormation per creare una base sicura per l'ambiente AWS. Ciò fornisce una soluzione Infrastructure-as-code (IaC) che accelera l'implementazione dei controlli tecnici di sicurezza. Le regole di Config risolvono eventuali delta di configurazione che si ritiene abbiano un impatto negativo sull'architettura prevista. È possibile utilizzare l'infrastruttura commerciale globale di AWS per carichi di lavoro sensibili e automatizzare i sistemi di sicurezza per svolgere le missioni più velocemente, migliorando continuamente i processi e le procedure.
-
Sicurezza
Questa guida utilizza Organizations per facilitare l'implementazione di guardrail organizzativi, come la registrazione delle API con CloudTrail. Questa guida fornisce anche controlli preventivi che si avvalgono di SCP prescrittive di AWS come il meccanismo di guardrail, utilizzato principalmente per negare specifiche o intere categorie di API all'interno dell'ambiente (per garantire che i carichi di lavoro siano implementati solo nelle regioni previste) o negare l'accesso a servizi AWS specifici. I log di CloudTrail e CloudWatch supportano una raccolta e una centralizzazione dei log completa, prevista tra i servizi e gli account AWS. Le funzionalità di sicurezza di AWS e la moltitudine di servizi rilevanti per la sicurezza sono configurati secondo uno schema definito che consente di soddisfare alcuni dei requisiti di sicurezza più rigidi al mondo.
-
Affidabilità
Questa guida utilizza più zone di disponibilità (AZ), per cui la perdita di una AZ non influisce sulla disponibilità delle applicazioni. È possibile utilizzare CloudFormation per automatizzare il provisioning e l'aggiornamento dell'infrastruttura in modo controllato e sicuro. Questa guida fornisce anche regole predefinite per valutare le configurazioni delle risorse AWS e le modifiche di configurazione all'interno dell'ambiente. In alternativa, è possibile creare regole personalizzate in AWS Lambda per definire best practice e linee guida. È possibile automatizzare la capacità di scalare l'ambiente per soddisfare la domanda e mitigare le interruzioni come configurazioni errate o problemi di rete transitori.
-
Efficienza delle prestazioni
Questa guida semplifica la gestione dell'infrastruttura cloud utilizzando Transit Gateway, che funge da hub centrale che collega più VPC tramite un unico gateway, facilitando la scalabilità e la manutenzione dell'architettura di rete. Ciò semplifica l'architettura di rete e facilita l'instradamento efficiente del traffico tra diversi account AWS all'interno dell'organizzazione.
-
Ottimizzazione dei costi
Questa guida consente di evitare o eliminare costi non necessari o l'uso di risorse non ottimali. Organizations offre centralizzazione e fatturazione consolidata, facilitando la netta separazione tra uso delle risorse e ottimizzazione dei costi. Questa guida stabilisce di spostare gli endpoint delle API pubbliche di AWS nello spazio di indirizzi VPC privato, utilizzando endpoint centralizzati per garantire l'efficienza dei costi. Inoltre, è possibile utilizzare i Report di costi e utilizzo di AWS (AWS CUR) per monitorare l'utilizzo di AWS e stimare i costi.
-
Sostenibilità
Questa guida consente di ridurre l'impronta ecologica associata alla gestione dei carichi di lavoro all'interno dei data center. L'infrastruttura globale di AWS offre un'infrastruttura di supporto (come l'alimentazione, il raffreddamento e la rete), un tasso di utilizzo più elevato e aggiornamenti tecnologici più rapidi rispetto ai data center tradizionali. Inoltre, la segmentazione e la separazione dei carichi di lavoro contribuiscono a ridurre gli spostamenti di dati non necessari e Amazon S3 offre livelli di archiviazione e la possibilità di spostare automaticamente i dati su livelli di archiviazione efficienti.
Risorse per l'implementazione
Il codice di esempio è un punto di partenza. È convalidato dal settore, prescrittivo ma non definitivo, ed è il punto di partenza per iniziare a lavorare.
Contenuti correlati
Configurazione di esempio TSE-SE (con motore di automazione LZA)
Enclavi sicure e affidabili - Versione sensibile
Disclaimer
Il codice di esempio, le librerie software, gli strumenti della linea di comando, le proof of concept, i modelli e le altre tecnologie correlate (comprese tutte le tecnologie di cui sopra fornite dal nostro personale) vengono forniti all'utente sotto forma di contenuto AWS ai sensi dell'Accordo cliente AWS o del relativo accordo scritto stipulato tra l'utente e AWS (a seconda dei casi). Non bisogna utilizzare il contenuto AWS in questione negli account di produzione o sui dati di produzione o altri dati fondamentali. L'utente è responsabile dei test, della sicurezza e dell'ottimizzazione del contenuto AWS, come il codice di esempio, in modo appropriato per l'utilizzo in produzione sulla base delle pratiche e degli standard di qualità specifici. L'implementazione del contenuto AWS può comportare costi AWS per la creazione o l'utilizzo di risorse AWS addebitabili, quali le istanze Amazon EC2 in esecuzione o l'archiviazione Amazon S3.
Eventuali riferimenti a servizi o organizzazioni di terze parti contenuti in questa guida non implicano alcuna approvazione, sponsorizzazione o affiliazione tra Amazon o AWS e dette terze parti. La guida di AWS è un punto di partenza tecnico e l'integrazione con servizi di terze parti può essere personalizzata al momento dell'implementazione dell'architettura.