Security Essentials

Quando crei un account AWS, inizi con quello che è noto come utente root. Questo è il primo utente AWS che esiste all'interno del tuo account AWS. AWS consiglia di non utilizzare questo account per le operazioni quotidiane poiché ha pieno accesso e controllo dell'account e dovrebbe seguire le best practice consigliate per proteggere l'utente root. Ciò comporta il blocco delle chiavi di accesso dell'utente root, l'utilizzo di una password complessa, l'abilitazione dell'autenticazione a più fattori AWS e la creazione di un utente IAM per accedere al tuo account. A questo account possono essere assegnati i privilegi di amministratore e potrà essere utilizzato per tutte le attività amministrative future.

Successivamente, dovresti assegnare dei contatti di sicurezza alternativi al tuo account. Il contatto di sicurezza alternativo riceverà notifiche relative alla sicurezza, incluse le notifiche dal team AWS Trust & Safety. Puoi scoprire di più sull'importanza di impostare queste informazioni di contatto nelle prime fasi di configurazione del tuo account nel post del blog Aggiornare il contatto di sicurezza alternativo nei tuoi account AWS per notifiche di sicurezza tempestive.

Una volta confermati i contatti per la sicurezza, dovresti considerare le regioni AWS in cui devono essere eseguiti i carichi di lavoro e le regioni in cui non dovrebbero. Puoi quindi bloccare le regioni inutilizzate per assicurarti che nessun carico di lavoro possa essere eseguito da quelle regioni. Questo aiuta a ottimizzare i costi, ma si presta anche alla sicurezza. In che modo? Bloccando le Regioni in cui non prevedi di eseguire carichi di lavoro, puoi concentrare i tuoi sforzi di monitoraggio sulle Regioni che utilizzi attivamente.

A questo punto, hai protetto l'utente root, creato uno o più utenti IAM, assegnato i contatti di sicurezza e bloccato le regioni in cui possono essere eseguiti i carichi di lavoro. Successivamente, consideriamo come gli utenti interagiranno con le risorse AWS. Esistono due metodi principali di interazione: l'interfaccia a riga di comando (AWS CLI) e la Console di gestione AWS. Si consiglia di configurare l'autenticazione unica (SSO) per AWS CLI e la console. Consulta l'articolo Configurazione dell'interfaccia a riga di comando di AWS per utilizzare AWS IAM Identity Center (successore di AWS Single Sign-On) per dettagli su come gestire centralmente l'accesso con AWS IAM Identity Center.

Il passaggio successivo per proteggere il tuo account è configurare gruppi di utenti AWS IAM per controllare l'accesso. Anziché controllare l'accesso dei singoli utenti impostando le policy direttamente sull'utente, è preferibile creare un gruppo, assegnargli le autorizzazioni necessarie e quindi assegnare gli utenti al gruppo. Gli utenti erediteranno le autorizzazioni di quel gruppo. Ciò offre un modo più scalabile per fornire il controllo degli accessi a molti utenti. È importante capire come funzionano IAM e i gruppi IAM perché si estendono su più servizi. IAM è un servizio che interagisce in una certa misura con tutti i servizi AWS, quindi assicurati di dedicare del tempo per familiarizzare con IAM.

Seguire queste pratiche sin dall'inizio ti aiuterà a fornire un accesso sicuro alle tue risorse AWS. Successivamente discuteremo di come proteggere l'infrastruttura che viene creata su AWS.

Man mano che costruisci la tua infrastruttura cloud, inizierai creando un Amazon Virtual Private Cloud (Amazon VPC). Questa è una rete virtuale che viene definita (ne viene creata una predefinita in ogni Regione quando crei il tuo account) e consente di avviare risorse. Un VPC assomiglia a una rete tradizionale in quanto ha un intervallo di indirizzi IP CIDR assegnato ed è suddiviso creando sottoreti. Le sottoreti possono essere utilizzate per garantire l'isolamento per diversi set di risorse e possono essere pubbliche o private. Le sottoreti pubbliche hanno un percorso verso un Internet Gateway, hanno accesso a Internet tramite questo gateway e possono essere raggiunte da Internet se i relativi controlli di accesso lo consentono. Anche le sottoreti private dispongono di una tabella di routing, ma non hanno un percorso verso un Internet Gateway, quindi per impostazione predefinita non possono raggiungere Internet e non possono essere raggiunte da Internet. Per consentire alle risorse di una sottorete privata di accedere a Internet, è necessario un gateway NAT. A livello di sottorete, un elenco di controllo degli accessi alla rete (ACL) consente o nega traffico specifico in entrata o in uscita. Puoi utilizzare l'ACL di rete predefinita per il tuo VPC oppure puoi creare un'ACL di rete personalizzata. Le ACL di rete sono elenchi numerati, elaborati dall'alto verso il basso e sono stateless. Ciò significa che è necessaria una regola ACL di rete in entrata e in uscita per consentire il traffico bidirezionale.

Man mano che distribuisci le risorse EC2 nel tuo VPC, assocerai ad esse un gruppo di sicurezza. Un gruppo di sicurezza controlla il traffico in entrata e in uscita che può raggiungere le risorse EC2. I gruppi di sicurezza sono simili a un firewall, ma invece di utilizzare solo un elenco o un intervallo di indirizzi IP, possono puntare a qualcosa chiamato riferimento alle risorse. Un riferimento a una risorsa è un gruppo specifico che mantiene un elenco aggiornato di indirizzi IP assegnati a ciascuna risorsa del gruppo. Ad esempio, se crei un gruppo con scalabilità automatica per avviare istanze Amazon EC2, a ciascuna istanza viene assegnato un nuovo IP all'avvio. Aggiungendo un gruppo di sicurezza a queste istanze, puoi concedere l'accesso al gruppo di sicurezza del tuo server di database tramite l'ID del gruppo di sicurezza delle istanze EC2 e qualsiasi nuova istanza EC2 avviata avrà accesso al database senza dover aggiungere il proprio indirizzo IP all'elenco consentito.

Le regole dei gruppi di sicurezza sono simili alle ACL di rete perché quando le crei, corrispondono per porta, protocollo e indirizzi, ma sono stateful, ovvero puoi considerarle simili a un firewall stateful. Quando si crea una voce per consentire un tipo specifico di traffico, non è necessario creare una regola che corrisponda al traffico di ritorno; essendo stateful, il traffico di ritorno sarà consentito. Per comprendere meglio come interagiscono i gruppi di sicurezza e gli ACL, questo confronto è utile.

Per aggiungere un ulteriore livello di sicurezza dell'infrastruttura, puoi implementare AWS Network Firewall. Il Firewall di rete è un servizio gestito che implementa la protezione per il tuo Amazon VPC. Fornisce una protezione più precisa dei gruppi di sicurezza in quanto può incorporare il contesto dai flussi di traffico, ad esempio il tracciamento di connessioni e l'identificazione di protocolli, per applicare policy come evitare che il VPC acceda ai domini utilizzando un protocollo non autorizzato. Questo viene fatto attraverso la configurazione di regole Suricata personalizzate. Ad esempio, puoi configurare il Network Firewall per proteggerti dagli attacchi di malware. Facendo un ulteriore passo avanti, puoi implementare un altro servizio gestito, AWS Shield Advanced, per proteggerti dalle minacce DDoS.

Quando crei risorse in AWS, devi fare attenzione a seguire le best practice di sicurezza consigliate per il tipo di risorsa con cui stai lavorando. Per le istanze EC2, la sicurezza inizia controllando l'accesso alla rete alle istanze, ad esempio configurando il VPC e i gruppi di sicurezza. (Per ulteriori informazioni, consulta "Sicurezza di Amazon VPC" nella sezione "Proteggere l'infrastruttura che costruisci".)

Un altro aspetto della sicurezza delle istanze è la gestione delle credenziali utilizzate per connettersi alle istanze. Questo inizia con le autorizzazioni utente IAM assegnate, ma si estende al gruppo assegnato. Ciò fornisce un livello di sicurezza per l'utente che lavora con l'istanza EC2, ma non per l'istanza stessa. È inoltre necessario configurare i ruoli IAM collegati all'istanza e le autorizzazioni associate a tali ruoli. Per accedere a un'istanza EC2, invece di aprire la porta per SSH o configurare un host bastion/jump, dovresti usare EC2 Instance Connect.

È necessario assicurarsi che il sistema operativo guest e il software distribuiti nell'istanza siano aggiornati con eventuali aggiornamenti del sistema operativo e patch di sicurezza. Per maggiori dettagli, visita Sicurezza in Amazon EC2.

La protezione del database è un aspetto importante del tuo approccio alla sicurezza. Come indicato nella sezione sulla sicurezza di Amazon VPC, si consiglia di distribuire i database su una sottorete privata per impedire l'accesso da parti esterne su Internet. AWS offre 15 database dedicati. Ciascuno è protetto in modo diverso, ma tutti condividono quanto segue in comune.

Per accedere a un database, è necessaria una qualche forma di autenticazione. Questo può assumere la forma di nome utente e password, che devono essere ruotati regolarmente. In alternativa, puoi utilizzare Amazon RDS Proxy per sfruttare i ruoli IAM per gestire l'accesso al database per te. Alcuni servizi di database, come Amazon DynamoDB, utilizzano i ruoli IAM per fornire l'accesso, quindi non è necessario gestire personalmente le credenziali.

SSH è uno dei metodi più comuni per gestire le istanze EC2 e Amazon EC2 Instance Connect consente di utilizzare SSH per connettersi alle istanze EC2 utilizzando chiavi SSH monouso direttamente nella console. I seguenti articoli forniscono una panoramica su come abilitare Amazon EC2 Instance Connect e spiegano il caso d'uso tipico. Puoi anche generare chiavi SSH al momento della creazione dell'istanza EC2, scaricarle in locale e usarle per connetterti all'istanza. Tuttavia, ciò significa che è necessario proteggere tali chiavi, assicurarsi che siano archiviate in un luogo a cui non si perda l'accesso e che sia possibile connettersi all'istanza solo da una macchina che abbia quelle chiavi scaricate. EC2 Instance Connect fornisce lo stesso accesso SSH, in modo sicuro, dalla console, su più macchine, in modo semplice da usare.

Una best practice consiste nel limitare l'accesso al database solo ai servizi e all'infrastruttura che richiedono l'accesso. Questo può essere fatto configurando gruppi di sicurezza per le tue istanze RDS, i database Amazon Neptune o per i cluster Amazon Redshift.

Backup e test dei ripristini

Il backup dei dati e l'esecuzione di ripristini frequenti per confermare il corretto funzionamento dei backup dovrebbero essere una priorità. Con AWS Backup, puoi configurare e gestire facilmente i backup per servizi AWS specifici, tra cui Amazon RDS, DynamoDB, Neptune e altri.

Per la sicurezza serverless, dovresti conoscere AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon SQS e IAM. Con la sicurezza serverless, AWS si assume una responsabilità maggiore rispetto al modello di responsabilità condivisa, ma c'è ancora una responsabilità del cliente di cui essere consapevoli. In un ambiente serverless, AWS gestisce l'infrastruttura, l'elaborazione, l'ambiente di esecuzione e il linguaggio di runtime. Il cliente è responsabile del codice funzionale e delle librerie del cliente, della configurazione delle risorse e della gestione delle identità e degli accessi, come mostrato nell'immagine.

Nelle sezioni seguenti, forniamo dettagli sulle pratiche di sicurezza che sono responsabilità del cliente. Per ulteriori dettagli, consulta Sicurezza in AWS Lambda.

AWS Lambda fornisce runtime che eseguono il codice della funzione in un ambiente di esecuzione basato su Amazon Linux. Tuttavia, se con la tua funzione utilizzi librerie aggiuntive, sei responsabile dell'aggiornamento delle librerie. Garantire che le librerie siano aggiornate può aiutarti a mantenere il tuo livello di sicurezza.

AWS Lambda si integra con diverse risorse AWS come Amazon DynamoDB, Amazon EventBridge e Amazon Simple Notification Service (Amazon SNS). Seguire le pratiche di sicurezza consigliate per ogni servizio che utilizzi come parte della tua funzione contribuirà a rafforzare il tuo livello di sicurezza. La documentazione relativa a ciascun servizio fornisce indicazioni aggiuntive.

L'esecuzione di funzioni Lambda può richiedere autorizzazioni e ruoli IAM specifici. Maggiori dettagli sono disponibili nella sezione Autorizzazioni della AWS Lambda Developer Guide.

La tua strategia di sicurezza dovrebbe includere anche il monitoraggio, la registrazione e la gestione della configurazione. Ad esempio, molte organizzazioni abilitano la contabilità dei propri dispositivi tramite il protocollo TACACS+, RADIUS o i log di Active Directory. Ciò aiuta a garantire la creazione di un audit trail per tutte le attività amministrative. All'interno del cloud AWS, ciò è possibile con AWS CloudTrail. CloudTrail permette la verifica, la sicurezza, il monitoraggio di sicurezza e la risoluzione dei problemi operazionali tracciando l'attività degli utenti e l'utilizzo delle API. Il Repository dell'applicazione serverless AWS, che consente a sviluppatori e aziende di trovare, implementare e pubblicare rapidamente applicazioni serverless nel cloud AWS, è integrato con AWS CloudTrail. Per ulteriori dettagli, consulta la AWS Serverless Application Repository Developer Guide.

Dovrai comunque fornire protezione dell'infrastruttura e DoS in una certa misura per i tuoi ambienti serverless, cosa che può essere eseguita con AWS Shield e AWS Shield Avanzato. Il monitoraggio e il rilevamento delle minacce sono descritti in maniera più approfondita nella sezione "Monitoraggio dell'ambiente".

In AWS, i dati vengono archiviati in Amazon S3, che dispone di diversi controlli per proteggere i dati. L'articolo Le 10 migliori pratiche di sicurezza per proteggere i dati in Amazon S3 illustra le tecniche più fondamentali. Queste includono il blocco dei bucket S3 pubblici a livello di organizzazione, l'utilizzo delle policy dei bucket per verificare che tutti gli accessi concessi siano limitati e specifici e la crittografia e la protezione dei dati.

Per la crittografia, Servizio di gestione delle chiavi AWS (AWS KMS) consente di creare e controllare le chiavi utilizzate per crittografare o firmare digitalmente i dati. Se desideri crittografare i tuoi dati su AWS, hai diverse opzioni. Il primo consiste nell'utilizzare la crittografia lato server con chiavi di crittografia gestite da Amazon S3 (SSE-S3). Utilizzando questo metodo, la crittografia avviene dopo l'invio dei dati ad AWS tramite chiavi gestite da AWS.

La seconda opzione consiste nel crittografare i dati una volta che sono in AWS, ma anziché utilizzare chiavi create e gestite da AWS, puoi eseguire la crittografia lato server con le chiavi master dei clienti (CMK) archiviate in AWS KMS (SSE-KMS).

La terza opzione per archiviare dati crittografati in AWS consiste nell'utilizzare la crittografia lato client. Con questo approccio, i dati vengono crittografati prima di essere trasferiti in AWS.

Nell'immagine è riportato un esempio di come la crittografia lato client e la crittografia lato server avvantaggino i clienti.

Le VPN possono comprendere diverse tecnologie. L'idea alla base di una VPN è che i dati in transito mantengano la loro integrità e possano essere scambiati in modo sicuro tra due parti. AWS offre diverse tecnologie che aiutano a proteggere i dati in transito. Uno di questi è AWS PrivateLink, che fornisce connettività privata crittografata tra VPC, servizi AWS e reti locali. Ciò si realizza senza esporre il tuo traffico alla rete Internet pubblica. Anche questa potrebbe essere considerata una rete privata virtuale.

Tuttavia, nella maggior parte dei casi, una discussione sulla VPN ruota attorno all'uso della crittografia dei dati. A seconda delle circostanze, potrebbe essere necessario fornire la crittografia tra un client e le risorse cloud AWS. Questa situazione richiederebbe AWS Client VPN. D'altra parte, potresti passare dati tra il tuo data center o filiale e le tue risorse AWS. Ciò è possibile utilizzando i tunnel IPsec tra le tue risorse on-premise e i nostri Amazon VPC o AWS Transit Gateway. Questa connettività sicura è nota come VPN da sito a sito.

Infine, anche la gestione delle risorse cloud tramite la Console di gestione AWS offre dati in transito crittografati. Sebbene normalmente non si faccia riferimento alla connettività con la console come a una VPN, la sessione utilizza la crittografia TLS (Transport Layer Security). Pertanto, mentre si crea l'architettura sicura le configurazioni vengono mantenute riservate. TLS viene utilizzato anche con l'API AWS.

AWS offre diversi servizi gestiti per agevolare il monitoraggio dell'ambiente, insieme a opzioni self-service. Ad esempio, puoi utilizzare VPC Flow Logs per registrare e visualizzare i flussi di traffico di rete oppure puoi utilizzare Amazon CloudWatch per analizzare i log AWS WAF o persino per creare allarmi per le istanze EC2. Puoi saperne di più su Amazon CloudWatch in questo workshop.

Inoltre, AWS CloudTrail monitora e registra l'attività degli account nell'infrastruttura AWS, offrendoti il controllo su storage, analisi e azioni correttive. Ciò è essenziale per creare un audit trail amministrativo, identificare gli incidenti di sicurezza e risolvere i problemi operativi.

Infine, Amazon GuardDuty può essere utilizzato per il rilevamento delle minacce e persino per fare un ulteriore passo avanti facendo sì che i risultati pubblicati avviino azioni di riparazione automatica all'interno del tuo ambiente AWS.

Affrontando ciascuna di queste aree operative, sarai sulla buona strada per stabilire le funzionalità di sicurezza essenziali per il tuo ambiente cloud.