L’uso dei container spinge la digital transformation, ma, per evitare i rischi alla sicurezza dei dati, la containerization va inserita nel DevOps
Cresce la consapevolezza sulle problematiche di sicurezza, ma mentre proliferano le minacce, i Ciso (Chief Security Officer) devono fare i conti con sistemi sempre più articolati e complessi. Hari Srinivasan, Director product mangement di Qualys, evidenzia l’importanza del proteggere le applicazioni realizzate dai reparti operativi e di sviluppo, che vengono distribuite nei container.
Il punto, afferma Srinivasan, è che «le misure di protezione configurate dai responsabili della sicurezza devono coprire l’intero ciclo di vita del container e integrarsi nel canale DevOps con efficacia e, al tempo stesso, discrezione», di fatto per non creare oneri aggiuntivi.
Per questo in azienda si deve approfondire la conoscenza delle tecnologie per la containerizzazione e scegliere adeguati strumenti e processi.
I container sono molto utili, ma portano difficoltà per la sicurezza e conformità alle normative, come il GDPR. In particolare sorgono alcuni problemi dovuti alle caratteristiche più apprezzate dagli sviluppatori, ci spiega Srinivasan, citando, per esempio, la possibilità di creare un pacchetto dell’applicazione, con dati e connettori, senza un client del sistema operativo. In un tale pacchetto, potrebbe trovarsi software non verificato, magati che arriva da repository pubblici, il quale spesso presenta vulnerabilità. Altri problemi potrebbero arrivare dal mettere in esercizio container con configurazioni non sicure o con valori predefiniti.
Sottolinea inoltre l’esperto: «I container comunicano tra loro direttamente e, normalmente, attraverso porte di rete esposte. Spesso sottraendosi ai controlli dell’host e pertanto sono difficili da monitorare».
Integrare la sicurezza nell’utilizzo dei container
Secondo Srinivasan: «Ci sono quattro obiettivi di sicurezza che è necessario perseguire per i container. Innanzi tutto, occorre ottenere visibilità sull’intero ambiente del container individuando e tenendo traccia delle installazioni attivate on premise e nel cloud».
È poi fondamentale «gestire le vulnerabilità del container e contemporaneamente prevenire e rilevare le intrusioni».
Il terzo obiettivo è consiste nello sfruttare le API REST per integrare i prodotti devops e gli strumenti per la messa in sicurezza dei container.
Infine, va riesaminata la funzionalità di risposta agli incidenti di sicurezza del container, specialmente perché «i container vulnerabili non vanno “pachati”, ma sostituiti con nuove unità create con un’immagine aggiornata», precisa l’esperto di Qualys.
Le imprese devono predisporre programmi di incident responce aggiornati e capaci di raccogliere informazioni sul sistema informativo dei container e sulla piattaforma di orchestrazione. In questo modo, sarà possibile introdurre, con le opportune pianificazioni, una modalità di sostituzione completa del programma per la risposta agli incidenti.
Protezione lungo la “filiera” del container
Raggiunti i quattro obiettivi, è possibile mettere in sicurezza tutte le fasi per mettere in esercizio i container: costruzione, implementazione e runtime.
Devono essere messe in sicurezza tutte e tre le fasi per il deployment.
Nella fase di costruzione è fondamentale bloccare l’ingresso d’immagini vulnerabili nei repository dell’organizzazione. «Questa misura è particolarmente importante nel caso in cui le immagini non vengano create da zero ma prelevate in parte o in toto da un repository/marketplace pubblico, pratica molto comune tra gli sviluppatori di container», precisa Srinivasan, che prosegue: «Usando API REST o plug-in nativi, è invece possibile eseguire in automatico i controlli di sicurezza direttamente negli strumenti CI/CD scelti dal team DevOps.
Per bloccare l’ingresso di immagini pericolose negli archivi Docker, è fondamentale sfruttare le API REST o i plug-in nativi perché consentono l’esecuzione in automatico dei controlli di sicurezza direttamente.
«Per questo, occorre dotarsi della flessibilità di definire i parametri per bloccare le immagini non sicure, come potrebbero essere la presenza di vulnerabilità con un punteggio di gravità pari a 3, 4 o 5, di rilevare il mancato rispetto dei requisiti di compliance e di individuare l’utilizzo aperto di codice aggiuntivo, magari malevolo, nelle immagini», evidenzia. Il manager.
Realizzando tali integrazioni, i security team potranno permettere agli sviluppatori l’accesso agli strumenti di sicurezza, per inserirle nel programma CI/CD senza delegarle al gruppo di sicurezza.
Per esempio: gli sviluppatori saranno in grado di accedere ai risultati delle scansioni e di operare interventi di remediation direttamente dall’interfaccia del loro programma di controllo.
3 fasi d’implementazione
Nella fase d’implementazione, occorre fare attenzione a che le immagini presenti nei vari repository siano prive di vulnerabilità, quindi va tenuto costantemente aggiornato l’inventario dei registri e dei repository. Il che significa avviare l’analisi delle vulnerabilità tutte le volte che si aggiunge le una nuova immagine. Resta però utile controllare sistematicamente tutte le immagini e pianificare scansioni automatizzate periodiche.
A questi accorgimenti va aggiunto un controllo dell’affidabilità e la rispettabilità delle fonti, assicurandosi che siano aggiornate e prive di vulnerabilità conosciute. In particolare, per firmare le immagini e assicurarsi che il proprio ambiente ospiti solo immagini affidabili Srinivasan, suggerisce di affidarsi a servizi, quale Docker Notary, per la certificazione della validità.
Una volta arrivati in produzione, ci sono alcuni accorgimenti suggeriti dall’esperto di Qualys per la fase di runtime. Innanzitutto serve una visibilità e un monitoraggio costanti. Il tutto concorre ad acquisire la capacità di impedire le violazioni e di reagire.
«I team di sicurezza devono essere in grado di identificare i container non autorizzati o vulnerabili, di individuarne la posizione e di valutarne il potenziale impatto in funzione del loro livello di impiego nell’ambiente», mette in evidenza Srinivasan, che suggerisce: «Un accorgimento utile in produzione consiste nel contrassegnare i container, tra quelli già attivi nel sistema, i quali evidenziano deviazioni rispetto al comportamento “immutabile” dell’immagine di partenza. Tali deviazioni potrebbero, infatti, indicare una falla».
Ovviamente, per effettuare un confronto è opportuno definire il comportamento predefinito dell’applicazione containerizzata, in modo da individuare le deviazioni sospette (per esempio una chiamata al sistema o una qualsiasi comunicazione imprevista)
Una volta riconosciuti i container compromessi, il sistema di sicurezza dovrà permettere all’utilizzatore di applicare contromisure, come il blocco o la messa in quarantena dell’esecuzione, per poi analizzare approfonditamente le origini delle e anomalie e identificare il potenziale problema. per determinare l’origine del problema.
L’attività di analisi non interferirà con la produttività, in quanto sarà sufficiente attivare un altro container con la stessa immagine di partenza per avviare una nuova istanza sostitutiva.
Ancora meglio, specifica Srinivasan: «è possibile utilizzare uno strumento diche consenta di convalidare i automaticamente la congruenza dell’immagine alle policy di sicurezza e blocchi la generazione di nuovi container con immagini non autorizzate».
Per questo occorre un servizio d’orchestrazione, per esempio Kubernetes, che impedisce ai container compromessi di entrare nell’ambiente.
Conclude l’esperto di Qualys: «Per creare ambienti operativi basati sul modello “di accesso minimo”, occorre inoltre attenersi alle pratiche di sicurezza prescritte per gli ambienti di orchestrazione e, se esiste un canale di accesso all’host sottostante, rafforzarlo mettendo in atto un controllo delle vulnerabilità e definendo requisiti di compliance».