Kubernetes e cybersecurity: la protezione dei container
Il modo in cui la maggior parte delle aziende protegge i propri container non è ancora adatto allo scopo. Recenti risultati suggeriscono che i cluster Kubernetes (K8s) appartenenti a più di 350 organizzazioni (tra cui diverse aziende Fortune 500) sono attualmente “apertamente accessibili e non protetti”. Quindi, in cosa sbagliano ancora le aziende?
Due passi avanti e uno indietro
Un rapporto del 2023 dell’Enterprise Strategy Group ha descritto il mercato dei container come “rovente”. Quasi la metà (47%) delle aziende ha dichiarato di utilizzare attualmente i container, mentre il 35% prevede di farlo nei prossimi 12 mesi. Se tutti questi piani diventassero realtà, entro la fine del 2024 l’82% delle organizzazioni utilizzerebbe i container.
È opinione comune che i container equivalgano a Kubernetes. Anche se non è esatto, poiché si tratta semplicemente di una piattaforma per la gestione dei container, il rapporto indica che sta diventando lo standard. Attualmente, il 66% delle organizzazioni lo utilizza per gestire e orchestrare i propri container. In sostanza, si tratta di un nome di prodotto che è diventato così diffuso da essere sinonimo dell’oggetto stesso, come JCB, Kleenex o Frisbee.
Ma “rosso fuoco” è un modo appropriato per descrivere l’attuale utilizzo dei container, in più di un senso. Con le pratiche attuali, troppe aziende rischiano di bruciarsi. Secondo lo stesso rapporto, meno della metà delle aziende che hanno implementato i container ha inserito la protezione dei dati nel processo di progettazione dell’architettura. Il 19% ha invece pensato a come proteggere i propri container solo dopo aver completato l’implementazione e, forse peggio, il 33% ha continuato a utilizzare gli strumenti e i processi di protezione dei dati esistenti. Ciò è sintomatico del divario di conoscenze in materia di container e Kubernetes e, in alcuni casi, di protezione dei dati in generale.
È il momento di andare avanti
Affrontiamo prima il problema peggiore. Secondo Enterprise Strategy Group, un terzo delle organizzazioni che utilizzano i container continua a utilizzare gli stessi strumenti e processi di protezione dei dati di un’applicazione “normale”. Questo è inefficace per diversi motivi. Mentre le soluzioni di backup tradizionali si concentrano principalmente sulle macchine virtuali (VM) o sui backup a livello di file, Kubernetes richiede un approccio più sfumato, data la sua natura dinamica e cloud-nativa. Eseguire il backup di un ambiente basato su container con una soluzione di backup tradizionale è come cercare di scattare un’istantanea di una città con una fotografia. Certo, si possono catturare gli edifici, ma non si ha la percezione del flusso del traffico o di ciò che accade all’interno o nel sottosuolo.
Ma se è così, perché le organizzazioni lo fanno? Nella maggior parte dei casi, si tratta semplicemente di un problema di consapevolezza. Le aziende pensano che la soluzione funzioni. Dopotutto, dispongono di backup e quindi non notano la differenza fino a quando non succede qualcosa di brutto, come un attacco informatico. Non appena cercano di ripristinare l’ambiente basato su container utilizzando questo backup, si rendono conto che il loro backup basato su immagini non può “vedere” i cluster K8. Una soluzione tradizionale esegue il backup solo della macchina virtuale che contiene l’ambiente containerizzato, causando tutti i tipi di problemi potenziali, tra cui backup incompleti, stati incoerenti, inefficienza e lacune nella sicurezza, per citarne alcuni.
Protezione dei dati dalla/alla progettazione
Quindi, capire la necessità di proteggere i container con un sistema che li comprende è il primo ostacolo mentale da superare. Ma c’è un altro ostacolo prima del traguardo. Quando si implementa Kubernetes, la protezione dei dati deve far parte del piano fin dalla fase iniziale di progettazione. Le ragioni sono molteplici, ma si riducono all’efficienza delle risorse (in termini informatici e finanziari), all’opportunità di testare e convalidare e, soprattutto, a garantire un ripristino affidabile e rapido. In realtà, il backup è la parte facile, è il ripristino che è difficile. È essenziale costruire tenendo conto del ripristino rispetto a chiari KPI, ossia l’obiettivo del punto di ripristino (RPO) e l’obiettivo del tempo di ripristino (RTO). Tuttavia, è infinitamente più facile raggiungere questo obiettivo quando fa parte del piano fin dal primo giorno.
Con quasi un’organizzazione su cinque che commette questo errore, si tratta di un problema antico per una nuova tecnologia. Se guardiamo a dieci o vent’anni fa, quando le organizzazioni proteggevano i loro server fisici, i dettagli tecnici sono cambiati, ma la ragione del problema rimane la stessa: il backup è “noioso e stancante”. È come guardare gli airbag quando si costruisce una nuova auto sportiva: nessuno lo fa per gli airbag, anche se spesso sono un salvavita. Di conseguenza, c’è il rischio che nessuno ci pensi nelle prime fasi di sviluppo. Ma se si è costruito il telaio e si è aggiunto un cruscotto ad alta tecnologia, l’inserimento dell’ultima misura di sicurezza sarà molto più costoso del necessario.
Questo non vuol dire che: “Se non ci avete ancora pensato, non preoccupatevi”. Le organizzazioni devono disporre di piani di backup e ripristino comprovati e testati. Secondo il Veeam Data Protection Trends Report 2023, l’85% delle organizzazioni ha subito almeno un attacco informatico nei dodici mesi precedenti, con un aumento rispetto al 76% dell’anno precedente. In un modo o nell’altro, è necessario essere “Left of Bang”. Se il lavoro venisse svolto dopo la progettazione di un ambiente containerizzato, potrebbe richiedere un po’ di riprogettazione e refactoring, ma è sempre meglio dell’alternativa di trovarsi impreparati durante un attacco ransomware di successo. Come dice il proverbio: Il momento migliore per piantare un albero è stato 20 anni fa. Il secondo momento migliore è adesso.
