Jump to section

Cos'è la sicurezza dei container?

Copia URL

Red Hat nominata Leader nel Gartner® Magic Quadrant™ 2023

Nel Gartner Magic Quadrant 2023 per la gestione dei container, Red Hat occupa le posizioni più alte per la sua capacità di esecuzione e la completezza della sua visione.

La sicurezza dei container 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.

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.

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 ottenere container affidabili e scalabili, è necessario integrare la sicurezza già nel flusso dei container e proteggere 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?

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)?

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.

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 ITC 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. Red Hat OpenShift integra nella piattaforma funzioni di sicurezza che completano quelle offerte dalle soluzioni dei partner, per proteggere applicazioni e container lungo l'intero ciclo di vita DevOps.

Offre inoltre molto altro materiale utile:

  • Orchestrazione e gestione di container web scale
  • Web console completa con funzionalità di collaborazione multiutente
  • Interfacce CLI e IDE
  • Integrazione con CI
  • Automazione di build e source to image
  • Automazione del deployment
  • Supporto per volumi di storage remoti
  • Installazione e amministrazione semplificate
  • Una vasta gamma di linguaggi di programmazione, framework e servizi supportati
Container thumbnail image

"KuppingerCole Report Leadership Compass: Container security"

Ottieni una panoramica completa del mercato della sicurezza dei container e di Kubernetes per valutare e selezionare la soluzione giusta.

Keep reading

ARTICOLO

Container e VM

I container Linux e le macchine virtuali (VM) sono entrambi pacchetti di ambienti di elaborazione che combinano vari componenti IT e li isolano dal resto del sistema.

ARTICOLO

Cos'è l'orchestrazione dei container?

Definiamo orchestrazione dei container l'automazione dei processi di deployment, gestione, scalabilità e networking dei container.

ARTICOLO

Cos'è un container Linux?

Un container Linux è un insieme di processi, isolati dal resto del sistema, che esegue un'immagine distinta contenente tutti i file necessari per supportare tali processi.

Scopri di più sui container

Prodotti

Una piattaforma applicativa aziendale che offre servizi verificati per consentire la distribuzione delle app sulle infrastrutture preferite.

Risorse

Checklist

10 considerazioni sui deployment Kubernetes

Checklist

Sei considerazioni per scegliere la piattaforma Kubernetes giusta

Serie Open Answers: Cos'è Red Hat OpenShift?

Formazione

Corso di formazione gratuito

Running Containers with Red Hat Technical Overview

Corso di formazione gratuito

Containers, Kubernetes and Red Hat OpenShift Technical Overview

Corso di formazione gratuito

Developing Cloud-Native Applications with Microservices Architectures