Le containerized applications sono sempre più diffuse, così aumenta la necessità di assicurare un'adeguata container security e la resilienza della supply chain software. In questo articolo elenchiamo i principali problemi di sicurezza dei container, per poi scoprire quali sono le best practice utili per migliorarla.
Il modo in cui le organizzazioni progettano e sviluppano il software è cambiato drasticamente negli ultimi anni. L’avvento delle architetture Cloud Native basate su microservizi e container ha cambiato la carte in tavola nel panorama IT. Oggi le applicazioni non sono più realizzate in maniera monolitica. Vengono bensì progettate basandosi su architetture a microservizi, secondo metodologie DevOps che non lascino la gestione operativa e la sicurezza a carico dei team di Operations a valle del ciclo di sviluppo.
Secondo Gartner il business delle piattaforme di container management raggiungerà i 944 milioni di dollari entro il 2024, partendo dalla cifra di 466 milioni stimata nel 2020. Questa crescita a doppia cifra evidenzia come la tecnologia dei container stia diventando man mano più capillare all’interno delle organizzazioni di qualsiasi dimensione (ecco ad esempio tre aziende che usano i container con successo).
E con i containerized environments sempre più diffusi, la ricerca di soluzioni per migliorare la container security è passata in cima alla lista delle priorità dei team di sicurezza e devsecops.
POTREBBE INTERESSARTI ANCHE
l’articolo DevSecOps: Cybersecurity for Cloud Native Applications
Il white paper gratuito Guida alla Cloud Native Security
Quando si parla di sicurezza dei container è necessario ragionare con uno spettro che spazia dal semplice workload containerizzato, all’host che permette l’esecuzione di tale applicazione o microservizio. Con questa idea in mente, possiamo individuare i problemi di sicurezza principali a cui ogni organizzazione deve prestare attenzione, vediamoli uno per uno.
La condivisione del kernel della macchina host espone, in caso di un attacco che sfrutti un exploit del sistema operativo, tutti i container in esecuzione su di essa. Questo rischio è fortemente mitigato dalla classica virtualizzazione basata su hypervisor. Questa pratica infatti aggiunge un ulteriore livello prima di raggiungere gli applicativi in esecuzione. Per questo motivo, negli ambienti container è di fondamentale importanza il patching e l’hardening del sistema operativo host.
Mettiamo il caso che un container abbia la possibilità di accedere a risorse illimitate in termini di capacità computazionale sul sistema host. Lo sfruttamento di una vulnerabilità o di un errore di programmazione dell’applicazione potrebbe monopolizzare le risorse computazionali disponibili, impedendo l’accesso di altri container a CPU e RAM e causando un attacco DoS.
Per fortuna questo scenario può essere prevenuto configurando opportunamente l’allocazione di risorse dedicate ad ogni container e i principali parametri per abilitare una scalabilità orizzontale e verticale efficiente.
In caso di un bug presente all’interno di un’applicazione, un utente potrebbe scalare la piramide di privilegi sino al livello di root e ottenere accesso all'host. Malgrado la remota possibilità che questo evento accada, è necessario pianificare controlli periodici per validare la robustezza e la sicurezza dei container in produzione.
Le immagini standard dei container (build) possono essere infettate con malware o presentare vulnerabilità conosciute. È fondamentale mantenere sempre le immagini dei container aggiornate all’ultima versione disponibile. Inoltre, è bene effettuare dei controlli periodici sulla sicurezza di queste attraverso opportune scansioni.
Durante l’esecuzione delle applicazioni il container accede periodicamente ad informazioni sensibili, chiavi API e credenziali. L’accesso indesiderato a queste informazioni comprometterebbe l’intera sicurezza dei servizi in esecuzione.
Le conseguenze possono essere anche molto serie, per questo è utile conoscere le best practice di sicurezza, come quelle che vedremo tra un attimo. Prima però, c’è un altro concetto che è bene affrontare, quello di supply chain software.
La diffusione delle architetture Cloud Native ha determinato indirettamente una positiva crescita nell’adozione da parte di organizzazioni di ogni dimensione di software definito “open”. Il software open source (OSS) lascia nelle mani della community la gestione, manutenzione ed evoluzione del software stesso, prediligendo la collaborazione e gli spunti di miglioramento derivanti da feedback sul campo.
L’utilizzo del software OSS da parte di aziende private è regolamentato e tutelato dalle tradizionali licenze (es: MIT, GNU GPL, ecc..). Tuttavia, la gestione dei pericoli che derivano dall’utilizzo di software open è demandata all’organizzazione.
In questo contesto il concetto di Supply Chain Security Management è fondamentale, poiché in un ambiente “non governato” non è possibile controllare e supervisionare l’utilizzo di SDK, librerie o strumenti di terze parti. Diventa quindi necessario mettere in piedi un processo che garantisca l’immutabilità di una dipendenza o del software stesso, al fine di proteggere da una terza parte malintenzionata il perimetro della nostra infrastruttura.
Il metodo tradizionale di verifica dell’integrità del software è stato quello di verificare la firma digitale delle componenti dell’applicazione stessa. Lo stesso concetto è applicabile anche ai container, ma purtroppo non è sufficiente.
Secondo lo standard Supply Chain Level for Software Artifacts (SLSA), per raggiungere un livello di sicurezza della supply chain software adeguato, è necessario ragionare seguendo un approccio strutturato. Le quattro aree che caratterizzano questo approccio sono: Artifacts, Metadata e Attestation and Policies. Di cosa si tratta? Le abbiamo descritte di seguito.
Una volta descritte le principali sfide in termini di Container Security, arriviamo finalmente alle security best practice. Sono le raccomandazioni che, aggiunte ad un processo di verifica della supply chain software, permettono di tenere sotto controllo i nostri workload containerizzati e ridurre la superficie di attacco. Ne abbiamo individuate 6.
Una base image vulnerabile o compromessa è in grado di creare dei problemi a tutti i workload che la utilizzano come base. Per questo motivo, è sempre opportuno personalizzare il meno possibile la base image del container (ad esempio aggiungendo package esterni o librerie SDK). È bene utilizzare solamente immagini provenienti da fonti certificate e affidabili.
I registry sono i repository delle immagini del software containerizzato. Per mantenere questa tipologia di repository in sicurezza (sia da accessi indesiderati sia da contenuti vulnerabili) è possibile:
Considerando un ambiente di produzione come target del nostro processo di deployment, questa fase può essere messa in sicurezza in diversi modi:
È bene seguire le best practice tradizionali nel contesto di architetture Cloud Native, quali:
I container non sono fatti per essere utilizzati come “server”. La loro personalizzazione e i file contenuti al loro interno devono essere ridotti al minimo, mantenendo la natura effimera di ciascuna istanza di un container.
Quest'ultimo obiettivo si ottiene implementando meccanismi che garantiscono un approfondito livello di osservabilità sui seguenti componenti dell’infrastruttura containerizzata:
Per non incappare in problemi di sicurezza e garantire la container security, ogni organizzazione deve rivedere i propri processi di application lifecycle management. È necessario infondere all’interno di essi tutti i meccanismi di verifica, remediation e monitoraggio.
Al fine di ridurre al minimo la potenziale superficie di attacco (attack surface), bisogna essere consapevoli dei principali problemi di sicurezza dei container, seguire un approccio strutturato per assicurare un livello di sicurezza adeguato alla supply chain software e applicare le best practice che abbiamo elencato in questo articolo.
Infine, è indispensabile mettere in pratica il famoso shift-left, anticipare quindi le pratiche di sicurezza a partire dalle fasi iniziali del software development lifecycle. È un processo cardine della filosofia DevSecOps, che ti consigliamo di approfondire se non l’hai ancora fatto. Ne parliamo anche nell’ebook gratuito che abbiamo dedicato alla Cloud Native Security.