Punti chiave
- Il CSPM (cloud security posture management) legge in continuo la configurazione delle risorse cloud dalle API del provider e la confronta con regole e standard, segnalando cosa è configurato male e come correggerlo.
- Controlla soprattutto identità e accessi, storage e database esposti, regole di rete, log, cifratura e MFA, con controlli presi dalle best practice dei provider e da standard come i CIS Benchmark, PCI DSS e NIST.
- AWS, Microsoft e Google hanno strumenti nativi con funzioni CSPM (Security Hub CSPM, Defender for Cloud, Security Command Center): sono il punto di partenza naturale, e vanno valutati su copertura dei cloud e capacità di dare priorità.
- Il limite del CSPM è il perimetro: vede le configurazioni, non le vulnerabilità dentro i workload, i permessi effettivi, i dati sensibili e le minacce a runtime. Collegare questi segnali è il lavoro della CNAPP.
- Per la NIS2 un CSPM produce evidenze sulle misure dell'art. 24 c. 2 del D.Lgs. 138/2024 (efficacia delle misure, controllo degli accessi e gestione dei beni, autenticazione a più fattori), ma il punteggio di conformità non coincide con il rischio.
La risposta breve: il CSPM (cloud security posture management) è lo strumento che legge in continuo la configurazione del tuo cloud dalle API del provider e la confronta con un insieme di regole, per dirti cosa è configurato male e come correggerlo. Storage pubblici, porte aperte verso internet, log spenti, account senza autenticazione a più fattori: il CSPM li trova, li mappa sugli standard e li tiene sotto controllo nel tempo.
Qui trovi cosa controlla, come lavora, quali strumenti nativi offrono AWS, Microsoft e Google, e soprattutto dove si ferma: il CSPM è il punto di partenza della sicurezza del cloud, ma non vede tutto. Il quadro completo della categoria di cui fa parte è nella nostra guida su CNAPP, cos'è e quali componenti ha.
Cos'è il CSPM, in pratica
Nel modello di responsabilità condivisa il provider risponde dell'infrastruttura, il cliente di come configura i servizi che usa. Ed è proprio la configurazione il punto in cui le cose si rompono: un bucket aperto per un test e mai richiuso, un gruppo di sicurezza con una regola troppo larga, un ruolo amministrativo dato per comodità.
Wiz, nella sua Academy, definisce il CSPM come una categoria di strumenti che monitora in continuo le configurazioni per individuare e correggere gli errori su ambienti IaaS, PaaS e SaaS, prima che un attaccante li sfrutti. La parola che conta è continuo. Nel cloud le risorse si creano e si cambiano ogni giorno, spesso da team diversi da quello della sicurezza, e un controllo annuale arriva tardi.
Cosa controlla un CSPM
I controlli cambiano da prodotto a prodotto, ma le famiglie sono sempre queste:
- Identità e accessi. Account amministrativi senza MFA, utente root usato per il lavoro di tutti i giorni, chiavi di accesso vecchie e mai ruotate, ruoli con permessi più larghi del necessario.
- Storage e database esposti. Bucket e container leggibili da chiunque, database gestiti raggiungibili da internet, snapshot condivise in pubblico.
- Rete. Regole firewall e gruppi di sicurezza che aprono porte di amministrazione (SSH, RDP) a tutto internet, endpoint pubblici non necessari.
- Log e monitoraggio. Log di audit disattivati o conservati per troppo poco, servizi di rilevamento spenti in alcune regioni.
- Cifratura. Volumi, database e backup senza cifratura, chiavi gestite senza rotazione.
Le regole arrivano da tre fonti: le best practice dei provider, gli standard pubblici come i CIS Benchmark e i framework di compliance (PCI DSS, NIST e altri), più le policy interne che l'azienda decide di aggiungere. Gli errori che si incontrano più spesso, con le fonti che li documentano, li abbiamo raccolti in errori di configurazione cloud: quali sono e come trovarli.
Come funziona un CSPM
Inventario via API, senza agenti
Il CSPM si collega a ogni account o progetto cloud con un ruolo dedicato e legge dalle API del provider l'elenco delle risorse e la loro configurazione. Wiz cita i servizi di inventario dei provider, come AWS Config, Azure Resource Graph e Cloud Asset Inventory di Google Cloud. Per questa parte bastano permessi di lettura e non si installa niente sulle macchine.
Valutazione contro le regole
Ogni risorsa viene confrontata con i controlli attivi. Ne esce un elenco di scostamenti, ognuno con risorsa, controllo violato, gravità e istruzioni per correggerlo, più una vista per framework con la quota di controlli rispettati.
Monitoraggio della deriva
Una configurazione corretta oggi può non esserlo domani: qualcuno apre una porta per un test, un template nuovo crea risorse con impostazioni diverse. Il CSPM rivaluta l'ambiente quando cambia e segnala la deriva rispetto allo stato atteso.
Correzione guidata o automatica
La correzione può essere guidata (la piattaforma spiega cosa cambiare e il team lo fa) oppure automatica per i casi più ricorrenti. AWS, per esempio, permette di collegare i risultati di Security Hub CSPM ad Amazon EventBridge per far partire risposte automatiche. Per correggere, lo strumento deve poter scrivere, quindi servono permessi di modifica, da decidere in modo esplicito con chi amministra il cloud.
Gli strumenti nativi dei cloud provider
Prima di un prodotto esterno, conviene sapere cosa offre già il provider:
- AWS Security Hub CSPM valuta gli account AWS rispetto a più standard, tra cui le AWS Foundational Security Best Practices, i CIS Benchmark, PCI DSS e NIST, e raccoglie anche i risultati di altri servizi AWS come GuardDuty, Inspector e Macie.
- Microsoft Defender for Cloud ha il CSPM tra le sue funzioni centrali: valuta Azure, AWS e Google Cloud rispetto a standard di sicurezza, a partire dal Microsoft Cloud Security Benchmark, e produce raccomandazioni per ridurre gli errori di configurazione. Nelle funzioni avanzate aggiunge analisi dei percorsi di attacco e priorità sul rischio.
- Google Cloud Security Command Center cerca le configurazioni errate e le vulnerabilità negli ambienti Google Cloud e mappa i risultati sui controlli di compliance. Nei livelli superiori simula i percorsi di attacco verso le risorse di maggior valore, per indicare da dove partire con le correzioni.
Per chi lavora su un solo cloud, lo strumento nativo è il punto di partenza naturale. Da verificare: quanti dei tuoi cloud copre davvero, e se restituisce una lista di scostamenti o una coda ordinata per rischio.
I limiti del CSPM: dove inizia la CNAPP
Il CSPM guarda la configurazione delle risorse. Ecco cosa resta fuori da un CSPM inteso in senso stretto:
- Dentro i workload. Il CSPM sa che una macchina virtuale esiste ed è esposta su internet, non sa che pacchetti ci girano sopra, quali vulnerabilità hanno, se sul disco c'è una chiave dimenticata. Questo è il lavoro della CWPP.
- I permessi effettivi. Segnala un ruolo troppo largo, ma calcolare cosa può fare davvero ogni identità, sommando policy, gruppi ed ereditarietà, è il lavoro del CIEM.
- I dati. Un bucket pubblico vuoto e uno pubblico con dati personali producono lo stesso avviso. Sapere dove stanno i dati sensibili è il lavoro della DSPM, che spieghiamo nella guida alla data security posture management.
- Quello che succede adesso. Il CSPM è preventivo: non vede un'escalation di privilegi in corso o un cryptominer avviato su un container. Lì servono il rilevamento a runtime e il SOC.
- Il contesto. Ogni scostamento ha la sua gravità standard, e senza sapere cosa è esposto, cosa contiene dati e chi ci accede è difficile capire da dove partire.
Wiz usa proprio l'esempio del bucket: con accesso pubblico in lettura e vuoto può avere bassa priorità; se contiene dati personali, è collegato a un database di produzione ed è raggiungibile tramite un ruolo con troppi permessi, diventa un percorso di attacco critico. Collegare questi segnali in un unico modello dati è ciò che distingue una CNAPP da un CSPM, e la stessa Wiz osserva che oggi il CSPM raramente lavora da solo: di solito è integrato in una CNAPP.
I dati di Google aiutano a dare le proporzioni. Nel Cloud Threat Horizons Report H1 2026, negli incidenti osservati sugli ambienti Google Cloud l'errore di configurazione è stato il vettore di accesso iniziale nel 29,4% dei casi nel primo semestre 2025 e nel 21% nel secondo. Nello stesso periodo lo sfruttamento di software di terze parti vulnerabile è salito dal 2,9% al 44,5%, diventando per la prima volta il primo vettore. Google precisa che i dati riguardano una parte dell'attività osservata, e legge il calo degli errori di configurazione come un probabile effetto dei controlli automatici e delle impostazioni sicure per default. Il messaggio per chi sceglie è doppio: la postura delle configurazioni resta una porta da tenere chiusa, ma un attaccante che la trova chiusa passa dalle vulnerabilità dei workload, che un CSPM puro non vede.
CSPM e compliance: NIS2, ISO 27001, clienti
Spesso un CSPM si adotta per dimostrare, con evidenze, che il cloud rispetta delle regole. L'art. 24, comma 2, del D.Lgs. 138/2024 elenca gli elementi minimi delle misure NIS2, e tra questi ci sono le politiche e procedure per valutare l'efficacia delle misure (lettera f), il controllo dell'accesso e la gestione dei beni e degli assetti (lettera i) e l'uso dell'autenticazione a più fattori (lettera l). Il comma 4 aggiunge che chi rileva di non essere conforme deve correggere senza indebito ritardo.
La legge non chiede un CSPM, ma sul perimetro cloud un CSPM fa esattamente questo: un inventario aggiornato, la verifica continua dei controlli, uno storico di quando uno scostamento è comparso e di quando è stato chiuso. Lo stesso materiale serve negli audit ISO/IEC 27001 e nei questionari dei clienti.
Un'avvertenza: il punteggio di conformità dice quanta parte delle regole è rispettata, non quanto rischio corri. Un ambiente con un punteggio alto può avere, tra i pochi controlli non rispettati, l'unica risorsa che conta.
Quando basta un CSPM e quando serve di più
Un CSPM, anche quello nativo del provider, può bastare se:
- lavori su un solo cloud, con pochi account e un team che conosce l'ambiente;
- i workload sono pochi e stabili, e le vulnerabilità delle macchine sono già coperte da un processo di patching che funziona;
- l'obiettivo principale è avere evidenze di conformità continue.
Serve qualcosa di più quando i cloud o gli account sono molti, quando container e Kubernetes cambiano ogni settimana, quando gli avvisi sono tanti e nessuno sa da quale partire, o quando clienti e auditor chiedono di sapere non solo cosa è configurato male, ma cosa è davvero raggiungibile e dove stanno i dati. A quel punto il passo naturale è una piattaforma che metta il CSPM nel contesto. Se vuoi prima capire a che punto sei, una fotografia della sicurezza del cloud te lo dice senza impegnarti su un prodotto.
Le domande da fare prima di scegliere
- Copertura. Legge tutti i tuoi cloud, account e servizi, compresi quelli gestiti e Kubernetes?
- Permessi. Quali permessi chiede esattamente, e quali in più servono per la correzione automatica?
- Priorità. Su un tuo account reale, le prime dieci segnalazioni sono cose che correggeresti subito?
- Contesto. Incrocia la configurazione con vulnerabilità, permessi effettivi e dati, o resta sulle regole?
- Flusso di lavoro. Manda le correzioni nei ticket dei team che possiedono le risorse, e controlla le configurazioni anche nei template di infrastructure as code prima del rilascio?
E poi la domanda più pratica: chi smaltisce la coda? Un CSPM trova gli scostamenti, a correggerli sono le persone.
In sintesi
In sintesi: il CSPM confronta in continuo la configurazione del cloud con regole e standard e segnala cosa correggere. È il punto di partenza della sicurezza del cloud e una fonte di evidenze per NIS2 e audit, ma vede le configurazioni, non le vulnerabilità dei workload, i permessi effettivi, i dati o le minacce in corso. Quando servono anche quelli, il CSPM diventa un componente di una CNAPP.
AmagisTech è partner Wiz, una CNAPP che si collega ai cloud via API, senza agenti, e mette la postura delle configurazioni nello stesso grafo di vulnerabilità, permessi e dati. Se vuoi vedere cosa emerge sul tuo ambiente, parti dalla fotografia del cloud con Wiz.