Come garantire la sicurezza dei Container

Un Container può agire, tramite il kernel, come punto di diffusione di attacchi cibernetici. Red Hat suggerisce come  evitare i rischi

I container rappresentano una componete di una  architettura per i dati che permette di rendere le applicazioni più portatili tra ambienti di sviluppo, test e produzione. In sostanza, aiutano  a semplificare gli sviluppi del software e a risparmiare tempo, e di conseguenza costi di sviluppo.

Proprio per la loro portabilità ed il fatto che contengano in un unico contenitore tutto quanto relativo a uno specifico progetto o attività business, ne risulta un aumento dei rischi connessi alla sicurezza. “Smarrire” o aprire la strada a un cyber criminale a un intero container non è come   perderne una limitata parte.

In proposito, ha osservato Kimberly Craven, product marketing  di Red Hat, un recente studio Forrester commissionato proprio da Red Hat ha rivelato che il 53% dei decision-maker IT ha identificato la sicurezza come principale freno all’adozione dei container. Le aziende che intendono adottarli dovrebbero quindi guardare attentamente al modo in cui garantire la sicurezza dei container, focalizzandosi su provenienza, contenuto, isolamento e fiducia.

Certificare  e ispezionare il container

La prudenza si impone. Oltre il 30% delle immagini ufficiali su Docker Hub, osserva il manager, contengono vulnerabilità importanti secondo uno studio di BanyanOps. La certificazione  con firme digitali per esempio aggiunge un livello di sicurezza confermando chi ha creato il container e a quale scopo.

Per aumentare la sicurezza Red Hat e altri leader di mercato stanno lavorando per stabilire standard e practice per la certificazione dei container in modo da garantire che:

• Tutti i componenti provengono da fonti fidate
• I container host non siano stati manomessi e siano aggiornati
• L’immagine container non presenti vulnerabilità note nei component della piattaforma e nei sui livelli
• I container siano compatibili e operino in ambienti ospitanti certificati

Verificare da dove viene un container è quindi importante, ma analizzare quello che c’è dentro l’immagine del container lo è ancora di più, mette in guardia Craven.

Come la deep packet inspection studia i pacchetti che viaggiano in rete alla ricerca di contenuti malevoli, così la Deep Container Inspection (DCI) guarda il contenuto. Avere visibilità sul codice all’interno del container è fondamentale per mantenere la sicurezza durante e dopo lo sviluppo.

Isolare mette al sicuro il business

Una volta che le applicazioni container-based sono composte da container sicuri, bisogna assicurarsi che non vengano compromessi da altre immagini container sullo stesso host. La realtà è che i container non contengono veramente delle applicazioni, è più corretto dire che i container pacchettizzano il codice di un’applicazione con le sue dipendenze.

Se si pensa ai container come degli oggetto con delle pareti, si deve essere consapevoli che sono estremamente sottili. I contenuti malevoli in un container possono passare a un altro o al sistema operativo host. Ogni singolo processo che gira all’interno di un container parla direttamente con l’host kernel e per tutti i container su quell’host. Il kernel può in sostanza fungere da single point of failure. Una vulnerabilità all’interno del kernel Linux potrebbe permettere a coloro che accedono a un container di impossessarsi dell’host OS e di tutti gli altri container sull’host.

Per questo è fondamentale affidarsi a un host OS che venga mantenuto da kernel engineer e che sia aggiornato frequentemente con i più recenti fix di sicurezza. I containers basati su host deboli ereditano il modello di sicurezza compromesso di quell’host. Il kernel deve includere funzionalità che offrono livelli di isolamento e separazione appropriati come SELinux, Seccomp, Namespaces, e altri.

La variabile tempo gioca contro

Un’altra variabile va considerata, quella temporale. Se nell’istante  T zero l’applicazione container-based viene messa in produzione, cosa succede il giorno uno? Il giorno due? Nuove vulnerabilità vengono identificate quotidianamente e l’immagine container è sicura come il codice e le dipendenze che contiene. Red Hat per esempio ha identificato e risolto 66 vulnerabilità di varia gravità nel JAVA Runtime Environment in 315 giorni, ma ne è sufficiente una per compromettere il container e, potenzialmente, l’intero stack infrastrutturale.

Quello che ne deriva è che anche i container e i loro host devono essere gestiti durante l’intero ciclo di vita. Le aziende necessitano quindi di tooling policy-driven che automatizzi la gestione di versioni e upgrade, identità e accessi, sicurezza e prestazioni.

Che fare?

Anche se velocità e agilità rappresentano driver fondamentali per l’adozione dei container in azienda, suggerisce Craven, non devono essere integrati a spese della sicurezza. Ecco perché un DCI enterprise-level, associato a certificazioni, policy e fiducia è parte integrante dello sviluppo, deployment e gestione dei container. Per trarre il massimo vantaggio dai container pur garantendo la sicurezza di questi ultimi e dei loro contenuti, l’azienda deve trovare modi più efficaci per determinarne:

• Provenienza. Prima di spostare un container in rete, accertarsi di sapere cosa contiene e dove ha avuto origine. Analizzare la tecnologia di validazione e le certificazioni relative alle fonti.
• Deep container inspection può guardare al di là dell’immagine per identificare e mitigare eventuali vulnerabilità.
• Isolamento. Considerare l’isolamento del percorso di esecuzione del container con SELinux. In ambienti multi-tenant, valutare l’associazione di container con la virtualizzazione per uno strato di sicurezza aggiuntivo.

Come evidenziato, non si deve poi  trascurare  di ispezionare regolarmente i contenuti dei container per ridurre eventuali rischi alla sicurezza per identificare ed eliminare le vulnerabilità.