Il valore dell'AWS SRA

Influenza il futuro della AWS Security Reference Architecture (AWSSRA) rispondendo a un breve sondaggio.

AWS dispone di un ampio (e crescente) set di servizi relativi alla sicurezza e alla sicurezza. I clienti hanno espresso apprezzamento per le informazioni dettagliate disponibili attraverso la documentazione del nostro servizio, i post di blog, i tutorial, i summit e le conferenze. Ci dicono anche che vogliono comprendere meglio il quadro generale e avere una visione strategica dei servizi di sicurezza AWS. Quando collaboriamo con i clienti per comprendere meglio ciò di cui hanno bisogno, emergono tre priorità:

• I clienti desiderano maggiori informazioni e modelli consigliati su come distribuire, configurare e gestire i servizi di sicurezza AWS 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 questa guida raggruppa i servizi in base ai livelli di protezione allineati alla struttura consigliata del tuo 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 allineare e connettere al meglio AWS Config con altri servizi per svolgere il lavoro pesante delle pipeline di audit e monitoraggio automatizzate?  I clienti chiedono indicazioni su come ogni servizio di sicurezza AWS si basa o supporta altri servizi di sicurezza.

Affrontiamo ognuno di questi aspetti nell'AWS SRA. La prima priorità nell'elenco (dove vanno le cose) è l'obiettivo del diagramma di architettura principale e delle discussioni che lo accompagnano in questo documento. Forniamo un'architettura AWS Organizations consigliata e una account-by-account descrizione di quali servizi vengono utilizzati.  Per iniziare con la seconda priorità dell'elenco (come pensare al set completo di servizi di sicurezza), leggi la sezione Applica i servizi di sicurezza alla tua organizzazione AWS. Questa sezione descrive un modo per raggruppare i servizi di sicurezza in base alla struttura degli elementi della tua organizzazione AWS. Inoltre, queste stesse idee si riflettono nella discussione sull'account Application, che evidenzia come i servizi di sicurezza possono essere gestiti per concentrarsi su determinati livelli dell'account: istanze Amazon Elastic Compute Cloud (Amazon EC2), reti Amazon Virtual Private Cloud (Amazon VPC) e l'account più ampio. Infine, la terza priorità (integrazione dei servizi) si riflette in tutta la guida, in particolare nella discussione dei singoli servizi nelle sezioni approfondite sugli account di questa documentazione e del codice nell'archivio di codici SRA di AWS.

Come usare l'AWS SRA

Esistono diversi modi per utilizzare AWS SRA a seconda della fase del percorso di adozione del cloud. Ecco un elenco di modi per ottenere il massimo delle informazioni dagli asset AWS SRA (diagramma di architettura, linee guida scritte ed esempi di codice).

• Definisci lo stato di destinazione per la tua architettura di sicurezza.

Che tu stia appena iniziando il tuo percorso nel cloud AWS, configurando il tuo primo set di account, o che tu stia pianificando di migliorare un ambiente AWS consolidato, AWS SRA è il punto di partenza per costruire la tua architettura di sicurezza. Inizia con una base completa di struttura degli account e servizi di sicurezza, quindi adattali in base al tuo particolare stack tecnologico, alle competenze, agli obiettivi di sicurezza e ai requisiti di conformità. Se sai che dovrai creare e lanciare altri carichi di lavoro, puoi prendere la tua versione personalizzata di AWS SRA e usarla 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 Building your security architecture — A phased approach.

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

Se disponi già di una progettazione e di un'implementazione di sicurezza, vale la pena dedicare del tempo a confrontare ciò che hai con l'AWS SRA. L'AWS SRA è progettato per essere completo e fornisce una base diagnostica di base per la revisione della propria sicurezza. Laddove i tuoi progetti di sicurezza sono allineati con l'AWS SRA, puoi sentirti più sicuro di seguire le best practice quando usi i servizi AWS. Se i tuoi progetti di sicurezza divergono o addirittura non sono d'accordo con le linee guida dell'AWS SRA, non è necessariamente un segno che stai facendo qualcosa di sbagliato. Invece, questa osservazione ti offre l'opportunità di rivedere il tuo processo decisionale. Esistono motivi aziendali e tecnologici legittimi per cui potresti discostarti dalle best practice di AWS SRA. Forse i vostri particolari requisiti di conformità, regolamentazione o sicurezza dell'organizzazione richiedono configurazioni di servizio specifiche. Oppure, anziché utilizzare i servizi AWS, potresti avere una preferenza in termini di funzionalità per un prodotto dell'AWS Partner Network o un'applicazione personalizzata creata e gestita da te. A volte, durante questa revisione, potresti scoprire che le tue decisioni precedenti sono state prese sulla base di tecnologie precedenti, funzionalità AWS o vincoli aziendali che non sono più validi. Questa è una buona opportunità per rivedere, dare priorità a eventuali aggiornamenti e aggiungerli alla posizione appropriata del backlog tecnico. Qualunque cosa tu scopra durante la valutazione della tua architettura di sicurezza alla luce dell'AWS SRA, troverai 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 la tua architettura di sicurezza. Questi moduli sono descritti in modo più approfondito nella sezione sull'archivio del codice e nell'archivio pubblico. GitHub Non solo consentono agli ingegneri di basarsi su esempi di alta qualità dei modelli contenuti nelle linee guida di AWS SRA, ma incorporano anche controlli di sicurezza consigliati come le policy sulle password di AWS Identity and Access Management (IAM), le politiche di blocco dell'accesso pubblico agli account di Amazon Simple Storage Service (Amazon S3), la crittografia Amazon Elastic Block Store (Amazon EBS) predefinita di Amazon EC2 e integrazione con AWS Control Tower in modo che i controlli vengano applicati o rimossi man mano che nuovi account AWS vengono inseriti o smantellati.

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

Le linee guida e le discussioni nell'AWS SRA includono caratteristiche importanti e considerazioni sulla distribuzione e la gestione di singoli servizi AWS relativi alla sicurezza e alla sicurezza. Una caratteristica di AWS SRA è che fornisce un'introduzione di alto livello all'ampiezza dei servizi di sicurezza AWS e al modo in cui funzionano insieme in un ambiente multi-account. Ciò integra l'analisi approfondita delle caratteristiche e della configurazione di ciascun servizio reperibile in altre fonti. Un esempio di ciò è la discussione su come AWS Security Hub acquisisce i risultati di sicurezza da una varietà di servizi AWS, prodotti partner AWS e persino dalle tue 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 la tua organizzazione ha un gruppo che gestisce tutte le chiavi di crittografia centralmente, ciò influirà su chi è autorizzato a creare le chiavi AWS Key Management Service (AWS KMS) e su quali account tali chiavi verranno gestite. Comprendere le caratteristiche della tua organizzazione, i vari team e le varie responsabilità, ti aiuterà a personalizzare l'AWS SRA per soddisfare al meglio le tue esigenze. 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 consiglia 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 del carico 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 che tutte le parti coinvolte ottengano visibilità su configurazioni, risultati ed eventi. L'AWS SRA può essere uno strumento per identificare e informare queste discussioni.

Principali linee guida di implementazione dell'AWS SRA

Ecco otto punti chiave dell'AWS SRA da tenere a mente durante la progettazione e l'implementazione della sicurezza.   

• AWS Organizations e una strategia multi-account appropriata sono elementi necessari della tua 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.

• D efense-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 struttura di AWS Organizations, il che aiuta a ridurre al minimo l'impatto di un problema: se c'è un problema con un livello, esistono controlli che isolano altre preziose risorse IT. L'AWS SRA dimostra come i diversi servizi AWS funzionano a diversi livelli dello stack tecnologico AWS e come l'uso combinato di tali servizi ti aiuta a ottenere risultati. defense-in-depth Questo defense-in-depth concetto su AWS viene ulteriormente discusso in una sezione successiva con esempi di progettazione mostrati in Account dell'applicazione.

• Usa l'ampia varietà di elementi costitutivi di sicurezza su più servizi e funzionalità AWS per creare un'infrastruttura cloud solida e resiliente. Quando personalizzi l'AWS SRA in base alle tue esigenze particolari, considera non solo la funzione principale dei servizi e delle caratteristiche AWS (ad esempio autenticazione, crittografia, monitoraggio, policy di autorizzazione), ma anche il modo in cui si adattano alla struttura della tua architettura. Una sezione successiva della guida descrive come alcuni servizi funzionano nell'intera organizzazione AWS. Altri servizi funzionano meglio all'interno di un singolo 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.

• Ove possibile (come dettagliato nelle sezioni successive), utilizza i servizi AWS che possono essere distribuiti in ogni account (distribuiti anziché centralizzati) e crea un set coerente di barriere condivise che possono aiutarti 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 (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 (attività dell'API del servizio di registrazione nell'ambiente) e Amazon Macie (classificazione dei dati) come set di base di servizi AWS da distribuire su ogni account AWS.

• Utilizza la funzionalità di amministrazione delegata di AWS Organizations, dove è supportata, come spiegato più avanti nella sezione di amministrazione delegata della guida. Ciò consente di registrare un account membro AWS 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à, per gestire i 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 nelle tue organizzazioni AWS. Utilizzando i servizi AWS che supportano l'aggregazione di più account (e talvolta più regioni), insieme a funzionalità di amministrazione delegata, consenti 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 al carico 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).

• Usa AWS Control Tower per configurare e gestire il tuo ambiente AWS 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. Puoi quindi utilizzare la soluzione Customizations for AWS Control Tower (cFCT) per basalizzare gli account gestiti da AWS Control Tower con controlli di sicurezza, configurazioni di servizio e governance aggiuntivi, come dimostrato dal repository di codici AWS SRA. La funzionalità account factory fornisce automaticamente nuovi account con modelli configurabili basati su configurazioni di account approvate per standardizzare gli account all'interno di AWS Organizations. Puoi anche estendere la governance a un singolo account AWS esistente registrandolo in un'unità organizzativa (OU) già gestita da AWS Control Tower.

• Gli esempi di codice AWS SRA dimostrano come automatizzare l'implementazione di pattern all'interno della guida AWS SRA utilizzando infrastructure as code (IaC). Codificando i pattern, puoi trattare IAc come altre applicazioni della tua 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 distribuiti in un ambiente multi-account AWS Organizations con o senza AWS Control Tower. Le soluzioni in questo repository che richiedono AWS Control Tower sono state distribuite e testate in un ambiente AWS Control Tower utilizzando AWS CloudFormation e Customizations for AWS Control Tower (cFCT). Le soluzioni che non richiedono AWS Control Tower sono state testate in un ambiente AWS Organizations utilizzando AWS CloudFormation. Se non utilizzi AWS Control Tower, puoi utilizzare la soluzione di distribuzione basata su AWS Organizations.