Cloud security gestita su AWS, Azure e Google Cloud

Cloud security gestita: cosa significa

La cloud security gestita è il servizio con cui un partner tiene sotto controllo, in modo continuo, la sicurezza di ciò che un'azienda ha su AWS, Azure e Google Cloud: inventario, identità e permessi, configurazioni, vulnerabilità, dati esposti. Non sostituisce il provider, che gestisce l'infrastruttura: lavora sulla parte che resta al cliente, la ordina per rischio reale e segue le correzioni finché il rischio non è chiuso.

La divisione dei compiti la scrive il provider stesso. Nella documentazione di architettura di Google Cloud (Shared responsibilities and shared fate on Google Cloud), il provider resta sempre responsabile della rete e dell'infrastruttura sottostanti, mentre il cliente resta sempre responsabile delle proprie policy di accesso e dei propri dati; in un servizio IaaS la maggior parte delle responsabilità di sicurezza è del cliente. Google affianca a questo modello quello che chiama shared fate, cioè il rapporto fra provider e cliente come una collaborazione continua per migliorare la sicurezza. Le differenze fra IaaS, PaaS e SaaS sono spiegate nella guida al modello di responsabilità condivisa nel cloud.

Nella pratica, chi cerca un servizio di cloud security vuole risposte a tre domande: che cosa ho davvero nei miei account, quali di queste cose un attaccante potrebbe usare oggi, e chi se ne occupa domani mattina. La terza è quella che decide se il lavoro regge nel tempo. La definizione completa, con i sei ambiti di controllo, è nella guida cloud security: cos'è e come funziona.

Questa pagina parla della sicurezza di cloud che esistono già, su uno o più provider. Per progettare, migrare o gestire l'infrastruttura su Google Cloud il servizio è cloud e infrastruttura gestita.

Dove nasce il rischio nel cloud di un'azienda

Il provider risponde dell'infrastruttura, e gli incidenti nascono quasi sempre nella parte del cliente. La documentazione di architettura di Google Cloud lo dice in modo diretto: molte violazioni della sicurezza del cloud sono la conseguenza diretta di una configurazione sbagliata.

I numeri più recenti vengono dal Cloud Threat Horizons Report H1 2026 di Google Cloud, che analizza un sottoinsieme degli incidenti osservati negli ambienti Google Cloud nel secondo semestre 2025:

• lo sfruttamento di software di terze parti vulnerabile è diventato per la prima volta il primo vettore di accesso iniziale, con il 44,5% dei casi (era il 2,9% nel primo semestre);
• l'accesso con credenziali deboli o assenti è sceso dal 47,1% al 27,2%;
• l'accesso tramite configurazioni errate è sceso dal 29,4% al 21%.

Secondo Google il cambiamento può dipendere dalla sua strategia di sicurezza predefinita (secure by default) e da protezioni più forti sulle credenziali, che hanno chiuso le strade più facili. Gli attacchi hanno colpito applicazioni non aggiornate e regole firewall troppo permissive definite dagli utenti, senza coinvolgere l'infrastruttura di Google Cloud. Lo stesso report osserva che nel secondo semestre 2025 il tempo fra la pubblicazione di una vulnerabilità e il suo sfruttamento si è ridotto da settimane a giorni, e che, negli interventi di Mandiant su ambienti cloud e SaaS, una compromissione dell'identità era alla base dell'83% delle compromissioni, con un passaggio dal phishing tradizionale al vishing e al furto di token delle applicazioni SaaS.

Messi in fila, questi dati dicono dove guardare:

• Identità e permessi: utenti, ruoli e service account con più accessi del necessario, chiavi che non scadono, autenticazione a più fattori mancante. È il campo del CIEM, la gestione dei permessi cloud.
• Esposizione su internet: risorse raggiungibili dall'esterno senza motivo, regole di rete aperte, storage pubblico. L'elenco dei casi ricorrenti è in errori di configurazione cloud.
• Vulnerabilità nei workload: pacchetti e immagini non aggiornati su macchine virtuali e container. Con finestre di sfruttamento di pochi giorni vanno messi in fila per esposizione, non per data di scoperta.
• Dati sensibili: dove stanno i dati personali e finanziari, e chi o cosa può arrivarci. Se ne occupa il DSPM.
• Segreti: chiavi, token e password rimasti nel codice, nelle immagini o nei dischi. Come si gestiscono è spiegato in secrets management.

Il rischio vero sta nelle combinazioni: una macchina esposta su internet, con una vulnerabilità nota e un'identità che arriva a un database di clienti, è un percorso d'attacco, e va in cima alla coda. È il ragionamento descritto in attack path e combinazioni tossiche.

Cosa chiedono NIS2, DORA e ISO 27001 sul cloud

Nessuna delle tre norme ha un capitolo a parte per il cloud, e nessuna lo vieta. Tutte e tre, però, considerano il cloud parte dei sistemi dell'azienda e il provider un fornitore da governare.

NIS2

Per i soggetti essenziali e importanti, l'art. 24 del D.Lgs. 138/2024 chiede misure tecniche, operative e organizzative per la sicurezza dei sistemi informativi e di rete che usano nelle loro attività: quindi anche quelli su AWS, Azure o Google Cloud. Fra gli elementi minimi del comma 2, diversi nel cloud diventano controlli concreti: continuità operativa e gestione dei backup (lettera c), sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori di servizi (d), gestione delle vulnerabilità (e), crittografia (h), controllo dell'accesso e gestione degli asset (i), autenticazione a più fattori (l). La conformità del provider non si trasferisce al cliente: account, configurazioni, identità e log restano tuoi. Il dettaglio, con le misure di base ACN, è in NIS2 e cloud: le misure su AWS, Azure e Google Cloud.

DORA

Il Regolamento (UE) 2022/2554 tratta AWS, Azure e Google Cloud come fornitori terzi di servizi TIC. L'art. 28 stabilisce che le entità finanziarie che usano servizi TIC di terzi restano sempre pienamente responsabili del rispetto degli obblighi del regolamento. Valutazione prima del contratto, registro delle informazioni, rischio di concentrazione e piani di uscita sono trattati in DORA e cloud: cosa chiede a fintech e intermediari.

ISO/IEC 27001

Nella ISO/IEC 27001:2022 il cloud ha un controllo dedicato nell'Annex A, il 5.23 (sicurezza delle informazioni per l'uso di servizi cloud), accanto all'8.8 sulla gestione delle vulnerabilità tecniche. Le linee guida specifiche per il cloud sono la ISO/IEC 27017 e la ISO/IEC 27018, descritte in ISO 27017 e 27018: cos'è e differenze. In audit contano le evidenze: inventari, configurazioni, vulnerabilità gestite, accessi rivisti. Come si producono in continuo, e come arrivano in Vanta, lo spiega SOC 2 e ISO 27001 nel cloud: le evidenze per l'audit.

Un punto vale per tutte e tre: una valutazione della sicurezza del cloud produce evidenze utili, ma non attesta la conformità. È un pezzo del lavoro, non il certificato.

Tool nativi, CSPM e CNAPP: cosa serve davvero

Ogni provider offre il proprio strumento di postura: Security Command Center su Google Cloud, Security Hub su AWS, Defender for Cloud su Azure. Sono il primo livello, vanno attivati comunque e sono pensati anzitutto per il proprio ambiente. Il limite compare quando gli account crescono, quando i provider diventano due o tre e quando il team che legge le segnalazioni è piccolo.

Sopra i tool nativi ci sono due famiglie di piattaforme:

• il CSPM confronta le configurazioni con regole e standard e segnala gli scostamenti: lo trovi in CSPM: cos'è, cosa controlla e limiti;
• la CNAPP riunisce in un modello dati unico configurazioni, workload, permessi, dati, Kubernetes e codice, e ne ricava i percorsi d'attacco sfruttabili: la definizione è in CNAPP: cos'è e quali componenti ha.

La CNAPP rende di più dove ci sono workload veri su IaaS e PaaS, più account o più cloud, cluster Kubernetes e rilasci frequenti. Se sviluppi software in casa conta anche quanto la piattaforma lavora a monte, sui template di infrastructure as code e sulle pipeline. Per i cluster c'è una guida dedicata alla sicurezza di Kubernetes e container. Se invece il tuo cloud è quasi solo SaaS, la priorità è un'altra: identità, posta e configurazione dei tenant.

Quando si confrontano le piattaforme, i criteri che pesano sono la copertura dei servizi che usi, i permessi richiesti, il luogo in cui avviene la scansione dei dischi, la qualità delle priorità, il runtime e l'integrazione con il SOC. Li abbiamo messi in fila in come scegliere una CNAPP: Wiz, Prisma Cloud e Orca, con ogni vendor descritto sulle sue fonti.

Perché lavoriamo con Wiz, e cosa è cambiato con Google

AmagisTech è partner Wiz e partner Google Cloud. Wiz è la piattaforma con cui facciamo la fotografia del cloud dei clienti e con cui seguiamo la postura nel tempo.

Nel post che annuncia la chiusura dell'acquisizione (blog Google Cloud, 11 marzo 2026), Thomas Kurian, CEO di Google Cloud, descrive così il lavoro di Wiz: costruisce in tempo reale una mappa dell'architettura applicativa, dei permessi, dei flussi di dati e del comportamento a runtime; su quella mappa individua l'esposizione e i percorsi d'attacco sfruttabili, ordina il rischio per impatto sul business e permette di correggere alla fonte, spesso prima che l'applicazione arrivi in produzione.

Dal post e dalle note di Alphabet si ricavano i fatti che interessano a chi valuta Wiz oggi:

• Acquisizione chiusa l'11 marzo 2026. L'accordo annunciato il 18 marzo 2025 valeva 32 miliardi di dollari, soggetti agli aggiustamenti di chiusura; alla chiusura Alphabet ha registrato 29,5 miliardi di dollari, dopo gli aggiustamenti di prezzo (Form 10-Q al 30 giugno 2026, nota 8). I risultati di Wiz rientrano nel segmento Google Cloud.
• Marchio e multicloud confermati. Google mantiene il marchio Wiz e scrive che i prodotti Wiz continueranno a funzionare ed essere disponibili sui principali cloud, fra cui Amazon Web Services, Microsoft Azure e Oracle Cloud, anche attraverso partner.
• Integrazione con la sicurezza di Google. Google annuncia una piattaforma che combina Wiz con Google Security Operations per le applicazioni cloud-native in sviluppo, build e runtime, insieme alla threat intelligence di Google e all'esperienza sul campo di Mandiant Consulting.
• Spazio per chi eroga servizi. Google scrive che metterà system integrator, rivenditori e managed security service provider in condizione di offrire servizi più ampi ai clienti, e che la piattaforma combinata aiuterà anche le aziende più piccole, che spesso non hanno competenze e risorse interne.

Per chi lavora su AWS o Azure, Wiz resta multicloud. Per chi ha già Google SecOps, o lo sta valutando, c'è un vantaggio in più: le issue e le rilevazioni di Wiz arrivano nel SIEM con il loro contesto, e il SOC le lavora insieme ai segnali di endpoint, identità e posta. Come funziona il collegamento è descritto in Wiz e Google SecOps: come funziona l'integrazione; il profilo completo della piattaforma è in Wiz cos'è: la cloud security che ora è di Google.

Sul collegamento conviene essere precisi, perché è la prima domanda di ogni team DevOps. Wiz si collega agli account via API, senza agenti, con un ruolo dedicato che resta sotto il tuo controllo e si revoca quando vuoi. Inventario, configurazioni e permessi si leggono via API; l'analisi dei dischi, per cercare vulnerabilità e chiavi esposte, lavora su snapshot temporanei e non sulle macchine in produzione. Quindi niente agenti e niente impatto sui sistemi in esercizio, ma non tutto in sola lettura: i permessi esatti per ogni cloud si guardano insieme sulla documentazione, prima di collegare gli account.

Come lavoriamo, fase per fase

Il percorso parte da una fotografia e diventa gestione continua solo se serve.

1. Una call di 20 minuti

Con un advisor cloud AmagisTech: su quali cloud lavori, quanti account hai, chi li gestisce, cosa ti chiedono clienti, auditor o investitori. Se la fotografia non ti serve, te lo diciamo. Dopo la richiesta ti ricontattiamo entro 24 ore.

2. Collegamento e fotografia del cloud

Si concordano il perimetro (account, subscription, progetti) e i permessi. Chi amministra il cloud crea il ruolo dedicato, Wiz si collega via API e costruisce l'inventario. La prima lista di rischi, in ordine di priorità, arriva entro la prima settimana. Il Proof of Value completo dura 30 giorni, con il Solutions Engineer di Wiz al fianco del nostro advisor.

Alla fine ricevi le combinazioni sfruttabili con il motivo di ciascuna priorità, un ordine di intervento che separa le correzioni rapide da quelle che chiedono un cambio di architettura, ed evidenze riutilizzabili per questionari di sicurezza, due diligence e audit. Il dettaglio è in cloud security assessment: cos'è, come si fa, cosa ricevi.

3. Gestione continua

Il cloud cambia ogni giorno, e una fotografia invecchia in fretta. Se decidi di proseguire, la postura resta sotto osservazione con Wiz: le nuove priorità arrivano ai responsabili giusti, le correzioni si verificano alla scansione successiva, le evidenze per gli audit restano aggiornate. Quando serve rilevare e rispondere agli attacchi in corso, i segnali del cloud entrano nel SOC italiano 24/7 di AmagisTech, costruito su Google SecOps e Mandiant: è il servizio di cybersecurity gestita.

Cosa serve da parte tua

• L'elenco di account, subscription e progetti su tutti i provider, compresi sviluppo e test. Ciò che non colleghi resta fuori dalla fotografia.
• Una persona che crea il ruolo di collegamento, di solito il responsabile cloud o DevOps, e che legge prima i permessi richiesti.
• Un obiettivo dichiarato: rispondere a un cliente enterprise, prepararsi a un audit, capire lo stato generale. Da qui dipendono perimetro e priorità.
• Chi correggerà: amministratori del cloud, sviluppatori, fornitori. Una lista di priorità che nessuno ha il mandato di lavorare resta una lista.
• Un referente per le decisioni, che sappia dire se una risorsa esposta deve restarlo o se è un residuo da spegnere.

Gli errori che vediamo più spesso

1. Collegare solo la produzione. Gli ambienti di test e gli account creati da un fornitore sono spesso quelli dimenticati, e un percorso d'attacco non rispetta i confini fra ambienti.
2. Trattare il cloud come un perimetro di rete. Se nei casi seguiti da Mandiant su cloud e SaaS l'identità è alla base dell'83% delle compromissioni, una regola firewall chiusa non basta quando un service account arriva dappertutto.
3. Ordinare per gravità invece che per esposizione. Una vulnerabilità critica su una macchina isolata può aspettare; una media su una macchina esposta, con accesso ai dati, no.
4. Fermarsi alla fotografia. Senza un controllo continuo i problemi tornano con il rilascio successivo.
5. Tenere la postura fuori dal SOC. Un attacco al cloud raramente resta nel cloud: passa da un'identità, da un endpoint, dalla posta. Se i segnali non arrivano a chi guarda il resto, nessuno vede la catena intera.
6. Confondere evidenze e conformità. Un report di postura aiuta in audit, ma non sostituisce policy, processi, gestione dei fornitori e responsabilità che NIS2, DORA e ISO 27001 chiedono.
7. Dare per scontato che il provider pensi a tutto. La sua conformità copre la sua infrastruttura, non le tue configurazioni. Per chi vende software ai grandi clienti è il punto da cui partono le domande, come raccontiamo in sicurezza cloud per startup e scaleup SaaS.

Come scegliere un partner di cloud security, e da cosa dipende il costo

Prima del nome della piattaforma conta chi la farà funzionare sul tuo ambiente. Queste sono le domande che consigliamo di fare a qualunque partner, noi compresi:

• Su quale ambiente lavora? Questionari e interviste servono per la governance, ma il rischio si vede collegandosi agli account veri.
• Quali permessi chiede, e come si revocano? L'elenco per ogni cloud va letto prima di iniziare.
• Copre tutti i tuoi provider? AWS, Azure e Google Cloud nella stessa vista, non tre report separati.
• Cosa succede dopo la lista? Chi segue le correzioni e chi verifica che il rischio sia chiuso.
• Con quale SOC parla? Senza quel collegamento la postura resta un esercizio separato.
• Parla la lingua degli auditor? Le evidenze servono anche per NIS2, DORA e ISO 27001.
• Ti dice quando non serve? Con un solo account piccolo e stabile, gestito da chi lo conosce bene, i controlli nativi del provider spesso bastano.

Da cosa dipende il costo

Non c'è un listino valido per tutti: il costo dipende dal tuo ambiente, e per questo si stima dopo la fotografia, sul perimetro reale. I fattori che lo muovono sono:

• la dimensione del perimetro, cioè quanti workload (macchine virtuali, container, funzioni) girano negli account collegati;
• quanti cloud e quanti account entrano nella vista;
• i moduli necessari: postura, codice e pipeline, rilevamento a runtime;
• il livello di servizio: fotografia una tantum, postura gestita nel tempo, oppure monitoraggio con il SOC 24/7;
• il lavoro sulle evidenze per NIS2, DORA, ISO 27001 o SOC 2.

Per confrontare due preventivi, chiedi a ogni fornitore su quale metrica si calcola il prezzo e cosa è compreso.

Cosa cambia nel 2026

• Wiz è parte di Google Cloud dall'11 marzo 2026, con marchio e multicloud confermati e una piattaforma combinata con Google Security Operations. Per chi ha o sceglie un SOC su Google SecOps, postura del cloud e detection lavorano sullo stesso contesto.
• Le finestre di sfruttamento si accorciano. Google ha osservato nel secondo semestre 2025 il tempo fra pubblicazione e sfruttamento di una vulnerabilità ridursi da settimane a giorni: una fotografia all'anno non tiene il passo.
• La Banca d'Italia chiede conto anche del cloud. Con la comunicazione al mercato del 17 luglio 2026 sulla resilienza operativa digitale, rivolta agli intermediari che vigila direttamente (dalle banche meno significative agli istituti di pagamento e di moneta elettronica, fino agli intermediari ex art. 106 TUB), chiede inventari completi e una classificazione delle risorse per criticità che tenga conto dell'esposizione diretta su internet e del ricorso al cloud. Il consiglio di amministrazione avvia una relazione sul livello di esposizione al rischio, con piano di lavoro, da trasmettere alla Vigilanza entro il 31 dicembre 2026.
• Le domande arrivano dalla catena di fornitura. Chi è soggetto a NIS2 o DORA deve governare i propri fornitori, quindi i questionari sulla sicurezza del cloud arrivano anche a chi non è obbligato direttamente.

Il punto di partenza resta lo stesso: sapere cosa è esposto oggi nei propri account, con quali permessi e vicino a quali dati, e decidere in che ordine intervenire.