Cinque miti da sfatare sulla sicurezza dei container
L’open source è alla base della maggior parte delle tecnologie innovative, come l’intelligenza artificiale e machine learning, l’edge computing, il serverless computing e, non ultima, la containerizzazione. Come in ogni settore dell’IT, la questione della sicurezza non deve essere trascurata quando si utilizzano software open source e container. Ci sono alcuni preconcetti e luoghi comuni che impediscono un approccio olistico e multilivello alla sicurezza, che mette in primo piano la IT Security dell’intera catena logistica, considerando quest’ultima in tutte le sue tre fasi: creazione, distribuzione ed esecuzione. In questo modo, nulla ostacola l’utilizzo dei container con un fattore di rischio ridotto.
Secondo Marie Innes, Solution Architect di Red Hat, sono soprattutto cinque i luoghi comuni che è il momento di sfatare quando si parla di sicurezza dei container.
La comunità è l’unica responsabile della sicurezza delle tecnologie open source
L’open source è caratterizzato da un elevato livello di innovazione e sicurezza, sostenuto da una comunità composta da migliaia di collaboratori. Tuttavia, le aziende devono adottare alcune misure di base, ad esempio per le immagini utilizzate, il processo di creazione o la distribuzione. Soprattutto, è importante utilizzare solo immagini di container provenienti da fonti affidabili. Esempi sono quelle comprovate per il sistema operativo Linux o quelle certificate per linguaggi di programmazione, middleware e database. Oltre a verificarne l’origine, un’azienda dovrebbe anche controllarne il contenuto tramite un sistema di sicurezza che permetta di rilevare eventuali vulnerabilità. Inoltre, non c’è quasi modo di evitare l’uso di una piattaforma che supporti lo sviluppo e la scalabilità coerente delle applicazioni containerizzate, che dovrebbe offrire principalmente la gestione del ciclo di vita, delle identità e degli accessi e la protezione dei dati della piattaforma.
I concetti di sicurezza consolidati sono sufficienti.
Dal data center all’edge, il carico di lavoro dei container è distribuito su molte e diverse infrastrutture. Di conseguenza, anche ogni livello dello stack infrastrutturale e ogni fase del ciclo di sviluppo dell’applicazione deve essere protetto. In linea di principio, un’azienda può fare affidamento su meccanismi di sicurezza consolidati, ma questi devono essere adattati alle nuove circostanze. Nell’era del software-defined everything, in cui vengono utilizzate numerose tecnologie basate su software, sono necessari anche diversi livelli di sicurezza, ad esempio per la rete software-defined o lo storage software-defined.
La sicurezza riguarda solamente gli audit
La sicurezza è spesso vista come un ostacolo che impedisce alle attività di svilupparsi. Tale questione viene quindi frequentemente affrontata attivamente solo alla fine del processo di sviluppo. Invece, deve essere sempre considerata come parte di un intero corso di produzione. Non si tratta solo di questioni tecnologiche, ma soprattutto di dipendenze organizzative e di una stretta collaborazione tra tutti gli attori con responsabilità condivise. La sicurezza non può quindi essere una pura questione di audit, ma piuttosto, deve essere inserita all’interno dei processi di progettazione. Tornando ai container e all’obiettivo di “costruire una volta, distribuire ovunque”, ciò significa che il processo di creazione deve produrre un sistema privo di errori che venga utilizzato nelle operazioni produttive.
Le scansioni delle vulnerabilità sono sufficienti per garantirsi sicurezza
È giusto eseguire le scansioni di sicurezza dei container con strumenti che utilizzano database di vulnerabilità costantemente aggiornati. Poiché emergono continuamente nuove fragilità, le aziende devono controllare il contenuto degli elementi dei loro container nel momento in cui vengono scaricati e monitorare lo stato di sicurezza. Tuttavia, questo è solo un aspetto, poiché la sicurezza deve essere sempre intesa come un processo olistico e non può essere ridotta alla mera scansione delle vulnerabilità. Alla fine, si tratta sempre dell’intero ciclo di vita di uno stack di soluzioni. Ad esempio, si può implementare anche nella creazione di una pipeline DevSecOps che includa il monitoraggio della sicurezza delle applicazioni, la protezione della piattaforma e la reazione alle minacce del runtime.
La sicurezza non è compito degli sviluppatori
Con oltre un milione di progetti open source, gli sviluppatori possono adottare quelli esistenti con relativa facilità, adattarli alle proprie esigenze aziendali e utilizzarli in modo produttivo. Tuttavia, sono indispensabili anche policy e indicazioni regolamentari chiare, ad esempio per controllare e automatizzare la creazione dei container. Le aziende dovrebbero anche osservare best practice per la sicurezza applicativa, soprattutto tramite l’integrazione di test di sicurezza automatici. Affrontare questi diversi preconcetti dimostra come che il tema della sicurezza debba assumere una priorità molto più alta durante l’intero ciclo di vita di un’applicazione containerizzata, sia dal punto di vista organizzativo che tecnologico, ossia nelle fasi di “Design”, “Build”, “Run”, “Manage & Automate” e “Adapt”.
La fase di progettazione consiste nell’identificazione dei requisiti di sicurezza, mentre la fase di realizzazione nell’integrare direttamente la sicurezza nello stack applicativo. Per ridurre l’onere delle operazioni, è opportuno utilizzare piattaforme affidabili con funzioni di sicurezza avanzate. La fase Manage & Automate prevede l’automazione dei sistemi per la sicurezza e la conformità, e infine Adapt prevede aggiornamenti regolari in caso di cambiamenti nel panorama dell’IT Security. Con questo approccio olistico, che si concentra sulla sicurezza dell’intera catena di approvvigionamento, un’azienda sarebbe strutturata in modo ottimale per l’utilizzo dei container. La sicurezza non deve più essere vista come un ostacolo, ma può piuttosto come fattore abilitante di una moderna infrastruttura IT.
