Il valore della AWS SRA

I clienti desiderano maggiori informazioni e modelli consigliati su come implementare, configurare e gestire i servizi di AWS sicurezza in modo olistico. In quali account e verso quali obiettivi di sicurezza devono essere distribuiti e gestiti i servizi? Esiste un account di sicurezza in cui devono funzionare tutti o la maggior parte dei servizi? In che modo la scelta della sede (unità organizzativa o Account AWS) influisce sugli obiettivi di sicurezza? Di quali compromessi (considerazioni di progettazione) i clienti devono essere consapevoli?

I clienti sono interessati a vedere prospettive diverse per l'organizzazione logica dei numerosi servizi di sicurezza. AWS Oltre alla funzione principale di ogni servizio (ad esempio, servizi di identità o servizi di registrazione), questi punti di vista alternativi aiutano i clienti a pianificare, progettare e implementare la propria architettura di sicurezza. Un esempio condiviso più avanti in questo documento raggruppa i servizi in base ai livelli di protezione allineati alla struttura consigliata dell'ambiente. AWS

I clienti sono alla ricerca di indicazioni ed esempi per integrare i servizi di sicurezza nel modo più efficace. Ad esempio, come dovrebbero allinearsi e connettersi al meglio AWS Config con altri servizi per svolgere il lavoro pesante delle pipeline automatizzate di audit e monitoraggio? I clienti chiedono indicazioni su come ciascun servizio AWS di sicurezza si basa o supporta altri servizi di sicurezza.

Definite lo stato di destinazione per la vostra architettura di sicurezza.

Sia che stiate appena iniziando il vostro Cloud AWS percorso, configurando il primo set di account, sia che stiate pianificando di migliorare un AWS ambiente consolidato, l' AWS SRA è il punto di partenza per costruire la vostra architettura di sicurezza. Iniziate con una base completa di struttura degli account e servizi di sicurezza, quindi adattatela in base al vostro particolare stack tecnologico, alle competenze, agli obiettivi di sicurezza e ai requisiti di conformità. Se sai che dovrai creare e lanciare più carichi di lavoro, puoi prendere la tua versione personalizzata dell' AWS SRA e utilizzarla come base per l'architettura di riferimento per la sicurezza della tua organizzazione. Per scoprire come raggiungere lo stato obiettivo descritto dall' AWS SRA, consulta la sezione Costruire l'architettura di sicurezza: un approccio graduale.  

Rivedi (e rivedi) i progetti e le funzionalità che hai già implementato.

Se disponete già di una progettazione e di un'implementazione di sicurezza, vale la pena dedicare del tempo a confrontare ciò che avete con l' AWS SRA. L' AWS SRA è progettato per essere completo e fornisce una base diagnostica di base per la revisione della propria sicurezza. Se i vostri progetti di sicurezza sono allineati allo AWS SRA, potete essere più sicuri di seguire le migliori pratiche durante l'utilizzo. Servizi AWS Se i vostri progetti di sicurezza divergono o addirittura non concordano con le linee guida dell' AWS SRA, ciò non è necessariamente un segno che state facendo qualcosa di sbagliato. Invece, questa osservazione vi offre l'opportunità di rivedere il vostro processo decisionale. Esistono motivi aziendali e tecnologici legittimi per cui potreste discostarvi dalle migliori pratiche AWS SRA. Forse i vostri particolari requisiti di conformità, regolamentazione o sicurezza dell'organizzazione richiedono configurazioni di servizio specifiche. Oppure, anziché utilizzare Servizi AWS, potreste avere una preferenza in termini di funzionalità per un prodotto di AWS Partner Network o per un'applicazione personalizzata da voi creata e gestita. A volte, durante questa revisione, potresti scoprire che le tue decisioni precedenti sono state prese sulla base di tecnologie, AWS funzionalità o vincoli aziendali obsoleti che non si applicano più. Questa è una buona opportunità per rivedere, dare priorità agli aggiornamenti e aggiungerli alla posizione appropriata del backlog tecnico. Qualunque cosa scoprirete valutando la vostra architettura di sicurezza alla luce dell' AWS SRA, troverete utile documentare tale analisi. Avere quel registro storico delle decisioni e delle loro giustificazioni può aiutare a informare e dare priorità alle decisioni future.

Avvia l'implementazione della tua architettura di sicurezza.

I moduli AWS SRA infrastructure as code (IaC) forniscono un modo rapido e affidabile per iniziare a creare e implementare l'architettura di sicurezza. Questi moduli sono descritti in modo più approfondito nella sezione relativa all'archivio del codice e nell'archivio pubblico. GitHub Non solo consentono agli ingegneri di basarsi su esempi di alta qualità dei modelli delle linee guida AWS SRA, ma incorporano anche controlli di sicurezza consigliati come le policy sulle password IAM, la crittografia Amazon Simple Storage Service (Amazon S3), l'accesso pubblico agli account di blocco, la crittografia Amazon Elastic Block Store ( EC2 Amazon EBS) predefinita di Amazon e l'integrazione AWS Control Tower , in modo che i controlli vengano applicati o rimossi man mano che vengono integrati. o dismesso. Account AWS

Scopri di più sui servizi e le funzionalità di sicurezza. AWS

Le linee guida e le discussioni contenute nell' AWS SRA includono caratteristiche importanti e considerazioni sull'implementazione e la gestione per i singoli servizi relativi AWS alla sicurezza e alla protezione. Una caratteristica dell' AWS SRA è che fornisce un'introduzione di alto livello all'ampiezza dei servizi di AWS sicurezza e al modo in cui interagiscono in un ambiente con più account. Ciò integra l'analisi approfondita delle funzionalità e della configurazione di ciascun servizio disponibile in altre fonti. Un esempio di ciò è la discussione su come AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM) acquisisce i risultati di sicurezza da una varietà di Servizi AWS AWS Partner prodotti e persino dalle vostre applicazioni.

Promuovi una discussione sulla governance organizzativa e sulle responsabilità in materia di sicurezza.

Un elemento importante della progettazione e implementazione di qualsiasi architettura o strategia di sicurezza è capire chi all'interno dell'organizzazione ha quali responsabilità in materia di sicurezza. Ad esempio, la questione di dove aggregare e monitorare i risultati di sicurezza è legata alla questione di quale team sarà responsabile di tale attività. Tutti i risultati dell'organizzazione sono monitorati da un team centrale che deve accedere a un account dedicato agli strumenti di sicurezza? Oppure i singoli team applicativi (o unità aziendali) sono responsabili di determinate attività di monitoraggio e quindi devono accedere a determinati strumenti di avviso e monitoraggio? Come altro esempio, se l'organizzazione ha un gruppo che gestisce tutte le chiavi di crittografia a livello centrale, ciò influirà su chi ha l'autorizzazione a creare AWS Key Management Service (AWS KMS) chiavi e su quali account verranno gestite tali chiavi. Comprendere le caratteristiche della vostra organizzazione, i vari team e le varie responsabilità, vi aiuterà a personalizzare l'SRA per adattarlo al meglio alle vostre esigenze. AWS Al contrario, a volte la discussione sull'architettura di sicurezza diventa lo stimolo per discutere delle responsabilità organizzative esistenti e considerare i potenziali cambiamenti. AWS raccomanda un processo decisionale decentralizzato in cui i team addetti al carico di lavoro siano responsabili della definizione dei controlli di sicurezza in base alle funzioni e ai requisiti dei rispettivi carichi di lavoro. L'obiettivo del team centralizzato di sicurezza e governance è creare un sistema che consenta ai proprietari dei carichi di lavoro di prendere decisioni informate e a tutte le parti di ottenere visibilità sulla configurazione, sui risultati e sugli eventi. L' AWS SRA può essere un veicolo per identificare e informare queste discussioni.

AWS Organizations e un'adeguata strategia multi-account sono elementi necessari della vostra architettura di sicurezza. La corretta separazione di carichi di lavoro, team e funzioni fornisce le basi per la separazione di compiti e strategie. defense-in-depth La guida approfondisce questo aspetto in una sezione successiva.

Defense-in-depth è una considerazione progettuale importante per la scelta dei controlli di sicurezza per l'organizzazione. Ti aiuta a inserire i controlli di sicurezza appropriati a diversi livelli della AWS Organizations struttura, il che aiuta a ridurre al minimo l'impatto di un problema: se c'è un problema con un livello, sono presenti controlli che isolano altre preziose risorse IT. L' AWS SRA dimostra come Servizi AWS funzioni diverse a diversi livelli dello stack AWS tecnologico e come l'utilizzo combinato di tali servizi contribuisca a raggiungere questi obiettivi. defense-in-depth Questo defense-in-depth concetto AWS viene ulteriormente discusso in una sezione successiva con esempi di progettazione mostrati in Account dell'applicazione.

Utilizza l'ampia gamma di elementi costitutivi di sicurezza tra molteplici Servizi AWS funzionalità per creare un'infrastruttura cloud solida e resiliente. Quando personalizzi l' AWS SRA in base alle tue esigenze particolari, considera non solo la funzione Servizi AWS e le caratteristiche principali (ad esempio, autenticazione, crittografia, monitoraggio, politica di autorizzazione), ma anche il modo in cui queste si adattano alla struttura dell'architettura. Una sezione successiva della guida descrive come alcuni servizi funzionano nell'intera AWS organizzazione. Altri servizi funzionano meglio all'interno di un unico account e alcuni sono progettati per concedere o negare l'autorizzazione ai singoli responsabili. Considerare entrambe queste prospettive aiuta a creare un approccio alla sicurezza più flessibile e stratificato.

Laddove possibile (come descritto nelle sezioni successive), sfruttatene la funzionalità Servizi AWS che può essere implementata in ogni account (distribuita anziché centralizzata) e create un set coerente di barriere condivise che possono aiutare a proteggere i carichi di lavoro da usi impropri e contribuire a ridurre l'impatto degli eventi di sicurezza. L' AWS SRA utilizza AWS Security Hub CSPM (monitoraggio centralizzato dei risultati e controlli di conformità), Amazon GuardDuty (rilevamento delle minacce e rilevamento delle anomalie), AWS Config (monitoraggio delle risorse e rilevamento delle modifiche), IAM Access Analyzer (monitoraggio dell'accesso alle risorse), AWS CloudTrail (registrazione dell'attività delle API del servizio nell'ambiente) e Amazon Macie (classificazione dei dati) come set di base da distribuire su tutti. Servizi AWS Account AWS

Utilizza la funzionalità di amministrazione delegata di AWS Organizations, laddove è supportata, come spiegato più avanti nella sezione di amministrazione delegata della guida. Ciò consente di registrare un account AWS membro come amministratore per i servizi supportati. L'amministrazione delegata offre ai diversi team dell'azienda la flessibilità necessaria per utilizzare account separati, in base alle rispettive responsabilità, da gestire Servizi AWS in tutto l'ambiente. Inoltre, l'utilizzo di un amministratore delegato consente di limitare l'accesso e gestire il sovraccarico delle autorizzazioni dell'account di gestione. AWS Organizations

Implementa il monitoraggio, la gestione e la governance centralizzati in tutte le organizzazioni. AWS Utilizzando Servizi AWS questo supporto per l'aggregazione di più account (e talvolta più regioni), insieme alle funzionalità di amministrazione delegata, consentite ai team di progettazione centralizzati di sicurezza, rete e cloud di avere un'ampia visibilità e controllo sulla configurazione di sicurezza e sulla raccolta dei dati appropriate. Inoltre, i dati possono essere restituiti ai team addetti ai carichi di lavoro per consentire loro di prendere decisioni efficaci in materia di sicurezza nelle prime fasi del ciclo di vita dello sviluppo del software (SDLC).

Utilizzali AWS Control Tower per configurare e gestire il tuo AWS ambiente multi-account con l'implementazione di controlli di sicurezza predefiniti per avviare la build dell'architettura di riferimento per la sicurezza. AWS Control Tower fornisce un modello per fornire gestione delle identità, accesso federato agli account, registrazione centralizzata e flussi di lavoro definiti per il provisioning di account aggiuntivi. È quindi possibile utilizzare la soluzione Customizations for AWS Control Tower (cFCT) per definire come base gli account gestiti AWS Control Tower con controlli di sicurezza, configurazioni di servizio e governance aggiuntivi, come dimostrato dal repository di codici SRA. AWS La funzione account factory fornisce automaticamente ai nuovi account modelli configurabili basati su configurazioni di account approvate per standardizzare gli account all'interno delle organizzazioni. AWS È inoltre possibile estendere la governance a un individuo esistente iscrivendolo a un'unità organizzativa (OU) già governata Account AWS da. AWS Control Tower

Gli esempi di codice AWS SRA dimostrano come automatizzare l'implementazione dei modelli all'interno della guida AWS SRA utilizzando l'infrastruttura come codice (IaC). Codificando i pattern, è possibile trattare IaC come altre applicazioni dell'organizzazione e automatizzare i test prima di distribuire il codice. IaC aiuta anche a garantire coerenza e ripetibilità implementando guardrail in più ambienti (ad esempio, SDLC o specifici per regione). Gli esempi di codice SRA possono essere implementati in un ambiente multi-account con o senza. AWS Organizations AWS Control Tower Le soluzioni richieste in questo repository AWS Control Tower sono state implementate e testate in un AWS Control Tower ambiente utilizzando AWS CloudFormation and Customizations for (cFCT). AWS Control Tower Le soluzioni che non richiedono AWS Control Tower sono state testate in un AWS Organizations ambiente utilizzando.AWS CloudFormation Se non si utilizza AWS Control Tower, è possibile utilizzare la soluzione di distribuzione AWS Organizations basata.