La parola container è entrata nel lessico quotidiano delle notizie di tecnologia ed è sempre più familiare anche per le aziende desiderose di sviluppare applicazioni e lanciare servizi in tempi rapidi, a costi accessibili e senza eccessive complessità. Ridurre la complessità non significa, tuttavia, ignorare le variabili che possono avere impatti sull’esito dei progetti (e in particolare sulla sicurezza). Quella della tecnologia da usare per il deployment e per l’orchestrazione non è certamente l’unica scelta da soppesare. Ce ne parla Marco Rottigni, chief technical security officer Emea di Qualys.
Marco Rottigni, chief technical security officer Emea di Qualys
Si sta diffondendo rapidamente l’utilizzo dei container per la distribuzione delle applicazioni. Che si tratti di Kubernetes o Docker, gli strumenti open source oggi più diffusi sia per il deployment sia per le attività di orchestrazione, i container si rivelano utili per implementare gli elementi che compongono l’applicazione e attivarli in ambienti cloud pubblici o ibridi. Sono ambienti runtime leggeri e forniscono un modo per astrarre e virtualizzare i componenti dei microservizi dall’hardware o dal servizio cloud sottostante, evitando di essere legati a un ambiente specifico. In ogni caso, trasferire applicazioni sui container significa prevedere dei cambiamenti per il team di sicurezza IT. I container sono da comprendere e gestire, esattamente come l’infrastruttura It tradizionale. Senza questa consapevolezza e attenzione, è difficile mantenere le immagini aggiornate e in sicurezza. Qual è dunque la miglior combinazione pragmatica tra container, sicurezza e attività di monitoraggio?
Le domande da porsi
Prima di tutto, è necessario capire se la containerizzazione sia in uso all’interno dell’organizzazione e dove, nello specifico, venga applicata. Può sembrare un punto semplice, ma accade spesso che gli sviluppatori creino e avviino le loro applicazioni nel cloud senza coinvolgere sin dall’inizio gli altri team It aziendali. È altrettanto importante capire quante implementazioni di questo tipo siano attivate nell’ambiente It aziendale e per quali scopi.
Una volta identificati container in attività, è fondamentale capire quanto il processo di sviluppo del software sia basato su questa tecnica, in quanto normalmente accade che quanto prototipato in fase di sviluppo sia esteso alla produzione. Pertanto se i progetti iniziali sono sviluppati in container è tipico che il processo di test, quello di quality assurance e le istanze di produzione finale migrino tutti, nel tempo, vero l’adozione di container. Questa situazione può portare all’esecuzione di più piattaforme e istanze in contemporanea.
Per una gestione ottimale è opportuno capire l’attuale livello di visibilità di tutte le risorse It aziendali, e stabilire dove le informazioni siano sufficienti e dove il contesto richieda più dati.
Tale processo dimostra nel tempo il miglioramento della visibilità sull’ambiente It aziendale.
Una volta individuate le aree di miglioramento, diventa possibile capire quali dati manchino. Per i container, ottenere informazioni sulle immagini in esecuzione può risultare difficile se non ci si è pensato in anticipo. Ad esempio, se un’azienda ha già distribuito più container applicativi in un servizio cloud, è possibile sapere quante immagini vengono eseguite in un dato momento, e come? Per ottenere questa informazione, è necessario che in ogni container standard siano incorporati degli agenti: includendo questi sensori in tutte le immagini è possibile generare automaticamente un report di status. Questo può aiutare a conoscere quale sia numero delle immagini implementate, quali librerie software siano incluse nell’ambiente runtime e se queste siano aggiornate.
È importante sottolineare che ognuna delle fasi indicate dovrà essere ripetuta in modo continuo. I container sono istanziati e rimossi automaticamente in base alla domanda: di conseguenza la validazione e la protezione delle applicazioni nei container deve garantire la stessa ritmica, distribuita lungo l’intero ciclo di vita delle applicazioni, dal momento in cui sono sviluppate, codificate e spedite nei registry come immagini fino al momento in cui sono istanziate come applicazioni in esecuzione in container.
Questo approccio serve a coprire la valutazione e l’esecuzione per tutte le parti in movimento coinvolte nella gestione dei container, inclusi stack dell’infrastruttura container e ciclo di vita dell’applicazione containerizzata nel tempo. Queste due aree, stack e ciclo di vita, devono essere allineate meticolosamente. Ancor più importante è che queste informazioni siano consolidate con dati sulle risorse It tradizionali, aiutando ad assegnare priorità agli elementi che richiedono un rimedio, a prescindere dalla loro collocazione nell’ambiente It.
La sicurezza deve riguardare anche i processi
I container vengono comunemente adottati come parte di metodologie di sviluppo Agile e di processi DevOps. Nel caso siano siano già in uso da parte di alcuni team, è importante ampliare il raggio d’analisi al processo di integrazione e distribuzione continua (CI/CD), in cui vengono utilizzati anche i container. L’integrazione continua o Continuous Integration (CI) implica la scomposizione dello sviluppo del software in blocchi più piccoli e gestibili, che possono essere consegnati più rapidamente, mentre Continuous Deployment (CD) muove questi progetti di sviluppo attraverso attività di testing e messa in produzione.
Affinché l’implementazione della pipeline CI/CD sia efficace, è necessario che i due processi siano automatizzati e integrati. Questo aiuta gli sviluppatori nell’accelerare l’attività di test e messa in produzione dei nuovi progetti software, mentre un’ulteriore integrazione con i servizi cloud supporta la collaborazione con i team operativi sull’ampliamento dell’implementazione, in modo da soddisfare la domanda. L’utilizzo di strumenti come Jenkins, CircleCI o Travis CI può velocizzare questi processi, sebbene siano automatizzati i soli passaggi che si decide di includere.
Per i professionisti della sicurezza che cercano di capire come comportarsi con i container, non è sufficiente dire che la sicurezza andrebbe considerata sin dall’inizio. È fondamentale sottolineare come la sicurezza possa aggiungere valore per gli sviluppatori al ciclo DevOps, fornendo al personale responsabile tutte le informazioni necessarie sullo stato delle risorse IT e dell’infrastruttura.
Ad esempio, è possibile aiutare gli sviluppatori permettendo loro di eseguire in completa autonomia la verifica di potenziali vulnerabilità di sicurezza all'interno di componenti o librerie software. Questa attività può essere resa parte dei loro workflow, inserendo automaticamente ogni anomalia riscontrata nel software di tracciamento dei problemi di sviluppo software, così da poter pianificare i rimedi. L’eliminazione della burocrazia nella segnalazione dei problemi di sicurezza, scoperti durante la scansione delle applicazioni o i controlli delle immagini dei container, aiuta il team a facilitare il processo di sviluppo del software.
Per i team che utilizzano i container, questo processo di scansione deve coprire tutte le diverse posizioni in cui possono essere presenti le immagini. Vanno incluse tutte le risorse software utilizzate all'interno dei container, tutte le immagini di container già archiviate nella libreria aziendale, tutte le immagini di container estratte dagli archivi pubblici, tutti i container stessi quando in esecuzione.
Ottenere queste informazioni aiuta gli sviluppatori a capire dove applicare dei correttivi all'interno dei container, e aiuta nella comprensione della superficie vulnerabile. La collaborazione al processo di scoperta e il supporto agli sviluppatori nel gestire la propria parte autonomamente, aumenta il livello di sicurezza. Ancor più importante è il fatto che queste informazioni siano rese disponibili contestualmente a quelle provenienti dalle altre piattaforme e dall’infrastruttura.
L'esecuzione di un servizio di gestione degli asset in questo contesto richiede visibilità e protezione native per i container, implementate sin dal principio. Questo processo deve anche integrarsi perfettamente con le pipeline CI / CD aziendali esistenti, in modo che ogni container venga gestito e tracciato correttamente. La tecnica di gestione asset basata su layering dovrebbe includere il monitoraggio del tempo di esecuzione di ogni container, cosicché qualsiasi modifica nell'immagine possa essere evidenziata per tempo.
Per i team di sicurezza It ottenere informazioni dettagliate sullo stato di tutte le risorse informatiche aziendali è essenziale per mantenere i dati protetti, sia che si tratti di server fisici tradizionali, di endpoint su rete aziendale o di nuove applicazioni distribuite in container su cloud pubblico. Senza questa visibilità sugli eventi dell’It aziendale è facile non accorgersi dei potenziali rischi che si corrono. Tuttavia, i cambiamenti che ruotano attorno ai container in termini di modalità di sviluppo e utilizzo delle applicazioni fanno sì che sia importante adottare un approccio più pragmatico per ottenere questi dati il prima possibile. Comprendendo i cambiamenti che avvengono nello sviluppo del software, è possibile integrare tempestivamente la sicurezza nel processo. Allo stesso modo, centralizzando informazioni e contesto relativi alle risorse It è possibile aumentare l’efficacia decisionale nell’impiego delle risorse di sicurezza.