Workloads OU — Account dell'applicazione - AWS Guida prescrittiva

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à.

Workloads OU — Account dell'applicazione

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

Il diagramma seguente illustra i servizi di sicurezza AWS configurati nell'account dell'applicazione (insieme all'applicazione stessa).


      Servizi di sicurezza per l'account Application

L'account dell'applicazione ospita l'infrastruttura e i servizi principali per l'esecuzione e la manutenzione di un'applicazione aziendale. L'account dell'applicazione e l'unità organizzativa Workloads soddisfano alcuni obiettivi di sicurezza principali. Innanzitutto, crei un account separato per ogni applicazione per fornire limiti e controlli tra i carichi di lavoro in modo da evitare problemi legati alla combinazione di ruoli, autorizzazioni, dati e chiavi di crittografia. Desiderate fornire un contenitore di account separato in cui al team dell'applicazione possano essere concessi ampi diritti per gestire la propria infrastruttura senza influire sugli altri. Successivamente, si aggiunge un livello di protezione fornendo un meccanismo per il team addetto alle operazioni di sicurezza per monitorare e raccogliere i dati di sicurezza. Utilizza un percorso organizzativo e distribuzioni locali di servizi di sicurezza degli account (Amazon, AWS GuardDuty Config, AWS Security Hub, Amazon, EventBridge AWS IAM Access Analyzer), configurati e monitorati dal team di sicurezza. Infine, consentite alla vostra azienda di impostare i controlli a livello centrale. L'account dell'applicazione viene allineato alla struttura di sicurezza più ampia rendendolo membro dell'unità organizzativa Workloads tramite la quale eredita le autorizzazioni di servizio, i vincoli e le barriere appropriati.

Considerazioni progettuali
  • È probabile che nella vostra organizzazione abbiate più di un'applicazione aziendale. L'unità organizzativa Workloads è progettata per ospitare la maggior parte dei carichi di lavoro specifici dell'azienda, inclusi ambienti di produzione e non di produzione. Questi carichi di lavoro possono essere una combinazione di applicazioni commerciali off-the-shelf (COTS) e applicazioni e servizi dati personalizzati sviluppati internamente. Esistono alcuni modelli per organizzare le diverse applicazioni aziendali insieme ai relativi ambienti di sviluppo. Un modello consiste nell'avere più unità organizzative secondarie basate sull'ambiente di sviluppo, ad esempio produzione, staging, test e sviluppo, e nell'utilizzare account AWS secondari separati in quelle unità organizzative che riguardano applicazioni diverse. Un altro modello comune consiste nell'avere unità organizzative secondarie separate per applicazione e quindi utilizzare account AWS secondari separati per i singoli ambienti di sviluppo. L'esatta struttura organizzativa e degli account dipende dalla progettazione dell'applicazione e dai team che gestiscono tali applicazioni. Considerate i controlli di sicurezza che desiderate applicare, siano essi specifici dell'ambiente o dell'applicazione, perché è più semplice implementare tali controlli come SCP sulle unità organizzative. Per ulteriori considerazioni sull'organizzazione delle unità organizzative orientate al carico di lavoro, consulta la sezione Organizzazione delle unità organizzative orientate al carico di lavoro del white paper AWS Organizing Your AWS Environment Using Multiple Accounts.

Applicazione VPC

Il cloud privato virtuale (VPC) nell'account Application richiede sia l'accesso in entrata (per i semplici servizi Web che stai modellando) sia l'accesso in uscita (per le esigenze delle applicazioni o dei servizi AWS). Per impostazione predefinita, le risorse all'interno di un VPC sono instradabili tra loro. Esistono due sottoreti private: una per ospitare le istanze EC2 (livello applicazione) e l'altra per Amazon Aurora (livello database). La segmentazione della rete tra diversi livelli, come il livello dell'applicazione e il livello del database, viene eseguita tramite gruppi di sicurezza VPC, che limitano il traffico a livello di istanza. Per garantire la resilienza, il carico di lavoro si estende su due o più zone di disponibilità e utilizza due sottoreti per zona.

Considerazioni progettuali
  • Puoi utilizzare Traffic Mirroring per copiare il traffico di rete da un'interfaccia di rete elastica di istanze EC2. È quindi possibile inviare il traffico ai dispositivi di out-of-band sicurezza e monitoraggio per l'ispezione dei contenuti, il monitoraggio delle minacce o la risoluzione dei problemi. Ad esempio, potresti voler monitorare il traffico che esce dal tuo VPC o il traffico la cui fonte è esterna al tuo VPC. In questo caso, rispecchierai tutto il traffico ad eccezione del traffico che passa all'interno del tuo VPC e lo invierai a un singolo dispositivo di monitoraggio. I log di flusso di Amazon VPC non acquisiscono traffico speculare; in genere acquisiscono informazioni solo dalle intestazioni dei pacchetti. Traffic Mirroring fornisce una visione più approfondita del traffico di rete consentendoti di analizzare il contenuto effettivo del traffico, incluso il payload. Abilita il mirroring del traffico solo per l'interfaccia di rete elastica delle istanze EC2 che potrebbero funzionare come parte di carichi di lavoro sensibili o per le quali prevedi di aver bisogno di una diagnostica dettagliata in caso di problemi.

Endpoint VPC

Gli endpoint VPC forniscono un altro livello di controllo della sicurezza oltre a scalabilità e affidabilità. Utilizzali per connettere il VPC dell'applicazione ad altri servizi AWS. (Nell'account Application, AWS SRA utilizza endpoint VPC per AWS KMS, AWS Systems Manager e Amazon S3.) Gli endpoint sono dispositivi virtuali. Sono componenti VPC con scalabilità orizzontale, ridondanza e disponibilità elevata. Consentono la comunicazione tra istanze del VPC e servizi senza comportare rischi di disponibilità o vincoli di larghezza di banda sul traffico di rete. Puoi utilizzare un endpoint VPC per connettere privatamente il tuo VPC ai servizi AWS supportati e ai servizi endpoint VPC basati su AWS PrivateLink senza richiedere un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione AWS Direct Connect. Le istanze nel tuo VPC non richiedono indirizzi IP pubblici per comunicare con altri servizi AWS. Il traffico tra il tuo VPC e l'altro servizio AWS non esce dalla rete Amazon. 

Un altro vantaggio dell'utilizzo degli endpoint VPC è l'abilitazione della configurazione delle policy degli endpoint. Una policy endpoint VPC è una policy della risorsa IAM che viene collegata a un endpoint durante la creazione o la modifica dell'endpoint. Se non alleghi una policy IAM quando crei un endpoint, AWS ti allega una policy IAM predefinita che consente l'accesso completo al servizio. Una policy per gli endpoint non sovrascrive o sostituisce le politiche IAM o le politiche specifiche dei servizi (come le policy dei bucket S3). È una policy IAM separata per il controllo dell'accesso dall'endpoint al servizio specificato. In questo modo, aggiunge un altro livello di controllo su come i responsabili di AWS possono comunicare con risorse o servizi.

Amazon EC2

Le istanze Amazon EC2 che compongono la nostra applicazione utilizzano la versione 2 dell'Instance Metadata Service (IMDSv2). IMDSv2 aggiunge protezioni per quattro tipi di vulnerabilità che potrebbero essere utilizzate per tentare di accedere all'IMDS: firewall delle applicazioni per siti Web, proxy inversi aperti, vulnerabilità SSRF (server-side request forgery), firewall open layer 3 e NAT. Per ulteriori informazioni, consulta il post del blog Aggiungi una difesa approfondita contro firewall aperti, proxy inversi e vulnerabilità SSRF con miglioramenti al servizio EC2 Instance Metadata.

Utilizza VPC separati (come sottoinsieme dei confini dell'account) per isolare l'infrastruttura in base ai segmenti di carico di lavoro. Utilizza sottoreti per isolare i livelli dell'applicazione (ad esempio, web, applicazione e database) all'interno di un singolo VPC. Utilizza sottoreti private per le istanze se non devono essere accessibili direttamente da Internet. Per chiamare l'API Amazon EC2 dalla tua sottorete privata senza usare un gateway Internet, usa AWS. PrivateLink Limita l'accesso alle tue istanze utilizzando gruppi di sicurezza. Utilizza Log di flusso VPC per monitorare il traffico che raggiunge le istanze. Usa Session Manager, una funzionalità di AWS Systems Manager, per accedere alle istanze da remoto anziché aprire porte SSH in entrata e gestire le chiavi SSH. Usa volumi Amazon Elastic Block Store (Amazon EBS) separati per il sistema operativo e i tuoi dati. Puoi configurare il tuo account AWS per applicare la crittografia dei nuovi volumi EBS e delle copie di snapshot che crei. 

Esempio di implementazione

La libreria di codici AWS SRA fornisce un'implementazione di esempio della crittografia Amazon EBS predefinita in Amazon EC2. Dimostra come abilitare la crittografia Amazon EBS predefinita a livello di account all'interno di ogni account AWS e regione AWS dell'organizzazione AWS.

Application Load Balancer

Gli Application Load Balancer distribuiscono il traffico delle applicazioni in entrata su più destinazioni, come le istanze EC2, in più zone di disponibilità. Nell'AWS SRA, il gruppo target per il load balancer sono le istanze EC2 dell'applicazione. AWS SRA utilizza listener HTTPS per garantire che il canale di comunicazione sia crittografato. L'Application Load Balancer utilizza un certificato server per interrompere la connessione front-end e quindi per decrittografare le richieste dei client prima di inviarle alle destinazioni.

AWS Certificate Manager (ACM) si integra nativamente con Application Load Balancers e AWS SRA utilizza ACM per generare e gestire i certificati pubblici X.509 (server TLS) necessari. È possibile applicare TLS 1.2 e cifrari avanzati per le connessioni front-end tramite la policy di sicurezza Application Load Balancer. Per ulteriori informazioni, consulta la Guida per l'utente di Elastic Load Balancing

Considerazioni di natura progettuale

CA privata AWS

AWS Private Certificate Authority(CA privata AWS) viene utilizzato nell'account dell'applicazione per generare certificati privati da utilizzare con un Application Load Balancer. È uno scenario comune che Application Load Balancer fornisca contenuti sicuri tramite TLS. Ciò richiede l'installazione di certificati TLS sull'Application Load Balancer. Per le applicazioni strettamente interne, i certificati TLS privati possono fornire un canale sicuro.

In AWS SRA, CA privata AWS è ospitato nell'account Security Tooling ed è condiviso con l'account dell'applicazione utilizzando la RAM AWS. Ciò consente agli sviluppatori di un account dell'applicazione di richiedere un certificato da una CA privata condivisa. La condivisione delle CA all'interno dell'organizzazione o tra account AWS aiuta a ridurre i costi e la complessità della creazione e della gestione di CA duplicate in tutti gli account AWS. Quando utilizzi ACM per emettere certificati privati da una CA condivisa, il certificato viene generato localmente nell'account richiedente e ACM fornisce la gestione e il rinnovo completi del ciclo di vita.

Amazon Inspector

AWS SRA utilizza Amazon Inspector per rilevare e scansionare automaticamente le istanze EC2 e le immagini dei container che risiedono nell'Amazon Elastic Container Registry (Amazon ECR) alla ricerca di vulnerabilità del software ed esposizione involontaria della rete.

Amazon Inspector viene inserito nell'account Application, poiché fornisce servizi di gestione delle vulnerabilità alle istanze EC2 in questo account. Inoltre, Amazon Inspector segnala percorsi di rete indesiderati da e verso le istanze EC2.

Amazon Inspector negli account dei membri è gestito centralmente dall'account amministratore delegato. In AWS SRA, l'account Security Tooling è l'account amministratore delegato. L'account amministratore delegato può gestire i risultati, i dati e determinate impostazioni per i membri dell'organizzazione. Ciò include la visualizzazione dei dettagli aggregati dei risultati per tutti gli account dei membri, l'attivazione o la disabilitazione delle scansioni per gli account dei membri e la revisione delle risorse scansionate all'interno dell'organizzazione AWS. 

Considerazioni progettuali

Amazon Systems Manager

AWS Systems Manager è un servizio AWS che puoi utilizzare per visualizzare i dati operativi da più servizi AWS e automatizzare le attività operative tra le tue risorse AWS. Con i flussi di lavoro e i runbook di approvazione automatizzati, puoi lavorare per ridurre l'errore umano e semplificare le attività di manutenzione e distribuzione sulle risorse AWS.

Oltre a queste funzionalità di automazione generali, Systems Manager supporta una serie di funzionalità di sicurezza preventive, investigative e reattive. AWS Systems Manager Agent (SSM Agent) è un software Amazon che può essere installato e configurato su un'istanza EC2, un server locale o una macchina virtuale (VM). SSM Agent consente a Systems Manager di aggiornare, gestire e configurare tali risorse. Systems Manager ti aiuta a mantenere la sicurezza e la conformità scansionando queste istanze gestite e segnalando (o adottando azioni correttive) su eventuali violazioni rilevate nelle patch, nella configurazione e nelle politiche personalizzate. 

AWS SRA utilizza Session Manager, una funzionalità di Systems Manager, per fornire un'esperienza interattiva basata su browser e CLI. Ciò fornisce una gestione delle istanze sicura e verificabile senza la necessità di aprire porte in entrata, mantenere host bastion o gestire chiavi SSH. AWS SRA utilizza Patch Manager, una funzionalità di Systems Manager, per applicare patch alle istanze EC2 sia per i sistemi operativi che per le applicazioni. 

AWS SRA utilizza anche Automation, una funzionalità di Systems Manager, per semplificare le attività comuni di manutenzione e distribuzione delle istanze Amazon EC2 e di altre risorse AWS. Il servizio di automazione consente di semplificare le attività IT più comuni, ad esempio la modifica dello stato di una o più nodi (utilizzando un'automazione di approvazione) e la gestione dello stato dei nodi in base a una pianificazione. Systems Manager comprende caratteristiche che supportano la gestione di grandi gruppi di istanze mediante l'uso di tag e controlli di velocità che semplificano l'implementazione delle modifiche in base ai limiti da te definiti. L'automazione offre automazioni con un solo clic per semplificare attività complesse come la creazione di Amazon Machine Images (AMI) dorate e il ripristino di istanze EC2 non raggiungibili. Inoltre, puoi migliorare la sicurezza operativa dando ai ruoli IAM l'accesso a runbook specifici per eseguire determinate funzioni, senza concedere direttamente le autorizzazioni a tali ruoli. Ad esempio, se desideri che un ruolo IAM disponga delle autorizzazioni per riavviare istanze EC2 specifiche dopo gli aggiornamenti delle patch, ma non vuoi concedere l'autorizzazione direttamente a quel ruolo, puoi invece creare un runbook di automazione e concedere al ruolo le autorizzazioni per eseguire solo il runbook.

Considerazioni di natura progettuale
  • Per funzionare correttamente Systems Manager si basa sui metadati dell'istanza EC2. Systems Manager può accedere ai metadati dell'istanza utilizzando la versione 1 o la versione 2 dell'Instance Metadata Service (IMDSv1 e IMDSv2). 

  • SSM Agent deve comunicare con diversi servizi e risorse AWS come messaggi Amazon EC2, Systems Manager e Amazon S3. Affinché questa comunicazione avvenga, la sottorete richiede la connettività Internet in uscita o il provisioning di endpoint VPC appropriati. L'AWS SRA utilizza gli endpoint VPC per l'agente SSM per stabilire percorsi di rete privati verso vari servizi AWS. 

  • L'utilizzo dell'automazione consente di condividere le best practice con tutta l'organizzazione. Puoi creare best practice per la gestione delle risorse nei runbook e condividere i runbook tra regioni e gruppi AWS. Puoi anche limitare i valori consentiti per i parametri del runbook. Per questi casi d'uso, potrebbe essere necessario creare runbook di automazione in un account centrale come Security Tooling o Shared Services e condividerli con il resto dell'organizzazione AWS. I casi d'uso più comuni includono la capacità di implementare centralmente patch e aggiornamenti di sicurezza, rimediare alla deriva dalle configurazioni VPC o dalle policy dei bucket S3 e gestire le istanze EC2 su larga scala. Per i dettagli sull'implementazione, vedere la documentazione di Systems Manager.

Amazon Aurora

Nell'AWS SRA, Amazon Aurora e Amazon S3 costituiscono il livello logico dei dati. Aurora è un motore di database relazionale completamente gestito compatibile con MySQL e PostgreSQL. Un'applicazione in esecuzione sulle istanze EC2 comunica con Aurora e Amazon S3 in base alle esigenze. Aurora è configurata con un cluster di database all'interno di un sottogruppo di database. 

Considerazioni progettuali
  • Come in molti servizi di database, la sicurezza per Aurora è gestita su tre livelli. Per controllare chi può eseguire azioni di gestione di Amazon Relational Database Service (Amazon RDS) su cluster e istanze DB Aurora, utilizzi IAM. Per controllare quali dispositivi e istanze EC2 possono aprire connessioni all'endpoint e alla porta del cluster dell'istanza DB per i cluster Aurora DB in un VPC, si utilizza un gruppo di sicurezza VPC. Per autenticare gli accessi e le autorizzazioni per un cluster Aurora DB, puoi adottare lo stesso approccio di un'istanza DB autonoma di MySQL o PostgreSQL oppure puoi utilizzare l'autenticazione del database IAM per Aurora MySQL Compatible Edition. Con quest'ultimo approccio, ti autentichi nel tuo cluster DB Aurora compatibile con MySQL utilizzando un ruolo IAM e un token di autenticazione.

Amazon S3

Amazon S3 è un servizio di storage di oggetti che offre scalabilità, disponibilità dei dati, sicurezza e prestazioni all'avanguardia nel settore. È la spina dorsale dei dati di molte applicazioni basate su AWS e autorizzazioni e controlli di sicurezza appropriati sono fondamentali per proteggere i dati sensibili. Per le best practice di sicurezza consigliate per Amazon S3, consulta la documentazione, i talk tecnici online e approfondimenti nei post del blog. La best practice più importante consiste nel bloccare l'accesso eccessivamente permissivo (in particolare l'accesso pubblico) ai bucket S3.

AWS KMS

L'AWS SRA illustra il modello di distribuzione consigliato per la gestione delle chiavi, in cui la chiave KMS risiede nello stesso account AWS della risorsa da crittografare. Per questo motivo, AWS KMS viene utilizzato nell'account Application oltre ad essere incluso nell'account Security Tooling. Nell'account dell'applicazione, AWS KMS viene utilizzato per gestire chiavi specifiche per le risorse dell'applicazione. Puoi implementare una separazione delle mansioni utilizzando politiche chiave per concedere le autorizzazioni di utilizzo delle chiavi ai ruoli delle applicazioni locali e limitare le autorizzazioni di gestione e monitoraggio ai tuoi custodi chiave. 

Considerazioni sulla progettazione
  • In un modello distribuito, la responsabilità della gestione delle chiavi di AWS KMS spetta al team dell'applicazione. Tuttavia, il tuo team di sicurezza centrale può essere responsabile della governance e del monitoraggio di importanti eventi crittografici come i seguenti:

    • Il materiale chiave importato in una chiave KMS si avvicina alla data di scadenza.

    • Il materiale chiave di una chiave KMS è stato ruotato automaticamente.

    • È stata eliminata una chiave KMS.

    • Esiste un elevato tasso di errori di decrittografia.

AWS CloudHSM

AWS CloudHSM fornisce moduli di sicurezza hardware gestiti (HSM) nel cloud AWS. Ti consente di generare e utilizzare le tue chiavi di crittografia su AWS utilizzando HSM convalidati FIPS 140-2 livello 3 a cui controlli l'accesso. Puoi usare CloudHSM per scaricare l'elaborazione SSL/TLS per i tuoi server web. Ciò riduce il carico sul server Web e fornisce una maggiore sicurezza archiviando la chiave privata del server Web in CloudHSM. Allo stesso modo, puoi implementare un HSM di CloudHSM nell'account VPC in entrata nell'account di rete per archiviare le tue chiavi private e firmare le richieste di certificati se devi agire come autorità di certificazione emittente. 

Considerazioni sulla progettazione
  • Se hai un requisito rigoroso per FIPS 140-2 livello 3, puoi anche scegliere di configurare AWS KMS per utilizzare il cluster CloudHSM come archivio di chiavi personalizzato anziché utilizzare l'archivio di chiavi KMS nativo. In questo modo, trarrai vantaggio dall'integrazione tra AWS KMS e i servizi AWS che crittografano i tuoi dati, pur essendo responsabile degli HSM che proteggono le tue chiavi KMS. Questo combina gli HSM single-tenant sotto il tuo controllo con la facilità d'uso e l'integrazione di AWS KMS. Per gestire l'infrastruttura CloudHSM, è necessario utilizzare un'infrastruttura a chiave pubblica (PKI) e disporre di un team con esperienza nella gestione degli HSM.

AWS Secrets Manager

AWS Secrets Manager ti aiuta a proteggere le credenziali (segreti) di cui hai bisogno per accedere alle tue applicazioni, servizi e risorse IT. Il servizio consente di ruotare, gestire e recuperare in modo efficiente le credenziali del database, le chiavi API e altri segreti durante tutto il loro ciclo di vita. Puoi sostituire le credenziali codificate nel codice con una chiamata API a Secrets Manager per recuperare il segreto a livello di codice. Questo aiuta a garantire che il segreto non possa essere compromesso da qualcuno che sta esaminando il codice, perché il segreto non esiste più nel codice. Inoltre, Secrets Manager consente di spostare le applicazioni tra ambienti (sviluppo, preproduzione, produzione). Invece di modificare il codice, potete assicurarvi che nell'ambiente sia disponibile un segreto denominato e referenziato in modo appropriato. Ciò favorisce la coerenza e la riutilizzabilità del codice applicativo in diversi ambienti, richiedendo al contempo un minor numero di modifiche e interazioni umane dopo il test del codice. 

Con Secrets Manager, puoi gestire l'accesso ai segreti utilizzando policy IAM granulari e politiche basate sulle risorse. Puoi contribuire a proteggere i segreti crittografandoli con chiavi di crittografia gestite utilizzando AWS KMS. Secrets Manager si integra anche con i servizi di registrazione e monitoraggio AWS per il controllo centralizzato. 

Secrets Manager utilizza la crittografia a busta con chiavi AWS KMS e chiavi dati per proteggere ogni valore segreto. Quando crei un segreto, puoi scegliere qualsiasi chiave gestita dal cliente simmetrica nell'account e nella regione AWS oppure puoi utilizzare la chiave gestita AWS per Secrets Manager. 

Come best practice, puoi monitorare i tuoi segreti per registrare eventuali modifiche. Questo vi aiuta a garantire che eventuali utilizzi o modifiche imprevisti possano essere esaminati. Le modifiche indesiderate possono essere annullate. Secrets Manager attualmente supporta due servizi AWS che consentono di monitorare l'organizzazione e l'attività: AWS CloudTrail e AWS Config. CloudTrail acquisisce tutte le chiamate API per Secrets Manager come eventi, incluse le chiamate dalla console Secrets Manager e le chiamate di codice alle API di Secrets Manager. Inoltre, CloudTrail acquisisce altri eventi correlati (non API) che potrebbero avere un impatto sulla sicurezza o sulla conformità sul tuo account AWS o che potrebbero aiutarti a risolvere problemi operativi. Questi includono alcuni eventi di rotazione dei segreti e l'eliminazione di versioni segrete. AWS Config può fornire controlli investigativi tracciando e monitorando le modifiche ai segreti in Secrets Manager. Queste modifiche includono la descrizione di un segreto, la configurazione di rotazione, i tag e la relazione con altre fonti AWS come la chiave di crittografia KMS o le funzioni AWS Lambda utilizzate per la rotazione segreta. Puoi anche configurare Amazon EventBridge, che riceve notifiche di modifica della configurazione e della conformità da AWS Config, per indirizzare particolari eventi segreti per azioni di notifica o correzione. 

In AWS SRA, Secrets Manager si trova nell'account dell'applicazione per supportare i casi d'uso delle applicazioni locali e per gestire i segreti vicini al loro utilizzo. Qui, un profilo di istanza è collegato alle istanze EC2 nell'account dell'applicazione. È quindi possibile configurare segreti separati in Secrets Manager per consentire a quel profilo di istanza di recuperare segreti, ad esempio per unirsi al dominio Active Directory o LDAP appropriato e accedere al database Aurora. Secrets Manager si integra con Amazon RDS per gestire le credenziali degli utenti quando crei, modifichi o ripristini un'istanza database Amazon RDS o un cluster DB Multi-AZ. Ciò consente di gestire la creazione e la rotazione delle chiavi e sostituisce le credenziali codificate nel codice con chiamate API programmatiche a Secrets Manager.

Considerazioni sulla progettazione
  • In generale, configura e gestisci Secrets Manager nell'account più vicino a dove verranno utilizzati i segreti. Questo approccio sfrutta la conoscenza locale del caso d'uso e offre velocità e flessibilità ai team di sviluppo delle applicazioni. Per informazioni strettamente controllate che potrebbero richiedere un ulteriore livello di controllo, i segreti possono essere gestiti centralmente da Secrets Manager nell'account Security Tooling.

Amazon Cognito

Amazon Cognito ti consente di aggiungere la registrazione, l'accesso e il controllo degli accessi degli utenti alle tue app Web e mobili in modo rapido ed efficiente. Amazon Cognito è scalabile fino a milioni di utenti e supporta l'accesso con provider di identità social, come Apple, Facebook, Google e Amazon, e provider di identità aziendali tramite SAML 2.0 e OpenID Connect. I due componenti principali di Amazon Cognito sono i pool di utenti e i pool di identità. I pool di utenti sono directory di utenti che forniscono opzioni di registrazione e accesso per gli utenti dell'applicazione. I pool di identità consentono di concedere agli utenti l'accesso ad altri servizi AWS. È possibile usare i pool di identità e i bacini d'utenza separatamente o insieme. Per scenari di utilizzo comuni, consulta la documentazione di Amazon Cognito.

Amazon Cognito offre un'interfaccia utente integrata e personalizzabile per la registrazione e l'accesso degli utenti. Puoi utilizzare Android, iOS e JavaScript SDK per Amazon Cognito per aggiungere pagine di registrazione e accesso degli utenti alle tue app. Amazon Cognito Sync è un servizio AWS e una libreria client che consente la sincronizzazione tra dispositivi dei dati utente relativi alle applicazioni.  

Amazon Cognito supporta l'autenticazione e la crittografia a più fattori dei dati inattivi e dei dati in transito. I pool di utenti di Amazon Cognito forniscono funzionalità di sicurezza avanzate per proteggere l'accesso agli account nell'applicazione. Queste funzionalità di sicurezza avanzate forniscono autenticazione adattiva basata sul rischio e protezione dall'uso di credenziali compromesse.  

Considerazioni di natura progettuale
  • Puoi creare una funzione AWS Lambda e poi attivarla durante le operazioni del pool di utenti come registrazione, conferma e accesso (autenticazione) con un trigger AWS Lambda. Puoi aggiungere i problemi di autenticazione, migrare gli utenti e personalizzare i messaggi di verifica. Per le operazioni e il flusso di utenti comuni, consulta la documentazione di Amazon Cognito. Amazon Cognito chiama le funzioni Lambda in modo sincrono. 

  • Puoi utilizzare i pool di utenti di Amazon Cognito per proteggere piccole applicazioni multi-tenant. Un caso d'uso comune della progettazione multi-tenant consiste nell'esecuzione di carichi di lavoro per supportare il test di più versioni di un'applicazione. La progettazione multi-tenant è utile anche per testare una singola applicazione con diversi set di dati che consente l'uso completo delle risorse del cluster. Tuttavia, assicurati che il numero di inquilini e il volume previsto siano in linea con le relative quote del servizio Amazon Cognito. Queste quote vengono condivise tra tutti i tenant dell'applicazione.

Autorizzazioni verificate da Amazon

Amazon Verified Permissions è un servizio scalabile di gestione delle autorizzazioni e di autorizzazione dettagliato per le applicazioni che crei. Gli sviluppatori e gli amministratori possono utilizzare Cedar, un linguaggio di policy open source creato appositamente e incentrato sulla sicurezza, con ruoli e attributi per definire controlli di accesso più granulari, sensibili al contesto e basati su policy. Gli sviluppatori possono creare applicazioni più sicure più rapidamente esternalizzando le autorizzazioni e centralizzando la gestione e l'amministrazione delle policy. Le autorizzazioni verificate includono definizioni di schemi, formulazioni di policy, grammatica e ragionamento automatico che si estendono a milioni di autorizzazioni, in modo da poter applicare i principi di negazione predefinita e privilegio minimo. Il servizio include anche uno strumento di simulazione di valutazione per aiutarvi a testare le vostre decisioni di autorizzazione e le politiche relative agli autori. Queste funzionalità facilitano l'implementazione di un modello di autorizzazione approfondito e granulare per supportare gli obiettivi zero-trust. Verified Permissions centralizza le autorizzazioni in un archivio di policy e aiuta gli sviluppatori a utilizzarle per autorizzare le azioni degli utenti all'interno delle loro applicazioni.

È possibile connettere l'applicazione al servizio tramite l'API per autorizzare le richieste di accesso degli utenti. Per ogni richiesta di autorizzazione, il servizio recupera le politiche pertinenti e le valuta per determinare se un utente è autorizzato a intraprendere un'azione su una risorsa, in base a input di contesto quali utenti, ruoli, appartenenza al gruppo e attributi. Puoi configurare e connettere Verified Permissions per inviare i log di gestione delle policy e di autorizzazione ad AWS. CloudTrail Se utilizzi Amazon Cognito come archivio di identità, puoi effettuare l'integrazione con Autorizzazioni verificate e utilizzare l'ID e i token di accesso che Amazon Cognito restituisce nelle decisioni di autorizzazione delle tue applicazioni. Fornisci token Amazon Cognito a Verified Permissions, che utilizza gli attributi contenuti nei token per rappresentare il principale e identificare i diritti del principale. Per ulteriori informazioni su questa integrazione, consulta il post sul blog di AWS Semplificare l'autorizzazione granulare con Amazon Verified Permissions e Amazon Cognito.

Verified Permissions ti aiuta a definire il controllo degli accessi basato su policy (PBAC). PBAC è un modello di controllo degli accessi che utilizza le autorizzazioni espresse sotto forma di policy per determinare chi può accedere a quali risorse in un'applicazione. PBAC unisce il controllo degli accessi basato sui ruoli (RBAC) e il controllo degli accessi basato sugli attributi (ABAC), dando vita a un modello di controllo degli accessi più potente e flessibile. Per ulteriori informazioni su PBAC e su come progettare un modello di autorizzazione utilizzando Verified Permissions, consulta il post sul blog di AWS Il controllo degli accessi basato su policy nello sviluppo di applicazioni con Amazon Verified Permissions.

In AWS SRA, Verified Permissions si trova nell'account dell'applicazione per supportare la gestione delle autorizzazioni per le applicazioni attraverso la sua integrazione con Amazon Cognito.

Difesa a più livelli

L'account Application offre l'opportunità di illustrare i principi di difesa a più livelli abilitati da AWS. Considera la sicurezza delle istanze EC2 che costituiscono il nucleo di una semplice applicazione di esempio rappresentata nell'AWS SRA e potrai vedere il modo in cui i servizi AWS interagiscono in una difesa a più livelli. Questo approccio è in linea con la visione strutturale dei servizi di sicurezza AWS, come descritto nella sezione Applica i servizi di sicurezza alla tua organizzazione AWS all'inizio di questa guida.

  • Il livello più interno sono le istanze EC2. Come accennato in precedenza, le istanze EC2 includono molte funzionalità di sicurezza native per impostazione predefinita o come opzioni. Gli esempi includono IMDSv2, il sistema Nitro e la crittografia dello storage Amazon EBS.

  • Il secondo livello di protezione si concentra sul sistema operativo e sul software in esecuzione sulle istanze EC2. Servizi come Amazon Inspector e AWS Systems Manager consentono di monitorare, generare report e intraprendere azioni correttive su queste configurazioni. Inspector monitora il software alla ricerca di vulnerabilità e Systems Manager ti aiuta a mantenere la sicurezza e la conformità scansionando le istanze gestite per verificarne lo stato di patch e configurazione, quindi segnalando e adottando le azioni correttive specificate.

  • Le istanze e il software in esecuzione su queste istanze si integrano nell'infrastruttura di rete AWS. Oltre a utilizzare le funzionalità di sicurezza di Amazon VPC, AWS SRA utilizza anche endpoint VPC per fornire connettività privata tra il VPC e i servizi AWS supportati e per fornire un meccanismo per posizionare le politiche di accesso ai confini della rete.

  • L'attività e la configurazione delle istanze EC2, del software, della rete e dei ruoli e delle risorse IAM sono ulteriormente monitorate da servizi incentrati sugli account AWS come AWS Security Hub, Amazon, AWS, AWS CloudTrail Config, GuardDuty AWS IAM Access Analyzer e Amazon Macie.

  • Infine, oltre all'account Application, AWS RAM aiuta a controllare quali risorse sono condivise con altri account e le policy di controllo dei servizi IAM ti aiutano a far rispettare autorizzazioni coerenti in tutta l'organizzazione AWS.