Cybersecurity e cloud 2026: il nodo non è più spostare i carichi ma renderli governabili

La spinta verso il cloud non si è fermata. Ha cambiato forma. Nelle organizzazioni più mature, la discussione non ruota più attorno al “se” migrare, ma al “come” mantenere controllo quando dati, applicazioni e identità si distribuiscono su più piani, dal cloud pubblico al private cloud fino a un ecosistema SaaS sempre più esteso. Non è un dettaglio: la frammentazione del perimetro è ormai un dato strutturale e coincide con una crescita del rischio operativo. Anche perché il cloud, per definizione, rende più semplice attivare servizi, aprire integrazioni, moltiplicare API e permessi. Tutto ciò accelera l’innovazione, ma amplia anche le opportunità per un attaccante che non deve più “entrare in rete” nel modo classico: spesso gli basta sfruttare identità, configurazioni e catene di fiducia. I numeri aiutano a inquadrare la scala. Gartner stima che in Europa nel 2026 la spesa end-user per i servizi di public cloud crescerà del 24%.

Quando la piattaforma diventa l’infrastruttura normale del business, la cybersecurity non può più essere trattata come uno “strato” aggiuntivo. Deve diventare un requisito di progetto, perché nel cloud la velocità è un vantaggio competitivo tanto quanto una possibile vulnerabilità.

Perché il cloud sposta il baricentro della sicurezza sulle identità

Nel mondo cloud-first, la chiave non è soltanto proteggere workload e dati, ma governare l’identità come nuovo perimetro. L’errore ricorrente è pensare che la sicurezza cloud sia la “stessa sicurezza” trasportata altrove. In realtà, la superficie di attacco cresce in modo diverso: aumenta il numero di componenti configurabili, la dipendenza da ruoli e policy, l’interconnessione tra servizi, l’uso di token e credenziali non umane. In pratica, le decisioni di accesso e le configurazioni diventano parte integrante del rischio.

Questa centralità dell’identità nasce dal fatto che nel cloud l’accesso precede quasi sempre l’azione. Un attaccante non deve necessariamente forzare un perimetro di rete, perché può cercare l’anello debole nella catena delle autorizzazioni: un account con privilegi eccessivi, una relazione di trust mal progettata, un token esposto, una chiave lasciata in chiaro in un repository, un servizio integrato senza adeguata segregazione. Nel cloud, molte operazioni “legittime” sono indistinguibili da operazioni ostili se l’identità è compromessa, perché l’infrastruttura tende a fidarsi delle credenziali e a eseguire quanto la policy consente. Per questo l’identità non è più soltanto un requisito di accesso, ma un elemento di controllo operativo.

Il problema si amplifica perché non esistono solo identità umane. Le applicazioni, i microservizi, le pipeline di sviluppo, gli agenti di automazione e i workload hanno identità proprie, spesso con permessi potenti per poter funzionare. È qui che si crea un paradosso tipico del cloud: più si automatizza per ridurre tempi e costi, più aumenta il numero di identità “macchina” che devono essere gestite, ruotate, monitorate e limitate. Se non si progetta questa governance, la complessità si traduce in una zona grigia dove i privilegi si accumulano, i permessi non vengono mai rimossi e le eccezioni diventano la regola.

Il baricentro si sposta sulle identità anche perché il cloud moltiplica le superfici indirette: API, servizi gestiti, integrazioni SaaS, federazioni tra domini e strumenti di collaborazione. Ogni connessione aggiunge potenziali percorsi laterali, spesso più rapidi della compromissione diretta di un server.

Da qui discende anche un’esigenza di visibilità diversa: nel cloud non basta sapere che cosa è esposto, serve anche sapere chi può farci cosa. Le policy di accesso, la loro evoluzione nel tempo, le eccezioni introdotte per urgenza e mai rimosse, le credenziali di emergenza e le identità di servizio diventano elementi da trattare come asset critici. In questo scenario, la maturità non si misura con la quantità di controlli, ma con la capacità di mantenere coerenti identità, autorizzazioni e configurazioni mentre l’ambiente cambia ogni giorno.

Dalla configurazione al rischio operativo l’ibrido è la normalità

Il cloud non ha cancellato il data center, né ha eliminato il legacy. Ha reso l’ibrido la condizione più comune. Le organizzazioni operano su architetture stratificate in cui convivono ambienti on premise, private cloud, public cloud e servizi SaaS, ciascuno con logiche operative, strumenti di gestione e modelli di responsabilità differenti. Questo aumenta l’attrito tra modelli operativi: da un lato piattaforme che evolvono rapidamente, con rilasci continui e automazione spinta, dall’altro processi e controlli che si aggiornano con tempi più lenti e spesso restano ancorati a logiche nate in contesti meno dinamici.

In questo spazio intermedio si accumula complessità. Errori di configurazione, esposizioni involontarie, permessi troppo ampi, segmentazioni incoerenti e dipendenze non mappate non sono anomalie occasionali, ma conseguenze strutturali di un ambiente che cambia più velocemente della sua governance. Ogni nuovo servizio attivato, ogni integrazione tra sistemi, ogni estensione di rete o federazione di identità aggiunge un punto di intersezione che deve essere compreso, documentato e monitorato. Se questo non avviene in modo sistematico, l’ibrido diventa una somma di eccezioni anziché un’architettura coerente.

Il rischio operativo nasce proprio da questa discontinuità tra progettazione e gestione. Nel modello ibrido non esiste un unico perimetro da presidiare, ma una pluralità di domini interconnessi in cui la responsabilità è condivisa tra team interni, provider esterni e partner tecnologici. La mancanza di allineamento tra questi attori può generare zone d’ombra: controlli applicati in un ambiente e non replicati in un altro, log non centralizzati, procedure di risposta agli incidenti che non coprono l’intera catena tecnologica.

È qui che prende forma una parte significativa degli incidenti: non per assenza di strumenti, ma per mancanza di governo continuo. L’ibrido richiede una visione trasversale che colleghi configurazioni, identità, rete, dati e processi operativi in un unico quadro di responsabilità. Senza questa integrazione, il rischio non è soltanto tecnico, ma organizzativo: la sicurezza viene percepita come frammentata, mentre l’attaccante sfrutta proprio le intersezioni tra ambienti diversi.

Automazione e visibilità la difesa deve stare nei tempi dell’incidente

Se l’attacco scala, anche la difesa deve scalare. Nel cloud, la finestra temporale tra esposizione e sfruttamento può essere breve e questo spinge verso due priorità tecniche e organizzative.

La prima è la visibilità: inventario reale degli asset e dei servizi, gestione delle dipendenze, monitoraggio continuo di configurazioni e permessi, correlazione tra eventi cloud-native e telemetria tradizionale. La seconda è l’automazione: non tanto per delegare decisioni complesse, quanto per ridurre latenza e ripetizione.

Nel cloud, molte azioni difensive meccaniche possono risultare molto efficaci se vengono preparate bene: per esempio isolare risorse, revocare credenziali, ruotare chiavi, applicare policy, bloccare traffico anomalo, ripristinare configurazioni corrette.

La cybersecurity nel cloud diventa più efficace quando si cambia il modo di costruire sistemi predisponendo le condizioni per minimizzare privilegi, separare ambienti, adottare controlli preventivi nelle pipeline, standardizzare configurazioni sicure, trattare segreti e identità non umane come asset critici, predisporre azioni di risposta fin dall’inizio. Questo consente di ridurre davvero la superficie di attacco ottenendo un risultato più efficace rispetto ad incrementare indefinitamente il numero di strumenti di cyber security.

Il cloud sovrano ridisegna il perimetro tra sicurezza e giurisdizione

Accanto alla crescita del public cloud e dei modelli ibridi, sta emergendo con forza il tema del cloud sovrano. Non si tratta soltanto di localizzazione dei dati, ma di controllo giuridico, operativo e infrastrutturale su workload e informazioni critiche.

Sempre secondo le stime più recenti di Gartner (9 febbraio 2026), la spesa mondiale per infrastrutture sovereign cloud in modalità Infrastructure-as-a-Service raggiungerà 80 miliardi di dollari nel 2026, con una crescita del 35,6% rispetto al 2025.

La spinta verso il cloud sovrano si inquadra in una situazione geopolitiche che  sarebbe limitativo definire incerta, alimentata da esigenze di compliance, resilienza e riduzione delle dipendenze strategiche.

Settori regolamentati e pubbliche amministrazioni chiedono maggiore trasparenza su dove risiedono i dati, quali leggi si applicano e chi può accedervi. Quando alla superficie tecnica si aggiunge quella giurisdizionale la sicurezza non riguarda più soltanto configurazioni, identità e segmentazioni, ma anche governance del dato, controllo delle chiavi crittografiche, segregazione operativa e indipendenza dagli hyperscaler globali.