Cloud security: cos'è e come funziona la sicurezza cloud

La risposta breve: la cloud security, o sicurezza del cloud, è l'insieme di regole, controlli e strumenti che tengono sotto controllo identità, configurazioni, dati e workload che un'azienda ha su AWS, Microsoft Azure, Google Cloud o in applicazioni SaaS. Il provider si occupa dell'infrastruttura fisica; configurazioni, accessi e dati restano al cliente, ed è su quella parte che si gioca la sicurezza di tutti i giorni.

In questo articolo vediamo cosa copre in pratica, come si divide la responsabilità tra te e il provider, quali sono gli ambiti da presidiare, cosa chiedono standard e NIS2, quali strumenti esistono e da dove partire se il cloud è cresciuto più in fretta di chi lo governa.

Cos'è la cloud security, in pratica

Il NIST, l'ente di standardizzazione statunitense, nella pubblicazione SP 800-145 definisce il cloud computing come un modello di accesso via rete, on demand, a un insieme condiviso di risorse configurabili (reti, server, storage, applicazioni, servizi) che si attivano e si rilasciano con il minimo sforzo di gestione. La stessa definizione individua tre modelli di servizio: IaaS, PaaS e SaaS.

La parola che conta è configurabili. Nel cloud un server, un database o un bucket di storage nascono da un template o da un clic in console, e la loro sicurezza dipende da come sono stati impostati. La cloud security quindi non è un prodotto: è la disciplina che verifica, in modo continuo, che quelle impostazioni restino coerenti con le regole dell'azienda e con il rischio che è disposta ad accettare.

Rispetto alla sicurezza di un data center cambiano tre cose:

• Il perimetro è l'identità. Chi ha le credenziali giuste raggiunge le risorse da qualunque rete, quindi permessi e autenticazione pesano più dei firewall.
• L'inventario si muove. Le risorse si creano e si distruggono ogni giorno, spesso da team diversi e su più account.
• Tutto passa dalle API. Configurazioni, log e permessi si leggono e si modificano via API: è un vantaggio per chi controlla, ed è la stessa strada che usa chi attacca.

Chi è responsabile di cosa: il modello di responsabilità condivisa

Ogni grande provider descrive la divisione dei compiti con un proprio schema. AWS la riassume nella distinzione tra sicurezza del cloud, che spetta ad AWS ed è l'infrastruttura su cui girano i servizi, e sicurezza nel cloud, che spetta al cliente: sistema operativo delle macchine virtuali, aggiornamenti, configurazione dei security group, gestione e cifratura dei dati, permessi IAM.

Microsoft, nella sua documentazione sul modello, è esplicita su un punto che vale per qualunque tipo di servizio: dati e identità restano sempre del cliente, insieme agli account, ai controlli di accesso e ai dispositivi che si collegano al cloud.

La quota di lavoro che ti resta dipende dal modello di servizio. Nella documentazione di architettura di Google Cloud la sintesi è questa:

• IaaS: la maggior parte delle responsabilità di sicurezza è del cliente, il provider si occupa dell'infrastruttura sottostante e della sicurezza fisica.
• PaaS: il provider gestisce più controlli, e la responsabilità sui controlli applicativi e sulla gestione di identità e accessi è condivisa.
• SaaS: il provider si fa carico della maggior parte dei controlli, al cliente restano gli accessi e i dati che sceglie di caricare.

La conseguenza pratica: comprare un servizio cloud certificato non rende sicuro l'uso che ne fai. Le certificazioni del provider coprono la sua parte; la tua parte resta da dimostrare a te.

Perché la sicurezza del cloud si rompe

La stessa pagina di Google Cloud lo dice senza giri di parole: molte violazioni della sicurezza del cloud sono la conseguenza diretta di una configurazione sbagliata. Non servono attacchi sofisticati se uno storage è pubblico per errore o se una chiave di accesso è rimasta in un repository.

Gli errori più frequenti hanno cause organizzative prima che tecniche:

• Permessi che si accumulano. Ruoli creati per un progetto e mai ritirati, account di servizio con privilegi da amministratore, utenti usciti dall'azienda ancora attivi.
• Risorse esposte su internet senza saperlo. Porte di gestione aperte, database raggiungibili, ambienti di test dimenticati.
• Segreti nel posto sbagliato. Chiavi e token nel codice, nelle variabili d'ambiente o nelle immagini dei container.
• Log spenti o non letti. Senza registri delle attività amministrative un incidente non si ricostruisce.
• Cloud fuori dal radar. Account aperti da un reparto con la carta aziendale, che nessuno in IT conosce.

Il prezzo di un incidente è concreto. Secondo il comunicato IBM Italia sul Cost of a Data Breach Report 2026, il costo medio di un data breach in Italia è salito a 3,55 milioni di euro, dai 3,31 milioni dell'anno precedente. Per un elenco ragionato delle configurazioni da controllare per prime, c'è il nostro approfondimento sugli errori di configurazione del cloud.

I sei ambiti della sicurezza del cloud

Non esiste una tassonomia ufficiale unica, ma i controlli si raggruppano in sei ambiti che ritrovi, con nomi diversi, nei principali framework.

1. Identità e accessi

Chi può fare cosa, su quali risorse. Autenticazione a più fattori per tutti gli accessi umani, privilegi minimi, nessun uso quotidiano dell'account root o amministratore globale, revisione periodica dei ruoli e delle identità di servizio.

2. Configurazioni e postura

Il confronto continuo tra come sono impostate le risorse e come dovrebbero esserlo. Il riferimento più usato sono i CIS Benchmark, che esistono per i principali provider e servizi.

3. Workload e vulnerabilità

Macchine virtuali, container, funzioni serverless: sistemi operativi da aggiornare, librerie con vulnerabilità note, immagini da controllare prima del rilascio.

4. Dati e cifratura

Sapere dove stanno i dati sensibili, chi li può leggere, se sono cifrati e chi gestisce le chiavi. È l'ambito che resta al cliente in ogni modello di servizio.

5. Rete ed esposizione

Segmentazione, regole di accesso, servizi pubblicati verso internet. Nel cloud la domanda utile non è se una porta è aperta, ma cosa si raggiunge passando da lì.

6. Log, rilevamento e risposta

Registri delle attività abilitati e conservati, eventi portati in un SIEM, qualcuno che li guarda e sa cosa fare quando qualcosa non torna. Senza questo ambito gli altri cinque restano una fotografia statica.

Cosa chiedono standard e normative

Nessuna norma usa la sigla cloud security come titolo di un obbligo, ma il cloud entra in tutti i framework che contano per un'azienda mid-market:

• ISO/IEC 27001:2022 dedica un controllo dell'Annex A, il 5.23, alla sicurezza delle informazioni nell'uso dei servizi cloud.
• Cloud Security Alliance: la Cloud Controls Matrix, giunta alla versione 4.1, conta 207 controlli organizzati in 17 domini, ed è la base del programma STAR. Ne parliamo nell'articolo su CSA STAR.
• NIS2: l'art. 24 c. 2 del D.Lgs. 138/2024 elenca gli elementi che le misure di gestione del rischio devono comprendere almeno, e diversi toccano il cloud da vicino: la sicurezza della catena di approvvigionamento, che comprende i fornitori di servizi (lett. d), la continuità operativa con backup e ripristino (lett. c), crittografia e cifratura (lett. h), controllo dell'accesso e gestione degli assetti (lett. i), autenticazione a più fattori (lett. l). Il quadro completo è nella guida alla NIS2.

Il punto comune: non basta dichiarare che il cloud è configurato bene, serve un'evidenza aggiornata che lo dimostri.

Gli strumenti della cloud security

Gli strumenti nativi dei provider sono il primo livello e coprono bene il singolo cloud. Quando gli account e i provider diventano più di uno, entrano in gioco piattaforme dedicate. Le sigle principali:

• CSPM (cloud security posture management): controlla le configurazioni rispetto a regole e standard.
• CWPP (cloud workload protection platform): vulnerabilità e minacce su macchine virtuali, container e serverless.
• CIEM (cloud infrastructure entitlement management): permessi effettivi di utenti e identità di servizio.
• DSPM (data security posture management): dove sono i dati sensibili e chi li raggiunge.
• CNAPP (cloud-native application protection platform): la piattaforma che unisce questi pezzi in un unico modello dati e collega i segnali in percorsi di attacco sfruttabili.

Come funzionano e come si scelgono lo spieghiamo nella pillar CNAPP: cos'è e quali componenti ha. Una nota: nessuno di questi strumenti sostituisce SIEM e SOC. Lavorano sulla postura del cloud; la correlazione con endpoint, identità e posta, e la risposta agli incidenti, restano un lavoro a parte.

Da dove partire

Se oggi non hai un quadro chiaro, l'ordine che regge è questo:

1. Inventario. Quali account, sottoscrizioni e progetti esistono, su quali provider, chi ne è il responsabile. Gli account che nessuno conosce sono spesso i più esposti.
2. Identità. Autenticazione a più fattori ovunque, account amministrativi ridotti al minimo, chiavi di accesso vecchie ruotate o ritirate.
3. Esposizione. Cosa è raggiungibile da internet, e cosa c'è dietro.
4. Log. Registri delle attività amministrative attivi su tutti gli account e conservati fuori dalla portata di chi li potrebbe cancellare.
5. Priorità. Una lista ordinata per rischio reale, non per numero di avvisi: in cima vanno le combinazioni di risorsa esposta, vulnerabilità nota e permesso che porta ai dati.

Il modo più rapido per avere i primi tre punti è una valutazione fatta sull'ambiente reale: ne descriviamo metodo e risultati nell'articolo sul cloud security assessment. Se invece i carichi devono ancora arrivare in cloud, identità, rete e piano di ritorno si decidono già nel progetto di migrazione cloud.

Wiz e AmagisTech

Wiz è una piattaforma CNAPP che si collega ai cloud via API, senza agenti, e mette in fila i rischi in base ai percorsi di attacco che rendono sfruttabili. Google ha completato l'acquisizione di Wiz l'11 marzo 2026; secondo l'annuncio di Google Cloud il marchio Wiz resta e i prodotti continuano a funzionare sui principali cloud, compresi AWS, Microsoft Azure e Oracle. Il quadro completo è nell'articolo su Wiz e Google Cloud.

AmagisTech è partner Wiz: lo usiamo per fare la fotografia del cloud di un'azienda, vedere cosa è esposto davvero e decidere insieme cosa sistemare prima.

In sintesi

In sintesi: la cloud security riguarda soprattutto la parte che resta al cliente, cioè identità, configurazioni, dati, workload, esposizione e log. Il provider gestisce l'infrastruttura, gli errori di configurazione fanno il resto, e standard come ISO/IEC 27001 e la NIS2 chiedono di dimostrare che quella parte è sotto controllo. Se vuoi sapere a che punto è il tuo cloud, parti dalla fotografia del cloud con Wiz: via API, senza agenti, con i rischi in ordine di priorità.