L'avvento di processori più potenti nei primi anni 2000 con supporto in hardware per la virtualizzazione ha iniziato la rivoluzione informatica che ha portato, nel tempo, a quello che ora chiamiamo cloud. Con le istanze hardware singole in grado di eseguire dozzine, se non centinaia di macchine virtuali contemporaneamente, le aziende potrebbero offrire ai loro utenti più servizi e applicazioni che altrimenti sarebbero state finanziariamente poco pratiche, se non impossibili.
Ma le macchine virtuali (VM) hanno diversi aspetti negativi. Spesso, un intero sistema operativo virtualizzato è eccessivo per molte applicazioni e, sebbene molto più malleabile, scalabile e agile di una flotta di server a metallo nudo, le macchine virtuali richiedono ancora una memoria e una potenza di elaborazione significativamente più e sono meno agili della prossima Evoluzione di questo tipo di tecnologia: contenitori. Oltre ad essere più facilmente ridimensionati (su o giù, secondo la domanda), le applicazioni containerizzate sono costituite solo dalle parti necessarie di un'applicazione e dalle sue dipendenze di supporto. Pertanto, le app basate sui micro-servizi tendono ad essere più leggere e più facilmente configurabili.
Le macchine virtuali mostrano gli stessi problemi di sicurezza che incidono sulle loro controparti a metallo nudo e, in una certa misura, i problemi di sicurezza dei contenitori riflettono quelli delle loro parti componenti: un bug MySQL in una versione specifica dell'applicazione a monte influenzerà anche le versioni containerizzate. Per quanto riguarda le macchine virtuali, le installazioni di metallo nudo e i contenitori, le preoccupazioni e le attività di sicurezza informatica sono molto simili. Ma le implementazioni dei container e i loro strumenti portano sfide di sicurezza specifiche a coloro che sono accusati di eseguire app e servizi, che mettono insieme manualmente applicazioni con contenitori scelti o che si svolgono in produzione con orchestrazione su vasta scala.
Rischi per la sicurezza specifici del contenitore
- Misconfigurazione: Le applicazioni complesse sono costituite da più contenitori e la configurazione errata – spesso solo una singola riga in un file .yaml, può concedere privilegi non necessari e aumentare la superficie di attacco. Ad esempio, sebbene non sia banale per un utente malintenzionato ottenere l'accesso alla radice alla macchina host da un contenitore, è ancora una pratica troppo comune per eseguire Docker come root, senza rimappatura dello spazio degli utenti, per esempio.
- Immagini del contenitore vulnerabili: Nel 2022, Sysdig trovato Oltre 1.600 immagini identificate come dannose in Docker Hub, oltre a molti contenitori immagazzinati nel repository con credenziali cloud codificate, chiavi SSH e token NPM. Il processo di estrazione di immagini dai registri pubblici è opaco e la comodità della distribuzione del contenitore (oltre alla pressione sugli sviluppatori per produrre risultati, velocemente) può significare che le app possano essere facilmente costruite con componenti intrinsecamente insicuri o persino dannosi.
- Strati di orchestrazione: Per progetti più grandi, strumenti di orchestrazione come Kubernetes possono aumentare la superficie di attacco, di solito a causa dell'errore di configurazione e alti livelli di complessità. Un 2022 Sondaggio da D2IQ ha scoperto che solo il 42% delle applicazioni in esecuzione su Kubernetes è entrato in produzione, in parte in parte per la difficoltà di amministrare cluster di grandi dimensioni e una ripida curva di apprendimento.
Secondo Ari Weil di Akamai, “Kubernetes è maturo, ma la maggior parte delle aziende e degli sviluppatori non si rende conto di quanto possa essere complesso (…) fino a quando non sono effettivamente su vasta scala”.
Sicurezza del contenitore con l'apprendimento automatico
Le sfide specifiche di Sicurezza del contenitore può essere affrontato usando Apprendimento automatico Algoritmi addestrati per osservare i componenti di un'applicazione quando è “in esecuzione pulita”. Creando una linea di base di comportamenti normali, l'apprendimento automatico può identificare anomalie che potrebbero indicare potenziali minacce da traffico insolito, modifiche non autorizzate alla configurazione, schemi di accesso agli utenti dispari e chiamate di sistema inaspettate.
Le piattaforme di sicurezza del contenitore basate su ML possono scansionare i repository di immagini e confrontare ciascuno con i database di vulnerabilità e problemi noti. Le scansioni possono essere attivate e programmate automaticamente, aiutando a prevenire l'aggiunta di elementi dannosi durante lo sviluppo e la produzione. I rapporti di audit auto-generati possono essere tracciati rispetto a benchmark standard o un'organizzazione può impostare i propri standard di sicurezza, utili in ambienti in cui dati altamente sensibili viene elaborato.
La connettività tra funzioni di sicurezza dei contenitori specializzati e software di orchestrazione significa che i contenitori sospetti possono essere isolati o chiusi immediatamente, le autorizzazioni non sicure revocate e l'accesso all'utente sospeso. Con le connessioni API a firewall locali ed endpoint VPN, possono essere isolati interi ambienti o sottoreti o il traffico interrotto ai confini della rete.
Parola finale
L'apprendimento automatico può ridurre il rischio di violazione dei dati in ambienti containerizzati lavorando su diversi livelli. Il rilevamento delle anomalie, la scansione delle risorse e la segnalazione di potenziali errate configurazioni sono tutti possibili, oltre a qualsiasi grado di avviso o miglioramento automatizzato sono relativamente semplici da attuare.
Le possibilità trasformative delle app basate su container possono essere affrontate senza i problemi di sicurezza che hanno impedito ad alcuni di esplorare, sviluppare e eseguire applicazioni basate su microservizi. I vantaggi delle tecnologie native cloud possono essere vinti senza compromettere gli standard di sicurezza esistenti, anche in settori ad alto rischio.
Fonte: www.artificialintelligence-news.com
