Cloud security assessment: cos'è, come si fa, cosa ricevi

La risposta breve: un cloud security assessment è una valutazione della sicurezza dei tuoi account cloud (AWS, Azure, Google Cloud) fatta sull'ambiente reale. Si fa l'inventario di cosa gira, si verifica cosa è raggiungibile da internet, con quali permessi e dove stanno i dati sensibili, e ne esce una lista di rischi in ordine di priorità. Si fa di solito collegando uno strumento ai cloud via API, senza installare agenti.

Questa pagina serve a chi deve decidere se farne uno: cosa copre, come si svolge, cosa si riceve alla fine, cosa non fa e come prepararsi. In fondo raccontiamo come lavoriamo noi, da partner Wiz, sulla fotografia del cloud.

Cos'è un cloud security assessment

È una fotografia dello stato di sicurezza del tuo cloud in un momento preciso. Non si limita a elencare le risorse: le mette in relazione, perché nel cloud il rischio nasce quasi sempre da una combinazione. Una macchina con una vulnerabilità nota è un problema; la stessa macchina esposta su internet, con una chiave che dà accesso a un database di clienti, è un altro ordine di problema.

Il punto di partenza è il modello di responsabilità condivisa. AWS lo descrive distinguendo la sicurezza of the Cloud, cioè l'infrastruttura fisica e i servizi che gestisce il provider, dalla sicurezza in the Cloud, che resta al cliente e dipende dai servizi scelti (AWS, Shared Responsibility Model). Configurazioni, identità, permessi, reti e dati sono tuoi. È esattamente quella parte che un assessment va a guardare. Se il provider lo stai ancora scegliendo, cosa verificare prima di firmare è nella guida su come scegliere un cloud provider.

Per chi lavora con la ISO/IEC 27001:2022 il tema ha anche un controllo dedicato nell'Annex A, il 5.23 (Information security for use of cloud services), accanto all'8.8 sulla gestione delle vulnerabilità tecniche. Una panoramica dei controlli è nella nostra guida ai requisiti e all'Annex A della ISO 27001.

Cosa copre, in pratica

Un assessment fatto sull'ambiente, e non solo su un questionario, guarda cinque aree.

• Inventario delle risorse. Macchine virtuali, container, funzioni serverless, database, bucket di storage, account e subscription. Spesso la prima sorpresa è qui: ambienti di test dimenticati, risorse create da un fornitore e mai spente.
• Esposizione su internet. Quali risorse sono raggiungibili dall'esterno, su quali porte, attraverso quali regole di rete o load balancer.
• Identità e permessi. Utenti, ruoli e service account con più permessi del necessario, chiavi di accesso vecchie, account con privilegi amministrativi che nessuno usa più.
• Vulnerabilità e segreti nei carichi di lavoro. Pacchetti con vulnerabilità note, sistemi operativi non aggiornati, password e chiavi rimaste nei dischi o nelle immagini dei container.
• Dati sensibili. Dove stanno i dati personali, finanziari o sanitari, e chi o cosa può arrivarci.

Il valore non sta in nessuna di queste liste presa da sola, ma nel collegarle. È la differenza tra ricevere migliaia di segnalazioni e riceverne poche, con la ragione per cui vanno affrontate prima delle altre.

Come si fa: due approcci

Assessment documentale

Si parte da questionari, interviste e revisione delle configurazioni a campione. È utile per capire come l'azienda governa il cloud (chi approva le modifiche, come si gestiscono gli accessi, che policy esistono), ma vede solo ciò che le persone sanno e dichiarano. Nel cloud una parte del rischio sta proprio in ciò che nessuno ricorda di aver creato.

Assessment sull'ambiente, via API

Si collega uno strumento agli account cloud con un ruolo dedicato. Lo strumento interroga le API del provider, ricostruisce l'inventario e le configurazioni, e analizza i carichi di lavoro senza installare agenti sulle macchine. È l'approccio che usiamo per la fotografia del cloud, con Wiz.

Conviene essere precisi su cosa significa senza agenti, perché è la prima domanda che fa un team DevOps. L'inventario e la lettura delle configurazioni passano da permessi API in lettura. L'analisi dei dischi, invece, lavora su snapshot: Wiz spiega che nel modello ospitato da Wiz lo scanner ha permessi limitati che includono la creazione, la condivisione e la cancellazione degli snapshot, e durante la scansione accede al disco analizzato in sola lettura. Esiste anche un modello in cui lo scanner gira nell'ambiente del cliente, con la sua infrastruttura e i suoi permessi, e Wiz riceve solo i risultati (Wiz, Securing clouds, securely, 31/10/2023). Quindi l'assessment non tocca le macchine in produzione, ma non è corretto dire che tutto avviene in sola lettura: i permessi esatti vanno visti con la documentazione, prima di collegare gli account.

Wiz prevede anche un sensore runtime per il rilevamento in tempo reale, che si aggiunge dopo se serve (Wiz, How to Evaluate Wiz: Common FAQs). Per la fotografia non è richiesto.

Cosa ricevi alla fine

Un assessment utile consegna decisioni, non un archivio. In concreto:

1. Una lista di rischi in ordine di priorità, dove in cima stanno le combinazioni sfruttabili: risorsa esposta, vulnerabilità nota, permesso o chiave che porta ai dati. Nel post che annuncia la chiusura dell'acquisizione, Google Cloud descrive questo lavoro di Wiz come identificazione dell'esposizione e dei percorsi di attacco sfruttabili, con una priorità basata sull'impatto sul business (Google Cloud Blog, 11/03/2026).
2. Il motivo di ogni priorità, leggibile anche da chi non gestisce il cloud tutti i giorni: cosa è esposto, cosa succederebbe, chi deve intervenire.
3. Un ordine di intervento, con le correzioni rapide separate da quelle che richiedono un cambio di architettura o una decisione del management.
4. Evidenze riutilizzabili per i questionari di sicurezza dei clienti, per una due diligence tecnica o per un audit.

Può anche succedere che la fotografia dica che il cloud è in ordine, o che i problemi veri sono pochi e già noti. È un risultato anche quello, e vale come base per decidere dove investire.

Cosa un cloud security assessment non fa

• Non è un penetration test. Trova e mette in relazione i rischi, non prova a sfruttarli. La distinzione è la stessa che trattiamo in penetration test e vulnerability assessment: un assessment lavora in ampiezza, un pen test in profondità.
• Non è una certificazione. Produce evidenze che servono in un percorso ISO 27001, SOC 2 o in una verifica legata a NIS2 e DORA, ma non attesta la conformità a nessuno di questi schemi.
• Non è un monitoraggio continuo. È una fotografia. Il cloud cambia ogni giorno, e ciò che è in ordine oggi può non esserlo tra un mese: per questo, dopo, si decide se e come tenerlo sotto controllo nel tempo.
• Non vede ciò che non colleghi. Il perimetro è quello degli account, delle subscription e dei progetti che metti a disposizione. Un account escluso resta fuori dalla fotografia.

Quando ha senso farne uno

Ci sono alcuni momenti tipici.

• Un cliente enterprise manda un questionario di sicurezza e servono risposte con evidenze, non dichiarazioni.
• Arriva una due diligence tecnica, da un investitore o da un acquirente. Cosa chiede di solito, e cosa conviene sistemare prima, lo trattiamo nella guida alla sicurezza cloud per startup e scaleup SaaS.
• Il cloud è cresciuto più in fretta della squadra che lo governa, magari con più provider e più fornitori che hanno creato risorse.
• Si prepara un percorso di compliance, per esempio ISO 27001 o SOC 2, e serve sapere da dove si parte. Per chi vende software è lo scenario della ISO 27001 per startup e SaaS.
• Si lavora su più cloud e ogni provider ha il suo strumento nativo (Security Hub su AWS, Security Command Center su Google Cloud, Defender for Cloud su Azure), ciascuno pensato per il proprio ambiente: serve una vista unica.

Come prepararsi

1. Definisci l'obiettivo. Rispondere a un cliente, prepararsi a un audit o capire lo stato generale portano a perimetri diversi.
2. Fai l'elenco di account, subscription e progetti su tutti i provider, compresi quelli di sviluppo e test.
3. Individua chi può creare il ruolo di collegamento: di solito il responsabile cloud o DevOps. Fagli leggere i permessi richiesti prima di iniziare.
4. Coinvolgi chi dovrà correggere. Una lista di priorità che nessuno ha il mandato di lavorare resta una lista.

La fotografia del cloud con AmagisTech

AmagisTech è partner Wiz. La fotografia del cloud è il modo in cui facciamo un cloud security assessment sull'ambiente vero.

1. Una call di 20 minuti con un advisor cloud: su quali cloud lavori, chi li gestisce, cosa ti chiedono clienti e investitori. Se la fotografia non ti serve, te lo diciamo.
2. Il collegamento via API: Wiz si collega ai tuoi account con un ruolo dedicato, che resta sotto il tuo controllo. Nessun agente sulle macchine, i dischi si analizzano da snapshot.
3. La fotografia in ordine di priorità: la prima lista arriva nella prima settimana. Il Proof of Value completo dura 30 giorni, con il Solutions Engineer di Wiz al fianco del nostro advisor.

Wiz dal 2026 fa parte di Google Cloud. Google ha comunicato la chiusura dell'acquisizione l'11 marzo 2026, ha mantenuto il marchio Wiz e ha confermato che i prodotti Wiz continuano a funzionare su AWS, Microsoft Azure e Oracle Cloud, oltre che su Google Cloud (Google Cloud Blog, 11/03/2026). Nello stesso post Google indica l'unione della piattaforma Wiz con Google Security Operations e l'affiancamento di Mandiant Consulting. Se dopo la fotografia serve tenere il cloud sotto osservazione, il passo successivo è il monitoraggio continuo del nostro SOC, costruito su Google SecOps.

In sintesi

Un cloud security assessment ti dice cosa è esposto nel tuo cloud, con quali permessi e vicino a quali dati, e in che ordine intervenire. Fatto via API sull'ambiente reale vede anche ciò che nessuno ricordava di aver creato, senza installare agenti. Non sostituisce un penetration test né una certificazione, e non è un monitoraggio continuo: è il punto da cui decidere.

Se vuoi capire se la fotografia fa per il tuo cloud, parti da qui: la fotografia del cloud con Wiz, una call di 20 minuti con un advisor AmagisTech.