Gestire la sicurezza dei container con le scansioni e non solo

Sebbene molte delle conversazioni sulla sicurezza dei container oggi abbiano come argomento i requisiti di sicurezza delle piattaforme di orchestrazione quali Kubernetes, non tutti i rischi per la sicurezza dei container possono essere valutati a livello di orchestrazione. È anche necessario gestire le minacce ai singoli container.

Il modo migliore per farlo è seguire le prassi di sicurezza standard Docker che risalgono agli albori dei container Docker, lanciati per il pubblico nel 2013. Benché oggi l’ecosistema dei container sia evoluto a un livello molto superiore a quello dei container Docker (infatti, gli stessi Docker non fanno più parte di molti stack di applicazioni containerizzate che utilizzano altri runtime e altre soluzioni di orchestrazione), i principi fondamentali della sicurezza Docker – quali la scansione dei container, la gestione delle vulnerabilità dei container e il controllo degli accessi ai container – valgono ancora. 

Questo articolo torna alle origini e presenta una panoramica delle principali categorie di vulnerabilità dei container e analizza le misure che le aziende possono adottare per gestirle. 

Vulnerabilità delle immagini dei container

La vulnerabilità delle immagini resta la principale minaccia alla sicurezza dei singoli container. Una vulnerabilità dell’immagine di un container è un rischio per la sicurezza incorporato nell’immagine di un container. Sebbene le immagini vulnerabili in sé non implichino una minaccia attiva, se vengono creati container in base a un’immagine vulnerabile, questi introdurranno la vulnerabilità in un ambiente attivo.

Le vulnerabilità delle immagini dei container derivano solitamente da librerie non sicure o da altre dipendenze importate in un’immagine. Le immagini potrebbero anche contenere codici dannosi inseriti durante un attacco alla catena di distribuzione di un software o una violazione simile dell’ambiente di sviluppo.

Rilevamento della vulnerabilità delle immagini con la scansione dei container

Fortunatamente, molte vulnerabilità delle immagini dei container possono essere rilevate piuttosto facilmente attraverso una scansione dei container. La scansione dei container consiste nell’utilizzo di strumenti automatici che confrontano i contenuti di ciascun container con un database di vulnerabilità conosciute. Se si determina che una libreria o un’altra dipendenza nell’immagine di un container è soggetta a una vulnerabilità conosciuta, l’immagine viene segnalata come non sicura.

La principale limitazione della scansione dei container è che di solito non è utile per il rilevamento delle vulnerabilità sconosciute, ovvero quelle che non sono state rese pubbliche o rivelate agli analisti della sicurezza. In altre parole, se l’immagine di un container utilizza una libreria con un bug per la sicurezza non ancora rilevato, le scansioni non lo individueranno perché non è ancora stato registrato nel database che utilizzano. Neanche le vulnerabilità che interessano i codici personalizzati e proprietari vengono rilevate con facilità, perché non sono tracciate pubblicamente. 

Sebbene la scansione delle immagini dei container sia un passaggio vitale per la protezione dei container, dunque, è importante ricordare che non è sufficiente né rappresenta una soluzione completa per la gestione delle vulnerabilità. 

Immagini dei container dannose

Benché anche immagini dei container legittime possano contenere (e spesso contengano) vulnerabilità, le immagini dannose che vengono deliberatamente progettate per mascherarsi da immagini legittime pongono un rischio ancora più grande alla sicurezza delle immagini dei Docker. Caricando un’immagine contenente malware su un registro container pubblico come Docker Hub e assegnandole un nome (ad esempiomysqldatabase o nginxserver) all’apparenza legittimo, gli autori degli attacchi possono indurre gli ignari amministratori a utilizzare versioni dannose di software pubblicamente disponibili.

Evitare le immagini dannose

Gli scanner di immagini di Docker potrebbero non catturare queste immagini se contengono malware non associato a una vulnerabilità pubblicamente conosciuta. Per questa ragione, il modo migliore per proteggersi dalle immagini dannose è scaricare immagini solo da fonti attendibili. Bisogna evitare registri Docker Hub o repository GitHub non ufficiali.

È inoltre buona norma evitare di utilizzare il tag “latest” (più recente) quando si cercano le immagini dei container. Piuttosto, è meglio specificare una versione dell’immagine. Questo riduce il rischio che gli hacker introducano un’immagine dannosa in un registro container altrimenti legittimo e, indicando un numero di versione più recente delle altre immagini, inducendo le persone a utilizzarla.

Minacce di escalation dei privilegi

Anche se tutte le immagini dei container utilizzate sono prive di vulnerabilità, potrebbe avvenire una violazione a causa di un attacco di escalation dei privilegi.

In un attacco di escalation dei privilegi, i processi che dovrebbero poter accedere solo alle risorse all’interno di un container “evadono” e accedono a risorse che si trovano in altri container o nel server host.

Impedire l’escalation dei privilegi

Il principale vettore di escalation dei privilegi è costituito dai bug del software di runtime del container, responsabile dell’esecuzione dei container, o del sistema operativo dell’host.

Pertanto, il principale strumento di difesa contro l’escalation dei privilegi è la protezione del runtime del container e del sistema operativo dell’host. È possibile fare ciò garantendo che tutti i software eseguiti sul server (o sui server) host siano aggiornati e privi di vulnerabilità conosciute.

È anche possibile ridurre il rischio di un attacco di escalation dei privilegi adottando un sistema di rafforzamento del kernel come AppArmor o SELinux. Questi contesti impongono ulteriori controlli degli accessi (basati su policy che vengono configurate e applicate) ai sistemi operativi dell’host, fornendo un secondo livello di difesa contro i processi che evadono dai container nei quali dovrebbero restare.

Infine, scegliere un sistema operativo minimalista quale Alpine Linux può mitigare il rischio di escalation dei privilegi nei container riducendo il numero di librerie e servizi che l’autore di un attacco potrebbe potenzialmente sfruttare. È buona prassi che l’OS host non includa software diversi da quelli minimi richiesti per adottare, orchestrare, monitorare e proteggere i container. Se si desidera eseguire altri workload insieme ai container, meglio farlo su un server diverso o su una VM.

Vulnerabilità delle applicazioni

Indipendentemente da quanto si rendano sicuri le immagini dei container e l’ambiente nel quale si trovano, si presenteranno problemi legati alla sicurezza se l’applicazione ospitata per mezzo dei container presenta un difetto nel codice sorgente.

Per esempio, una convalida insufficiente dei dati immessi potrebbe facilitare attacchi come SQL injection, consentendo agli hacker di accedere alle informazioni sensibili. Oppure, una vulnerabilità come il sovraccarico del buffer potrebbe permettere agli autori di un attacco di eseguire codice arbitrario e impossessarsi del container (e, magari, dell’intero host).

Gestione delle vulnerabilità delle applicazioni

Dal momento che le vulnerabilità delle applicazioni si presentano nel codice sorgente e non nei processi o negli strumenti associati ai container, sarà necessario gestirle a livello di applicazione.

È bene effettuare una scansione del codice sorgente alla ricerca di vulnerabilità come parte della pipeline CI/CD utilizzando il test statico della sicurezza delle applicazioni, che consente di individuare prassi non adeguate a livello di codice che potrebbero costituire una minaccia. Poi, è possibile testare nuovamente l’applicazione prima dell’uso con il test dinamico della sicurezza delle applicazioni, un metodo che monitora un’applicazione eseguita in ambiente sandbox allo scopo di rilevare comportamenti che potrebbero indicare una vulnerabilità per la sicurezza.

Anche in questo caso, strumenti per il rafforzamento del kernel quali SELinux e AppArmor possono aiutare a ridurre il rischio di vulnerabilità delle applicazioni rendendo gli exploit più difficili da eseguire. Ma queste risorse non agiscono sulla causa fondamentale della mancanza di sicurezza di un’applicazione.

Utilizzare i benchmark di Docker CIS

Sebbene non esista un modo per garantire la libertà totale dalle minacce alla sicurezza dei container, per stabilire una base di riferimento è molto utile misurare le configurazioni dei container confrontandole con i benchmark di sicurezza di Docker stabiliti dal Center for Internet Security, o CIS.

I benchmark CIS per la sicurezza dei container riguardano tutti i livelli dello stack del software di un container. Stabiliscono le migliori prassi per proteggere gli host, configurare le autorizzazioni nelle immagini dei container, configurare il runtime del container e molto altro.

Dunque, benché rispettare le raccomandazioni del CIS non garantisca la sicurezza del Docker, vale la pena dedicare del tempo a esaminare i benchmark e accertarsi di rispettare ciascuno di essi.

Utilizzare container sicuri in un ambiente sicuro richiede strumenti e prassi in grado di mitigare diverse minacce. Dalla scansione delle immagini dei container agli strumenti di rafforzamento del kernel, fino alla sicurezza delle applicazioni, è necessario schierare un grande numero di difese per ridurre al minimo il rischio posto dalle vulnerabilità della sicurezza all’interno degli ambienti applicativi containerizzati.