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 multiaccount per la tua zona di destinazione di AWS Control Tower
I clienti di AWS 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 raccomandazioni, denominata strategia multi-account, per aiutarti a utilizzare al meglio le tue AWS risorse, inclusa la zona di atterraggio di AWS Control Tower.
Essenzialmente, AWS Control Tower funge da livello di orchestrazione che funziona con altri AWS servizi, che ti aiutano a implementare i consigli relativi a AWS più account e. AWS AWS Organizations Dopo aver impostato la zona di destinazione, AWS Control Tower continua ad assisterti nel mantenimento delle politiche e delle pratiche di sicurezza aziendali su più account e carichi di lavoro.
La maggior parte delle zone di atterraggio si sviluppa nel tempo. Man mano che aumenta il numero di unità organizzative (OU) e account nella zona di destinazione di AWS Control Tower, puoi estendere la distribuzione di AWS Control Tower in modi che aiutino a organizzare i carichi di lavoro in modo efficace. Questo capitolo fornisce indicazioni prescrittive su come pianificare e configurare la zona di destinazione di AWS 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 Practices for Organizational Units with. AWS Organizations
AWS strategia multi-account: guida alle migliori pratiche
AWS Le best practice 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 e la riduzione del raggio di esplosione 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, 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 il tuo ambiente è ben progettato, puoi gestire più AWS account in modo efficace e, quindi, gestire più carichi di lavoro e ambienti.
AWS Control Tower configura un ambiente ben progettato. Si basa, inoltre, sugli AWS account che aiutano a governare le modifiche all'ambiente che possono estendersi su più account. AWS Organizations
- Definizione di un ambiente ben progettato
-
AWS definisce un ambiente ben architettato quello che inizia con una zona di atterraggio.
AWS Control Tower offre una zona di atterraggio configurata automaticamente. Applica i controlli per garantire la conformità alle linee guida aziendali, su più account nel tuo ambiente.
- Definizione di una zona di atterraggio
-
La zona di atterraggio è un ambiente cloud che offre un punto di partenza consigliato, inclusi account predefiniti, struttura degli account, layout di rete e di sicurezza e così via. Da una zona di atterraggio, puoi distribuire carichi di lavoro che utilizzano le tue soluzioni e applicazioni.
Linee guida per creare un ambiente ben progettato
I tre componenti chiave di un ambiente ben progettato, spiegati nelle sezioni seguenti, sono:
-
Account multipli AWS
-
Unità organizzative multiple (OU)
-
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 con più 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 indicare un singolo account che ospita 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 in un account senza influire sugli altri. Pertanto, le esigenze di sicurezza potrebbero richiedere l'isolamento degli account l'uno dall'altro. Ad esempio, potresti avere team con diversi profili di sicurezza.
-
Molti team: i team hanno responsabilità e esigenze di risorse diverse. Configurando più account, i team non possono interferire tra loro, come potrebbero fare quando utilizzano lo stesso account.
-
Isolamento dei dati: l'isolamento degli archivi di dati in un account aiuta a 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 riservati. Ad esempio, l'isolamento dei dati aiuta a supportare la conformità al Regolamento generale sulla protezione dei dati (GDPR).
-
Processo aziendale: le unità o i prodotti aziendali 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, inclusi elementi come le spese di trasferimento e così via. La strategia multi-account consente di creare voci fatturabili separate tra unità aziendali, team funzionali o singoli utenti.
-
Assegnazione delle quote: le AWS quote sono 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
AWS Control Tower e altri framework di orchestrazione degli account possono apportare modifiche che superano i confini degli account. Pertanto, le AWS best practice riguardano le modifiche tra account, che potenzialmente possono compromettere 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 impostare almeno due account obbligatori, Production e Staging.
Inoltre, AWS gli account sono spesso raggruppati in unità organizzative (OU), ai fini della governance e del controllo. Le unità organizzative sono progettate per gestire l'applicazione delle policy su più account.
Il nostro consiglio è di creare almeno un ambiente di pre-produzione (o staging) distinto dall'ambiente di produzione, con controlli e policy distinti. Gli ambienti di produzione e staging possono essere creati e gestiti come unità organizzative separate e fatturati come account separati. Inoltre, potresti voler configurare un'unità organizzativa Sandbox per il test del codice.
Utilizzate una struttura ben pianificata per le unità organizzative nella vostra zona di atterraggio
AWS Control Tower configura automaticamente alcune unità organizzative. Man mano che i carichi di lavoro e i requisiti si espandono nel tempo, puoi estendere la configurazione originale della zona di destinazione 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 le unità organizzative dopo aver impostato la zona di atterraggio, selezionando Modifica nella pagina dei dettagli dell'unità organizzativa.
Raccomandazioni
Dopo che AWS Control Tower ha impostato la prima unità organizzativa obbligatoria per te, l'unità organizzativa di sicurezza, ti consigliamo di creare alcune unità organizzative aggiuntive nella tua zona di destinazione.
Ti consigliamo di consentire ad AWS Control Tower di creare almeno un'unità organizzativa aggiuntiva, denominata Sandbox OU. Questa unità organizzativa è destinata ai tuoi ambienti di sviluppo software. AWS Control Tower può configurare l'unità organizzativa Sandbox al posto tuo durante la creazione della zona di atterraggio, se la selezioni.
Altre due unità organizzative consigliate che puoi configurare 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 unità organizzativa Workloads. Puoi aggiungere unità organizzative aggiuntive nella tua zona di destinazione tramite la console AWS Control Tower nella pagina delle unità organizzative.
Unità organizzative consigliate oltre a quelle configurate automaticamente
-
Unità organizzativa dell'infrastruttura: contiene i servizi condivisi e gli account di rete.
Nota
AWS Control Tower non configura l'unità organizzativa dell'infrastruttura al posto tuo.
-
Sandbox OU: un'unità organizzativa per lo sviluppo software. Ad esempio, potrebbe avere un limite di spesa fisso o potrebbe non essere connesso alla rete di produzione.
Nota
AWS Control Tower consiglia di configurare l'unità organizzativa Sandbox, ma è facoltativa. Può essere impostato automaticamente come parte della configurazione della zona di atterraggio.
-
Workloads OU: contiene gli account che eseguono i tuoi carichi di lavoro.
Nota
AWS Control Tower non configura l'unità organizzativa dei carichi di lavoro al posto tuo.
Per ulteriori informazioni, consulta Production starter organization with AWS Control Tower.
Esempio di AWS Control Tower con una struttura OU completa con più account
AWS Control Tower supporta una gerarchia di unità organizzative annidate, il che significa che puoi creare una struttura gerarchica di unità organizzative che soddisfi i requisiti dell'organizzazione. Puoi creare un ambiente AWS Control Tower in base alle linee guida strategiche per più AWS account.
Puoi anche creare una struttura dell'unità organizzativa più semplice e piatta che funzioni bene e sia in linea con le linee guida per AWS più account. Il fatto che sia possibile creare una struttura gerarchica dell'unità organizzativa non significa che sia necessario farlo.
-
Per visualizzare un diagramma che mostra un set di unità organizzative di esempio in un ambiente AWS Control Tower espanso e piatto con indicazioni per AWS più account, consulta Example: Workloads in a Flat OU Structure.
-
Per ulteriori informazioni su come funziona AWS Control Tower con strutture OU annidate, consulta. Unità organizzative annidate in AWS Control Tower
-
Per ulteriori informazioni su come AWS Control Tower si allinea alle AWS linee guida, consulta il AWS white paper Organizing Your AWS Environment Using Multiple Accounts.
Il diagramma nella pagina collegata mostra che sono state create più unità organizzative fondamentali e altre unità organizzative aggiuntive. Queste unità organizzative soddisfano le esigenze aggiuntive di un'implementazione più ampia.
Nella colonna Unità organizzative fondamentali, sono state aggiunte due unità organizzative alla struttura di base:
-
Security_Prod Unità organizzativa: fornisce un'area di sola lettura per le politiche di sicurezza, nonché un'area di controllo della sicurezza infrangibile.
-
Unità organizzativa dell'infrastruttura: è possibile separare l'unità organizzativa dell'infrastruttura, consigliata in precedenza, in due unità organizzative (per l'infrastruttura di pre-produzione) e Infrastructure_Test Infrastructure_Prod (per l'infrastruttura di produzione).
Nell'area Unità organizzative aggiuntive, sono state aggiunte diverse unità organizzative alla struttura di base. Le seguenti sono le prossime unità organizzative consigliate da creare man mano che l'ambiente cresce:
-
Workloads OU: l'unità organizzativa Workloads, consigliata in precedenza ma opzionale, è stata suddivisa in due unità organizzative Workloads_Test (per i carichi di lavoro di pre-produzione) e Workloads_Prod (per i carichi di lavoro di produzione).
-
PolicyStaging Unità organizzativa: consente agli amministratori di sistema di testare le modifiche ai controlli e alle policy prima di applicarle completamente.
-
Unità organizzativa sospesa: offre una posizione per gli account che potrebbero essere stati temporaneamente disattivati.
Informazioni su Root
The Root non è un'unità organizzativa. È un contenitore per l'account di gestione e per tutte le unità organizzative e gli account dell'organizzazione. Concettualmente, Root contiene tutte le unità organizzative. 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 delle tue unità organizzative. Per un diagramma utile, consulta la AWS Organizations documentazione.
