Cos'è la sicurezza dei container?

La sicurezza dei container consiste nella protezione delle applicazioni containerizzate da malware e altre vulnerabilità. Prevede la definizione e il rispetto di procedure di creazione, deployment e runtime tese a proteggere i container Linux, dalle applicazioni che supportano all'infrastruttura su cui si basano. 

Man mano che le organizzazioni adottano modelli di progettazione basati su microservizi e tecnologie per container, come Docker e Kubernetes, i team di sicurezza devono sviluppare soluzioni per la sicurezza dei container che agevolino questi cambiamenti all'infrastruttura. Quella dei container deve essere una sicurezza integrata e continua e supportare il profilo di sicurezza complessivo di un'azienda. 

L'agente di orchestrazione (nello specifico Kubernetes) è essenziale alla sicurezza dei container, e permette di accedere a dati di contesto completi che garantiscono visibilità e conformità, profilazione del rischio in base al contesto, networking e individuazione dei runtime. Le regole di Kubernetes in materia di deployment, pod, criteri di rete e altri sono alla base di un'efficace sicurezza dei container. I criteri di rete di Kubernetes, ad esempio, sono funzionalità di sicurezza integrate utilizzabili per controllare la comunicazione da pod a pod e per ridurre il raggio di azione di un attaccante.

In generale, questo significa che l'azienda deve:

• Proteggere il flusso dei container e l'applicazione
• Proteggere l'ambiente di deployment e l'infrastruttura dei container
• Proteggere i carichi di lavoro containerizzati durante il runtime

Scopri le iniziative di sicurezza dei container adottate dalle aziende.

In un ambiente di sviluppo software tradizionale, un'indagine sulla sicurezza può essere costituita da una serie di test condotti al termine dello sviluppo. Nei flussi di sviluppo moderni e cloud native, la superficie è molto più estesa e la sicurezza acquisisce un'altra complessità. Negli ambienti cloud native in cui i container sono il formato standard per la distribuzione delle applicazioni, il codice viene aggiornato frequentemente e inviato in più repository. Le errate configurazioni, o altri errori umani, possono causare l'accesso non autorizzato in vari punti del ciclo di sviluppo e deployment. Nella pratica, le falle nella sicurezza possono emergere ovunque. Per questo motivo la sicurezza deve essere un processo continuo.

Così come il deployment dei container viene gestito tramite l'automazione (utilizzando strumenti per l'orchestrazione dei container come Kubernetes), anche la sicurezza deve essere automatizzata. Tramite i principi DevSecOps (un concetto creato per aggiungere enfasi sulla sicurezza all'approccio DevOps), è possibile verificare e controllare il codice durante tutto il ciclo di sviluppo. In questo modo le vulnerabilità vengono identificate e corrette tempestivamente, invece di essere trascurate per poi diventare problemi più difficili da risolvere. Essendo i container immutabili, la loro sicurezza prevede l'applicazione di patch al codice in fase di creazione e non durante l'esecuzione, in modo che le vulnerabilità non emergano quando i container vengono eliminati e ricreati.

L'analisi delle immagini container alla ricerca di malware e altre vulnerabilità della sicurezza è un passaggio critico e deve rientrare in uno dei diversi livelli di sicurezza. Occorre tener conto della sicurezza dell'intera catena di distribuzione del software, cioè di tutte le fasi di sviluppo e distribuzione del software containerizzato, comprese le dipendenze e gli ambienti di runtime. 

Di seguito alcune strategie specifiche che considerano la sicurezza della catena di distribuzione:

• Contenuti attendibili e un repository di contenuti di livello enterprise offrono immagini già protette con sicurezza e controlli di accesso avanzati.
• Un approccio Zero Trust assegna i livelli di accesso più bassi possibili alle risorse critiche.
• Un approccio Policy as Code integra i controlli di sicurezza direttamente nella pipeline CI/CD.
• La firma e le verifiche stabiliscono attestazione e attendibilità, confermando che le immagini container non sono state manomesse.
• Le procedure GitOps facilitano la gestione delle configurazioni della sicurezza di container e applicazioni.

Scopri di più su Red Hat® Trusted Software Supply Chain

Acquisizione delle immagini

I container sono costituiti da livelli di file chiamati immagini. 

Uno strumento come Buildah consente di creare da zero immagini compatibili con OCI e Docker, con o senza un punto di partenza per l'immagine container esistente.

Le immagini container costituiscono il formato standard di distribuzione delle applicazioni negli ambienti cloud native, ma anche le aziende cloud native combinano i carichi di lavoro tra i provider di servizi cloud. La soluzione di sicurezza per container ideale supporta tutte le architetture, sia che l'infrastruttura venga eseguita su hardware privato, in un datacenter condiviso o in un cloud pubblico come Amazon Web Services (AWS), Microsoft Azure o Google Cloud Platform.

L'immagine di base, o golden image, è la più importante per la sicurezza, perché rappresenta il punto di partenza dalla quale vengono create le immagini derivate. La sicurezza del container inizia con l'individuazione di origini affidabili per le immagini di base. Conferma che l'immagine proviene da società o community open source note, si trova in un registro attendibile e che il codice sorgente dei componenti dell'immagine è disponibile.

Anche se si usano immagini affidabili, l'aggiunta di applicazioni e configurazioni introduce nuove variabili. Quando si introduce il contenuto esterno con il quale vengono realizzate le app, è necessario mantenere una gestione proattiva delle vulnerabilità.

• Usa uno scanner di immagini, integrato nel registro o distinto, per scansionare con regolarità tutte le immagini. Individua uno scanner che esegua l'analisi in base a linguaggi, pacchetti e livelli di immagine specifici.
• Identifica le immagini container modificate (anche note come errate configurazioni di container) che non rispettano i criteri o le procedure documentate, in modo da ridurre la probabilità e le conseguenze delle potenziali compromissioni.

Leggi l'articolo del blog sulla sicurezza dell'immagine dei container

Anticipazione e correzione delle vulnerabilità

L'ampia diffusione dei container è dovuta alla facilità di compilare, raggruppare e promuovere un'applicazione o un servizio, e tutte le relative dipendenze, per l'intero ciclo di vita e su diversi flussi di lavoro e destinazioni di deployment. Rispetto alla sicurezza, tuttavia, i container presentano alcune complessità. I container consentono di adottare una sicurezza più dettagliata a livello di carico di lavoro, ma introducono anche nuovi componenti per l'infrastruttura e superfici di attacco poco familiari. Una giusta soluzione per la sicurezza dei container deve garantire la sicurezza dell'infrastruttura del cluster, dell'orchestratore e delle applicazioni containerizzate in esecuzione.

I criteri e le checklist di sicurezza statici non si adattano alle esigenze di crescita dei container aziendali:

• La catena di distribuzione ha bisogno di più servizi correlati ai criteri di sicurezza.
• I team della sicurezza devono trovare un equilibrio fra le esigenze di rete e quelle di governance di un ambiente containerizzato.
• Gli strumenti utilizzati nelle fasi di creazione, gestione e assistenza devono prevedere diversi criteri di autorizzazione.

Un programma per la sicurezza dei container efficace mira a correggere le vulnerabilità in tempo reale e a ridurre la superficie di attacco prima del deployment delle immagini, conservando le informazioni sulla provenienza. Per esser certi che i container siano affidabili e scalabili, è necessario prevedere la sicurezza già nel flusso dei container e difendere l'infrastruttura.

Durante l'acquisizione delle immagini container, occorre porsi le seguenti domande:

• Le immagini container sono firmate? Provengono da origini affidabili?
• Da dove proviene l'immagine e come è possibile ricostruirla?
• Quando è stata eseguita l'ultima analisi di una determinata immagine?
• I livelli relativi a runtime e sistema operativo sono aggiornati?
• Con quale frequenza e velocità vengono aggiornati i container?
• I rischi per la sicurezza vengono identificati? Come vengono tracciati?

Scopri i modelli Kubernetes specifici per il deployment e l'orchestrazione dei container

Dopo aver ottenuto le immagini, il passo successivo consiste nella gestione dell'accesso e nella promozione di tutte le immagini container usate dal team, il che significa proteggere sia le immagini scaricate che quelle realizzate. L'impiego di un registro privato consente di controllare l'accesso con assegnazioni basate su ruoli, agevolando la gestione del contenuto tramite l'associazione dei metadati rilevanti al container. I metadati consentono di identificare e tracciare le vulnerabilità note. Il registro di container privato permette inoltre di automatizzare e assegnare criteri per le immagini container archiviate, riducendo gli errori umani che possono introdurre vulnerabilità nell'ambiente di container. I registri dei container con funzionalità di sicurezza di livello enterprise prevedono anche scanner integrati delle vulnerabilità.

Nel processo decisionale sulla gestione degli accessi occorre chiedersi quanto segue:

• Quali controlli degli accessi basati su ruoli è possibile usare per gestire immagini container?
• È possibile aggiungere tag per facilitare l'ordinamento delle immagini? È possibile applicare tag di approvazione alle immagini solo per gli ambienti di sviluppo, quindi per quelli di test e infine per quelli di produzione?
• Il registro offre metadati visibili che consentono di tenere traccia delle vulnerabilità note?
• È possibile usare il registro per assegnare e automatizzare i criteri (ad esempio controllando firme, scansioni di codici delle applicazioni e così via)?

Ebook: Incrementa la sicurezza del cloud ibrido

L'ultima fase del flusso è il deployment. Una volta completate le compilazioni, queste vanno gestite in base agli standard di settore, come quelli del Center for Internet Security (CIS) e del National Institute of Standards and Technology (NIST). In questa fase è necessario comprendere come automatizzare i criteri affinché vengano contrassegnate le build con problemi di sicurezza, soprattutto quando vengono individuate nuove vulnerabilità. Sebbene la scansione delle vulnerabilità continui a essere un aspetto importante, è solo una parte di un insieme più ampio di iniziative di sicurezza utilizzate per proteggere gli ambienti containerizzati.

Poiché applicare patch ai container non è mai una soluzione valida quanto ricrearli, l'integrazione dei test di sicurezza deve tenere conto dei criteri che generano nuove build automatiche. La prima parte di questo passaggio consiste nell'esecuzione di strumenti di analisi dei componenti in grado di registrare e contrassegnare i problemi. La seconda fase consiste nel definire gli strumenti necessari per un deployment automatico e basato su criteri.

Al momento di integrare i test di sicurezza e automatizzare il deployment, occorre porsi le domande seguenti:

• I container contengono vulnerabilità note che vanno corrette prima della distribuzione in un ambiente di produzione?
• I deployment sono stati configurati correttamente? Sono presenti container con privilegi eccessivi che non sono necessari? Viene utilizzato un filesystem root di sola lettura?
• Qual è il profilo di conformità rispetto ai benchmark CIS e NIST SP 800-190?
• L'isolamento dei carichi di lavoro considerati sensibili viene effettuato con funzionalità integrate come i criteri di rete e gli spazi dei nomi?
• Vengono utilizzate funzionalità di sicurezza integrate come SELinux, AppArmor, e i profili seccomp?

La sicurezza dei container continua dopo le fasi di test e di deployment e si estende all'esecuzione delle applicazioni containerizzate. Il rilevamento delle minacce, la sicurezza di rete e la risposta agli incidenti diventano più importanti.

Durante il runtime, le applicazioni possono incorrere in minacce non previste e provocate dallo sfruttamento delle vulnerabilità e degli errori di configurazione ignorati nelle fasi precedenti. Nella fase di runtime, la sicurezza deve esaminare le applicazioni che si comportano in modi non previsti. Il rilevamento delle anomalie durante il runtime consente di identificare l'escalation dei privilegi, le attività di cryptomining, flussi di rete non previsti, perdita di dati dai container e altri comportamenti non sicuri.

Anche la segmentazione della rete è un aspetto di cui tener conto per ridurre al minimo la superficie di attacco. In Kubernetes, i criteri di rete predefiniti consentono ai pod di comunicare con gli altri pod in un cluster. Applicando un approccio Zero Trust, è possibile evitare che un singolo pod compromesso danneggi tutti gli altri pod all'interno del cluster.

Infine, le strategie di risposta agli incidenti aiutano i team a rispondere adeguatamente agli eventi. Le azioni di risposta possono includere l'invio degli eventi a un sistema SIEM (Security Information and Event Management), l'invio di avvisi al proprietario dell'applicazione con informazioni dettagliate e azioni relative ai deployment da correggere e anche l'eliminazione e il riavvio automatico dei pod. La procedura consigliata è quella di ricostruire e ridistribuire i container problematici invece di applicare le patch ai container in esecuzione.

White paper: Un approccio multilivello alla sicurezza di Kubernetes e dei container

Un altro livello di sicurezza dei container è l'isolamento fornito dal nodo/sistema operativo host (SO) del container. È necessario un SO host che offra al container il massimo isolamento possibile. Questo costituisce un elemento di assoluta importanza nella difesa dell'ambiente di deployment del container. Il SO host in un ambiente Kubernetes containerizzato è condiviso tra più container, ed è gestito da un runtime del container che interagisce con Kubernetes per creare e gestire i container (o pod di container). 

Per evitare che un container compromesso possa danneggiare il SO host e tutti gli altri container, il SO host deve essere isolato dal container stesso. Per rendere resiliente la piattaforma containerizzata, lo spazio dei nomi di rete viene usato per isolare applicazioni e ambienti; lo storage viene connesso tramite montaggi protetti. Non configurare il runtime del container affinché condivida lo spazio dei nomi della rete host, lo spazio dei nomi IPC o lo spazio dei nomi UPC. Scegli un SO host ottimizzato per container e già reso sicuro e utilizza un motore di scansione delle vulnerabilità dell'host.

Una soluzione di gestione delle API deve includere funzionalità di autenticazione e autorizzazione, integrazione LDAP, controlli dell'accesso agli endpoint e limitazione della velocità.

Per decidere come difendere l'infrastruttura dei container, occorre tenere conto dei seguenti aspetti:

• Quali container devono poter accedere ad altri? In che modo vengono rilevati?
• Come viene effettuato il controllo degli accessi e la gestione delle risorse condivise (ad esempio rete e storage)?
• In che modo viene monitorata l'integrità del container?
• In che modo avviene la scalabilità automatica della capacità delle applicazioni per soddisfare la domanda?
• Come vengono gestiti gli aggiornamenti dell'host? Tutti i container devono essere aggiornati nello stesso momento?

Red Hat® OpenShift® include Red Hat Enterprise Linux®. Automatizza il ciclo di vita dell'applicazione containerizzata, integra la sicurezza nel flusso del container e consente la transizione da un approccio DevOps a una strategia DevSecOps. Il catalogo dei container consente di accedere a numerose immagini certificate, runtime del linguaggio, database e middleware, che possono essere eseguiti ovunque venga eseguito Red Hat Enterprise Linux. Le immagini Red Hat sono sempre firmate e verificate, per confermarne origine e integrità.

Red Hat monitora le sue immagini container per individuare vulnerabilità recenti appena riscontrate (con un indice di integrità costantemente aggiornato e pubblicamente visibile), oltre a rilasciare aggiornamenti della sicurezza e container ricompilati e pubblicati nel registro pubblico. Grazie all'integrazione con DevOps e strumenti di sicurezza, Red Hat Advanced Cluster Security for Kubernetes aiuta a difendersi dalle minacce e ad applicare criteri di sicurezza per ridurre al minimo il rischio operativo delle applicazioni.

Red Hat Service Interconnect permette l'accesso e la comunicazione reciproca tra container, riducendo al minimo il rischio aggiuntivo implicito per la sicurezza dell'organizzazione o i dati degli utenti.

I partner di Red Hat che offrono soluzioni di sicurezza possono fornire integrazioni certificate per estendere e migliorare le funzionalità di protezione dei container. La sicurezza di Red Hat OpenShift è integrata nella piattaforma, che si integra con le soluzioni dei nostri partner di sicurezza per proteggere le applicazioni e i container nell'intero ciclo di vita DevOps.

Offre inoltre molti altri aspetti utili:

• Orchestrazione e gestione di container su web
• Console web completa con funzionalità di collaborazione multi utente
• Interfacce CLI & IDE
• Integrazione con CI
• Automazione di build & source to image
• Automazione del deployment
• Supporto per volumi di storage remoti
• Installazione & amministrazione semplificate
• Una vasta gamma di linguaggi di programmazione, framework & servizi supportati

Scopri di più sull'integrazione delle protezioni con Red Hat® Advanced Cluster Security for Kubernetes