containerizzazione
Al giorno d’oggi una qualche forma di virtualizzazione o containerization è presente in quasi tutte le grandi soluzioni IT. I container offrono numerosi vantaggi durante lo sviluppo, l’installazione, la manutenzione e l’utilizzo del sistema. Accelerano lo sviluppo, assicurano risparmi sui costi e consentono di salvaguardare le altre risorse. Allo stesso tempo, molte soluzioni di sicurezza che funzionano su server fisici e virtuali non sono direttamente applicabili ai container. Quali rischi dovrebbero prendere in considerazione le aziende durante l’implementazione della containerization e quali misure sono necessarie per proteggere l’infrastruttura dei container?
Vantaggi della containerization per lo sviluppo e le operazioni
Un container è un ambiente isolato per l’esecuzione di una singola applicazione creato da strumenti a livello di kernel del sistema operativo. L’immagine del container include sia l’applicazione che le impostazioni richieste e i componenti ausiliari, rendendo molto pratico per gli sviluppatori inserire tutto ciò di cui hanno bisogno nel container. Chi utilizza i container li trova molto più semplici da utilizzare rispetto a un’infrastruttura vecchio stile. Inoltre, l’isolamento riduce notevolmente l’influenza reciproca delle applicazioni containerizzate. Un’infrastruttura container presenta quindi meno possibilità di errori, aumentando al tempo stesso le capacità di controllo per gli amministratori.
La containerization è una tecnologia più leggera della virtualizzazione: i container non emulano l’hardware e non è necessario fornire l’intero contenuto della macchina virtuale, in particolare il sistema operativo guest. In molti casi, i carichi di lavoro containerizzati sono più facili da scalare.
Senza dubbio, lo strumento più comune per la creazione e l’archiviazione delle immagini dei container è Docker, mentre l’orchestrazione dei carichi di lavoro dei container viene spesso implementata con Kubernetes, Docker Swarm o Red Hat OpenShift.
La containerization è diventata una parte essenziale dei moderni approcci di sviluppo IT. Molte applicazioni sono sviluppate in un’architettura di microservizi: le singole funzionalità di un’applicazione di grandi dimensioni sono allocate a microservizi che comunicano con le altre parti dell’applicazione tramite API. Un esempio è un lettore video in un social network o il processo di pagamento di un negozio online. Questi microservizi vengono spesso distribuiti come container, consentendo agli sviluppatori di adottare il proprio ciclo di sviluppo e distribuzione.
I container si integrano perfettamente con la moderna metodologia CI/CD (Continuous Integration/Continuous Delivery), quindi gli aggiornamenti delle applicazioni vengono rilasciati più rapidamente e con minori quantità di bug. Questo approccio prevede un ciclo di sviluppo breve, team che lavorano in parallelo sullo stesso codice e l’automazione delle azioni di routine. La containerization in una pipeline CI/CD migliora anche l’efficienza della pipeline: il sistema CI/CD utilizza le immagini del container come modelli e fornisce la build come immagine pronta per la distribuzione. Il punto chiave è che gli aggiornamenti vengono forniti sotto forma di nuove immagini, anziché distribuiti all’interno di un container esistente e operativo. Ciò accelera la preparazione e il debug della release, riduce i requisiti per l’infrastruttura sia dello sviluppatore che del cliente, migliora la stabilità operativa e semplifica la scalabilità dell’applicazione.
Integrando correttamente i requisiti di sicurezza dei container nei processi di sviluppo e compilazione, un’azienda compie un grande passo avanti verso la piena implementazione di DevSecOps.
Minacce fondamentali per l’infrastruttura dei container
Il sistema host, gli ambienti di containerization e le applicazioni containerizzate sono tutti soggetti alla maggior parte dei tipici rischi per la sicurezza delle informazioni, come vulnerabilità nei componenti, impostazioni non sicure e simili.
I cybercriminali stanno già sfruttando attivamente questi rischi. Ad esempio, nel repository Docker Hub pubblico sono state individuate 1.650 immagini di container con malware. In un caso simile, le immagini dannose non sono state rilevate per circa un anno. Alcune campagne dannose utilizzano l’API Docker per creare container con malware su sistemi mirati, disabilitare i sistemi di monitoraggio e avviare attività di mining. In un altro attacco, gli autori delle minacce hanno colpito i cluster Kubernetes con PostgreSQL configurato in modo errato. Un altro problema comune è che le immagini dei container obsolete che contengono vulnerabilità note come Log4shell possono essere archiviate nei repository per diverso tempo. Inoltre, gli sviluppatori lasciano regolarmente chiavi API e altri segreti nei container.
Sistematizzando le minacce per ciascun elemento nel sistema di containerization, otteniamo questo schema leggermente semplificato:
| Immagini | Registro delle immagini | Orchestrator | Container | Sistema operativo host |
| Utilizzo di immagini non attendibili | Connessione non protetta | Accesso amministrativo illimitato | Vulnerabilità dell’ambiente di runtime | Kernel del sistema operativo condiviso per tutti i container |
| Vulnerabilità software | Immagini obsolete con vulnerabilità | Accesso non autorizzato | Accesso illimitato alla rete | Vulnerabilità dei componenti del sistema operativo |
| Errore di configurazione | Autenticazione e autorizzazione insufficienti | Mancanza di isolamento e ispezione del traffico tra i container | Configurazione di runtime non sicura | Autorizzazioni utente errate |
| Malware | Nessuna separazione dei container con diversi livelli di sensibilità dei dati tra gli host | Vulnerabilità delle applicazioni nei container | File system accessibile dai container | |
| Segreti in chiaro | Errori di configurazione dell’orchestrator | Container non conformi nell’ambiente di runtime |
Container e protezione tramite strumenti di protezione tradizionali
Molte difese che funzionavano bene per le macchine virtuali non possono essere applicate alla sicurezza dei container. In genere, non è possibile eseguire un agente EDR all’interno di un container come in una macchina virtuale. Inoltre, ciò che accade nel container non è completamente disponibile per l’analisi da parte dei sistemi di sicurezza convenzionali nel sistema host. Pertanto, il rilevamento, ad esempio, di software vulnerabile e dannoso all’interno del container è problematico, così come l’applicazione di strumenti di protezione come WAF nelle applicazioni containerizzate. Il traffico tra i container viene spesso trasmesso su una rete virtuale a livello di orchestrator e potrebbe non essere accessibile agli strumenti di protezione della rete.
Anche nel sistema operativo host, un agente di protezione non adattato può comportare un degrado delle prestazioni o della stabilità delle applicazioni containerizzate distribuite. La protezione del cluster deve essere fornita a livello di host in linea con il particolare ambiente di orchestrazione e la natura dei carichi di lavoro dei container.
Esistono anche problemi specifici che devono essere risolti per gli ambienti container, come impedire l’esecuzione di container non attendibili, individuare la presenza di segreti nei container e limitare il traffico di rete per ogni container specifico in base alle relative funzioni. Tutto questo è disponibile solo in soluzioni specializzate come Kaspersky Container Security.
Che dire della protezione con strumenti nativi?
Tutti i principali fornitori di container sembrano impegnarsi a fondo per migliorare la sicurezza dei loro prodotti. Gli strumenti nativi di Kubernetes, ad esempio, possono essere utilizzati per configurare quote di risorse e criteri di registrazione, nonché per implementare RBAC (Role-Based Access Control) con il principio dei privilegi minimi. Tuttavia, esistono intere classi di attività di protezione delle informazioni che non possono essere affrontate con gli strumenti nativi, come il monitoraggio dei processi all’interno di un container in esecuzione, l’analisi delle vulnerabilità, il controllo della conformità ai criteri e alle best practice di protezione delle informazioni e molto altro.
Ma soprattutto, un sistema maturo e completo per la sicurezza dei container deve garantire la protezione fin dalle prime fasi della containerizzazione: lo sviluppo, la distribuzione e l’archiviazione. Per raggiungere questo obiettivo, la sicurezza della containerizzazione deve essere incorporata nel processo di sviluppo e integrata con gli strumenti di sviluppo.
In che modo la protezione dei container diventa parte di DevSecOps
L’approccio DevOps si è evoluto in DevSecOps, a causa delle crescenti richieste di affidabilità e sicurezza delle applicazioni. Per rendere la sicurezza una parte organica dello sviluppo, i requisiti fondamentali di sicurezza delle informazioni vengono verificati automaticamente in tutte le fasi della preparazione e della distribuzione dell’applicazione, laddove possibile. Gli ambienti container facilitano questa operazione.
Fase di pianificazione: protezione delle operazioni di VCS e registro. All’inizio del ciclo di sviluppo, gli sviluppatori di software selezionano i componenti, inclusi quelli containerizzati, da distribuire nell’applicazione. Il sistema di protezione deve eseguire la scansione delle immagini del registro per verificarne l’aggiornamento e analizzare i file di configurazione (IaC, in particolare Dockerfile) alla ricerca di errori e impostazioni non sicure. Le immagini di base utilizzate nello sviluppo devono essere scansionate alla ricerca di vulnerabilità, malware, segreti e simili. In tal modo, gli sviluppatori riducono significativamente i rischi di compromissione della supply chain.
Fase di compilazione e test: protezione delle operazioni di Continuous Integration. In questa fase è necessario assicurarsi che nell’immagine non siano presenti segreti, versioni vulnerabili delle librerie o malware e che tutti gli aspetti della sicurezza delle informazioni che possono essere analizzati siano conformi ai requisiti delle autorità di regolamentazione e dell’azienda stessa. La compilazione di un’applicazione non può essere completata correttamente se sono presenti violazioni dei criteri. Questa operazione viene eseguita integrando il sistema di sicurezza dei container con una piattaforma CI/CD, che si tratti di Jenkins, Gitlab o CircleCI. Insieme ai test statici e dinamici della sicurezza delle applicazioni (AppSec), questa misura è ciò che distingue DevSecOps da altri approcci di sviluppo.
Fase di delivery e distribuzione: sicurezza a livello di Continuous Delivery. Le immagini rese operative devono essere scansionate per garantire l’integrità e la piena conformità ai criteri adottati. Se la situazione richiede un’eccezione (ad esempio, una vulnerabilità viene pubblicata ma non è ancora stata corretta), deve essere sempre documentata e limitata nel tempo.
Fase operativa: protezione dell’orchestrator e dei container in esecuzione. Avvio e controllo del funzionamento dei container. Questa fase riduce al minimo i rischi associati alle vulnerabilità nell’ambiente di runtime o alla sua errata configurazione. Cosa ancora più importante, solo qui è possibile rilevare varie anomalie nel funzionamento dell’applicazione, come un carico computazionale eccessivo o comunicazioni impreviste con altri container e la rete nel suo insieme. Questa fase monitora anche la sicurezza della personalizzazione dell’orchestrator e la possibilità di accedervi. Per la sicurezza dei container, il funzionamento nativo con l’orchestrator Kubernetes o OpenShift è fondamentale. Al tempo stesso, il sistema operativo host non deve essere lasciato senza protezione.
Per operare in queste fasi, lo stesso sistema di sicurezza per i container deve essere multicomponente. L’illustrazione mostra gli elementi principali di Kaspersky Container Security e la loro relazione con la piattaforma di containerization e la piattaforma CI/CD.
Kaspersky Container Security: architettura a ciclo chiuso
Quali misure di protezione adottare per ciascun componente dell’ambiente container?
Diamo un’occhiata a un elenco più dettagliato di misure di protezione che devono essere applicate a ciascun componente del sistema di containerization perché la sua sicurezza possa essere definita completa.
| Immagini | Registro delle immagini | Orchestrator | Container | Sistema operativo host |
| Vulnerability assessment | Integrazione del registro e scansione delle immagini | Rilevamento di errori di configurazione e correzioni consigliate | Controllo dell’avvio e del funzionamento solo dei container attendibili | Rilevamento di errori di configurazione e correzioni consigliate |
| Scansione alla ricerca di errori di configurazione delle immagini | “Elenco chiuso”: utilizzo solo di immagini approvate e aggiornate | Visualizzazione delle risorse nel cluster | Monitoraggio dell’integrità dei container | Mitigazione dei rischi per la sicurezza tramite il controllo dell’avvio dei container |
| Scansione anti-malware | Ricerca di configurazioni e impostazioni di accesso errate | Rilevamento e scansione delle immagini nel cluster (ricerca di container di cui non è stato tenuto conto) | Controllo dell’avvio di applicazioni e servizi all’interno dei container | Versione del sistema operativo adattata per ridurre al minimo la superficie di attacco |
| Ricerca di segreti | Monitoraggio del traffico dei container | |||
| Valutazione del rischio e identificazione di immagini potenzialmente pericolose | Riduzione al minimo dei privilegi dei container | |||
| Raggruppamento dei container negli host per livello di rischio/importanza |
L’elemento centrale del sistema di sicurezza è la scansione approfondita delle immagini. Il sistema di sicurezza deve essere integrato con i registri chiave (come DockerHub, GitLab Registry o JFrog Artifactory), sia pubblici che aziendali, ed eseguire regolarmente la scansione delle immagini utilizzate in conformità con i criteri aziendali. Ogni scansione nell’elenco è importante di per sé, ma il profilo di rischio e le specifiche delle applicazioni variano per ogni azienda, quindi potrebbe, ad esempio, essere possibile consentire l’utilizzo di immagini con vulnerabilità a bassa criticità. Inoltre, a seconda dei criteri di sicurezza applicati, i suggerimenti CIS Kubernetes o vari database di vulnerabilità possono essere fondamentali.
Le immagini dei container che non superano la scansione vengono semplicemente contrassegnate per gli amministratori o bloccate nelle fasi successive di sviluppo e distribuzione.
Il secondo gruppo di strumenti di protezione, altrettanto importante e specifico, opera nella fase di distribuzione e avvio del container. Innanzitutto, viene impedita l’esecuzione dei container non conformi ai criteri e non inclusi negli elenchi attendibili.
La protezione dell’ambiente di runtime è incompleta senza l’ispezione dell’orchestrator stesso. Questa aiuta a identificare errori di configurazione, non conformità con i criteri di sicurezza e tentativi non autorizzati di modificare la configurazione. Una volta che i container sono in esecuzione, il monitoraggio dell’attività dell’orchestrator consente di rilevare e arrestare le attività sospette sia all’interno che tra i cluster.
Alcune attività della matrice non possono essere delegate a una soluzione di sicurezza di alcun tipo. Queste includono la scelta iniziale di una build del sistema operativo sicura e minimalista, appositamente adattata per l’esecuzione dei carichi di lavoro dei container, oltre all’attività cruciale del raggruppamento dei container. Per una corretta protezione a più livelli e una gestione pratica, i container in esecuzione devono essere raggruppati negli host in modo che le informazioni con determinati requisiti di sicurezza vengano elaborate separatamente dalle informazioni con requisiti di sicurezza inferiori. L’implementazione dipende dall’orchestrator in uso, ma in ogni caso si tratta principalmente di un esercizio di valutazione del rischio e di modellazione delle minacce.
In generale, esistono numerose attività di protezione dei container e tentare di affrontarle singolarmente, con i propri strumenti o con una configurazione manuale, comporterebbe un aumento dei costi. Pertanto, gli ambienti container di medie e grandi dimensioni richiedono soluzioni di sicurezza olistiche profondamente integrate con la piattaforma di containerization, la pipeline CI/CD e gli strumenti di protezione delle informazioni utilizzati nell’azienda.
Il lavoro degli esperti di sicurezza delle informazioni è semplificato da: integrazione con SIEM e canali di notifica dei problemi rilevati, scansione automatica periodica di tutte le immagini rispetto a un database di vulnerabilità aggiornato (come NVD), funzionalità per l’accettazione temporanea dei rischi per la sicurezza delle informazioni e la registrazione dettagliata degli eventi amministrativi nel sistema di protezione dell’ambiente di containerization.
In che modo Kaspersky Container Security implementa la protezione
La nostra soluzione completa protegge l’infrastruttura dei container “by design”: i suoi componenti proteggono l’intero ciclo di vita delle applicazioni containerizzate, dallo sviluppo all’esecuzione quotidiana. Lo scanner dedicato funziona con le immagini dei container e fornisce una protezione statica, mentre l’agente KCS in esecuzione come container separato sotto il controllo dell’orchestrator protegge gli host nell’ambiente di runtime e l’ambiente di orchestrazione nel suo insieme. Al tempo stesso, il componente centrale di Kaspersky Container Security integra questi elementi e fornisce un’interfaccia di gestione.
La piattaforma ad alte prestazioni offre una protezione efficiente per i cluster K8s con centinaia di nodi.
La prima versione di Kaspersky Container Security, che implementa la protezione di base per gli ambienti container, è già disponibile. Siamo inoltre impegnati a sviluppare il prodotto e a estenderne le funzionalità in futuro.
