Marie Innes, Solution Architect, Red Hat, e Miriam Bressan, Manager Solution Architect, Red Hat, sfatano i miti riguardanti open source e container.
La considerazione olistica della sicurezza informatica è un processo continuo che riguarda sia il software open source in generale che in particolare l’uso dei container. Un aspetto centrale è la sicurezza della catena di approvvigionamento e quindi la protezione di ogni fase del ciclo di vita di un’applicazione containerizzata. Si va da “Design” e “Build” a “Run“, da “Manage & Automate” fino ad “Adapt“.
Il software open source è alla base della maggior parte delle tecnologie innovative, quali intelligenza artificiale e machine learning, edge computing, serverless computing e, non ultima, la containerizzazione.
Tuttavia, ci sono ancora alcuni miti e malintesi che circondano l’uso dell’open source e quindi anche della containerizzazione, e in molti casi portano le aziende a non adottare misure di sicurezza elementari o ad adottarle in modo inadeguato.
Mito 1: Chi utilizza tecnologie open source non deve preoccuparsi della sicurezza, se ne occupa la community
In linea di principio, l’open source è sinonimo di alta innovazione e sicurezza, sostenute da comunità con migliaia di collaboratori e, di solito, un gran numero di revisori del codice. Tuttavia, è necessario tenere conto di alcune raccomandazioni di base sulla sicurezza.
Ad esempio, quando si utilizzano i container, le aziende dovrebbero utilizzare solo immagini di container provenienti da fonti affidabili. Sono disponibili immagini di base verificate per il sistema operativo Linux e un gran numero di immagini certificate per diversi linguaggi di programmazione, middleware e database. Il livello di sicurezza può essere ulteriormente aumentato con la firma digitale, che conferma che il container applicativo non è stato modificato da terzi.
Inoltre, è necessario utilizzare un registro che contenga le funzioni di base per la gestione delle immagini dei container. Questo include, ad esempio, l’accesso alle immagini basato sui ruoli, che regola le autorizzazioni push e pull. È sempre importante che ci sia un flusso di lavoro chiaramente definito per l’accesso alle immagini dei container create esternamente e internamente. Idealmente, il registro supporta anche l’automazione dei criteri e dei flussi di lavoro per l’utilizzo delle immagini.
Oltre a verificare l’origine di un container applicativo, è importante controllarne anche il contenuto. Dopo tutto, l’analisi del codice del programma per quanto riguarda le vulnerabilità della sicurezza è un fattore di successo essenziale per lo sviluppo, l’implementazione e il funzionamento di applicazioni affidabili basate su tecnologie container. L’uso di scanner di sicurezza che rilevano le vulnerabilità nelle immagini è consigliato per un rapido esame del contenuto del container.
Infine, ma non meno importante, per la sicurezza è fondamentale che un’azienda utilizzi una piattaforma che supporti lo sviluppo e la scalabilità coerente delle applicazioni containerizzate. Aspetti importanti sono la gestione del ciclo di vita, la gestione delle identità e degli accessi e la protezione dei dati della piattaforma.
Mito 2: I tradizionali concetti di sicurezza per lo sviluppo applicativo sono sufficienti
I carichi di lavoro dei container sono distribuiti su molte infrastrutture, dal data center fino all’edge. La sicurezza tradizionale basata sul perimetro non può più essere applicata in questo ambiente tecnologico. Al contrario, è necessario proteggere ogni livello dello stack infrastrutturale e ogni fase del ciclo di vita dell’applicazione. Questo è l’unico modo per garantire una sicurezza globale.
Ad esempio, è necessario tenere conto del gran numero di dispositivi che servono come base per i carichi di lavoro dei container nell’area dell’Internet of Things. Questi dispositivi devono essere sempre mantenuti al livello più aggiornato di patch, con la possibilità di un monitoraggio continuo.
In linea di principio, un’azienda può affidarsi a meccanismi di sicurezza già collaudati, ma questi devono essere adattati al nuovo contesto. Nell’era del software-defined everything, in cui il software è disaccoppiato dall’hardware e vengono utilizzate diverse tecnologie basate sul software, sono necessari anche altri concetti di sicurezza, ad esempio per le reti o per lo storage software-defined.
Mito 3: La sicurezza è un argomento che riguarda solamente la fase di audit
In molti casi, la realtà attuale è ancora quella che considera la sicurezza come un ostacolo che impedisce lo sviluppo. Di conseguenza, il tema della sicurezza viene spesso affrontato solo alla fine di un processo di sviluppo, spesso solo quando la certificazione o le normative legali lo richiedono. Dal punto di vista della sicurezza, un approccio di questo tipo è problematico e poco efficiente. La sicurezza deve essere considerata come parte di un intero processo e deve essere definita anche come obiettivo del progetto. Non si tratta solo di questioni tecnologiche, ma anche di dipendenze organizzative e di stretta collaborazione o responsabilità condivisa da tutti gli attori del processo.
La sicurezza non è quindi un argomento di puro audit né deve limitarsi alla scansione delle vulnerabilità. Piuttosto, il tema più attuale per garantire la massima sicurezza è la Security-by-Design.
Quando si parla di container e di “creare una volta, distribuire ovunque”, ciò significa che nel processo di costruzione viene creato un prodotto privo di errori che viene utilizzato nelle operazioni produttive. Nel farlo, lo sviluppatore deve anche tenere conto dell’immutabilità desiderata dei container. Nella realtà, l’applicazione di patch ai container attivi non è una strada percorribile, i container devono sempre essere creati e distribuiti da zero.
A questo punto, entrano in gioco anche gli approcci di test shift-left, ovvero la conduzione di test nelle prime fasi del processo di sviluppo. Le conseguenze sono una risoluzione più rapida dei problemi e, in ultima analisi, una maggiore qualità dei prodotti. In linea di principio, si tratta di stabilire una pipeline DevSecOps in cui gli aspetti della sicurezza sono integrati nel processo DevOps. Idealmente, la sicurezza viene implementata il più vicino possibile al codice sorgente in una forma riproducibile e automatizzabile: si parla di Security as Code. Questo garantisce anche la velocità, l’agilità e la flessibilità che DevOps nella sostanza promette.
Mito 4: Non sono gli sviluppatori a doversi preoccupare della sicurezza
Con oltre un milione di progetti open source, è facile per gli sviluppatori prendere ciò che altri hanno sviluppato, adattarlo alle esigenze aziendali e distribuirlo nel proprio ambiente. Tuttavia, se non ci sono linee guida da seguire per gli sviluppatori, è altrettanto facile perdere di vista le potenziali vulnerabilità esistenti a causa delle numerose versioni di librerie presenti in azienda.
Di conseguenza, sono indispensabili policy e regole chiare, ad esempio per controllare e automatizzare la creazione di container. Le imprese dovrebbero anche considerare le best practice per la sicurezza nella pipeline delle applicazioni, soprattutto per quanto riguarda l’integrazione dei test di sicurezza automatizzati nella pipeline, compresi gli strumenti di registro, IDE e CI/CD. Ad esempio, per la scansione in tempo reale delle vulnerabilità note e di quelle nuove, è possibile arricchire gli scanner con la CI (Continuous Integration).
Per una sicurezza elevata sono importanti anche policy automatizzate che consentono alle aziende di gestire la distribuzione di container e cluster dal punto di vista della sicurezza. Ciò include la distribuzione di container basata su criteri che consentono o negano il download di immagini da registri specifici e la gestione multi-cluster basata su criteri per la distribuzione o la migrazione tra diversi cloud provider.
Porre l’attenzione sul ciclo di vita di uno stack di soluzioni
I vari miti citati dimostrano che il tema della sicurezza deve avere una priorità molto più alta, sia dal punto di vista organizzativo che tecnologico, durante l’intero ciclo di vita di un’applicazione containerizzata, ossia nelle fasi di “Design“, “Build“, “Run“, “Manage & Automate” e “Adapt“.
La fase di progettazione (Design) consiste nell’identificare i requisiti di sicurezza, mentre la fase di realizzazione (Build) consiste nell’integrare la sicurezza direttamente nello stack applicativo. Per alleggerire l’onere delle operazioni (Run) e dello sviluppo, è necessario utilizzare piattaforme affidabili con funzioni di sicurezza avanzate, la cui base è stata sviluppata tenendo conto della sicurezza della catena di approvvigionamento per il sistema operativo e il software della piattaforma. La fase “Manage & Automate” comprende l’automazione dei sistemi per la sicurezza e la conformità, mentre “Adapt” prevede infine aggiornamenti regolari in caso di cambiamenti nel panorama della sicurezza.
In linea di principio, piattaforme open source e container, in combinazione con gli ambienti di runtime cloud-native, sono oggi i principali motori dell’innovazione. Come in ogni settore dell’IT, la questione della sicurezza non deve essere trascurata. Con un approccio olistico che mette in primo piano la sicurezza della catena di approvvigionamento e include i container in tutte le fasi – durante la creazione, l’implementazione e l’esecuzione – nulla ostacola la riduzione del rischio. E la sicurezza non è più vista come un ostacolo, ma piuttosto come un fattore abilitante di una moderna infrastruttura IT.
