I container sono ovunque: come li proteggi?

I container stanno aumentando di numero ogni giorno e sembrano essere ovunque, poiché le organizzazioni sono ansiose di raccogliere i numerosi vantaggi offerti da loro, come lo sviluppo agile di applicazioni e la distribuzione su tutte le piattaforme.

Molti credono inoltre che l'uso dei container possa aiutarli a ridurre al minimo i vincoli di sicurezza a causa della loro natura di breve durata. È vero o è solo un'altra errata percezione?

Sebbene i container non presentino insicurezze intrinseche, vengono spesso implementati in modo non sicuro, con conseguenti numerose sfide alla sicurezza.

Problemi di sicurezza durante la distribuzione di container

Il numero, la versatilità e lo stato effimero dei container distribuiti, oltre al fatto che i container devono comunicare con altre entità, portano le organizzazioni a non avere la capacità di possedere un'adeguata visibilità del traffico tra container.

A causa di questa mancanza di visibilità, i container vengono spesso dimenticati e le misure di prevenzione delle intrusioni e i controlli di sicurezza diventano inefficaci, aumentando la superficie di attacco e quindi il rischio aziendale complessivo. Inoltre, la mancanza di visibilità può comportare una scarsità di responsabilità poiché i container attraversano ambienti diversi dallo sviluppo alla produzione.

Un'altra sfida alla sicurezza relativa ai container è la scarsa gestione delle vulnerabilità. Ad esempio, quando si clonano immagini esistenti per creare nuovi contenitori, anche le loro vulnerabilità verranno replicate.

Ciò evidenzia la necessità che la sicurezza sia parte integrante della strategia del contenitore organizzativo. In caso contrario, gli errori di configurazione e le patch mancanti potrebbero essere la causa della distribuzione e dell'esecuzione di immagini non autorizzate negli ambienti di produzione, determinando una maggiore superficie di attacco e attacchi più efficaci.

Infine, poiché i contenitori utilizzano un kernel del sistema operativo condiviso, una compromissione del kernel del sistema operativo host da parte di un contenitore canaglia può portare alla perdita di accesso a tutti oa tutti i contenitori in esecuzione sull'host allo stesso modo come potenzialmente altri host sulla rete.

Come mettere in sicurezza i tuoi container

Forse la migliore pratica per proteggere il tuo ambiente containerizzato è riconoscere la necessità di farlo. Fatta eccezione per questo concetto fondamentale, ci sono alcuni buoni consigli da seguire per proteggere efficacemente i tuoi contenitori.

Ottieni visibilità sui tuoi container

Prima di distribuire un container, assicurati di aver compreso le sue dipendenze e cosa è incluso in esso. Per garantire che le immagini del tuo contenitore siano incontaminate, devi ottenere visibilità in ogni fase, dallo sviluppo alla produzione.

Non fidarsi del software di un container è un ottimo punto di partenza. Devi controllarlo molto attentamente per capire "da dove provengono, come sono stati prodotti e le loro fonti corrispondenti", come ha sottolineato Dirk Hohndel, vicepresidente di VMware, all'Open Source Leadership Summit 2019.

In poche parole, ricontrolla il contenuto dei tuoi contenitori prima di distribuirli e non eseguire mai un contenitore con software sconosciuto o obsoleto. Solo perché un'immagine contenitore afferma di contenere i programmi e le librerie più recenti e migliori, ciò non significa che lo faccia effettivamente.

Un modo per mitigare questo problema consiste nell'utilizzare applicazioni che possono aiutarti a ripulire i tuoi contenitori. Anche se non mi piace reinventare la ruota, forse l'approccio migliore è smettere di usare le immagini dei contenitori di altre persone.

Se tu, proprio come Hercules, prendi la strada più difficile di Virtue e inizi a costruire le tue immagini di container, avrai una comprensione molto migliore di cosa sta succedendo all'interno dei container, il che ha vantaggi oltre la sicurezza.

Controlla l'accesso alla radice

La maggior parte dei container viene compilata con l'accesso root per impostazione predefinita. Tuttavia, questa è una pratica discutibile. Sebbene sia più facile per gli sviluppatori eseguire i container come root, ci sono enormi rischi con l'accesso come root.

Esistono diversi approcci per gestire questo problema. Un modo consiste nell'accertare una politica aziendale in base alla quale nessun container può mai essere eseguito come root. Un modo alternativo consiste nell'esercitare il principio del privilegio minimo. Puoi specificare un utente non root all'interno del Dockerfile, quando crei un'immagine del contenitore, per eseguire il contenitore come quell'utente specifico con l'accesso al sistema minimo richiesto.

Infine, puoi anche utilizzare lo spazio dei nomi utente durante l'esecuzione di processi contenitore con privilegi per aiutare i contenitori sicuri. Con questo metodo, l'UID per l'esecuzione di questi processi all'interno del contenitore è zero (che è la radice), ma al di fuori del contenitore l'UID è 1000 senza privilegi.

Controllare il runtime del contenitore

La " Guida alla sicurezza dei container delle applicazioni " SP 800-190 del National Institute of Standards and Technology (NIST) sottolinea che anche i runtime dei container sono vulnerabili agli attacchi. Sebbene questa non sia una lacuna di sicurezza comune, il NIST sottolinea che le vulnerabilità della sicurezza del runtime dei container possono essere " particolarmente pericolose " se consentono scenari in cui il software dannoso può attaccare le risorse in altri container e lo stesso sistema operativo host.

Un utente malintenzionato può anche essere in grado di sfruttare le vulnerabilità per compromettere il software di runtime stesso e quindi alterare quel software in modo da consentire all'attaccante di accedere ad altri container, monitorare le comunicazioni da container a container, ecc.

I problemi di sicurezza sono molto più comuni con le configurazioni di runtime. I runtime del contenitore in genere espongono molte opzioni configurabili. Un'impostazione impropria può ridurre la sicurezza relativa del sistema.

Ad esempio, sugli host di container Linux, l'insieme delle chiamate di sistema consentite è spesso limitato per impostazione predefinita solo a quelle richieste per il funzionamento sicuro dei container. Se questo elenco viene ampliato, potrebbe esporre i contenitori e il sistema operativo host a un rischio maggiore da un contenitore compromesso.

Allo stesso modo, se un container viene eseguito in modalità privilegiata, ha accesso a tutti i dispositivi dell'host, consentendogli di agire essenzialmente come parte del sistema operativo host e di influire su tutti gli altri container in esecuzione su di esso.

Un altro esempio di configurazione di runtime non sicura consiste nel consentire ai contenitori di montare directory sensibili sull'host. Se un container compromesso può apportare modifiche a questi percorsi, potrebbe essere utilizzato per elevare i privilegi e attaccare l'host stesso, nonché altri container in esecuzione sull'host.

Rafforza il sistema operativo

Il NIST consiglia inoltre di eseguire un sistema operativo specifico per container perché le minacce sono in genere più minime poiché i sistemi operativi sono progettati specificamente per ospitare container e hanno altri servizi e funzionalità disabilitati.

Inoltre, poiché questi sistemi operativi ottimizzati sono progettati specificamente per l'hosting di container, in genere presentano file system di sola lettura e utilizzano altre pratiche di protezione avanzata per impostazione predefinita. Quando possibile, le organizzazioni dovrebbero utilizzare questi sistemi operativi minimalisti per ridurre le loro superfici di attacco e mitigare i rischi tipici e le attività di rafforzamento associati ai sistemi operativi generici.

Le organizzazioni che non possono utilizzare un sistema operativo specifico per container devono seguire le indicazioni in NIST SP 800-123, Guide to General Server Security per ridurre il più possibile la superficie di attacco dei propri host.

Ad esempio, gli host che eseguono contenitori devono eseguire solo contenitori e non eseguire altre app, come un server Web o un database, al di fuori dei contenitori. Il sistema operativo host non deve eseguire servizi di sistema non necessari, come uno spooler di stampa, che ne aumenta la superficie di attacco.

Infine, gli host dovrebbero essere continuamente scansionati alla ricerca di vulnerabilità e aggiornamenti applicati rapidamente, non solo al runtime del contenitore ma anche ai componenti di livello inferiore come il kernel su cui i contenitori fanno affidamento per un funzionamento sicuro e compartimentato.

La sicurezza dei container è una priorità assoluta

Con sempre più aziende che adottano e distribuiscono container, la loro sicurezza sta diventando una delle principali priorità aziendali. Secondo un recente sondaggio, il 94% degli intervistati ha subito un incidente di sicurezza nei propri container. Ciò evidenzia solo quanto sia importante ottenere i diritti di sicurezza dei container per proteggere la tua azienda e i tuoi clienti.