Workloads OU - Account dell'applicazione - AWSGuida 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 future dellaAWS Security Reference Architecture (AWSSRA) partecipando 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 dell'applicazione

L'account dell'applicazione ospita l'infrastruttura e i servizi principali per eseguire e gestire un'applicazione aziendale. L'account dell'applicazione e l'unità organizzativa dei carichi di lavoro soddisfano alcuni obiettivi di sicurezza principali. Innanzitutto, devi creare un account separato per ogni applicazione per fornire confini e controlli tra i carichi di lavoro in modo da evitare problemi legati alla combinazione di ruoli, autorizzazioni, dati e chiavi di crittografia. Si desidera 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, aggiungi un livello di protezione fornendo al team delle operazioni di sicurezza un meccanismo per monitorare e raccogliere i dati di sicurezza. Utilizza un percorso organizzativo e implementazioni locali di servizi di sicurezza degli account (Amazon GuardDuty, AWS Config, AWS Security Hub, Amazon EventBridge, AWS IAM Access Analyzer), configurati e monitorati dal team di sicurezza. Infine, consenti alla tua azienda di impostare i controlli centralmente. È possibile allineare l'account dell'applicazione alla struttura di sicurezza più ampia rendendolo membro dell'unità organizzativa Workloads attraverso la quale eredita le autorizzazioni, i vincoli e i guardrail di servizio appropriati.

Applicazione VPC

Il cloud privato virtuale (VPC) nell'account dell'applicazione 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 l'una verso l'altra. 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, ad esempio il livello dell'applicazione e il livello del database, viene effettuata tramite gruppi di sicurezza VPC, che limitano il traffico a livello di istanza. Per quanto riguarda la resilienza, il carico di lavoro si estende su due o più zone di disponibilità e utilizza due sottoreti per zona.

Considerazione del design
  • Puoi utilizzare Traffic Mirroring per copiare il traffico di rete da un'elastic network interface di istanze EC2. Puoi quindi inviare il traffico alle appliance out-of-band di sicurezza e monitoraggio per l'analisi del contenuto, il monitoraggio delle minacce o la risoluzione dei problemi. Ad esempio, potresti voler monitorare il traffico in uscita dal tuo VPC o il traffico la cui origine è esterna al tuo VPC. In questo caso, eseguirai il mirroring di tutto il traffico ad eccezione del traffico che passa all'interno del tuo VPC e lo invierai a un'unica appliance di monitoraggio. I log di flusso di Amazon VPC non acquisiscono il traffico mirroring; in genere acquisiscono informazioni solo dalle intestazioni dei pacchetti. Il Traffic Mirroring fornisce informazioni più approfondite sul traffico di rete consentendo di analizzare il contenuto effettivo del traffico, incluso il payload. Abilita Traffic Mirroring solo per l'elastic network interface 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 della tua applicazione agli altri servizi AWS. (Nell'account dell'applicazione, 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 VPC a servizi AWS supportati e servizi endpoint VPC con tecnologia AWS PrivateLink senza richiedere un Internet gateway, un dispositivo NAT, una connessione VPN o una connessione AWS Direct Connect. Le istanze nel VPC non richiedono indirizzi IP pubblici per comunicare con altri servizi AWS. Il traffico tra il VPC e gli altri servizi AWS non lascia la 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 colleghi una policy IAM durante la creazione di un endpoint, AWS collega una policy IAM predefinita che consente l'accesso completo al servizio. Una policy endpoint non esclude né sostituisce policy dell'utente IAM o policy specifiche del servizio (ad esempio policy di un bucket S3). Si tratta di una policy IAM separata per controllare l'accesso dall'endpoint al servizio specificato. In questo modo, aggiunge un altro livello di controllo sul quale i responsabili di AWS possono comunicare con risorse o servizi.

Amazon EC2

Le istanze 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 dei siti Web, reverse proxy aperti, vulnerabilità SSRF (server-side request falgery), firewall open layer 3 e NAT. Per ulteriori informazioni, consulta il post del blog Aggiungi protezione in profondità contro firewall aperti, proxy inversi e vulnerabilità SSRF con miglioramenti al servizio metadati dell'istanza EC2.

Utilizza VPC separati (come sottoinsieme dei confini degli account) per isolare l'infrastruttura in base ai segmenti del 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 di Amazon EC2 dal VPC senza inviare traffico sulla rete Internet pubblica, utilizza AWS PrivateLink. Limita l'accesso alle istanze mediante gruppi di sicurezza. Utilizza Log di flusso VPC per monitorare il traffico che raggiunge le istanze. Utilizza Session Manager, una funzionalità di AWS Systems Manager, per accedere alle istanze in remoto anziché aprire porte SSH in entrata e gestire chiavi SSH. Utilizza volumi Amazon Elastic Block Store (Amazon EBS) separati per il sistema operativo e i dati. È possibile configurare il proprio account AWS affinché applichi la crittografia alle nuove copie di volumi e snapshot EBS create. 

Application Load Balancer

Gli Application Load Balancer distribuiscono il traffico di applicazioni in ingresso su più target, ad esempio istanze EC2, in più zone di disponibilità. In AWS SRA, il gruppo target per il load balancer sono le istanze di EC2 dell'applicazione. AWS SRA utilizza listener HTTPS per garantire che il canale di comunicazione sia crittografato. Application Load Balancer utilizza un certificato server per terminare la connessione front-end e decrittografare le richieste provenienti dai client prima di inviarle alle destinazioni.

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

Considerazioni di natura progettuale
  • Per scenari comuni, ad esempio applicazioni strettamente interne che richiedono un certificato TLS privato su Application Load Balancer, puoi utilizzare ACM all'interno di questo account per generare un certificato privato daCA privata AWS. In AWS SRA, la CA privata root di ACM è ospitata nell'account Security Tooling e può essere condivisa con l'intera organizzazione AWS o con account AWS specifici per emettere certificati di entità finale, come descritto in precedenza nella sezione dell'account Security Tooling

  • Per i certificati pubblici, puoi utilizzare ACM per generare tali certificati e gestirli, inclusa la rotazione automatica. In alternativa, puoi generare i tuoi certificati mediante strumenti SSL/TLS per creare una richiesta di firma del certificato (CSR), ottenere il CSR firmato da un'autorità di certificazione (CA) per produrre un certificato, quindi importare il certificato in ACM o caricare il certificato in IAM per l'utilizzo con Application Load Balancer. Se si importa un certificato in ACM, è necessario monitorare la data di scadenza del certificato e rinnovarlo prima che scada. 

  • Per ulteriori livelli di difesa, puoi implementare policy AWS WAF per proteggere l'Application Load Balancer. La presenza di policy all'avanguardia, policy applicative e persino livelli di applicazione delle policy privati o interni aumenta la visibilità delle richieste di comunicazione e garantisce un'applicazione unificata delle policy. Per ulteriori informazioni, consulta il post del blog Deplying Manager Defense Manager for AWS WAF.

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 in cui gli Application Load Balancer forniscono contenuti sicuri tramite TLS. Ciò richiede l'installazione di certificati TLS su Application Load Balancer. Per le applicazioni strettamente interne, i certificati TLS privati possono fornire il 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 si utilizza 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 scoprire e scansionare automaticamente le istanze e le immagini dei container di EC2 che risiedono nel Amazon Elastic Container Registry (Amazon ECR) per vulnerabilità software e esposizione non intenzionale della rete.

Amazon Inspector viene inserito nell'account dell'applicazione, poiché fornisce servizi di gestione delle vulnerabilità alle istanze EC2 di 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 dati dei risultati 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 disattivazione delle scansioni per gli account dei membri e la revisione delle risorse scansionate all'interno dell'organizzazione AWS. 

Considerazione del design

Manager Systems Manager

AWS Systems Manager è un servizio AWS che puoi utilizzare per visualizzare dati operativi da più servizi AWS e automatizzare le attività operative nelle risorse AWS. Con flussi di lavoro e runbook di approvazione automatizzati, puoi lavorare per ridurre gli errori umani 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 (Agente SSM) è 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 consente di mantenere la sicurezza e la conformità eseguendo la scansione di queste istanze gestite e segnalando eventuali violazioni rilevate nelle patch, nella configurazione e nelle policy personalizzate. 

AWS SRA utilizza Session Manager, una funzionalità di Systems Manager, per fornire un'esperienza shell e CLI interattiva basata su browser. 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 inoltre automazione, una funzionalità di Systems Manager, per semplificare le attività più comuni di manutenzione e implementazione delle istanze di 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. Nel servizio di automazione sono disponibili operazioni di automazione basate su un unico clic in modo da semplificare processi complessi come la creazione di versioni finali di Amazon Machine Images (AMIs) e il ripristino di istanze di EC2 irraggiungibili. 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, ad esempio messaggi Amazon EC2, Systems Manager e Amazon S3. Affinché questa comunicazione avvenga, la sottorete richiede la connettività Internet in uscita o la fornitura di endpoint VPC appropriati. L'AWS SRA utilizza 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. È possibile creare best practice per la gestione delle risorse nei runbook e condividere i runbook in più regioni e gruppi AWS. È inoltre possibile limitare i valori consentiti relativamente ai 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 a livello centralizzato l'applicazione di patch e aggiornamenti della sicurezza, correggere gli errori su configurazioni VPC o policy di bucket S3 e gestire le istanze di EC2 a qualsiasi livello. Per maggiori dettagli sull'implementazione, consulta la documentazione di Systems Manager.

Amazon Aurora

In 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 necessità. Aurora è configurata con un cluster di database all'interno di un gruppo di sottoreti DB. 

Considerazione del design
  • Come in molti servizi di database, la sicurezza di Aurora viene gestita su tre livelli. Per controllare chi è in grado di eseguire le operazioni di gestione di Amazon Relational Database Service (Amazon RDS) nei cluster database e nelle istanze database, viene utilizzato IAM. Per controllare i dispositivi e le istanze EC2 che possono aprire le connessioni all'endpoint e alla porta dell'istanza database per i cluster DB Aurora in un VPC, è necessario utilizzare un gruppo di sicurezza VPC. Per autenticare gli accessi e le autorizzazioni per un cluster database Aurora, puoi adottare lo stesso approccio utilizzato con un'istanza database standalone di MySQL o PostgreSQL oppure è possibile utilizzare l'autenticazione del database IAM per l'edizione compatibile con Aurora MySQL. Questo metodo prevede l'autenticazione nel cluster database compatibile con MySQL di Aurora tramite un ruolo IAM e un token di autenticazione.

Simple Storage Service (Amazon S3)

Amazon S3 è un servizio di archiviazione di oggetti che offre scalabilità, disponibilità dei dati, sicurezza e prestazioni tra le migliori del settore. È la spina dorsale dei dati di molte applicazioni basate su AWS e le autorizzazioni e i controlli di sicurezza appropriati sono fondamentali per proteggere i dati sensibili. Per le best practice di sicurezza consigliate per Amazon S3, consulta la documentazione, le conferenze tecniche online e gli approfondimenti nei post del blog. La migliore pratica più importante è 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 dell'applicazione oltre a essere incluso nell'account Security Tooling. Nell'account dell'applicazione, AWS KMS viene utilizzato per gestire le chiavi specifiche delle risorse dell'applicazione. È possibile implementare una separazione dei compiti utilizzando politiche chiave per concedere le autorizzazioni di utilizzo chiave ai ruoli delle applicazioni locali e per limitare le autorizzazioni di gestione e monitoraggio ai custodi chiave. 

Considerazione del design
  • In un modello distribuito, la responsabilità di gestione chiave di AWS KMS spetta al team dell'applicazione. Tuttavia, il 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.

    • Viene ancora utilizzata una chiave KMS in attesa di eliminazione.

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

    • È stata eliminata una chiave KMS.

    • C'è un alto 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 di 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 ulteriore sicurezza archiviando la chiave privata del server Web in CloudHSM. Allo stesso modo, puoi distribuire un HSM di CloudHSM nel VPC in entrata nell'account di rete per archiviare le tue chiavi private e firmare le richieste di certificato se devi agire come autorità di certificazione emittente. 

Considerazione del design
  • Se hai un requisito rigido per lo standard FIPS 140-2 livello 3, puoi anche scegliere di configurare AWS KMS per utilizzare il cluster CloudHSM come archivio chiavi personalizzato anziché utilizzare l'archivio chiavi KMS nativo. In questo modo, trarrai vantaggio dall'integrazione tra AWS KMS e i servizi AWS che crittografano i tuoi dati, mentre sei responsabile degli HSM che proteggono le tue chiavi KMS. Questo combina HSM single-tenant sotto il tuo controllo con la facilità d'uso e 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 il ciclo di vita. È possibile sostituire le credenziali 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, puoi assicurarti che nell'ambiente sia disponibile un segreto con un nome e un riferimento appropriati. Ciò favorisce la coerenza e la riutilizzabilità del codice dell'applicazione in ambienti diversi, richiedendo al contempo meno modifiche e interazioni umane dopo che il codice è stato testato. 

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

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

Come best Manager, puoi monitorare i segreti per registrare eventuali modifiche. Questo ti aiuta a garantire che qualsiasi modifica o utilizzo imprevisto possa essere analizzato. Le modifiche indesiderate possono essere annullate. Secrets Manager attualmente supporta due servizi AWS che consentono di monitorare l'organizzazione e le attività: AWS CloudTrail e AWS Config. CloudTrail acquisisce un sottoinsieme di chiamate API per Secrets Manager come eventi, incluse le chiamate dalla console Secrets Manager e dalle chiamate in codice alle API Secrets Manager. Inoltre, CloudTrail acquisisce altri eventi (non API) che potrebbero avere un impatto a livello di sicurezza e conformità sull'account AWS oppure che potrebbero semplificare le operazioni di risoluzione di problemi operativi. Questi includono alcuni eventi di rotazione segreti e la cancellazione 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 della 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 in prossimità del loro utilizzo. Qui, un profilo di istanza viene 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 i segreti, ad esempio per unirsi al dominio Active Directory o LDAP appropriato e per accedere al database Aurora. 

Considerazione del design
  • 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 in cui un ulteriore livello di controllo potrebbe essere appropriato, 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 bacini d'utenza e i pool di identità. I bacini d'utenza sono directory utente che forniscono opzioni di registrazione e di accesso agli utenti delle tue applicazioni. 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 gli scenari di utilizzo più 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 di accesso degli utenti alle tue app. Amazon Cognito Sync è un servizio e una libreria client AWS che consente la sincronizzazione tra più dispositivi di dati dell'utente relativi all'applicazione.  

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

Considerazioni di natura progettuale
  • Puoi creare una funzione AWS Lambda e attivarla durante l'esecuzione delle operazioni del bacino d'utenza, ad esempio la registrazione, la conferma e l'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 utente più comuni, consulta la documentazione di Amazon Cognito. Amazon Cognito chiama le funzioni Lambda in modo sincrono. 

  • È possibile utilizzare i bacini d'utenza di Amazon Cognito per proteggere piccole applicazioni multi-tenant. Un caso d'uso comune della progettazione multi-tenant è l'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 tenant e il volume previsto siano allineati con le quote di servizio Amazon Cognito correlate. Queste quote vengono condivise tra tutti i tenant dell'applicazione.

Difesa a strati

L'account dell'applicazione 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 puoi vedere come i servizi AWS collaborano 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 all'intera organizzazione AWS in precedenza in questa guida.

  • Il livello più interno sono le istanze EC2. Come accennato in precedenza, le istanze EC2 includono molte funzionalità di sicurezza native di default 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 aiuta a mantenere la sicurezza e la conformità analizzando le istanze gestite per verificarne lo stato delle patch e della configurazione, quindi segnalando e adottando le azioni correttive specificate.

  • Le istanze e il software in esecuzione su queste istanze si trovano 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 cloud privato virtuale e i servizi AWS supportati e per fornire un meccanismo per posizionare le politiche di accesso al confine della rete.

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

  • Infine, oltre all'account dell'applicazione, AWS RAM aiuta a controllare quali risorse vengono condivise con altri account e le politiche di controllo dei servizi IAM consentono di applicare autorizzazioni coerenti in tutta l'organizzazione AWS.