La velocità e l’innovazione nell’era cloud e dell’AI sono innegabili pur portandosi dietro responsabilità e rischi. Per mantenere gli ambienti cloud sicuri e protetti, occorre esaminare in modo introspettivo come migliorare l’attenzione del personale interno al tema cyber, adottando processi e tecnologia adatti in linea al nuovo contesto delle minacce esterne.
A tal fine, SentinelOne ha pubblicato di recente due report che evidenziano ogni lato della medaglia nella sfida della sicurezza del cloud quali:
- Il Cloud Security Survey Report che raccoglie i dati di 400 responsabili e professionisti della sicurezza informatica che gestiscono le operazioni di sicurezza del cloud, le responsabilità, le percezioni delle tecnologie e i futuri piani di investimento.
- Il Cloud Security Risk Report che descrive i cinque rischi emergenti nel 2025 con esempi di attacchi che sfruttano il furto di credenziali cloud, il movimento laterale, l’archiviazione cloud, gli attacchi alla supply chain e i servizi di AI in cloud.
Entrambi i report evidenziano la necessità di migliorare la sicurezza del cloud, riducendone le configurazioni errate e il numero di compromissione delle credenziali.
Indice degli argomenti
Configurazioni errate del cloud
La criticità delle configurazioni errate in cloud è nota ai team di sicurezza sin dal 2019 quando Gartner affermò che il 99% dei problemi per la sicurezza del cloud sarebbe stato legato a distrazioni degli utenti. Nonostante oggi siano disponibili molteplici innovazioni e soluzioni di Cloud Security Posture Management (CSPM), la sfida rimane alta e le violazioni continuano a verificarsi a causa di semplici errori di configurazione.
Il problema rilevato di frequente è quello del public storage cloud non crittografato. Tra gli esempi forniti dal Risk Report figura una violazione del dicembre 2024, quando il bucket S3 di una filiale Volkswagen configurato in modo errato ha reso vulnerabili dati sensibili di oltre 800.000 proprietari di auto. Un altro caso avvenuto sempre lo scorso dicembre è stato quando si è scoperto che l’hacker Nemesis, specializzato nel furto di credenziali e di attacchi allo storage cloud, aveva configurato in modo errato i propri bucket S3.
Nella survey sulla sicurezza del cloud, il tema della configurazione errata ha fornito risposte contrastanti. Nella classifica dell’importanza delle funzionalità di sicurezza del cloud, la soluzione CSPM si è classificata al secondo posto (la prima era Cloud Detection and Response, CDR). Concentrandosi sull’efficacia delle funzionalità, la CSPM ha ottenuto un punteggio elevato, piazzandosi al terzo posto a pari merito quando agli intervistati è stato chiesto di valutare il livello di soddisfazione della propria organizzazione nei confronti della CSPM scelta, con un punteggio di 4,22 su 5.
Pertanto, la CSPM è ampiamente considerata vitale ed efficace contro le configurazioni errate del cloud. Ciò contrasta con la fiducia degli intervistati nella capacità della propria organizzazione di “valutare le configurazioni errate”. Purtroppo, questa si colloca all’ultimo posto delle 8 funzioni di sicurezza del cloud elencate, con un punteggio di 3,98 su 5.
Un possibile indizio di questa discrepanza potrebbe trovarsi nella definizione delle priorità e nella gestione dei falsi positivi. Dopotutto, le soluzioni CSPM sono notoriamente molto attive e la struttura ripetuta di molti ambienti cloud può spesso generare avvisi a cascata per lo stesso problema, riscontrati in più aree. Ben l’86,9% degli intervistati conferma di avere difficoltà a convalidare e stabilire le priorità degli avvisi e degli eventi cloud. Inoltre, due terzi delle organizzazioni (67,7%) concordano sul fatto che generare così tanti dati sulla sicurezza cloud causa criticità ai propri team nell’ottenere informazioni utili.
Chain di configurazioni errate
Nel momento in cui i difensori diventano abili nel chiudere la porta alle evidenti opportunità di violazione del cloud, gli hacker concatenano sempre più spesso configurazioni errate minori e meno significative per abilitare compromissioni più gravi e movimenti laterali all’interno degli ambienti cloud. Come esempio di configurazioni errate concatenate, si può analizzare il case study fittizio che ruota attorno a un negozio di e-commerce che sfrutta le funzioni Lambda descritte in dettaglio nel Risk Report.
Configurazioni errate guidate da utenti malintenzionati
Le complesse campagne di attacco al cloud degli ultimi tempi hanno incluso hacker che causano configurazioni errate del cloud mentre modificano o disabilitano i servizi cloud.
Ad esempio, ScarletEel automatizza la disabilitazione dei servizi di sicurezza cloud nelle campagne di cryptomining. Più comunemente, gli autori delle minacce creano ruoli eccessivamente permissivi (un errore di configurazione comune del cloud) per facilitare il movimento laterale e il rilevamento. Gli esempi includono la campagna di estorsione su larga scala (potenzialmente da parte di Nemesis con le sue scarse abitudini di cloud storage), in cui implementano una serie di funzioni Lambda per automatizzare la creazione di queste identità mal configurate.
Ciò solleva una sfida interessante per i team di sicurezza del cloud: come distinguere le configurazioni errate del cloud derivanti dalle scelte di implementazione della propria organizzazione dalle configurazioni errate che potrebbero essere state causate da autori di minacce esterni o interni. Se la lista delle configurazioni errate del cloud è statica, ovvero basata su cosa esiste e non su quando o come, questa differenziazione sarà difficile.
Le credenziali compromesse e la scansione segreta
Nonostante la loro criticità, la survey di SentinelOne sulla sicurezza del cloud ha rilevato che tra le funzionalità di sicurezza del cloud di base, la scansione segreta (che aiuta i difensori a cercare le credenziali perse) si è classificata all’ultimo posto. Meno del 13% degli intervistati ha incluso la scansione segreta in un elenco delle cinque funzionalità di sicurezza cloud più importanti che includeva il rilevamento e la risposta al cloud, le piattaforme di protezione dei carichi di lavoro cloud (CWPP), la scansione Infrastructure-as-Code (IaC) e altro ancora.
Inoltre, la scansione segreta è stata penultima in una classifica dell’efficacia degli strumenti e delle funzionalità di sicurezza del cloud. Pertanto, i difensori considerano la capacità di scansione delle credenziali compromesse come non critica e non efficace rispetto ad altre funzionalità. Forse la cosa più drastica è l’alta percentuale di intervistati che attualmente non possiede capacità di scansione segrete. Quasi il 30% degli intervistati non ha iniziato a implementare funzionalità di scansione segrete o non ha intenzione di farlo.
La survey prevede, tuttavia, che l’importanza relativa della scansione segreta aumenterà nel prossimo futuro, poiché DevSecOps e lo spostamento della sicurezza nella pipeline di sviluppo diventeranno un obiettivo crescente per i team di sicurezza.
Casi reali
Una singola credenziale compromessa può garantire agli aggressori l’accesso a più sistemi contemporaneamente, rendendo prevedibile un’escalation dopo aver ottenuto l’accesso alle credenziali. Le organizzazioni stanno inconsapevolmente codificando le credenziali o divulgandole in servizi di condivisione del codice accessibili in modalità public.
Un esempio evidenziato dal Risk Report è la scoperta di oltre 1,1 milioni di codici trapelati in sole 58.000 applicazioni web con file di ambiente accessibili. Un altro esempio è stata la campagna di alto profilo ShinyHunters dello scorso anno, che ha comportato la raccolta di credenziali su endpoint e siti web, provocando numerose violazioni di Snowflake. Nei casi in cui hanno avuto successo, gli aggressori hanno preso di mira direttamente le istanze di Snowflake basate su cloud per un’enorme esfiltrazione di dati, portando inizialmente a supposizioni che Snowflake stesso fosse stato violato.
Un ulteriore esempio riguarda un dipendente di xAI che ha fatto trapelare una chiave API privata su GitHub, fornendo l’accesso a modelli linguistici di grandi dimensioni inediti e informazioni sensibili di organizzazioni associate come SpaceX: una singola perdita che ha causato impatti lungo una catena di approvvigionamento.
Gli autori delle minacce conoscono il potere delle credenziali compromesse e sta evolvendo l’uso di infostealer e di movimenti laterali “creativi” su sistemi sempre più connessi per sfruttare ulteriormente questo vettore di attacco.
Gli infostealer sono sempre più a caccia di credenziali cloud e container e vengono integrati in campagne di attacco più ampie per aumentare le loro capacità di compromissione. Esempi di ciò includono la campagna di furto di risorse SilentBob di TeamTNT che sfrutta un infostealer dopo che l’impatto dei cryptominer è stato stabilito, per ampliare la portata di ciò che l’aggressore può fare dopo.
