Costruire la propria architettura di sicurezza: un approccio graduale

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

L'architettura di sicurezza multi-account consigliata da AWS SRA è un'architettura di base per aiutarti a inserire la sicurezza nelle prime fasi del processo di progettazione. Il percorso verso il cloud di ogni organizzazione è unico. Per far evolvere con successo la vostra architettura di sicurezza cloud, dovete immaginare lo stato di destinazione desiderato, comprendere la vostra attuale preparazione al cloud e adottare un approccio agile per colmare eventuali lacune. L'AWS SRA fornisce uno stato target di riferimento per la tua architettura di sicurezza. La trasformazione incrementale consente di dimostrare rapidamente il valore aggiunto riducendo al minimo la necessità di fare previsioni di ampia portata.

L'AWS Cloud Adoption Framework (AWS CAF) consiglia quattro fasi di trasformazione del cloud iterative e incrementali: Envision, Align, Launch e Scale. Quando entri nella fase di lancio e ti concentri sulla realizzazione di iniziative pilota in produzione, dovresti concentrarti sulla creazione di una solida architettura di sicurezza come base per la fase di scalabilità, in modo da avere la capacità tecnica di migrare e gestire i carichi di lavoro più critici per l'azienda con sicurezza. Questo approccio graduale è applicabile se sei una startup, una piccola o media azienda che desidera espandere la propria attività o un'azienda che sta acquisendo nuove unità aziendali o sta effettuando fusioni e acquisizioni. AWS SRA ti aiuta a raggiungere quell'architettura di base di sicurezza in modo da poter applicare i controlli di sicurezza in modo uniforme a tutta la tua organizzazione in espansione in AWS Organizations. L'architettura di base è composta da più account e servizi AWS. La pianificazione e l'implementazione dovrebbero essere un processo in più fasi in modo da poter eseguire iterazioni su traguardi più piccoli per raggiungere l'obiettivo più grande di configurare l'architettura di sicurezza di base. Questa sezione descrive le fasi tipiche del tuo percorso verso il cloud sulla base di un approccio strutturato. Queste fasi sono in linea con i principi di progettazione della sicurezza di AWS Well-Architected Framework.

Fase 1: creazione dell'unità organizzativa e della struttura degli account

Un prerequisito per una solida base di sicurezza è un'organizzazione e una struttura di account AWS ben progettate. Come spiegato in precedenza nella sezione relativa agli elementi costitutivi SRA di questa guida, disporre di più account AWS aiuta a isolare diverse funzioni aziendali e di sicurezza in base alla progettazione. All'inizio potrebbe sembrare un lavoro inutile, ma è un investimento per aiutarti a scalare in modo rapido e sicuro. Questa sezione spiega anche come utilizzare AWS Organizations per gestire più account AWS e come utilizzare le funzionalità di accesso affidabile e di amministratore delegato per gestire centralmente i servizi AWS su questi account multipli.

Puoi usare AWS Control Tower come descritto in precedenza in questa guida per orchestrare la tua landing zone. Se attualmente utilizzi un singolo account AWS, consulta la guida sulla transizione a più account AWS per migrare a più account AWS il prima possibile. Ad esempio, se la tua startup sta attualmente ideando e prototipando il tuo prodotto in un unico account AWS, dovresti prendere in considerazione l'adozione di una strategia multi-account prima di lanciare il prodotto sul mercato. Allo stesso modo, le organizzazioni di piccole, medie e imprese dovrebbero iniziare a sviluppare la propria strategia multi-account non appena pianificano i carichi di lavoro di produzione iniziali. Inizia con le unità organizzative di base e gli account AWS, quindi aggiungi le unità organizzative e gli account relativi ai carichi di lavoro.

Per consigli sulla struttura degli account e delle unità organizzative AWS oltre a quelli forniti nell'AWS SRA, consulta il post sul blog Strategia multiaccount per le piccole e medie imprese. Mentre stai finalizzando la struttura dell'unità organizzativa e degli account, prendi in considerazione i controlli di sicurezza di alto livello a livello di organizzazione che vorresti applicare utilizzando le policy di controllo dei servizi (SCP).

Considerazioni sulla progettazione

• Non replicate la struttura di rendicontazione della vostra azienda quando progettate l'unità organizzativa e la struttura dei conti. Le unità organizzative devono essere basate sulle funzioni del carico di lavoro e su una serie comune di controlli di sicurezza applicabili ai carichi di lavoro. Non cercate di progettare la struttura completa del vostro account fin dall'inizio. Concentrati sulle unità organizzative di base, quindi aggiungi le unità organizzative per i carichi di lavoro in base alle tue esigenze. È possibile spostare gli account tra le unità organizzative per sperimentare approcci alternativi durante le prime fasi della progettazione. Tuttavia, ciò potrebbe comportare un sovraccarico relativo alla gestione delle autorizzazioni logiche, a seconda degli SCP e delle condizioni IAM basate sull'unità organizzativa e sui percorsi degli account.

Esempio di implementazione

La libreria di codici AWS SRA fornisce un'implementazione di esempio di Account Alternate Contacts. Questa soluzione imposta i contatti alternativi di fatturazione, operazioni e sicurezza per tutti gli account all'interno di un'organizzazione.

Fase 2: Implementazione di una solida base di identità

Non appena hai creato più account AWS, devi consentire ai tuoi team di accedere alle risorse AWS all'interno di tali account. Esistono due categorie generali di gestione delle identità: gestione delle identità e degli accessi della forza lavoro e gestione delle identità e degli accessi dei clienti (CIAM). Workforce IAM è destinato alle organizzazioni in cui dipendenti e carichi di lavoro automatizzati devono accedere ad AWS per svolgere il proprio lavoro. CIAM viene utilizzato quando un'organizzazione ha bisogno di un modo per autenticare gli utenti per fornire l'accesso alle applicazioni dell'organizzazione. È innanzitutto necessaria una strategia IAM per la forza lavoro, in modo che i team possano creare e migrare le applicazioni. Dovresti sempre utilizzare i ruoli IAM anziché gli utenti IAM per fornire l'accesso a utenti umani o automatici. Segui le linee guida di AWS SRA su come utilizzare AWS IAM Identity Center all'interno degli account Org Management e Shared Services per gestire centralmente l'accesso Single Sign-On (SSO) ai tuoi account AWS. La guida fornisce anche considerazioni di progettazione per l'utilizzo della federazione IAM quando non è possibile utilizzare IAM Identity Center.

Quando lavori con i ruoli IAM per fornire l'accesso degli utenti alle risorse AWS, dovresti usare AWS IAM Access Analyzer e IAM access advisor come indicato nelle sezioni Security Tooling and Org Management di questa guida. Questi servizi ti aiutano a ottenere il privilegio minimo, un importante controllo preventivo che ti aiuta a creare un buon livello di sicurezza.

Considerazioni relative alla progettazione

• Per ottenere il privilegio minimo, progettate processi che consentano di esaminare e comprendere regolarmente le relazioni tra le vostre identità e le autorizzazioni necessarie per funzionare correttamente. Man mano che impari, perfeziona tali autorizzazioni e riducile gradualmente al minimo possibile. Per quanto riguarda la scalabilità, questa dovrebbe essere una responsabilità condivisa tra i team di sicurezza centrale e i team addetti alle applicazioni. Utilizzate funzionalità come policy basate sulle risorse, limiti di autorizzazione, controlli di accesso basati sugli attributi e policy di sessione per aiutare i proprietari delle applicazioni a definire un controllo granulare degli accessi.

Esempi di implementazione

La libreria di codici AWS SRA fornisce due implementazioni di esempio che si applicano a questa fase:

• IAM Password Policy imposta la politica relativa alle password degli account per consentire agli utenti di allinearsi agli standard di conformità comuni.

• Access Analyzer configura un analizzatore a livello di organizzazione all'interno di un account amministratore delegato e un analizzatore a livello di account all'interno di ciascun account.

Fase 3: mantenimento della tracciabilità

Quando i tuoi utenti avranno accesso ad AWS e inizieranno a creare, vorrai sapere chi sta facendo cosa, quando e da dove. Avrai anche bisogno di visibilità su potenziali configurazioni errate di sicurezza, minacce o comportamenti imprevisti. Una migliore comprensione delle minacce alla sicurezza consente di dare priorità ai controlli di sicurezza appropriati. Per monitorare l'attività di AWS, segui i consigli di AWS SRA per configurare un percorso organizzativo utilizzando AWS CloudTrail e centralizzando i log all'interno dell'account Log Archive. Per il monitoraggio degli eventi di sicurezza, usa AWS Security Hub, Amazon GuardDuty, AWS Config e AWS Security Lake come indicato nella sezione Account Security Tooling.

Considerazioni sulla progettazione

• Quando inizi a utilizzare nuovi servizi AWS, assicurati di abilitare i log specifici del servizio e di archiviarli come parte del tuo repository centrale di log.

Esempi di implementazione

La libreria di codici AWS SRA fornisce le seguenti implementazioni di esempio che si applicano a questa fase:

• L'organizzazione CloudTrail crea un percorso organizzativo e imposta le impostazioni predefinite per configurare gli eventi relativi ai dati (ad esempio, in Amazon S3 e AWS Lambda) per ridurre la duplicazione di quanto configurato da AWS Control CloudTrail Tower. Questa soluzione offre opzioni per la configurazione degli eventi di gestione.

• L'account di gestione di AWS Config Control Tower consente ad AWS Config nell'account di gestione di monitorare la conformità delle risorse.

• Conformance Pack Organization Rules distribuisce un pacchetto di conformità agli account e alle regioni specifiche all'interno di un'organizzazione.

• AWS Config Aggregator distribuisce un aggregatore delegando l'amministrazione a un account membro diverso dall'account Audit.

• Security Hub Organization configura Security Hub all'interno di un account amministratore delegato per gli account e le regioni governate all'interno dell'organizzazione.

• GuardDuty L'organizzazione GuardDuty si configura all'interno di un account amministratore delegato per gli account all'interno di un'organizzazione.

Fase 4: applicare la sicurezza a tutti i livelli

A questo punto, dovresti avere:

• I controlli di sicurezza appropriati per i tuoi account AWS.

• Una struttura di account e unità organizzative ben definiti con controlli preventivi definiti tramite SCP e ruoli e policy IAM con privilegi minimi.

• La capacità di registrare le attività di AWS utilizzando AWS CloudTrail; di rilevare eventi di sicurezza utilizzando AWS Security Hub GuardDuty, Amazon e AWS Config; e di eseguire analisi avanzate su un data lake creato appositamente per la sicurezza utilizzando Amazon Security Lake.

In questa fase, pianifica di applicare la sicurezza ad altri livelli della tua organizzazione AWS, come descritto nella sezione Applica i servizi di sicurezza all'organizzazione AWS. Puoi creare controlli di sicurezza per il tuo livello di rete utilizzando servizi come AWS WAF, AWS Shield, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM), Amazon CloudFront, Amazon Route 53 e Amazon VPC, come indicato nella sezione Account di rete. Man mano che procedi verso il basso dello stack tecnologico, applica controlli di sicurezza specifici per il tuo carico di lavoro o lo stack di applicazioni. Usa gli endpoint VPC, Amazon Inspector, Amazon Systems Manager, AWS Secrets Manager e Amazon Cognito come indicato nella sezione Account dell'applicazione.

Considerazioni relative alla progettazione

• Quando progettate i controlli di sicurezza DiD (Defense In Depth), prendete in considerazione i fattori di scalabilità. Il tuo team di sicurezza centrale non avrà la larghezza di banda o la piena comprensione del comportamento di ogni applicazione nel tuo ambiente. Consentite ai vostri team applicativi di assumersi la responsabilità e la responsabilità di identificare e progettare i controlli di sicurezza giusti per le loro applicazioni. Il team di sicurezza centrale dovrebbe concentrarsi sulla fornitura degli strumenti e della consulenza giusti per supportare i team addetti alle applicazioni. Per comprendere i meccanismi di scalabilità utilizzati da AWS per adottare un approccio alla sicurezza più orientato a sinistra, consulta il post sul blog How AWS built the Security Guardians program, un meccanismo per distribuire la proprietà della sicurezza.

Esempi di implementazione

La libreria di codici AWS SRA fornisce le seguenti implementazioni di esempio che si applicano a questa fase:

• EC2 Default EBS Encryption configura la crittografia Amazon Elastic Block Store (Amazon EBS) predefinita in Amazon EC2 per utilizzare la chiave AWS KMS predefinita all'interno delle regioni AWS fornite.

• S3 Block Account Public Access configura le impostazioni Block Public Access (BPA) a livello di account in Amazon S3 per gli account all'interno dell'organizzazione.

• Firewall Manager dimostra come configurare una policy di gruppo di sicurezza e policy AWS WAF per gli account all'interno di un'organizzazione.

• Inspector Organization configura Amazon Inspector all'interno di un account amministratore delegato per gli account e le regioni governate all'interno dell'organizzazione.

Fase 5: protezione dei dati in transito e a riposo

I dati aziendali e dei clienti sono risorse preziose che devi proteggere. AWS offre vari servizi e funzionalità di sicurezza per proteggere i dati in movimento e a riposo. Usa AWS CloudFront con AWS Certificate Manager, come indicato nella sezione Account di rete, per proteggere i dati in movimento raccolti su Internet. Per i dati in movimento all'interno delle reti interne, utilizza un Application Load Balancer con AWS Private Certificate Authority, come spiegato nella sezione Account dell'applicazione. AWS KMS e AWS CloudHSM ti aiutano a fornire la gestione delle chiavi crittografiche per proteggere i dati inattivi.

Fase 6: preparazione per gli eventi di sicurezza

Durante la gestione dell'ambiente IT, si verificheranno eventi di sicurezza, ossia cambiamenti nel funzionamento quotidiano dell'ambiente IT che indicano una possibile violazione delle politiche di sicurezza o un fallimento del controllo di sicurezza. Una tracciabilità adeguata è fondamentale per essere consapevoli di un evento di sicurezza il più rapidamente possibile. È altrettanto importante essere preparati a valutare e rispondere a tali eventi di sicurezza in modo da poter intraprendere le azioni appropriate prima che l'evento di sicurezza si aggravi. La preparazione consente di valutare rapidamente un evento di sicurezza per comprenderne il potenziale impatto.

AWS SRA, attraverso la progettazione dell'account Security Tooling e la distribuzione di servizi di sicurezza comuni all'interno di tutti gli account AWS, ti offre la possibilità di rilevare gli eventi di sicurezza all'interno della tua organizzazione AWS. AWS Detective all'interno dell'account Security Tooling ti aiuta a valutare un evento di sicurezza e a identificarne la causa principale. Durante un'indagine di sicurezza, devi essere in grado di esaminare i log pertinenti per registrarli e comprendere l'intero ambito e la tempistica dell'incidente. I registri sono necessari anche per la generazione di avvisi quando si verificano azioni di interesse specifiche.

AWS SRA consiglia un account Log Archive centrale per lo storage immutabile di tutti i log operativi e di sicurezza. Puoi interrogare i log utilizzando CloudWatch Logs Insights per i dati archiviati in gruppi di CloudWatch log e Amazon Athena e OpenSearch Amazon Service per i dati archiviati in Amazon S3. Usa Amazon Security Lake per centralizzare automaticamente i dati di sicurezza provenienti dall'ambiente AWS, dai provider di software as a service (SaaS), dagli ambienti locali e da altri provider cloud. Configura gli abbonati nell'account Security Tooling o in qualsiasi account dedicato, come indicato dall'AWS SRA, per interrogare quei log a fini di indagine.

Considerazioni di natura progettuale

• Dovresti iniziare a prepararti a rilevare e rispondere agli eventi di sicurezza sin dall'inizio del tuo percorso verso il cloud. Per utilizzare meglio le risorse limitate, assegna dati e criticità aziendali alle tue risorse AWS in modo che, quando rilevi un evento di sicurezza, puoi dare priorità al triage e alla risposta in base alla criticità delle risorse coinvolte.

• Le fasi per la creazione di un'architettura di sicurezza cloud, come illustrato in questa sezione, sono di natura sequenziale. Tuttavia, non è necessario attendere il completamento completo di una fase prima di iniziare la fase successiva. Ti consigliamo di adottare un approccio iterativo, in cui inizi a lavorare su più fasi in parallelo e ad evolvere ogni fase man mano che evolvi la tua posizione di sicurezza sul cloud. Man mano che attraverserai le diverse fasi, il tuo design si evolverà. Valuta la possibilità di personalizzare la sequenza suggerita mostrata nel diagramma seguente in base alle tue esigenze particolari.

Esempio di implementazione

La libreria di codici AWS SRA fornisce un'implementazione di esempio di Detective Organization, che abilita automaticamente Detective delegando l'amministrazione a un account (ad esempio, Audit o Security Tooling) e configura Detective per gli account AWS Organizations esistenti e futuri.