L'adozione di container da parte delle aziende rappresenta un’opportunità unica in ambito sicurezza.
In questo articolo spiegheremo perché i container rappresentano un’opportunità importante per colmare il divario tra team di sviluppo e sicurezza.
È possibile che i container semplifichino l’adozione di metodologia DevSecOps? Prima di rispondere alla domanda ripercorriamo le evoluzioni storiche che ci hanno portato fin qui.
Brevi Cenni Storici
Ci piace pensare al computing come una sequenza di più fasi. La prima, relativa al client-server in esecuzione su bare metal con un singolo sistema operativo e un’app. La seconda è relativa a quando VMware è entrato nel mercato dei server nel 2001.
Questo ha inaugurato l’era del computing virtualizzato. La terza fase ci riporta al presente con i container. La metodologia DevOps e il desiderio di rendere le applicazioni portabili ha portato ad una rapida adozione dei container.
La quarta fase, ancora non ampiamente diffusa nelle aziende, è relativa al cosiddetto FaaS (Function-as-a-Service). Esso rappresenta una tipologia di computing altrimenti nota come serverless o anche event-driven.
I servizi di elaborazione serveless più noti sono Cloud Functions di Google e Lambda di AWS.
Analizziamo adesso la Container Security Triad (vedi immagine seguente) per capire in che modo consente di avvicinare i team di sicurezza alla metodologia DevSecOps.
Sicurezza in Fase di Costruzione
La sicurezza del container nella fase di sviluppo significa che essa è effettivamente integrata nelle fasi del processo anziché nel runtime. Proviamo a capire attraverso un esempio pratico: la prima cosa che facciamo prima di costruire una casa è capire come vogliamo che sia costruita.
Accade la stessa cosa per quanto riguarda la sicurezza dei container. La sicurezza durante la costruzione dovrebbe focalizzarsi sull'eliminazione di vulnerabilità, malware e codici non sicuri.
Poiché i container sono costituiti da librerie, binari e codici applicativi, è importante stabilire un registro di container ufficiale dell’organizzazione. È compito del team di sicurezza trovare i registri per ottenere rapidamente il consenso per l’accesso e stabilire gli standard di sicurezza.
L’obiettivo principale di identificare e creare un registro container standard è creare immagini affidabili. È necessario concordare un processo e garantire che nessun container sia distribuito da un registro non attendibile.
Con oltre 2 milioni di applicazioni, Docker Hub è probabilmente il registro container più noto.
Sicurezza in Fase di Deploy
Nella fase di deploy, il focus si sposta dalla sicurezza che i materiali utilizzati per la costruzione della casa siano senza difetti, ad essere sicuri che il team stia lavorando correttamente.
Puoi avere un’immagine priva di vulnerabilità, ma se è distribuita su un pod Kubernetes configurato in modo non sicuro, significa che il rischio non è stato sufficientemente gestito. Una ricerca sulle minacce realizzata da Unit 42 di Palo Alto Networks, ha rilevato che il 46% delle organizzazioni accetta il traffico verso i pod Kubernetes da qualsiasi fonte.
Nel mondo on-premises, questo equivale a distribuire un server e consentire qualsiasi tipologia di traffico. È una cosa che nessuno metterebbe in pratica, allora per quale motivo la maggior parte delle organizzazioni lo attua con il cloud pubblico?
Il deploy di una configurazione sicura può essere ottenuto adottando uno standard di sicurezza sia per l’orchestrazione che per il container selezionato. È importante non dimenticare di mettere in atto il processo e gli strumenti necessari che consentiranno automazione e monitoraggio.
Il Center for Internet Security (CIS) ha svolto un ottimo lavoro creando benchmark di sicurezza sia per Docker che per Kubernetes.
Sicurezza in Fase di Runtime
La casa è costruita, e adempie al suo scopo funzionale, ma i sistemi tendono verso l’entropia (vedi la seconda legge della termodinamica).
La sicurezza nella fase di runtime riguarda l’identificazione di nuove vulnerabilità nell'esecuzione di container; inoltre, comprende anche lo studio di attività sospette/anomale che potrebbero indicare attacchi zero-day.
Se il team di sicurezza è stato coinvolto fin dall'inizio (a partire dalla fase di costruzione), ottenere sicurezza in fase di runtime è molto meno complesso.
L’IBM Systems Sciences Institute ha scoperto che il costo per correggere un bug durante la fase di manutenzione (ad es. runtime) è 100 volte più costoso rispetto che correggerlo durante la progettazione.
In Conclusione
L'approccio DevSecOps prevede che la sicurezza sia integrata nello sviluppo di app dall'inizio alla fine. Questo richiede una nuova strategia organizzativa oltre a nuovi strumenti.
I team DevOps, tenendo a mente tutto questo, devono automatizzare la sicurezza per proteggere l'ambiente e i dati, nonché il processo di distribuzione e integrazione continua: obiettivo che includerà con ogni probabilità anche la sicurezza dei microservizi nei container.
Palo Alto Networks è l'organizzazione a più alta crescita nel mercato internazionale della Cyber Security, riconosciuta da Fortune Magazine nella lista delle "Top 50 companies changing the world".
Palo Alto Networks offre una suite completa di nuova generazione per la sicurezza dell'azienda: Next-Generation Firewalls, Virtualized Next-Generation Firewalls, Network Security Management, Security Subscriptions, Advanced Endpoint Protection e SaaS Security.
Per avere maggiori informazioni sulla soluzione invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250.
In alternativa, puoi compilare il form sottostante con la tua domanda.