Kubernetes, sicurezza della Supply Chain e protezione dai Ransomware

La Supply Chain può essere un fattore di rischio in un contesto Kubernetes che si appoggia su OpenSource. Il pericolo per le applicazioni ed i dati costituito dai Ransomware è sempre più concreto ed occorre predisporre una linea di difesa basata anche sulla possibilità di ricreare gli ambienti partendo da Backup immutabili.
blank

L’approccio alla sicurezza in Kubernetes è “variabile” o, se vogliamo usare un termine più appropriato, “olistico”. Questo perché Kubernetes non è solo un potente orchestratore, come qualcuno ancora si ostina a dire, ma è piuttosto il primo vero esempio di Software Defined Datacenter e parlare di sicurezza per Kubernetes è come parlare di sicurezza per un Datacenter, un argomento che ha tante e differenti declinazioni.

Partendo dall’esperienza fatta in una serie di simulazioni di attacco da parte del nostro Red Team Aditinet, possiamo dire che Kubernetes, in generale, ed Openshift, in particolare, hanno un’ottima difesa by design dagli attacchi esterni al cluster e che, se installati secondo le best practices, sono assolutamente difficili da compromettere.

Questa caratteristica intrinseca di “robustezza” rispetto agli attacchi esterni non può comunque far dormire sonni tranquilli agli amministratori ed utilizzatori di cluster Kubernetes.

Dove risiedono i pericoli più insidiosi per Kubernetes?

Sicuramente risiedono negli attacchi portati dall’interno, nei pod compromessi con possibilità di escalation di privilegi e, pensando al modo più insidioso per portare un attacco dall’interno, sicuramente negli attacchi alla Supply Chain.

La catena la conosciamo: un git, un registry, un helm repository; sempre di più i developer si appoggiano ad applicazioni e librerie depositate in repository pubblici e sempre più Architects, Ops e persino gli utenti finali installano applicazioni open source che trovano dopo qualche ricerca su Internet.

Gli attacchi possono essere sofisticati e molto insidiosi, ad esempio un furto di credenziali di contributor e l’iniezione di codice malevolo nelle librerie di uso comune; possono essere semplici ma disruptive, con la creazione di una git con un’assonanza di nome ad un pacchetto conosciuto e che contiene una versione compromessa dell’utilities con C&C o Ransomware.

Uno studio eseguito da Google nell’ambito dell’iniziativa Scorecard Project sulla sicurezza dei progetti OpenSource mostra che su 50.000 Repository analizzati, meno del 2% usa Security Policy, strumenti SAST, Fuzz testing o esegue un pin delle dipendenze.

blank
copyright by Google

La semplicità d’uso, la flessibilità e la portabilità garantiti da Kubernetes possono diventare la sua debolezza, perché la velocità è per definizione la nemica numero uno della Sicurezza.

La Sicurezza Kubernetes

Ovviamente in un ambiente Kubernetes in cui la Sicurezza sia stata approcciata nel modo corretto le probabilità di successo di un attacco sono veramente basse: registry e git airgapped, sistemi di Vulnerability Management su tutta la Pipeline, una Run Time protection potente, una policy ristretta sui Pod privilegiati, un’attenta gestione dei privilegi degli account sono tutte azioni che contribuiscono a rendere il sistema più sicuro.

Tuttavia, le probabilità che un attacco entri attraverso la Supply Chain esistono ed è dovere delle aziende essere sicure che esista un’ultima linea di difesa inattaccabile, specie contro la tipologia di attacco più insidiosa, i Ransomware.

Subire la cifratura e l’inaccessibilità dei dati e delle applicazioni, se non addirittura dei servizi del cluster Kubernetes, è una possibilità non remota. Inoltre, un re-deploy partendo dai git e dai registry potrebbe dimostrarsi non percorribile qualora questi siano le prime vittime di un attacco ben congegnato.

La linea di difesa contro questa tipologia di attacchi è definita nella letteratura di Veeam, che tra le Best Practices della Sicurezza Kubernetes indica che si dovrebbero prevedere 3 copie su due tipi diversi di media, di cui uno off-site, il famoso 3-2-1.

Applicando questa filosofia anche all’infrastruttura, alle applicazioni ed ai dati di Kuberntes si avrà la certezza di poter ripartire dopo un attacco Ransomware senza dover sottostare al ricatto.

I vincoli della soluzione che devono essere implementati per Kubernetes sono gli stessi delle soluzioni tradizionali, nulla più e nulla meno, con la differenza che per raggiungere l’obiettivo bisogna partire da soluzioni Kubernetes Native e non da quelle tradizionali adattate a questo mondo.

Ma perchè scegliere una soluzione Kubernetes Native?

Per prima cosa è necessario garantire l’integrità dei dati e delle applicazioni e questo è possibile solo se si utilizzano i meccanismi nativi di Kuberntes e un approccio Kubernetes aware al backup, salvando tutti gli oggetti e tutte le API che costituiscono l’applicazione per evitare che la mancanza di anche solo uno di essi ne impedisca la ripartenza.

La velocità è importante; per il restore dell’intera infrastruttura i tempi di ripristino devono essere bassi e questo richiede necessariamente di lavorare a livello nativo in Kubernetes, senza agent o proxy che potrebbero diventare dei colli di bottiglia.

In realtà vi è poi una terza caratteristica che un po’ allontana dal classico modo di lavorare della community Kubernetes ed invece riavvicina al mondo del Backup e Restore tradizionali: la semplicità d’uso.

In un momento di crisi o pericolo non è possibile correre il rischio di essere dipendenti da una squadra di pochi esperti del mondo Kubernetes in grado di usare le CLI per eseguire delle procedure manuali di ripristino seguendo la documentazione.

La soluzione scelta deve avere interfacce immediate e semplici, deve poter essere utilizzata anche da operatori Junior con skill Kubernetes limitate e deve poter essere automatizzata con un approccio API driven, cosa che Kasten K10 by Veeam consente di fare.

Ultima considerazione riguarda il Backup target, on-premises od off-premises che sia, per cui deve essere garantita l’immutabilità per il periodo di retention dei dati.

L’immutabilità del dato deve essere gestita ovviamente in primis da parte dell’applicazione di Backup, che deve anche dimostrarsi efficiente nella gestione degli spazi per evitare che la crescita dei costi di archiviazione diventi un deterrente all’implementazione di un processo sicuro.

La scelta del Backup target deve traguardare tecnologie Cloud native come i bucket S3 per garantire la portabilità; AWS offre per esempio la possibilità di avere bucket immutabili e l’implementazione veloce anche della parte off-site dell’architettura di Backup.

Una volta che un’infrastruttura di questo tipo è stata implementata, la filosofia di Kubernetes aiuta a combattere un attacco Ransomware. La precarietà dei Containers e l’esistenza di best practices per la loro costruzione al fine di minimizzarne la superficie di attacco rendono molto semplice l’individuazione di uno stato del sistema in cui il Ransomware è stato eliminato, consentendo così di ripartire velocemente in un contesto di massima sicurezza.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on email
Share on print

Articoli correlati

Non sei ancora iscritto alla nostra newsletter?

Torna su