Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Sicurezza del cloud AWS: nozioni di base e migliori prassi

Da tempo, Amazon Web Services, o AWS, è la piattaforma cloud pubblica più utilizzata. Nell’ultimo decennio, si è sviluppata enormemente e ha dato vita a una serie di nuovi servizi (come container gestiti e servizi Kubernetes, solo per citare un paio di esempi) che hanno aggiunto complessità alla sicurezza del cloud AWS.

Allo stesso tempo, la diffusione delle architetture basate su cloud ibrido o multicloud comporta che le aziende che utilizzano AWS si trovino ad affrontare nuove sfide per la sicurezza che non esistevano quando tutto esisteva in un ambiente a cloud singolo.

Di conseguenza, le prassi di sicurezza utilizzate in passato non sono più necessariamente sufficienti a soddisfare i requisiti di sicurezza di AWS. Tenendo ben presente questa sfida, il nostro articolo analizza le nozioni fondamentali alla base della moderna sicurezza di AWS e suggerisce le migliori prassi da adottare per proteggere i workload eseguiti su AWS, comprese le applicazioni basate su container e Kubernetes.

Responsabilità condivisa su AWS

Il primo passo per pianificare la sicurezza di AWS è capire il modello di responsabilità condivisa di AWS. Esattamente come altri importanti cloud pubblici, AWS adotta un concetto di sicurezza condivisa che distingue tra rischi per la sicurezza gestiti da AWS e rischi per la sicurezza che ci si aspetta vengano gestiti dai clienti.

La definizione ufficiale che AWS dà del proprio modello di responsabilità condivisa è meno dettagliata rispetto a quella di altri provider di cloud pubblici. Si riduce al concetto che “AWS è responsabile di proteggere l’infrastruttura che esegue tutti i servizi offerti nel Cloud AWS”, mentre ai clienti spetta proteggere tutto il resto.

Ciò detto, in pratica, la responsabilità condivisa di AWS è teoricamente identica ai modelli adottati da altri cloud pubblici, nonostante il fatto che AWS non descriva le sfumature in modo altrettanto dettagliato. In pratica, i clienti devono ricordare che AWS protegge tutta l’infrastruttura cloud a cui loro non possono accedere o che non possono configurare direttamente, mentre a loro spetta proteggere tutto il resto. Questo avviene anche nel caso di servizi gestiti da AWS, come Elastic Kubernetes Service, o EKS, dove AWS protegge l’infrastruttura cluster ma i clienti devono proteggere l’ambiente Kubernetes e tutte le applicazioni in uso.

Come proteggere gli ambienti AWS

Una volta capito il modello di responsabilità condivisa di AWS, la fase successiva della pianificazione della sicurezza di AWS è individuare e adottare gli strumenti e le pratiche necessari per proteggere gli aspetti dell’ambiente AWS di cui si è responsabili.

Migliori prassi di base per la sicurezza AWS

Per molti aspetti, le migliori prassi che si riferiscono alla sicurezza del cloud AWS non sono diverse da quelle che si applicherebbero a qualunque tipo di ambiente cloud. Esse includono:

  • Utilizzo di IAM nel cloud: Utilizzando lo strumento Identity and Access Management (IAM) di AWS, i clienti possono configurare controlli degli accessi granulari per limitare al minimo necessario i privilegi di accesso per ciascun utente e servizio attivi in un ambiente AWS. I clienti possono anche utilizzare gli strumenti di controllo IAM per rilevare errori di configurazione nelle policy IAM che creano un profilo di sicurezza cloud debole.
  • Utilizzo di VPC cloud: I clienti possono configurare ambienti isolati per i propri workload utilizzando l’Amazon Virtual Private Cloud, o VPC. Creando un VPC, i clienti possono isolare i workload da altri workload (e, in base al modo in cui il VPC è configurato, dall’Internet pubblico) a livello di rete. Sebbene non sia necessario utilizzare un VPC con AWS, è uno strumento molto utile per ridurre l’esposizione alle minacce.
  • Gestione equilibrata degli account cloud: Non vi è alcun limite al numero di risorse cloud che possono essere utilizzate su un unico account AWS. Tuttavia, è una migliore prassi creare account separati per utenti o reparti separati al fine di isolare i workload non collegati a livello di account. Il rovescio della medaglia degli account multipli è che sono più difficili da gestire, ma servizi quali AWS Landing Zone possono aiutare in questa sfida.
  • Crittografia dei dati nel cloud: Oltre a proteggere i dati archiviati nel cloud in servizi quali AWS S3 utilizzando il controllo degli accessi, i clienti dovrebbero abilitare la crittografia predefinita lato server. Dovrebbero applicare la crittografia lato server per proteggere i dati cloud in transito.
  • Sapere dove si trovano i dati sensibili: In ambienti cloud molto grandi, è facile perdere traccia dell’ubicazione dei dati sensibili (ad esempio dati che contengono informazioni di identificazione personale). Assegnare tag alle risorse AWS aiuta ad affrontare questo rischio perché consente ai team di etichettare i workload sensibili. Amazon fornisce inoltre un servizio automatizzato, chiamato Macie, in grado di individuare le informazioni sensibili archiviate sul cloud AWS.

Considerazioni particolari sulla sicurezza di AWS

Oltre alle migliori pratiche standard per la sicurezza del cloud descritte sopra, esistono alcuni aspetti particolari che i team potrebbero voler considerare quando utilizzano AWS:

  • Protezione dei workload cloud legacy: Dal momento che AWS è il cloud pubblico più datato, alcune aziende lo utilizzano già da oltre un decennio. Potrebbero quindi utilizzare alcuni workload “legacy” (ad esempio container distribuiti su ECS, il servizio di orchestrazione in-house che AWS ha lanciato prima di aggiungere l’opzione per i container gestiti da Kubernetes) non necessariamente aggiornati rispetto alle attuali prassi di sicurezza. Se un team utilizza AWS da qualche anno, vale la pena valutare i diversi tipi di servizi in uso per comprendere se le configurazioni applicate quando tali risorse sono state originariamente configurate sono ancora conformi con gli attuali standard di sicurezza cloud.
  • Utilizzare gli strumenti di sicurezza di AWS: AWS offre una scelta di strumenti di sicurezza nativi molto più vasta rispetto ad altri importanti provider di cloud pubblici. Oltre agli strumenti di monitoraggio della sicurezza standard come GuardDuty, AWS offre la sua soluzione CSPM e Trusted Advisor, uno strumento che consiglia le migliori prassi durante la configurazione dei workload. Quindi, AWS dispone di un insieme ampio e complesso di strumenti di sicurezza nativi che i team possono considerare di utilizzare come parte della propria strategia di sicurezza AWS. Allo stesso tempo, tuttavia, è importante comprendere i limiti di tali strumenti, soprattutto per il fatto che supportano quasi esclusivamente gli ambienti AWS (il che significa che non funzionano bene in architetture multicloud e basate su cloud ibrido). Esistono anche soluzioni di sicurezza più generiche, di solito non pensate per tenere conto di tutte le sfumature dei requisiti di sicurezza di ambienti molto specifici, come Kubernetes.
  • Sicurezza del cloud ibrido in AWS: AWS offre uno strumento di cloud ibrido chiamato Outposts che consente ai clienti di eseguire servizi AWS su server che esistono on-premise o in una struttura privata. I server stessi sono forniti da AWS, eppure i clienti si assumono la responsabilità della sicurezza di gran parte della loro infrastruttura, che ricadrebbe invece su AWS nel contesto di un’infrastruttura di proprietà di AWS. Quello che ci preme sottolineare è che, se per esempio si utilizza Outposts per creare una soluzione di cloud ibrido, è importante conoscere bene l’architettura di sicurezza specifica che AWS utilizza per Outposts.

Protezione dei container in AWS

Come altri grandi cloud pubblici, AWS offre diversi modi per eseguire le applicazioni containerizzate. I principali servizi per container offerti da AWS includono:

  • Elastic Container Service, o ECS, un servizio di container gestiti basato su un agente di orchestrazione sviluppato da Amazon.
  • Elastic Kubernetes Service, o EKS, un servizio di container gestiti basato su Kubernetes.
  • Fargate, un servizio che semplifica la distribuzione di container attraverso ECS o EKS, con lo svantaggio che gli utenti hanno minore controllo sull’infrastruttura e sulla configurazione.
  • Lambda, un servizio serverless che è in grado di eseguire applicazioni come immagini di container.

È anche possibile utilizzare direttamente i container sulle macchine virtuali EC2 di AWS se si desidera configurare e gestire in modo autonomo l’infrastruttura, il runtime del container e i livelli di orchestrazione.

In base ai servizi utilizzati per distribuire i container su AWS, l’approccio alla sicurezza varia. Indipendentemente dal server utilizzato, tuttavia, è necessario considerare alcune migliori prassi di base sempre valide per i container in AWS:

  • È necessario scansionare le immagini dei container alla ricerca di vulnerabilità. AWS non scansiona le immagini.
  • Per quanto possibile, bisogna scansionare tutte le configurazioni associate all’ambiente, ad esempio la distribuzione Kubernetes, i file RBAC e le policy AWS IAM, per rilevare problemi che riguardano il profilo di sicurezza del cloud.
  • Inoltre, è consigliabile utilizzare gli strumenti messi a disposizione dall’agente di orchestrazione del container per proteggere l’ambiente e rilevare eventuali violazioni. In ambienti AWS basati su Kubernetes, questo significa utilizzare strumenti quali i registri di controllo di Kubernetes, RBAC e i contesti di protezione.

È anche importante capire in che modo viene applicato e a quali servizi si riferisce il modello di responsabilità condivisa di AWS. Questo argomento presenta una buona dose di complessità e molte sfumature, soprattutto dato che AWS fornisce diversi modi per utilizzare servizi come EKS (possono essere gestiti attraverso Fargate o direttamente attraverso EKS), e ogni approccio ha implicazioni diverse in termini di responsabilità che ricadono sul cliente. La documentazione di AWS è piuttosto esaustiva, quindi è buona norma leggere le policy di sicurezza specifiche per il servizio container in uso.

Conclusione

Per quanto AWS resti la piattaforma di cloud computing dominante sul mercato, la protezione dei workload su AWS resta una preoccupazione fondamentale per le aziende in tutto il mondo. E mentre AWS continua a rendere disponibili nuovi tipi di servizi e ne facilita l’integrazione con architetture ibride e multicloud, la sua sicurezza diventa via via più complessa.

La buona notizia è che, per quanto tempo si dedichi alla comprensione dei requisiti di sicurezza che si applicano ai diversi tipi di servizi cloud e alle diverse configurazioni, gestire la sicurezza di AWS non è difficile. Le informazioni e gli strumenti necessari esistono. Basta solo trovare le risorse giuste.