Lo sviluppo è andato decisamente nella direzione delle applicazioni cosiddette cloud-native, cioè quelle che fanno un uso intensivo, per non dire esclusivo, di alcuni componenti chiave delle moderne infrastrutture cloud: virtualizzazione via container, API e microservizi. La parola chiave in questo senso è elasticità: per gestire un volume imprevedibile di dati e richieste di servizio provenienti da ovunque sulla rete, un'applicazione spesso non può essere monolitica. Va scomposta in un insieme sinergico di elementi - distribuiti potenzialmente ovunque - che devono operare in sincronia.

Fin qui tutto bene, il problema è che in questo tipo di scenari molti concetti tradizionali della sicurezza non sono applicabili. Resta importante seguire le best practice della protezione dei sistemi ma bisogna anche pensare a tecniche più specifiche di microsegmentazione, monitoraggio delle risorse, isolamento, evidenziazione delle anomalie e orchestrazione delle risposte alle minacce.

In generale, blindare container e microservizi non è banale e ciascuno dei due ambiti presenta problematiche specifiche. Anche perché i vettori di attacco nel tempo si sono evoluti e la partita si gioca a più livelli contemporaneamente: i componenti di base, le piattaforme di gestione, il flusso intero di microservizi.

Anelli deboli della catena

I componenti di base oggi sono, principalmente, i container che realizzano i microservizi (in toto o in parte). È risaputo che lato sicurezza i container sono meno "isolati" delle macchine virtuali. Condividono il sistema operativo sottostante, quindi una eventuale violazione di un container può estendersi lateralmente e portare alla compromissione anche di altri. È un rischio che si contiene in vari modi ma che va comunque sempre tenuto presente.

Un secondo limite dei container è che c'è poco controllo sulla loro affidabilità. Pochi utenti attivano sistemi che controllano i container prima di istanziarli, dando per scontato che siano stati sviluppati al meglio e non facciano niente di improprio. Non è detto che sia così.

Anche una applicazione containerizzata può avere errori di programmazione tali da aprire una falla che mette a rischio la sicurezza di tutto il sistema che la esegue. Inoltre, basta un supply chain attack per inserire falle volute in un ambiente cloud, ad esempio è successo più volte che hacker ostili si impadronissero dell'account Github (o di qualche altro repository di codice) di un team di sviluppo per modificare ad arte il codice applicativo.

Attacchi come questo mettono in evidenza un tema spesso sottovalutato: le piattaforme di gestione dei container sono a rischio come qualsiasi altra piattaforma software. Il numero degli attacchi alle "basi" Docker e Kubernetes della containerizzazione è in aumento, attacchi facilitati anche dal fatto che spesso queste piattaforme sono gestite dai team di sviluppo in maniera non proprio blindata, per favorire l'elasticità rispetto alla rigidità (percepita) della sicurezza e del controllo accessi.

Così un attaccante può ottenere l'accesso a un account di gestione magari perché le sue credenziali sono state condivise su Github. O più banalmente sfruttando vulnerabilità non corrette nelle piattaforme di container management ed orchestration. Qualsiasi mezzo si usi, diventa possibile attivare o disattivare a piacimento container usando le risorse in cloud della malcapitata azienda utente. Un esempio, tra i più semplici, di questa forma di attacco è il cryptojacking.

Cloud security: una questione di scala

C'è, infine, una questione di scala che interessa in modo molto specifico le applicazioni cloud-native basate su microservizi. In generale questi sono componenti atomici che svolgono un compito molto mirato, cosa che rende semplice anche valutare il loro stato di funzionamento ed eventuale compromissione. Ma un'applicazione cloud-nativa è fatta da molti microservizi che devono interagire fra loro, dialogando attraverso API e scambiando i dati necessari.

In questa catena di microservizi la debolezza (un'API modificata ma non documentata, un passaggio di dati non corretto, una autenticazione sbagliata...) anche di uno solo diventa la debolezza di tutta la catena. Con conseguenze variabili. Se un microservizio "cade" e blocca un'applicazione, poco male: la si fa ripartire. Se però porta l'applicazione a uno stato indefinito che comporta una vulnerabilità per i dati o la rete dell'utente, la prospettiva cambia.

Controllare tutto questo flusso è complicato e potrebbe persino essere impossibile per l'azienda che eroga servizi via applicazioni cloud-native. Bisogna avere visibilità e controllo completi sulla catena dei microservizi usati, alcuni dei quali però possono essere stati creati od erogati da altri.