• BitMAT
  • BitMATv
  • Top Trade
  • Linea EDP
  • Itis Magazine
  • Speciale Stampanti
  • Industry 4.0
  • Sanità Digitale
  • ReStart in Green
  • Redazione
  • Contattaci
LineaEDP
    Facebook Twitter Vimeo LinkedIn RSS
    Trending
    • Fintech e criptovalute: due mondi così vicini, eppure così distanti
    • Piwik PRO fa l’analytics a misura di azienda
    • Certificazione Common Criteria per Veeam
    • Come ridurre i costi delle Telco
    • Sostenibilità digitale delle imprese: la Prassi UNI ora disponibile
    • Digital Italy Summit 2023. Costruire la nazione digitale: a Roma dal 14 al 16 novembre
    • Vancouver, l’IA generativa al servizio del business
    • Webgate400 e Power-b10: la rivoluzione html5 responsive per le applicazioni RPG
    Facebook Twitter Vimeo LinkedIn RSS
    LineaEDP
    • Cio
    • Cloud
    • Mercato
    • News
    • Tecnologia
    • Case History
    • Report
    • Sicurezza
    • IOT
    LineaEDP
    Sei qui:Home»Rubriche»Attualità»Container: sfida sicurezza

    Container: sfida sicurezza

    Di Redazione LineaEDP08/10/2018Lettura 6 Min
    Facebook Twitter LinkedIn Reddit Telegram WhatsApp Email

    Qualys pone l’attenzione sull’integrazione della sicurezza nelle tre fasi di deployment dei container

    A cura di Hari Srinivasan, Qualys

    L'adozione dei container ha avuto una crescita esponenziale negli ultimi anni e l'importanza della messa in sicurezza delle applicazioni create dai team DevOps e distribuite nei container è cresciuta di pari passo. Le misure di protezione configurate dai responsabili della sicurezza devono coprire l'intero ciclo di vita del container ed integrarsi nella pipeline DevOps in modo efficace e discreto. Riuscirci richiede conoscenza della tecnologia di containerizzazione Docker e l'adozione di strumenti e processi ideati su misura per questi ambienti.

    Le sfide sulla sicurezza dei container

    I container introducono problemi di sicurezza e compliance particolari, la maggior parte dei quali sono originati dalle caratteristiche che gli sviluppatori trovano così attraenti, come la possibilità di creare un pacchetto dell'applicazione e delle sue dipendenze in assenza di un sistema operativo ospite. Tra questi problemi annoveriamo l'uso di software non verificato proveniente da repository pubblici, che contiene spesso vulnerabilità irrisolte, e il deployment di container con configurazioni insicure o a valori predefiniti.

    I container, inoltre, comunicano tra loro direttamente attraverso porte di rete esposte; sottraendosi ai controlli esercitati dall'host e restando quindi difficili da monitorare a causa della loro natura effimera.

    Obiettivi di sicurezza per i container

    Sono quattro gli obiettivi di sicurezza che è necessario perseguire per i container. Innanzi tutto, occorre ottenere visibilità sull'intero ambiente del container identificando e tracciando tutti i deployment esistenti in locale e nel cloud.

    In secondo luogo, è necessario gestire le vulnerabilità del container e contemporaneamente prevenire e rilevare le intrusioni. In terzo luogo, bisogna sfruttare le API REST per integrare i prodotti DevOps e gli strumenti di messa in sicurezza dei container.

    Infine, va ripensata la funzionalità di risposta agli incidenti del programma di sicurezza del container, specialmente perché i container vulnerabili non vengono “rattoppati” ma sostituiti con nuove unità create con un'immagine aggiornata.

    I team di sicurezza devono aggiornare il programma di risposta agli incidenti, dotarlo della capacità di raccogliere informazioni sul nuovo sistema operativo dei container e sulla piattaforma di orchestrazione, al fine di pianificare l'introduzione del modello “sostituzione completa” nel programma di risposta agli incidenti.

    Protezione della pipeline del container

    Devono essere messe in sicurezza tutte e tre le fasi del deployment del container, costruzione, implementazione e runtime, dove ognuna presenta particolarità e requisiti diversi. Approfondiamo ogni fase.

    Costruzione

    In questa prima fase, l'obiettivo principale consiste nel bloccare l'ingresso di 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 pubblico, pratica assai comune tra gli sviluppatori di container.

    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 negli strumenti CI/CD scelti dal team DevOps. Occorre dotarsi della flessibilità di definire i parametri per bloccare le immagini non sicure, ad esempio la presenza di vulnerabilità con un punteggio di gravità di 3, 4 o 5, di rilevare il mancato rispetto dei requisiti di compliance e di individuare l'utilizzo aperto di secrets nelle immagini.

    Grazie a queste integrazioni, i responsabili della sicurezza potranno concedere agli sviluppatori l'accesso agli strumenti di sicurezza, così che possano svolgere preventivamente alcune attività di sicurezza direttamente nel programma CI/CD senza delegarle al gruppo di sicurezza. Gli sviluppatori potranno accedere, ad esempio, ai risultati delle scansioni e operare interventi di remediation direttamente dall'interfaccia del loro programma CI/CD.

    Implementazione

    In questa fase è essenziale assicurarsi che le immagini già presenti nei repository siano prive di vulnerabilità. Fare l'inventario di registri e repository e, man mano che le immagini vengono aggiunte, avviare analisi di ricerca delle vulnerabilità. È buona norma, inoltre, pianificare scansioni quotidiane automatiche per cercare nuove eventuali vulnerabilità e controllare sistematicamente tutte le immagini che ogni giorno vengono aggiunte ai repository.

    Accertare anche l'affidabilità e la rispettabilità delle fonti da cui la propria organizzazione preleva le immagini e assicurarsi che le immagini siano aggiornate e prive di vulnerabilità conosciute. Affidarsi a servizi di certificazione della validità, come Docker Notary, per firmare le immagini e assicurarsi che il proprio ambiente ospiti solo immagini affidabili.

    Runtime

    Ora che le immagini dei container sono nel registro dell'azienda pronte per la produzione, è necessario disporre di visibilità costante e capacità di monitoraggio continue sugli ambienti runtime, oltre che della 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.

    Un accorgimento utile in questo scenario consiste nel contrassegnare i container già attivi nel sistema che evidenziano deviazioni rispetto al comportamento “immutabile” dell'immagine di partenza. Tali deviazioni potrebbero, infatti, indicare una falla.

    Dal momento che i container sono uguali a un'immagine, è essenziale definire il comportamento predefinito dell'applicazione containerizzata per rilevare qualsiasi deviazione sospetta, cioè attività impreviste come chiamate al sistema, processi e comunicazioni.

    I team di sicurezza devono determinare dove sono memorizzate tali immagini nell'ambiente runtime e individuare sia le versioni attive che quelle latenti.

    Una volta individuati i container compromessi, il programma di sicurezza dovrà consentire all'utente di applicare contromisure, come il blocco dell'esecuzione del container o la messa in quarantena, e di analizzare in modo approfondito i dettagli delle anomalie per determinare l'origine del problema. Generalmente, questa attività non interferisce con il normale funzionamento del sistema perché sarà possibile sostituire l'unità compromessa attivando un nuovo container dalla stessa immagine di partenza.

    Una strategia migliore sarebbe usare uno strumento che convalidi automaticamente la congruenza dell'immagine alle policy di sicurezza e blocchi la generazione di nuovi container usando immagini non autorizzate. Qui entrano in gioco i servizi di orchestrazione, come Kubernetes, che impediscono ai container compromessi di superare i controller di ammissione ed entrare nell'ambiente.

    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.

    Sintesi

    Ci auguriamo che questo articolo abbia gettato un po' di luce sui particolari problemi di sicurezza che riguardano i container e come affrontarli nel corso del loro intero ciclo di vita: bloccare l'ingresso di immagini vulnerabili nei repository durante la fase di costruzione; mantenere sicure le immagini inviate nei registri durante la fase di implementazione ed eseguire analisi delle immagini pronte per la produzione nella fase di runtime per individuare e gestire i container compromessi.

    container Qualys sicurezza
    Condividi: Facebook Twitter LinkedIn Reddit Telegram WhatsApp Email
    Redazione LineaEDP
    • Facebook
    • Twitter

    LineaEDP è parte di BitMAT Edizioni, una casa editrice che ha sede a Milano con copertura a 360° per quanto riguarda la comunicazione rivolta agli specialisti dell'lnformation & Communication Technology.

    Correlati

    Come ridurre i costi delle Telco

    22/09/2023

    Sostenibilità digitale delle imprese: la Prassi UNI ora disponibile

    22/09/2023

    Digital Italy Summit 2023. Costruire la nazione digitale: a Roma dal 14 al 16 novembre

    22/09/2023
    Newsletter

    Iscriviti alla Newsletter per ricevere gli aggiornamenti dai portali di BitMAT Edizioni.

    BitMATv – I video di BitMAT
    Guido Pellegata: “46 anni di lavoro… senza lavorare”
    Attacco hacker? Reagire in modo efficace con IBM Security QRadar Suite
    Exor aiuta gli OEM
    SPECIALE ITG: IL MEGLIO DI SPS 2023
    Emerson: Floor to Cloud
    Defence Tech

    Certificazione Common Criteria per Veeam

    22/09/2023

    App spia: ESET lancia l’allarme

    21/09/2023

    Armis lancia Armis Centrix

    20/09/2023

    Kaspersky Digital Footprint è sempre più Intelligence

    19/09/2023
    Report

    Software: perché sceglierlo di qualità

    19/09/2023

    Modernizzazione del mainframe, risparmio sicuro

    13/09/2023

    Intelligenza Artificiale Responsabile: istruzioni da Cefriel

    12/09/2023

    Field service management: nuove sfide per i CSP

    01/09/2023
    Chi Siamo
    Chi Siamo

    BitMAT Edizioni è una casa editrice che ha sede a Milano con una copertura a 360° per quanto riguarda la comunicazione online ed offline rivolta agli specialisti dell'lnformation & Communication Technology.

    Facebook Twitter Vimeo LinkedIn RSS
    Rete BitMAT
    • Bitmat
    • BitMATv
    • Top Trade
    • LineaEdp
    • ItisMagazine
    • Speciale Sicurezza
    • Industry 4.0
    • Sanità Digitale
    • Redazione
    • Contattaci
    NAVIGAZIONE
    • Cio
    • Cloud
    • Mercato
    • News
    • Tecnologia
    • Case History
    • Report
    • Sicurezza
    • IOT
    Ultime

    Fintech e criptovalute: due mondi così vicini, eppure così distanti

    24/09/2023

    Piwik PRO fa l’analytics a misura di azienda

    22/09/2023

    Certificazione Common Criteria per Veeam

    22/09/2023
    • Contattaci
    • Cookies Policy
    • Privacy Policy
    • Redazione
    © 2012 - 2023 BitMAT Edizioni - P.Iva 09091900960 - tutti i diritti riservati - Iscrizione al tribunale di Milano n° 293 del 28-11-2018 - Testata giornalistica iscritta al ROC

    Scrivi nel campo e premi Invio per cercare. Premi Esc per annullare