Sicurezza multicloud: una sola vista su AWS, Azure e GCP

La risposta breve: la sicurezza multicloud è la capacità di applicare le stesse regole, vedere gli stessi rischi e rispondere agli stessi incidenti su tutti i cloud che usi, per esempio AWS, Azure e Google Cloud. Il problema non è la sicurezza di ciascun provider, che è solida: è che ognuno ha i suoi permessi, i suoi log e la sua console. Serve una sola vista.

In questo articolo vediamo dove si rompe la sicurezza quando i cloud diventano due o tre, cosa fanno gli strumenti nativi dei provider, cosa significa in concreto avere una vista unica e da dove partire. Le categorie di prodotto (CNAPP, CSPM, CIEM) hanno articoli dedicati, linkati dove servono.

Cosa vuol dire sicurezza multicloud, in pratica

Un'azienda mid-market raramente sceglie il multicloud a tavolino. Ci arriva: il gestionale su Azure perché c'era già Microsoft 365, i dati e l'analisi su Google Cloud, un prodotto SaaS nato su AWS, un'acquisizione che porta il suo account. Ogni ambiente ha senso da solo. Il problema nasce quando qualcuno chiede una risposta che li attraversa tutti: quante risorse abbiamo esposte su internet? Chi può leggere i dati dei clienti? Siamo allineati alla politica di sicurezza che abbiamo approvato?

Fare sicurezza multicloud significa poter rispondere a queste domande una volta sola, con un solo inventario e un solo ordine di priorità, invece di aprire tre console e confrontare tre fogli di calcolo.

Perché tre cloud non sono tre volte un cloud

AWS, Azure e Google Cloud offrono gli stessi concetti di fondo: identità, rete, storage, calcolo, log. Cambiano nomi, valori predefiniti e confini, ed è lì che si aprono i buchi.

Identità e permessi

AWS ha IAM con ruoli e policy, Azure lega i permessi a Microsoft Entra ID e ai ruoli sulle risorse, Google Cloud ha il suo IAM con ruoli assegnati su organizzazione, cartelle e progetti. Lo stesso principio, il privilegio minimo, si scrive in tre linguaggi diversi. Un utente o un account di servizio con permessi eccessivi su un cloud non compare nel report dell'altro, e le identità federate tra cloud sono proprio quelle che nessuno guarda per intero. Il tema dei permessi effettivi è trattato nell'articolo sul CIEM e i permessi nel cloud.

Gerarchia di account e progetti

Su AWS si ragiona per account sotto un account di gestione, su Azure per sottoscrizioni, su Google Cloud per organizzazione, cartelle e progetti. Una regola applicata in alto nella gerarchia di un provider non ha un equivalente automatico negli altri due. Il risultato tipico: un ambiente di test creato in fretta sul cloud meno presidiato, fuori dalle regole che valgono sul cloud principale.

Log e audit

CloudTrail su AWS, Activity Log su Azure, Cloud Audit Logs su Google Cloud. Formati diversi e impostazioni predefinite diverse: la documentazione di Google Cloud, per esempio, indica che i log di accesso ai dati (Data Access) sono disattivati per impostazione predefinita, tranne che per BigQuery. Chi non conosce questi dettagli su ogni provider scopre durante un incidente che il log che serviva non è mai stato scritto.

Regole di riferimento

Anche gli standard di configurazione sono separati. Il Center for Internet Security pubblica tre benchmark distinti: Amazon Web Services Foundations, Microsoft Azure Foundations e Google Cloud Platform Foundation. Una baseline aziendale unica va quindi tradotta tre volte, e tenuta allineata a ogni nuova versione.

Cosa fanno gli strumenti nativi dei provider

Ogni provider ha un servizio di postura per il proprio cloud: AWS Security Hub CSPM, Microsoft Defender for Cloud, Google Security Command Center. Sono il punto di partenza naturale, e su un solo cloud spesso bastano. Cosa fa e cosa non fa un CSPM è spiegato nell'articolo su cos'è il CSPM.

Alcuni si allargano anche agli altri cloud. La documentazione Microsoft descrive i connettori con cui Defender for Cloud si collega ad account AWS e a progetti Google Cloud. La documentazione AWS descrive un'integrazione di Security Hub CSPM con Azure, che applica il CIS Microsoft Azure Foundations Benchmark e tiene punteggi di sicurezza separati per AWS e per Azure.

Quando si valuta uno strumento nativo per un uso multicloud conviene fare tre domande concrete:

• Quali cloud copre davvero, e con quali funzioni su ciascuno: la copertura sul cloud di casa e quella sugli altri spesso non coincidono.
• Se produce una sola lista di priorità o tante liste affiancate, una per provider.
• Chi la guarda: se il team che usa Azure non apre mai la console AWS, una funzione multicloud che vive in una console sola resta inutilizzata.

Cosa significa avere una sola vista

Una vista unica non è una dashboard con tre riquadri. È un modo di lavorare in cui le stesse domande hanno la stessa risposta, qualunque sia il cloud. In concreto servono cinque cose.

1. Un inventario unico, letto dalle API dei provider e aggiornato in continuo: account, sottoscrizioni, progetti, risorse, identità, dati.
2. Una baseline scritta una volta e verificata su tutti i cloud, mappata sui benchmark di ciascun provider.
3. Priorità per rischio, non per provider: una macchina esposta su internet, con una vulnerabilità nota e un permesso che porta ai dati dei clienti va prima di cento configurazioni imperfette, su qualunque cloud stia. Mettere in relazione questi segnali è il lavoro di una CNAPP, descritta nell'articolo CNAPP: cos'è e quali componenti ha.
4. Identità viste insieme: chi può fare cosa, su tutti i cloud, comprese le identità non umane come gli account di servizio e le chiavi delle pipeline.
5. Log centralizzati in un SIEM, con qualcuno che li guarda. La postura dice cosa è esposto; il rilevamento dice cosa sta succedendo. Servono entrambi, e il secondo richiede persone, interne o di un SOC gestito.

Da dove partire

Con più cloud la tentazione è comprare subito uno strumento. Conviene invece seguire un ordine:

1. Fare l'elenco degli ambienti: tutti gli account, le sottoscrizioni e i progetti, con un responsabile per ciascuno. Quelli senza responsabile sono i primi da guardare.
2. Accendere e centralizzare i log che servono su ogni provider, verificando le impostazioni predefinite cloud per cloud.
3. Scrivere la baseline una volta, partendo dai benchmark CIS dei tre provider, e decidere quali eccezioni sono accettate.
4. Fare una fotografia di tutti gli ambienti insieme, con i rischi in ordine di priorità: è il momento in cui si scopre cosa è esposto davvero.
5. Assegnare le correzioni a chi gestisce ciascun ambiente e misurare quanto restano aperte. Una lista che nessuno smaltisce non abbassa il rischio.

Multicloud, NIS2 e DORA

Le norme non chiedono di usare un cloud o tre: chiedono di gestire i rischi dei sistemi su cui gira l'azienda, ovunque siano. Per un soggetto NIS2 questo vuol dire produrre evidenze sulle misure di sicurezza per ogni ambiente, e con più provider il lavoro si moltiplica se gli strumenti restano separati. Le misure applicate al cloud sono nell'articolo su NIS2 e cloud.

Per il settore finanziario, il Regolamento (UE) 2022/2554 (DORA) all'articolo 6, paragrafo 9, prevede che le entità finanziarie possano definire una strategia per le TIC «basata su una varietà di fornitori», che indichi le principali dipendenze dai fornitori terzi. È una facoltà, non un obbligo: ma chi la adotta si trova per scelta in un ambiente multicloud e deve poterlo governare come uno solo. Cosa chiede DORA sul cloud, dal registro alle strategie di uscita, è nell'articolo DORA e cloud per fintech.

Wiz e la vista multicloud

Wiz è una piattaforma di sicurezza per il cloud che si collega agli account via API, senza installare agenti, costruisce l'inventario delle risorse e mette in relazione configurazioni, vulnerabilità, permessi, esposizione e dati sensibili per ordinare i rischi. L'inventario passa dalle API; l'analisi dei dischi passa da snapshot temporanei e cifrati, analizzati in un ambiente separato, senza toccare i carichi in esecuzione.

Google ha annunciato l'accordo per acquisire Wiz il 18 marzo 2025, a un prezzo di 32 miliardi di dollari in contanti, soggetto ad aggiustamenti, e ha completato l'operazione l'11 marzo 2026. Nella relazione trimestrale al 30 giugno 2026 (nota 8) Alphabet registra l'acquisizione per 29,5 miliardi di dollari dopo gli aggiustamenti di prezzo, e la descrive come un investimento di Google Cloud per accelerare le proprie capacità nel multicloud e nella sicurezza basata sull'AI. Alla chiusura Google ha confermato che il marchio Wiz resta e che i prodotti continuano a funzionare sui principali cloud, compresi AWS, Microsoft Azure e Oracle; a luglio 2026 Wiz ha ribadito di restare una piattaforma multicloud. Il quadro completo è nell'articolo su cos'è Wiz.

AmagisTech è partner Wiz e partner Google Cloud. Usiamo Wiz per fare la fotografia di aziende che hanno carichi su più cloud: un solo inventario, una sola lista di priorità, e poi il lavoro di correzione insieme a chi gestisce ciascun ambiente. Uno strumento non sostituisce le decisioni: quali rischi accettare e in che ordine intervenire resta una scelta dell'azienda.

In sintesi

In sintesi: la sicurezza multicloud non è un prodotto in più, è la capacità di avere un solo inventario, una sola baseline, una sola lista di priorità e log centralizzati su tutti i cloud che usi. Gli strumenti nativi dei provider sono un buon punto di partenza e alcuni coprono anche gli altri cloud; quando i provider sono due o tre, la differenza la fa poter guardare i rischi insieme, ordinati per quanto sono sfruttabili e non per la console in cui compaiono.

Se vuoi vedere com'è messo oggi il tuo ambiente su AWS, Azure e Google Cloud, partiamo da una fotografia del cloud con Wiz: una call di 20 minuti, poi il collegamento via API ai tuoi account e la lista di cosa è esposto, in ordine di priorità.