Cinque miti da sfatare sulla sicurezza dei container

Ci sono ancora alcuni luoghi comuni che accompagnano l’uso dell’open source e quindi anche dei container. Spesso questa disinformazione porta le aziende a non adottare misure di sicurezza elementari o ad adottarle in maniera inadeguata. Marie Innes, Solution Architect di Red Hat, illustra questi luoghi comuni e spiega come le aziende che hanno adottato i container possono mettersi in sicurezza.

Pubblicato il 27 settembre 2022

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.

Ecco cinque luoghi comuni che è il momento di sfatare:

1° Mito: 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.

2° Mito: 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.

3° Mito: 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.

4° Mito: 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.

5° Mito: 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.

 



Contenuti correlati

  • Altair soluzioni AI HPC simulazione aerospace Farnborough Airshow
    AI in simulazione e HPC con Altair al Farnborough Airshow 2024

    Altair porta in mostra le ultime innovazioni nel campo della simulazione ingegneristica, dell’intelligenza artificiale (AI) e del calcolo ad alte prestazioni (HPC) al Farnborough International Airshow 2024, in programma dal 22 al 26 luglio presso il Farnborough...

  • Giochi olimpici di Parigi 2024: il fattore sicurezza

    Dopo la conclusione dei campionati europei di calcio ‘Euro 2024’, l’attenzione degli appassionati di sport è ora rivolta ai Giochi Olimpici di Parigi di quest’estate, uno dei più grandi palcoscenici del mondo che proprio per questo è...

  • Security Summit sbarca a Cagliari

    L’innovazione digitale è certamente motore di sviluppo per il settore turistico alberghiero, così come può avere enormi potenzialità per le piccole e medie imprese del Made in Italy; imprescindibile è, tuttavia, la consapevolezza dei rischi cyber che...

  • Fortinet headquarter
    Cybersecurity e trasparenza, Fortinet firma le linee guida Secure by Design della CISA

    Fortinet ha rafforzato il proprio impegno di lunga data verso una trasparenza radicale e responsabile, essendo tra i primi firmatari delle linee guida Secure by Design sviluppate dalla Cybersecurity and Infrastructure Security Agency (CISA). Questo atto volontario...

  • Direttiva NIS2: uno studio Zscaler mette in evidenza criticità e opportunità

    Una nuova ricerca di Zscaler suggerisce una discrepanza tra la fiducia che le aziende europee hanno di raggiungere l’obiettivo della conformità alla direttiva NIS 2 prima della scadenza del 17 ottobre 2024, quando entrerà in vigore, e...

  • Margo, l’iniziativa di standard aperto per l’interoperabilità proposto da ABB

    Ospitata dalla Linux Foundation e guidata da un gruppo fondatore di fornitori di soluzioni di automazione industriale, tra cui ABB Process Automation e ABB Machine Automation (B&R), l’iniziativa denominata Margo mira a sbloccare l’interoperabilità all’edge, uno strato...

  • Sicurezza e rischi nell’era digitale

    Rischi e pericoli sulle macchine cambiano con l’evoluzione della tecnologia: il nuovo Regolamento Macchine adegua la normativa ai requisiti relativi ai sistemi con algoritmi evolutivi, digitalizzazione, robotica, software e cybersecurity Pubblicato in Gazzetta Ufficiale dell’Unione Europea il...

  • Layer di collegamento tra produzione e management

    Come si crea uno ‘strato software’ che faccia realmente convergere IT e OT? Efficienza, sicurezza e interoperabilità sono le 3 parole chiave A cosa ci riferiamo quando parliamo di Production & Management Integration Layer? È presto detto....

  • Arduino ad Automate 2024: potere a una nuova generazione di ingegneri, con l’Industrial IoT

    Ad Automate Show 2024 (Chicago 6-9 maggio) Arduino svela come l’hardware e il software open source stanno trasformando il mondo dell’automazione industriale in ogni settore, grazie a una prospettiva originale capace di offrire opportunità inedite e impensabili...

  • sicurezza AI Axitea
    AI e sicurezza: come prevenire gli infortuni sul lavoro

    Di Marco Bavazzano, Amministratore Delegato di Axitea Ciclicamente, e con dispiacere, ci troviamo a leggere o ascoltare di storie di infortuni sul lavoro che hanno purtroppo spesso un epilogo tragico, con conseguenti bilanci, commenti e iniziative sulle...

Scopri le novità scelte per te x