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à.
Il valore del AWS SRA
| Influenza il futuro della AWS Security Reference Architecture (AWS SRA) rispondendo a un breve sondaggio |
AWSdispone di un ampio (e crescente) set di servizi di sicurezza e relativi alla sicurezza
-
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 AWS account) 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 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 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 AWS di sicurezza si basa o supporta altri servizi di sicurezza.
Affrontiamo ciascuno di questi nel AWSSRA. La prima priorità nell'elenco (dove vanno le cose) è il fulcro 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 vanno dove. Per iniziare con la seconda priorità dell'elenco (come pensare all'insieme completo di servizi di sicurezza), leggi la sezione Applica i servizi di sicurezza all'intera AWS organizzazione. Questa sezione descrive un modo per raggruppare i servizi di sicurezza in base alla struttura degli elementi AWS dell'organizzazione. Inoltre, queste stesse idee si riflettono nella discussione sull'account dell'applicazione, che evidenzia come i servizi di sicurezza possono essere gestiti per concentrarsi su determinati livelli dell'account: istanze Amazon Elastic Compute Cloud (AmazonEC2), reti Amazon Virtual Private Cloud (AmazonVPC) 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 del AWS SRA codice.
Come usare il AWS SRA
Esistono diversi modi per utilizzarlo AWS SRA a seconda della fase del percorso di adozione del cloud. Ecco un elenco di modi per ottenere il massimo delle informazioni dagli AWS SRA asset (diagramma di architettura, linee guida scritte ed esempi di codice).
-
Definite lo stato di destinazione per la vostra architettura di sicurezza.
Che tu stia appena iniziando il tuo percorso verso il AWS cloud, configurando il tuo primo set di account, o che tu stia pianificando di migliorare un AWS ambiente consolidato, questo AWS SRA è il posto giusto per iniziare a costruire la tua architettura di sicurezza. Inizia con una base completa di struttura degli account e servizi di sicurezza, quindi adattala 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 più carichi di lavoro, puoi prendere la tua versione personalizzata di 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 da AWSSRA, 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 il AWSSRA. AWSSRAÈ 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 ai requisiti AWSSRA, puoi sentirti più sicuro di seguire le migliori pratiche quando utilizzi AWS i servizi. Se i vostri progetti di sicurezza divergono o addirittura non concordano con le linee guida contenute nel documento AWSSRA, 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 AWS SRA migliori pratiche. Forse i vostri particolari requisiti di conformità, regolamentazione o sicurezza dell'organizzazione richiedono configurazioni di servizio specifiche. Oppure, anziché utilizzare AWS i servizi, potreste avere una preferenza in termini di funzionalità per un prodotto del AWS Partner Network o un'applicazione personalizzata creata e gestita da voi. 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 del AWSSRA, 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) offrono 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 sull'archivio del codice e nell'archivio pubblico GitHub
-
Scopri di più sui servizi e le AWS funzionalità di sicurezza.
Le linee guida e le discussioni AWS SRA incluse includono caratteristiche importanti e considerazioni sull'implementazione e la gestione dei singoli servizi relativi AWS alla sicurezza e alla protezione. Una delle sue caratteristiche 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 acquisisce i risultati di sicurezza da una varietà di AWS servizi, prodotti dei AWS partner 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 l'organizzazione ha un gruppo che gestisce tutte le chiavi di crittografia a livello centrale, ciò influirà su chi è autorizzato a creare le chiavi del AWS Key Management Service (AWSKMS) e sugli account in cui tali chiavi verranno gestite. Comprendere le caratteristiche della vostra organizzazione, vale a dire i vari team e le diverse responsabilità, vi aiuterà ad adattarla al meglio alle vostre esigenze. AWS SRA Al contrario, a volte la discussione sull'architettura di sicurezza diventa lo stimolo per discutere delle responsabilità organizzative esistenti e considerare i potenziali cambiamenti. AWSraccomanda 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. AWSSRAPuò essere un veicolo per identificare e informare queste discussioni.
Principali linee guida di implementazione del AWS SRA
Ecco otto punti chiave da tenere AWS SRA a mente durante la progettazione e l'implementazione della sicurezza.
-
AWSOrganizations e una strategia multi-account appropriata sono elementi necessari della vostra architettura di sicurezza. La corretta separazione dei carichi di lavoro, dei team e delle 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 struttura 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. AWSSRADimostra come i diversi AWS servizi funzionino 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 su più AWS servizi e funzionalità per creare un'infrastruttura cloud solida e resiliente. Quando li personalizzi in base AWS SRA alle tue esigenze particolari, considera non solo la funzione principale dei AWS servizi e delle funzionalità (ad esempio, autenticazione, crittografia, monitoraggio, politica di autorizzazione), ma anche il modo in cui si inseriscono nella struttura della tua 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), utilizza AWS servizi che possono essere implementati in ogni account (distribuiti anziché centralizzati) e crea 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. AWSSRAUtilizza 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 (registrazione API dell'attività del servizio nell'ambiente) e Amazon Macie (classificazione dei dati) come set di base di AWS servizi da distribuire su ogni account. AWS
-
Utilizza la funzionalità di amministrazione delegata di AWS Organizations, dove è supportata, come spiegato più avanti nella sezione sull'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 aziendali la flessibilità di utilizzare account separati, in base alle rispettive responsabilità, per gestire AWS i servizi 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 AWS servizi che supportano l'aggregazione di più account (e talvolta più regioni), insieme a 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 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 AWS ambiente multi-account con l'implementazione di controlli di sicurezza predefiniti per avviare la build dell'architettura di riferimento per la sicurezza. AWSControl 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 basalizzare gli account gestiti da AWS Control Tower con controlli di sicurezza, configurazioni di servizio e governance aggiuntivi, come dimostrato dal repository di codice. AWS SRA La funzionalità account factory fornisce automaticamente nuovi account con modelli configurabili basati sulla configurazione degli account approvata per standardizzare gli account all'interno delle OrganizzazioniAWS. È inoltre possibile estendere la governance a un singolo AWS account esistente registrandolo in un'unità organizzativa (OU) già gestita da AWS Control Tower. -
Gli esempi di AWS SRA codice dimostrano come automatizzare l'implementazione dei pattern all'interno della AWS SRA guida 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 ambienti multipli (ad esempio, o specifici di una regione). SDLC Gli esempi di SRA codice possono essere implementati 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 implementate e testate in un ambiente AWS Control Tower utilizzando AWS CloudFormation 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 si utilizza AWS Control Tower, è possibile utilizzare la soluzione di distribuzione AWSbasata sulle organizzazioni .
