L’avvento di processori più potenti nei primi anni 2000, insieme al supporto hardware per la virtualizzazione, ha dato il via alla rivoluzione informatica che ha portato, nel tempo, a quello che oggi chiamiamo cloud. Con singole istanze hardware in grado di eseguire decine, se non centinaia di macchine virtuali in contemporanea, le aziende potevano offrire ai propri utenti molteplici servizi e applicazioni che altrimenti sarebbero stati finanziariamente impraticabili, se non impossibili.
Ma le macchine virtuali (VM) hanno diversi lati negativi. Spesso un intero sistema operativo virtualizzato è eccessivo per molte applicazioni e, sebbene siano molto più malleabili, scalabili e agili di una flotta di server bare-metal, le macchine virtuali richiedono comunque molta più memoria e potenza di elaborazione e sono meno agili della prossima evoluzione di questo tipo di tecnologia: i container. Oltre ad essere più facilmente scalabili (in aumento o in diminuzione, a seconda della domanda), le applicazioni containerizzate sono costituite solo dalle parti necessarie di un’applicazione e dalle sue dipendenze di supporto. Pertanto, le applicazioni basate su microservizi tendono a essere più leggere e più facilmente configurabili.
Le macchine virtuali presentano gli stessi problemi di sicurezza che affliggono le loro controparti bare-metal e, in una certa misura, i problemi di sicurezza dei container riflettono quelli delle loro parti componenti: un bug di mySQL in una versione specifica dell’applicazione upstream interesserà anche le versioni containerizzate. Per quanto riguarda le macchine virtuali, le installazioni bare metal e i container, le preoccupazioni e le attività di cybersicurezza sono molto simili. Tuttavia, le distribuzioni di container e i relativi strumenti pongono sfide di sicurezza specifiche a coloro che si occupano dell’esecuzione di applicazioni e servizi, sia che si tratti di mettere insieme manualmente le applicazioni con container a scelta, sia che si tratti di eseguirle in produzione con l’orchestrazione su scala.
Rischi per la sicurezza specifici dei container
- Configurazione errata: Le applicazioni complesse sono composte da più container e un’errata configurazione, spesso solo una singola riga in un file .yaml, può concedere privilegi non necessari e aumentare la superficie di attacco. Ad esempio, sebbene non sia banale per un aggressore ottenere l’accesso root alla macchina host da un container, è ancora una pratica troppo comune eseguire Docker come root, ad esempio senza il remapping dello spazio dei nomi utente.
- Immagini di container vulnerabili: Nel 2022, Sysdig ha trovato oltre 1.600 immagini identificate come dannose in Docker Hub, oltre a molti container archiviati nei repo con credenziali cloud, chiavi ssh e token NPM codificati. Il processo di estrazione delle immagini dai registri pubblici è poco trasparente e la convenienza della distribuzione dei container (oltre alla pressione esercitata sugli sviluppatori affinché producano risultati in tempi brevi) può far sì che le app siano facilmente costruite con componenti intrinsecamente insicuri o addirittura dannosi.
- Livelli di orchestrazione: Per i progetti più grandi, gli strumenti di orchestrazione come Kubernetes possono aumentare la superficie di attacco, di solito a causa di una configurazione errata e di alti livelli di complessità. Un’indagine condotta nel 2022 da D2iQ ha rilevato che solo il 42% delle applicazioni che girano su Kubernetes entrano in produzione, in parte a causa della difficoltà di amministrare cluster di grandi dimensioni e della ripida curva di apprendimento.
Secondo Ari Weil di Akamai, “Kubernetes è maturo, ma la maggior parte delle aziende e degli sviluppatori non si rendono conto di quanto possa essere complesso […] fino a quando non si trovano su scala reale”
Sicurezza dei container con il machine learning
Le sfide specifiche della sicurezza dei container possono essere affrontate utilizzando algoritmi di apprendimento automatico addestrati all’osservazione dei componenti di un’applicazione quando è “pulita” Creando una linea di base di comportamento normale, l’apprendimento automatico può identificare le anomalie che potrebbero indicare potenziali minacce derivanti da traffico insolito, modifiche non autorizzate alla configurazione, strani modelli di accesso degli utenti e chiamate di sistema inaspettate.
Le piattaforme di sicurezza per container basate sul ML possono scansionare i repository di immagini e confrontarli con i database di vulnerabilità e problemi noti. Le scansioni possono essere attivate e programmate automaticamente, aiutando a prevenire l’aggiunta di elementi dannosi durante lo sviluppo e la produzione. I rapporti di audit generati automaticamente possono essere monitorati rispetto a parametri standard, oppure un’organizzazione può stabilire i propri standard di sicurezza, utili in ambienti in cui vengono elaborati dati altamente sensibili.
La connettività tra le funzioni di sicurezza dei container e il software di orchestrazione significa che i container sospetti possono essere isolati o chiusi immediatamente, le autorizzazioni non sicure revocate e l’accesso degli utenti sospeso. Con le connessioni API ai firewall locali e agli endpoint VPN, è possibile isolare interi ambienti o sottoreti o bloccare il traffico ai confini della rete.
Parola d’ordine
Il machine learning può ridurre il rischio di violazione dei dati negli ambienti containerizzati lavorando su diversi livelli. È possibile effettuare il rilevamento di anomalie, la scansione delle risorse e la segnalazione di potenziali configurazioni errate; inoltre, qualsiasi grado di avviso o miglioramento automatizzato è relativamente semplice da attuare.
Le possibilità di trasformazione delle applicazioni basate su container possono essere affrontate senza i problemi di sicurezza che hanno impedito ad alcuni di esplorare, sviluppare ed eseguire applicazioni basate su microservizi. I vantaggi delle tecnologie cloud-native possono essere sfruttati senza compromettere gli standard di sicurezza esistenti, anche nei settori ad alto rischio.
