AWS strategia multi-account per la tua landing zone AWS della Control Tower - AWS Control Tower

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

AWS strategia multi-account per la tua landing zone AWS della Control Tower

AWSI clienti Control Tower spesso richiedono indicazioni su come configurare il proprio AWS ambiente e i propri account per ottenere i migliori risultati.AWS ha creato una serie unificata di consigli, denominata strategia multi-account, per aiutarti a utilizzare al meglio le tue AWS risorse, inclusa la landing zone della AWS Control Tower.

In sostanza, AWS Control Tower funge da livello di orchestrazione che funziona con altri AWS servizi, che ti aiutano a implementare i consigli AWS multi-account per AWS account e. AWS Organizations Dopo aver configurato la landing zone, AWS Control Tower continua ad assisterti nel mantenimento delle politiche aziendali e delle pratiche di sicurezza su più account e carichi di lavoro.

La maggior parte delle zone di atterraggio si sviluppa nel tempo. Con l'aumentare del numero di unità organizzative (OUs) e account nella landing zone AWS della Control Tower, è possibile estendere l'implementazione AWS della Control Tower in modo da organizzare i carichi di lavoro in modo efficace. Questo capitolo fornisce linee guida prescrittive su come pianificare e configurare la landing zone AWS della Control Tower, in linea con la strategia AWS multi-account, ed estenderla nel tempo.

Per una discussione generale sulle migliori pratiche per le unità organizzative, consulta Best practice per le unità organizzative con. AWS Organizations

AWS strategia multi-account: linee guida sulle migliori pratiche

AWS le migliori pratiche per un ambiente ben progettato consigliano di separare le risorse e i carichi di lavoro in più account. AWS Puoi pensare AWS agli account come a contenitori di risorse isolati: offrono la categorizzazione dei carichi di lavoro, oltre a una riduzione del raggio d'azione quando le cose vanno male.

Definizione di account AWS

Un AWS account funge da contenitore di risorse e limite di isolamento delle risorse.

Nota

Un AWS account non è uguale a un account utente, che viene impostato tramite Federation o AWS Identity and Access Management (IAM).

Ulteriori informazioni sugli AWS account

Un AWS account offre la possibilità di isolare le risorse e contenere le minacce alla sicurezza per i AWS carichi di lavoro. Un account fornisce anche un meccanismo per la fatturazione e la governance di un ambiente di carico di lavoro.

L' AWS account è il meccanismo di implementazione principale per fornire un contenitore di risorse per i carichi di lavoro. Se l'ambiente è ben progettato, è possibile gestire più AWS account in modo efficace e, quindi, gestire più carichi di lavoro e ambienti.

AWSControl Tower crea un ambiente ben progettato. Si basa anche sugli AWS account che aiutano a gestire le AWS Organizations modifiche all'ambiente che possono estendersi a più account.

Definizione di un ambiente ben progettato

AWS definisce un ambiente ben architettato come un ambiente che inizia con una landing zone.

AWSControl Tower offre una landing zone che viene configurata automaticamente. Implementa i controlli per garantire la conformità alle linee guida aziendali su più account dell'ambiente.

Definizione di landing zone

La landing zone è un ambiente cloud che offre un punto di partenza consigliato, inclusi account predefiniti, struttura degli account, layout di rete e sicurezza e così via. Da una landing zone, puoi distribuire carichi di lavoro che utilizzano le tue soluzioni e applicazioni.

Linee guida per configurare un ambiente ben progettato

I tre componenti chiave di un ambiente ben progettato, spiegati nelle seguenti sezioni, sono:

  • Account multipli AWS

  • Unità organizzative multiple (OUs)

  • Una struttura ben pianificata

Usa più account AWS

Un account non è sufficiente per configurare un ambiente ben progettato. Utilizzando più account, puoi supportare al meglio i tuoi obiettivi di sicurezza e i tuoi processi aziendali. Ecco alcuni vantaggi dell'utilizzo di un approccio multi-account:

  • Controlli di sicurezza: le applicazioni hanno profili di sicurezza diversi, quindi richiedono politiche e meccanismi di controllo diversi. Ad esempio, è molto più semplice parlare con un revisore e puntare su un unico account che gestisca il carico di lavoro del settore delle carte di pagamento (PCI).

  • Isolamento: un account è un'unità di protezione della sicurezza. I potenziali rischi e le minacce alla sicurezza possono essere contenuti all'interno di un account senza influire sugli altri. Pertanto, per esigenze di sicurezza potrebbe essere necessario isolare gli account l'uno dall'altro. Ad esempio, potresti avere team con profili di sicurezza diversi.

  • Molti team: i team hanno responsabilità e esigenze di risorse diverse. Configurando più account, i team non possono interferire l'uno con l'altro, come potrebbero fare quando utilizzano lo stesso account.

  • Isolamento dei dati: l'isolamento degli archivi dati in un account consente di limitare il numero di persone che hanno accesso ai dati e possono gestire l'archivio dati. Questo isolamento aiuta a prevenire l'esposizione non autorizzata di dati altamente privati. Ad esempio, l'isolamento dei dati aiuta a garantire la conformità al Regolamento generale sulla protezione dei dati (GDPR).

  • Processo aziendale: le unità aziendali o i prodotti hanno spesso scopi e processi completamente diversi. È possibile creare account individuali per soddisfare esigenze specifiche dell'azienda.

  • Fatturazione: un account è l'unico modo per separare gli elementi a livello di fatturazione, ad esempio le spese di trasferimento e così via. La strategia multi-account consente di creare elementi fatturabili separati tra unità aziendali, team funzionali o singoli utenti.

  • Allocazione delle AWS quote: le quote vengono impostate per account. La separazione dei carichi di lavoro in diversi account conferisce a ciascun account (ad esempio un progetto) una quota individuale ben definita.

Utilizza più unità organizzative

AWSControl Tower e altri framework di orchestrazione degli account possono apportare modifiche che superano i confini degli account. Pertanto, le AWS migliori pratiche riguardano le modifiche tra account, che potenzialmente possono danneggiare un ambiente o comprometterne la sicurezza. In alcuni casi, le modifiche possono influire sull'ambiente generale, al di là delle politiche. Di conseguenza, ti consigliamo di configurare almeno due account obbligatori, Production e Staging.

Inoltre, AWS gli account sono spesso raggruppati in unità organizzative (OUs), a fini di governance e controllo. OUssono progettati per gestire l'applicazione delle politiche su più account.

La nostra raccomandazione è di creare almeno un ambiente di preproduzione (o staging) distinto dall'ambiente di produzione, con controlli e politiche distinti. Gli ambienti di produzione e messa in scena possono essere creati e gestiti come account separati e fatturati come OUs account separati. Inoltre, potresti voler configurare un'unità organizzativa Sandbox per il test del codice.

Usa una struttura ben pianificata per la OUs tua landing zone

AWSControl Tower ne configura alcuni OUs automaticamente. Man mano che i carichi di lavoro e i requisiti aumentano nel tempo, puoi estendere la configurazione originale della landing zone in base alle tue esigenze.

Nota

I nomi forniti negli esempi seguono le convenzioni di AWS denominazione suggerite per la configurazione di un ambiente con più account. AWS Puoi rinominare la tua OUs dopo aver configurato la landing zone, selezionando Modifica nella pagina dei dettagli dell'unità organizzativa.

Raccomandazioni

Dopo che AWS Control Tower ha configurato la prima unità organizzativa necessaria per te, la Security OU, ti consigliamo di crearne un'altra OUs nella tua landing zone.

Si consiglia di consentire a AWS Control Tower di creare almeno un'unità organizzativa aggiuntiva, denominata Sandbox OU. Questa unità organizzativa è destinata agli ambienti di sviluppo software. AWSControl Tower può configurare l'unità organizzativa Sandbox per te durante la creazione della landing zone, se la selezioni.

Altre due unità organizzative OUs consigliate possono essere configurate autonomamente: l'unità organizzativa dell'infrastruttura, per contenere i servizi condivisi e gli account di rete, e un'unità organizzativa per contenere i carichi di lavoro di produzione, denominata Workloads OU. Puoi aggiungerne altre OUs nella tua landing zone tramite la console AWS Control Tower nella pagina Unità organizzative.

Consigliato OUs oltre a quelli impostati automaticamente
  • Infrastructure OU: contiene i servizi condivisi e gli account di rete.

    Nota

    AWSControl Tower non configura l'unità organizzativa dell'infrastruttura per te.

  • Sandbox OU: un'unità organizzativa per lo sviluppo di software. Ad esempio, potrebbe avere un limite di spesa fisso o potrebbe non essere connessa alla rete di produzione.

    Nota

    AWSControl Tower consiglia di configurare l'unità organizzativa Sandbox, ma è facoltativa. Può essere configurato automaticamente come parte della configurazione della landing zone.

  • Workloads OU: contiene account che eseguono i tuoi carichi di lavoro.

    Nota

    AWSControl Tower non configura l'unità organizzativa Workloads per te.

Per ulteriori informazioni, vedere Production starter organization with AWS Control Tower.

Esempio di AWS Control Tower con una struttura di unità organizzativa multi-account completa

AWSControl Tower supporta una gerarchia di unità organizzative annidate, il che significa che è possibile creare una struttura di unità organizzative gerarchica che soddisfi i requisiti dell'organizzazione. Puoi creare un ambiente AWS Control Tower che corrisponda alle linee guida sulla strategia AWS multi-account.

Puoi anche creare una struttura di unità organizzativa più semplice e piatta che funzioni bene e sia in linea con le AWS linee guida per più account. Il fatto che sia possibile creare una struttura di unità organizzative gerarchica non significa che sia necessario farlo.

Il diagramma nella pagina collegata mostra che OUs sono stati creati più elementi fondamentali OUs e altri aggiuntivi. Questi OUs soddisfano le esigenze aggiuntive di un'implementazione più ampia.

Nella OUs colonna Foundational, due OUs sono state aggiunte alla struttura di base:

  • Security_Prod OU: fornisce un'area di sola lettura per le politiche di sicurezza, nonché un'area di controllo di sicurezza infrangibile.

  • Infrastructure OU: è possibile separare l'unità organizzativa dell'infrastruttura, consigliata in precedenza, in dueOUs, Infrastructure_Test (per l'infrastruttura di preproduzione) e Infrastructure_Prod (per l'infrastruttura di produzione).

Nell'OUsarea Aggiuntiva, ne sono state aggiunte molte altre alla struttura di base. OUs I seguenti sono i seguenti che consigliamo OUs di creare man mano che l'ambiente cresce:

  • Workload OU: l'unità organizzativa Workloads, consigliata in precedenza ma facoltativa, è stata suddivisa in dueOUs, Workloads_Test (per carichi di lavoro di preproduzione) e Workloads_Prod (per carichi di lavoro di produzione).

  • PolicyStaging OU: consente agli amministratori di sistema di testare le modifiche apportate ai controlli e alle politiche prima di applicarle completamente.

  • Unità organizzativa sospesa: offre un'ubicazione per gli account che potrebbero essere stati temporaneamente disabilitati.

Informazioni sul Root

The Root non è un'unità organizzativa. È un contenitore per l'account di gestione e per tutti OUs gli account dell'organizzazione. Concettualmente, il Root contiene tutti i. OUs Non può essere eliminato. Non è possibile gestire gli account registrati a livello Root all'interno di AWS Control Tower. Gestisci invece gli account registrati all'interno del tuo. OUs Per un diagramma utile, consulta la documentazione. AWS Organizations