Gli attacchi informatici verso ambienti cloud sono in aumento, ma il vero problema non è la tecnologia: tra errori di configurazione, identità compromesse e scarsa visibilità, le imprese faticano ad adattare le strategie di sicurezza a un contesto sempre più complesso.
Indice degli argomenti
Non è “solo” un tema tecnologico
Negli ultimi mesi chi lavora nella cybersecurity lo sta vedendo chiaramente, gli attacchi verso ambienti Cloud stanno aumentando. Non è una percezione, ma è proprio quello che succede sul campo. In fondo è anche logico, le aziende hanno spostato molti servizi in Cloud – infrastrutture, dati, applicazioni di business e persino servizi mission-critical – ed è quindi lì che oggi si gioca la partita.
Il problema è che questo passaggio è stato spesso più rapido dell’evoluzione delle competenze, dei processi e dei controlli necessari per gestirlo in sicurezza.
Qui entra in gioco il grande fraintendimento. Molte organizzazioni danno per scontato che “sicurezza del cloud” significhi “se ne occupa il provider”, sottovalutando il proprio ruolo nel modello di responsabilità condivisa.
Il Cloud non è un monolite: a seconda che si parli di IaaS, PaaS o SaaS cambia radicalmente cosa protegge il provider e cosa resta in carico al cliente. Nel modello di responsabilità condivisa, il provider garantisce sicurezza dell’infrastruttura (data center, rete, hypervisor), mentre l’azienda resta responsabile di configurazioni, identità, dati e, spesso, anche dei carichi applicativi. Il problema è che questo confine, in molti casi, non è realmente compreso né tradotto in procedure concrete. Alcuni esempi tipici sono bucket di storage resi pubblici “per comodità”, poi mai più ricontrollati; account e ruoli con privilegi eccessivi, creati per urgenze progettuali e mai ridimensionati, ma anche assenza di log centralizzati e di monitoraggio coerente tra diversi account e provider.
Il risultato è che una parte essenziale della superficie di attacco resta di fatto “terra di nessuno”: non controllata dal provider, ma nemmeno dall’azienda, benché formalmente di sua responsabilità.
Identità esposte: il nuovo “perimetro” da proteggere
Sempre meno exploit sofisticati, sempre più abuso di quello che già esiste. Accessi legittimi, configurazioni sbagliate, sistemi e servizi non hardenizzati. In molti casi non c’è nemmeno bisogno di “bucare” qualcosa. Nel cloud, l’identità è il nuovo perimetro: chi controlla le identità e i token di accesso controlla i dati e i servizi. Vediamo che gli attaccanti stanno cambiando approccio: non cercano più solo vulnerabilità tecniche, ma puntano a sfruttare errori umani e complessità degli ambienti Cloud.
Gli attaccanti lo sanno bene e puntano soprattutto a compromettere credenziali privilegiate (admin cloud, account DevOps, service account di automazioni), a riutilizzare token, chiavi API e secret esposti in repository pubblici o strumenti di test, ma anche a sfruttare MFA non applicata in modo coerente, eccezioni “temporanee” mai rimosse, bypass operativi. In altre parole: se trovano una porta aperta, entrano e nel caso del cloud succede più spesso di quanto si pensi.
Qui sta il punto centrale. Il Cloud non è “insicuro”, ma è molto facile usarlo male. Configurazioni ad alto rischio lasciate a default, permessi troppo ampi, mancanza di segmentazione tra ambienti (sviluppo, test, produzione), assenza di criteri minimi di hardening sono tra i vettori più frequenti che vediamo negli incidenti reali. Il multi-cloud – l’utilizzo di diversi provider di servizi Cloud – complica ulteriormente tutto: più piattaforme, più regole, più modelli di sicurezza da comprendere e gestire.
La superficie di attacco si estende in modo esponenziale: più account, più identity store, più servizi gestiti da team diversi, spesso con visibilità limitata o frammentata. Il cloud non è meno sicuro, ma è diverso. Richiede competenze, visibilità e un controllo continuo che molte organizzazioni stanno ancora costruendo. Ed è proprio questo che trasforma rischi teorici in incidenti concreti.
Quando anche gli strumenti di sicurezza diventano un rischio
Poi c’è un tema che negli ultimi mesi sta emergendo sempre di più, e che sorprende molti.
Strumenti nati per studiare ed eseguire test di sicurezza, che diventano… un problema.
Parliamo di applicazioni usate per test o formazione, quelle volutamente vulnerabili. In teoria dovrebbero stare in ambienti isolati, in pratica, finiscono spesso esposte su ambienti Cloud di produzione non correttamente segregati. Magari vengono lasciate operative dopo un test, con accessi aperti, collegate a risorse reali e con permessi più ampi del necessario. Ed è lì che iniziano i problemi. Gli attaccanti le conoscono già, sanno esattamente come comprometterle dato che le vulnerabilità sono pubbliche.
È il paradosso della sicurezza moderna, purtroppo: strumenti pensati per studiare e quindi migliorare la protezione possono diventare un vettore di attacco se lasciati senza controllo.
Dall’incidente tecnico all’impatto sul business e sulla compliance
Un altro errore comune è pensare che queste dinamiche abbiano impatto solo sui reparti tecnici, ma non è più così da tempo. Un incidente su ambienti Cloud oggi può fermare servizi di moltissime aziende differenti, esporre dati, bloccare operatività. E succede in tempi molto più rapidi rispetto al passato.
Basta colpire un provider o un servizio condiviso per generare impatti “a catena” lungo tutta la supply chain digitale, come alcuni recenti attacchi ransomware al cloud provider di servizi per la PA hanno dimostrato, con blocchi nei sistemi di pagamento e disservizi per cittadini e imprese. A questo si aggiunge poi la parte normativa, con la NIS2 in primis, che rende il tema ancora più critico.
Oggi dobbiamo considerare che un incidente cyber è a tutti gli effetti un rischio aziendale. Non riguarda più solo i sistemi, ma la continuità operativa e la fiducia dei clienti. E qui entrano in gioco anche management e decision maker, non solo l’IT.
Verso un nuovo modello di sicurezza
Continuare a ragionare “a perimetro” nel Cloud non funziona più perché è un modello che, semplicemente, non esiste più.
Per ridurre davvero la probabilità e l’impatto degli incidenti sono necessarie alcune azioni concrete:
Chiarire e formalizzare la responsabilità condivisa
Mappare esplicitamente, per ogni servizio cloud, cosa è in carico al provider e cosa all’azienda, trasformandolo in policy, playbook e controlli misurabili.
Rafforzare la gestione delle identità e degli accessi
Applicare il principio del minimo privilegio, estendere MFA a tutti gli account sensibili, segmentare gli accessi per ambiente e funzione, monitorare in modo continuo attività anomale sulle identità.
Standardizzare le configurazioni e ridurre gli errori
Utilizzare baseline di sicurezza, template infrastrutturali (IaC) e controlli automatici di posture (CSPM) per individuare e correggere configurazioni deboli prima che diventino un problema.
Mettere ordine nel multi-cloud
Centralizzare per quanto possibile log, telemetria e gestione degli alert, in modo da avere una vista unificata sugli eventi di sicurezza tra provider diversi.
Gestire con rigore ambienti di test, lab e strumenti di sicurezza “vulnerabili”
Isolare questi asset, limitarne la superficie di esposizione, prevedere processi di decommissioning e verifiche periodiche per evitare che restino esposti in produzione.
Serve visibilità reale, controllo sulle identità, capacità di capire cosa sta succedendo e soprattutto reagire velocemente. Perché sì, gli attacchi succederanno comunque. La vera differenza tangibile la fa quanto velocemente riesci a capirlo e a fermarli.
In questo scenario, piattaforme in grado di unificare monitoraggio, rilevazione e risposta su ambienti ibridi e multi-cloud – integrando dati da endpoint, identità, rete e workload cloud – diventano un abilitatore fondamentale per ridurre la finestra di esposizione.
La vera sfida non è evitare ogni attacco, ma essere pronti a gestirlo. La velocità di risposta è ciò che oggi fa davvero la differenza.
Una sfida destinata a crescere
Il Cloud non è il problema, ma in realtà è ormai parte della soluzione e proprio per questo continuerà a essere uno degli obiettivi principali. Per le aziende la vera sfida non è tornare indietro, ma andare avanti con più consapevolezza.
Man mano che cresce l’adozione del cloud e di servizi digitali connessi, cresce in modo proporzionale anche la superficie potenziale di attacco: più identità, più integrazioni, più punti di accesso che gli attaccanti possono mettere nel mirino.
E gli attaccanti, per natura, colpiscono dove è più semplice: la combinazione tra una tecnologia che richiede un modello di difesa diverso (spesso sottovalutato nelle fasi iniziali di adozione) e l’uso sempre più massiccio di infostealer per il furto di credenziali e sessioni sta alimentando un nuovo trend di attacco, meno spettacolare e remunerativo del ransomware, ma comunque molto costoso per chi lo subisce in termini di fermi operativi, bonifiche e perdita di fiducia.
Per questo la vera discriminante diventa la postura della sicurezza: non serve solo avere strumenti, ma saperli usare in modo coerente con il modello cloud, aggiornando continuamente controlli, processi e capacità di risposta man mano che l’adozione tecnologica cresce. Questo significa riconoscere che la sicurezza nel cloud è una responsabilità condivisa ma non “diluibile”, e che la parte in carico all’organizzazione non può più essere trattata come un dettaglio operativo. Capire dove sono i rischi, accettare che esistono e gestirli meglio: dalla progettazione delle architetture alla gestione delle identità, dai controlli sulle configurazioni fino alle capacità di detection e incident response.
Perché oggi non vince chi evita tutti gli attacchi, ma chi mantiene una postura di sicurezza capace di assorbire l’evoluzione delle minacce e dell’adozione tecnologica meglio degli altri.
