Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Cos’è la sicurezza dei container?

La sicurezza dei container è il processo che consente di proteggere i container da malware, perdite di dati e altre minacce in ogni fase del loro ciclo di vita. Dal momento in cui si crea l’immagine di un container al momento in cui questa viene caricata su un registro o distribuita in un ambiente di produzione, è necessario adottare strumenti e processi per garantire che il container sia protetto da potenziali minacce.

Questo articolo presenta tutte le informazioni necessarie sulla gestione della sicurezza dei container in tutto il loro ciclo di vita.

Minacce comuni alla sicurezza dei container

Per comprendere cos’è la sicurezza dei container è necessario capire quali sono i fattori che li minacciano.

Le minacce alla sicurezza dei container assumono moltissime forme diverse, che non possono essere indicate tutte in questa sede. Per questo motivo, presentiamo di seguito i tipi di minacce più comuni:

Malware nel container

Il malware è un codice dannoso che viene diffuso in un container. Può insinuarsi nei container in più di una fase del loro ciclo di vita. Un hacker che compromette un ambiente CI/CD potrebbe inserire un malware nei repository di codice sorgente che vengono successivamente utilizzati per creare le immagini dei container. Oppure, potrebbe violare il registro di un container e sostituire le immagini legittime con immagini dannose che contengono malware. Un terzo tipo di attacco malware consiste nell’indurre gli utenti a scaricare immagini dei container dannose da fonti esterne.

In tutti questi casi, i malware non vengono rilevati prima che un container venga lanciato ed entri in un ambiente di runtime, il che potrebbe portare a molti problemi per la sicurezza, ad esempio la raccolta di dati sensibili da un’applicazione o l’interruzione del funzionamento di altri container.

Assegnazione di privilegi non sicuri

Tipicamente, i container dovrebbero operare in modalità non privilegiata, il che significa che non devono avere accesso a risorse al di fuori dell’ambiente containerizzato che controllano direttamente. Le comunicazioni tra i container dovrebbero inoltre essere limitate, a meno che non vi siano precise ragioni per consentire la comunicazione (come ad esempio avverrebbe per un container sidecar che raccoglie i registri del container di un’applicazione).

Quando ai container vengono assegnati più privilegi rispetto a quelli strettamente necessari, si determinano rischi per la sicurezza. Privilegi non sicuri sono solitamente causati da configurazioni problematiche stabilite dall’agente di orchestrazione del container. Per esempio, container orchestrati da Kubernetes potrebbero avere più privilegi rispetto a quanti ne avrebbero se i contesti di protezione e le policy di rete di Kubernetes non fossero definiti in modo adeguato.

Container con dati sensibili

I container non sono pensati come strumenti di archiviazione di dati. Eppure, a volte le aziende commettono l’errore di archiviare informazioni sensibili all’interno delle immagini dei container. Per esempio, tutto il codice sorgente di Vine è stato esposto quando è stato scoperto un registro di un container che Vine riteneva privato ma che in realtà era accessibile al pubblico e ospitava immagini che contenevano il codice sorgente. (A essere onesti, questo episodio è avvenuto agli albori dell’era dei container, quando le migliori prassi per la gestione delle immagini non erano ancora state chiaramente stabilite. È comprensibile che un errore come questo possa essersi verificato.)

Gestione della sicurezza nel ciclo di vita dei container

Per evitare rischi come questo, le aziende devono implementare controlli di sicurezza in grado di proteggere i container in tutte le fasi del loro ciclo di vita. Quella che segue è una panoramica delle principali fasi di questo processo e dei tipi di minacce che i team devono gestire per ognuna di esse. 

Pipeline di sviluppo

Il ciclo di vita di un container inizia con la pipeline di sviluppo, il momento in cui viene creato il codice che verrà poi inserito nei container.

Come già sottolineato, gli hacker che manomettono gli strumenti di sviluppo possono inserire codici dannosi nei repository del codice sorgente e causare i cosiddetti attacchi alla catena di distribuzione del software. Se gli sviluppatori non rilevano in tempo questi codici dannosi, prima di utilizzarli per creare le immagini, essi possono introdursi nella pipeline e negli ambienti di produzione.

Controllare gli accessi per gli strumenti di sviluppo e applicare il principio dei privilegi minimi aiuta a evitare questo rischio. In questo caso, è anche consigliabile scansionare il codice sorgente alla ricerca di malware prima di utilizzarlo e distribuirlo.

Immagini dei container

L’immagine di un container è il file che contiene il codice necessario per eseguire il container. L’immagine non rappresenta solo il container, ma è come una struttura di base alla quale si appoggia il suo funzionamento. Quindi, se l’immagine di un container contiene malware o dati sensibili, i container creati da essa non saranno sicuri.

Come già menzionato, è buona norma scansionare il codice sorgente interno per garantire che eventuali malware non raggiungano le immagini dei container.

Tuttavia, dal momento che le immagini dei container spesso contengono risorse importate da terze parti, scansionare il proprio codice non basta. Bisognerebbe anche scansionare l’intera immagine del container utilizzando uno scanner che valuterà il contenuto dell’immagine e segnalerà eventuali componenti riconosciuti come non sicuri. La scansione delle immagini non può rilevare ogni tipo di minaccia (in particolare, i malware personalizzati non ancora registrati nei database delle vulnerabilità potrebbero eludere la sorveglianza), ma avvertono della maggior parte delle minacce conosciute.

Registri dei container

Una volta create le immagini dei container, queste vengono di solito archiviate in un registro di container dal quale gli utenti possono scaricarle.

Per gestire correttamente la sicurezza dei registri, è importante seguire alcune migliori prassi. Innanzi tutto, è consigliabile applicare controlli degli accessi per garantire che solo gli utenti autorizzati possano accedere alle immagini presenti nel registro. Fare questo aiuta a evitare le fughe accidentali di dati che potrebbero verificarsi se le immagini contengono applicazioni o dati privati.

In secondo luogo, è necessario controllare regolarmente i registri per sapere quali immagini contengono. Le immagini non aggiornate che contengono versioni obsolete di un’applicazione dovrebbero essere rimosse per minimizzare la superficie di attacco.

Infine, quando si lavora con immagini di container desunte de registri di terze parti, è necessario accertarsi di utilizzare una fonte affidabile. Metà delle immagini presenti in Docker Hub, il registro di container pubblico più conosciuto, contiene almeno una vulnerabilità in termini di sicurezza. E, a volte, gli autori degli attacchi caricano deliberatamente immagini dannose con nomi (come mysqlimage o nginxapp) pensati appositamente per attrarre gli ignari utenti. Evitare pertanto di utilizzare immagini provenienti da registri pubblici non ufficiali e assicurarsi di scansionare tutte le immagini, indipendentemente dalla fiducia che si ripone nell’organizzazione che le ha create.

Ambiente di runtime del container

La fase finale del ciclo di vita di un container è il runtime. È il momento in cui i container vengono distribuiti in un ambiente live utilizzando le immagini scaricate dal registro.

La sicurezza del runtime è uno degli aspetti più complessi della sicurezza dei container, poiché coinvolge diverse componenti in movimento che possono variare in base al tipo di stack in uso. In molti casi, tuttavia, la sicurezza di runtime si basa sulla protezione di:

  • Runtime del container: È il processo nel server che esegue effettivamente i container. Bisogna assicurare che il software di runtime sia aggiornato e protetto dalle vulnerabilità conosciute.
  • Agente di orchestrazione: L’agente di orchestrazione del container distribuisce e gestisce il container. Molti agenti di orchestrazione offrono diversi strumenti per limitare i privilegi e massimizzare la sicurezza, ma è anche necessario affidarsi a strumenti di monitoraggio e analisi di terze parti per consentire di rilevare i problemi di sicurezza a livello di agente di orchestrazione.
  • Nodi: I nodi sono i server che ospitano i container. È necessario proteggere il sistema operativo, gli account utente, le configurazioni di rete e le altre risorse dei nodi per fare in modo che una violazione a livello di nodo non consenta agli autori di un attacco di danneggiare l’ambiente del container.

Sicurezza continua dei container

Il ciclo di vita di un container è un processo circolare e continuo. Dopo che il container di un’applicazione è stato distribuito in un ambiente di runtime, il ciclo ricomincia quando l’applicazione viene aggiornata, il che determina che una nuova serie di container ripercorra la pipeline. Ogni nuovo container potrebbe contenere nuovi rischi.

Pertanto, la gestione della sicurezza dei container è un processo senza fine. È necessario monitorare continuamente i rischi in tutto il ciclo di vita dei container e aggiornare gli strumenti di monitoraggio, i database delle vulnerabilità e le configurazioni per garantire di aderire sempre alle migliori prassi previste per la sicurezza dei container anche quando l’ambiente evolve.