Il punto di vista di Michael Cade, Global Field CTO Cloud-Native Product Strategy, Veeam, sulla sicurezza dei container Kubernetes e delle applicazioni cloud-native.
Mentre le aziende cercano framework di sviluppo più veloci e flessibili, l'uso di container e Kubernetes (K8s) continua ad aumentare. Sebbene Kubernetes offra teoricamente diversi vantaggi in termini di sicurezza rispetto alle applicazioni tradizionali, questa rimane una delle principali criticità per le organizzazioni che intraprendono un percorso cloud-native.
Questa preoccupazione, a quanto pare, risulta giustificata. Un recente rapporto ha rilevato che i cluster Kubernetes appartenenti a più di 350 organizzazioni, tra cui diverse aziende Fortune 500, erano apertamente accessibili ed esposti a cyberattacchi come il ransomware.
Dunque, come mai le organizzazioni hanno problemi con la sicurezza di Kubernetes su questa scala?
La possibilità di sbagliare
Spesso si descrive la sicurezza come una gara, immaginando i team di sicurezza che competono per stare un passo avanti ai malintenzionati, adottando nuove tecnologie e rispondendo a nuove tecniche e vulnerabilità. Tuttavia, a volte si tratta di una gara per stare al passo con la propria organizzazione che adotta nuove tecnologie. In ogni caso, la sicurezza deve tenere il passo e garantire la sicurezza dell'azienda, qualunque sia la direzione scelta.
Secondo un recente report di Enterprise Strategy Group, l'utilizzo di Kubernetes sta per raggiungere un "punto di svolta", con l'82% delle organizzazioni che li utilizzerà entro la fine del 2024. I container sono in uso da oltre un decennio. Sebbene l'adozione di Kubernetes non sia stata propriamente rapida, quando un'organizzazione decide di fare il salto in qualcosa di nuovo, c'è sempre una curva di apprendimento. Con Kubernetes, ci sono insidie invisibili che gli sviluppatori e i team di sicurezza possono lasciarsi sfuggire mentre cercano di far decollare le nuove applicazioni.
Il compromesso tra velocità e sicurezza è familiare ai team di sviluppo e, poiché uno dei principali fattori che spingono all'adozione dei container è la velocità insieme all'agilità, non sorprende che la rapida adozione di Kubernetes abbia lasciato alcune "porte aperte". Lo sviluppo non sicuro non è mai una decisione consapevole, ma se le aziende sentono la pressione di aggiungere nuove funzionalità o sviluppare nuovi prodotti da zero, possono ritrovarsi a soprassedere su qualche aspetto.
Contenere il caos
Le vulnerabilità di Kubernetes sono spesso dovute a una configurazione errata durante la fase di progettazione e sviluppo. La già citata tempistica è un fattore che incide, ma la mancanza di conoscenze specifiche di K8 è spesso l'aspetto chiave.
Il report di Aqua Security, che ha identificato centinaia di ambienti container vulnerabili, si basa in gran parte su due configurazioni errate. La prima prevede che gli utenti anonimi richiedano solo un singolo livello di autenticazione, che se superato può garantire l'accesso anonimo con privilegi che includono quelli di amministratore. È come avere una serratura debole su un'auto sportiva, con le chiavi inserite. L'altra vulnerabilità comune è rappresentata da cluster mal configurati, che in alcuni casi espongono i cluster al pubblico. Ciò può consentire ai malintenzionati di sfruttare strumenti come "Kubectl" per connettersi semplicemente al vostro cluster Kubernetes e iniziare a scatenare il caos.
Questo problema non è esclusivo di K8, ma lasciare le applicazioni esposte a Internet quando non è necessario è un vettore di attacco comune a tutti i tipi di applicazioni. L'accesso a Internet è un'altra porta attraverso cui gli aggressori possono introdursi. Se la porta non esistesse, non sarebbe un problema. Ecco perché si parla di Zero Trust o del "principio del minimo privilegio": anche con le applicazioni cloud-native, non tutto dovrebbe essere accessibile in ogni momento.
Fare il backup
Ancora una volta, i professionisti non si svegliano un giorno e decidono di sviluppare falle di sicurezza nelle loro applicazioni. È solo il risultato delle lacune di conoscenza e delle rapide tempistiche di sviluppo. Col tempo, man mano che gli sviluppatori diventeranno più esperti con le piattaforme cloud-native, questi problemi diventeranno meno comuni. Ciò rende ancora più necessaria la presenza di solidi processi di backup e ripristino. La resilienza informatica è a più livelli. Non si può mai essere del tutto sicuri della prima linea di difesa (la sicurezza delle applicazioni), quindi è fondamentale che le aziende abbiano a disposizione elementi su cui contare.
Purtroppo, questa è un'altra area di Kubernetes in cui si registra una curva di apprendimento ripida. L'ultimo report di Enterprise Strategy Group sulla protezione di Kubernetes ha rilevato che il 33% delle organizzazioni che utilizzano Kubernetes ha continuato a utilizzare gli stessi strumenti e processi di protezione dei dati delle normali applicazioni. Questo è un problema. Le applicazioni cloud-native richiedono soluzioni di backup cloud-native. Sebbene queste aziende dispongano di backup e quindi pensino di essere al sicuro, i backup tradizionali non sono in grado di tracciare la parte mobile di Kubernetes. Ciò significa che quando si cerca di recuperare i dati si possono verificare problemi di prestazioni e perdita di dati.
Se la sicurezza e il ripristino sono fondamentalmente difettosi, le aziende si lasciano completamente esposte ad attacchi come il ransomware. Con settembre che è stato registrato come uno dei più grandi mesi di attacchi ransomware di sempre, le aziende devono assicurarsi di aver fatto le cose per bene. Questo non è un appello a evitare o smettere di usare Kubernetes o le applicazioni basate su container, tutt'altro.
Tuttavia, la sicurezza deve essere al passo con le nuove pratiche di sviluppo, altrimenti i criminali si faranno strada tra le lacune. Questi ambienti sono complessi da gestire da soli, ed è per questo che DevSecOps è così cruciale. La collaborazione tra i team di sviluppo e di sicurezza può mantenere l'infrastruttura sicura fin dall'inizio e far funzionare le aziende, al riparo dall'ondata incessante di ransomware.