I container non sono sempre sicuri, cinque regole da seguire

I container sono uno strumento sempre più sfruttato per la creazione e la distribuzione delle app, anzi si può dire che stiano colonizzando un po’ tutta l’infrastruttura informatica delle aziende, grazie alla loro “leggerezza” ed efficienza operativa. Ma nel loro utilizzo, per evitare rischi per la sicurezza informatica, vanno considerate alcune regole. Ce ne parla Lori MacVittie, principal technical evangelist di F5 Networks.

 

 

Lori MacVittie, principal technical evangelist di F5 Networks

 

I container vivono un periodo di crescente successo e oggi aziende di tutte le dimensioni sviluppano piani su come containerizzare le proprie applicazioni. Tutti sanno che Kubernetes ha vinto la sfida di mercato dei containers, nell’ambito dell’orchestrazione. In realtà la gestione del ciclo di vita dell’immagine dei container è stata vinta da Docker. Lo confermano i dati sulla loro diffusione, con oltre 1 miliardo di container Docker scaricati ogni due settimane secondo quanto dichiarato nello State of Open Source Security Report 2019, promosso da Snyk.

 

Docker Hub è diventato per le aziende quello che l'App Store e Google Play rappresentano per i consumatori. Le immagini del container oggi sono eseguite nell’intera infrastruttura, dai sistemi operativi di base agli stack applicativi, ai database al middleware fino agli app engine che supportano node.js, Python e Go e includono anche l’integrazione con l’ecosistema per i servizi applicativi. La maggior parte delle organizzazioni che fanno deploy di app mediante container utilizzano Kubernetes come sistema di orchestrazione di immagini Docker. In molti casi però si tratta di immagini vulnerabili.

 

 La ricerca di Snyk ha rivelato che "ognuna delle prime dieci immagini Docker predefinite più popolari contiene almeno trenta librerie di sistema vulnerabili”. È evidente che queste librerie di sistema siano presenti su molte immagini Docker, dato che queste si basano su un'immagine principale che utilizza comunemente come base una distribuzione Linux”. I dati di Snyk lo confermano: il numero di vulnerabilità è in costante aumento in tutte e tre le principali distribuzioni Linux. In sintesi, ci troviamo di fronte a un’enormità di immagini vulnerabili che vengono scaricate in ogni momento dalle organizzazioni. Non sorprende, quindi, che lo State of Container Security 2019 di Tripwire abbia riscontrato una percentuale allarmante: il 60% degli intervistati negli ultimi dodici mesi ha subito un incidente di sicurezza che ha riguardato i container.

 

Circa un intervistato su cinque (il 17%) ha dichiarato che l'organizzazione in realtà era a conoscenza delle vulnerabilità, ma che ha comunque deciso di implementare le immagini. Tutto questo nonostante sia noto che il 44% delle immagini Docker contiene vulnerabilità conosciute e che fossero disponibili immagini di base più recenti e sicure. In altre parole, implementare un'immagine aggiornata avrebbe consentito di mitigare il rischio e un altro 22% delle immagini con vulnerabilità si poteva affrontare e risolvere semplicemente ricostruendo l'immagine.

 La situazione mi sembra per certi versi assurda: gran parte dell’attenzione quando si parla di “shift security left” è rivolta tanto all'implementazione di servizi adeguati per applicare la sicurezza (difesa dai bot, web application firewall, controllo dell'identità e degli accessi) quanto all’integrazione di security practice nel ciclo di sviluppo ed implementazione dei container. Tali pratiche includono la scansione del codice e dei container per identificare vulnerabilità note e quindi risolverle.

 

Una cosa è certa: possiamo fare di meglio. La velocità è importante, anche nella containerizzazione, però la velocità senza la sicurezza è pericolosa, non solo per l'organizzazione, ma anche per i clienti che alla fine utilizzeranno le app che saranno distribuite. Per questo motivo credo che una containerizzazione sicura debba prevedere cinque passaggi fondamentali:

 

1. Valutare il reale utilizzo. Molte organizzazioni non sono consapevoli di quanto sia pervasivo il loro consumo di immagini/sorgenti open source e di terze parti. Averne la consapevolezza rappresenta un primo passo importante. Non si può pensare di affrontare le vulnerabilità di un software senza nemmeno sapere che lo si sta utilizzando.

2. Standardizzare. Cercare di identificare un terreno comune tra applicazioni e le operation per standardizzare il minor numero possibile di immagini/componenti del container. Un approccio di questo tipo consente di distribuire l'onere della sicurezza in tutta l'organizzazione e si traduce alla fine in un livello di sicurezza maggiore per tutti.

3. Controllare la sicurezza del codice tramite review costanti. Nel caso vengano incluse componenti o script di terze parti (cosa che avviene quasi sempre) vanno sempre analizzate e distribuite/costruite a partire da un repository privato.

4. Promuovere gli audit sulla sicurezza del container. Quando si consumano immagini di terze parti, è necessario promuovere audit specifici e certificare la loro sicurezza, per poi effettuare la delivery da un repository privato.

5. Tenersi informati sulle nuove vulnerabilità. Se si fa affidamento su un’immagine o codice sorgente, è necessario iscriversi ai canali dedicati alla sicurezza dei container che comunicano le potenziali vulnerabilità. Dopo tutto, il sapere rappresenta sempre l’arma più potente per vincere ogni battaglia.