Sicurezza nel cloud ibrido e nel multi-cloud
- Il cloud ibrido combina l’infrastruttura di proprietà con il cloud pubblico; il multi-cloud si avvale di più di un fornitore di servizi cloud pubblici.
- La sicurezza ibrida si concentra sul confine tra ambiente locale e cloud; la sicurezza multi-cloud si concentra sulle differenze tra i vari provider.
- L'identità, la classificazione dei dati e le politiche di accesso devono rimanere coerenti in ogni ambiente in entrambi i modelli.
- Da una ricerca condotta da Flexera nel 2026 è emerso che il 73% delle organizzazioni gestisce infrastrutture ibride, spesso in combinazione con più cloud.
- Secondo lo studio condotto da IBM per il 2025, le violazioni che hanno interessato più ambienti sono risultate le più costose e quelle che hanno richiesto più tempo per essere contenute.
Sia la sicurezza del cloud ibrido che quella del multi-cloud riguardano la protezione dei carichi di lavoro e dei dati distribuiti su più di un ambiente, ma le problematiche sono diverse. La sicurezza del cloud ibrido si concentra sul mantenimento di controlli coerenti tra l’infrastruttura gestita dall’organizzazione e quella gestita da un fornitore di servizi cloud. La sicurezza del multi-cloud si concentra invece sul mantenimento di controlli coerenti tra diversi fornitori di cloud pubblico, ciascuno con il proprio modello di identità, le proprie architetture di rete e i propri servizi di sicurezza.
Il presente articolo fa parte della guida alla sicurezza del cloud ibrido.
Definizioni
Il cloud ibrido combina infrastrutture cloud proprietarie e pubbliche, il multi-cloud si avvale di diversi fornitori pubblici, mentre il multi-cloud ibrido combina entrambe le soluzioni.
Cloud ibrido. La definizione di cloud computing fornita dal NIST, contenuta nella specifica SP 800-145, descrive il cloud ibrido come un insieme di due o più infrastrutture cloud distinte (private, comunitarie o pubbliche) che rimangono entità autonome ma sono collegate tra loro da una tecnologia che consente la portabilità dei dati e delle applicazioni. Nell’uso comune, il termine “ibrido” include anche i tradizionali data center on-premise collegati al cloud pubblico.
Multi-cloud. L’utilizzo di più di un fornitore di cloud pubblico, ad esempio l’esecuzione di carichi di lavoro su due hyperscaler o la combinazione di servizi IaaS di un fornitore con servizi di piattaforma di un altro. Anche l’utilizzo di soluzioni SaaS offerte da diversi fornitori costituisce una forma di multi-cloud.
Multi-cloud ibrido. Infrastruttura on-premise o privata combinata con più cloud pubblici. Questa configurazione caratterizza la maggior parte delle grandi imprese.
Quanto è diffuso ciascun modello
Gli ambienti ibridi e multi-cloud sono ormai la norma, e molti di essi si sono sviluppati per caso piuttosto che in modo pianificato.
Il rapporto “State of the Cloud 2026” di Flexera, basato su un sondaggio condotto su 753 responsabili delle decisioni in ambito cloud, ha rilevato che il 73% delle organizzazioni gestisce infrastrutture ibride. Il comunicato stampa di Flexera indica che l’utilizzo del multi-cloud si attesta all’88%, e il rapporto sottolinea che la crescita del multi-cloud potrebbe derivare da fusioni o da applicazioni isolate piuttosto che da una strategia deliberata. Ciò è rilevante ai fini della sicurezza: gli ambienti multi-cloud che si sono sviluppati in modo accidentale presentano solitamente controlli non uniformi.
Confronto diretto
La sicurezza degli ambienti ibridi e multi-cloud si differenzia in sei dimensioni: architettura, accesso, gestione dei dati, responsabilità, gestione delle politiche e modalità di guasto principale.
| Dimensione | Sicurezza del cloud ibrido | Sicurezza multi-cloud |
|---|---|---|
| Architettura | Collega l’infrastruttura di proprietà con quella del fornitore; la sicurezza copre entrambi i lati di tale confine | Comprende diversi fornitori, ciascuno con modelli di rete, identità e servizi diversi |
| Accesso | Gli utenti accedono alle applicazioni nei data center e nel cloud; i percorsi in loco e quelli remoti presentano delle differenze | Gli utenti e i carichi di lavoro accedono ai servizi su diversi cloud; ogni fornitore dispone dei propri controlli di accesso |
| Trattamento dei dati | I dati vengono trasferiti tra le infrastrutture locali e il cloud; la sede di conservazione e il luogo di ispezione rappresentano decisioni fondamentali | I dati circolano tra i vari fornitori; ciascuno di essi dispone di opzioni diverse in materia di crittografia, gestione delle chiavi e registrazione delle attività |
| Responsabilità | Il cliente è proprietario di tutto ciò che si trova presso la propria sede e condivide la responsabilità per quanto riguarda il cloud | Le ripartizioni della responsabilità condivisa variano a seconda del fornitore e del tipo di servizio |
| Gestione delle politiche | Rischio derivante dall'adozione di politiche distinte per l'applicazione delle norme in ambiente locale e nel cloud | Rischio di politiche distinte per ciascuno degli strumenti nativi del fornitore |
| Modalità di guasto principale | Incoerenza tra le politiche di applicazione a livello locale e quelle nel cloud | Errori di configurazione dovuti alle diverse impostazioni predefinite dei fornitori e alle lacune nelle competenze |
Architettura
L'architettura ibrida è caratterizzata dalle interconnessioni tra gli ambienti, mentre l'architettura multi-cloud è caratterizzata dalla coerenza tra i vari fornitori.
In un’architettura ibrida, gli aspetti critici della progettazione sono le connessioni tra gli ambienti: interconnessioni private, VPN e i punti di controllo che ispezionano il traffico che li attraversa. Le decisioni relative al luogo in cui ispezionare il traffico e a quello in cui decriptarlo determinano le prestazioni, la sovranità e la resilienza. Si veda l’Architettura di riferimento per la sicurezza del cloud ibrido.
In un’architettura multi-cloud, gli aspetti fondamentali della progettazione sono l’astrazione e la coerenza: un livello di identità comune, modelli di segmentazione della rete coerenti e strumenti di sicurezza che funzionino a livello trasversale tra i vari provider, anziché limitarsi a un unico provider.
Accesso
L'accesso coerente in entrambi i modelli dipende da un unico fornitore di identità e da un unico insieme di autorizzazioni per ciascuna applicazione.
La progettazione dell’accesso ibrido deve gestire gli utenti in sede che accedono alle applicazioni in sede, gli utenti remoti che accedono alle applicazioni in sede e tutti gli utenti che accedono ai servizi cloud. La funzione “ Zero trust network access ”, con applicazione sia a livello locale che nel cloud, gestisce tutti e tre i percorsi nell’ambito di un’unica politica. Si veda “ZTNA on-premise per applicazioni private”.
La progettazione dell’accesso multi-cloud deve integrare diversi sistemi di gestione delle identità e degli accessi dei vari provider. Un unico provider di identità aziendale federato con ciascun cloud, dotato di definizioni coerenti dei ruoli, riduce le discrepanze.
Trattamento dei dati
La protezione dei dati in entrambi i modelli dovrebbe basarsi su un livello trasversale a tutti gli ambienti, piuttosto che sugli strumenti nativi di ciascun fornitore.
Gli ambienti ibridi sollevano questioni relative alla residenza e alla sede delle ispezioni, in particolare quali dati possano essere trasferiti nel cloud, dove si trovi il traffico decriptato e dove siano archiviati i log. Sollevano inoltre, separatamente, questioni di sovranità relative a chi gestisca l’infrastruttura che elabora il traffico e chi la gestisca. Si veda “Sovranità dei dati nella sicurezza del cloud ibrido”.
Gli ambienti multi-cloud sollevano questioni relative alla coerenza: occorre verificare se la classificazione, la crittografia, la gestione delle chiavi e l’ data loss prevention o funzionino allo stesso modo presso ciascun provider. Un livello di sicurezza dei dati trasversale ai provider (DSPM per l’individuazione e DLP per l’applicazione) evita di dover fare affidamento sugli strumenti nativi, diversi tra loro, di ciascun provider. Si veda “DLP in ambienti cloud e on-premises”.
Il rapporto di IBM del 2025 sul costo delle violazioni dei dati ha rilevato che le violazioni riguardanti dati distribuiti su più ambienti hanno comportato un costo medio di 5,05 milioni di dollari e hanno richiesto 276 giorni per essere individuate e contenute: si tratta del costo più elevato e del ciclo di vita più lungo tra tutte le configurazioni di archiviazione.
Responsabilità
Gli ambienti ibridi presentano un unico confine di responsabilità per ciascun fornitore, mentre gli ambienti multi-cloud moltiplicano tali confini tra i vari fornitori e livelli di servizio.
Le dieci principali strategie di mitigazione dei rischi per la sicurezza nel cloud definite dalla NSA e dalla CISA pongono in primo piano il rispetto del modello di responsabilità condivisa e includono una strategia specifica per le complessità derivanti dagli ambienti ibridi e multi-cloud.
Negli ambienti ibridi, il confine di responsabilità si colloca tra l’organizzazione e ciascun fornitore. Negli ambienti multi-cloud, i confini sono molteplici e vengono definiti in modo diverso da ciascun fornitore e per ciascun livello di servizio. Si raccomanda di mantenere una matrice delle responsabilità per ciascun servizio.
Gestione delle politiche
Il rischio comune a entrambi i modelli è la frammentazione delle politiche: un insieme di politiche per ogni stack di applicazione, che con il passare del tempo tendono a divergere.
Per l’accesso degli utenti ad applicazioni web, SaaS e private, un unico motore di policy SSE, che garantisce l’applicazione delle norme sia nel cloud che in locale, copre sia gli ambienti ibridi che quelli multi-cloud. Per quanto riguarda la configurazione dei carichi di lavoro, la gestione dello stato di sicurezza cross-cloud e il modello “policy-as-code” garantiscono la coerenza delle impostazioni dell’infrastruttura. Si veda “Policy di sicurezza coerenti tra cloud e ambiente locale”.
Architettura ibrida multi-cloud: priorità in materia di sicurezza
Un programma di sicurezza ibrido multi-cloud si basa su sette priorità che garantiscono la coerenza dei controlli in ogni ambiente.
- Un unico provider di identità federato con tutti i sistemi cloud e on-premises.
- Un unico schema di classificazione dei dati applicato da DSPM e DLP in ogni ambiente.
- Un’unica politica di accesso per gli utenti relativa a applicazioni web, SaaS e private, applicata sia a livello locale che nel cloud.
- Gestione della sicurezza cross-cloud per la configurazione dell’infrastruttura.
- Registrazione centralizzata e sensibile alla residenza per tutti i fornitori e tutte le sedi.
- Una matrice delle responsabilità per ciascun fornitore e servizio.
- Pianificazione della resilienza che presuppone che qualsiasi singolo fornitore possa subire un’interruzione. Si veda “Resilienza SSE ibrida: failover e ripristino”.
Quale modello è più sicuro?
Nessuno dei due modelli è intrinsecamente più sicuro; il risultato dipende dalla coerenza con cui vengono applicate le politiche relative all’identità, ai dati e agli accessi.
L’approccio ibrido offre alle organizzazioni un maggiore controllo sulla sede di elaborazione dei dati e sulle modalità di prosecuzione delle operazioni in caso di interruzioni del servizio da parte del fornitore. L’approccio multi-cloud può ridurre la dipendenza da un unico fornitore, ma aumenta la complessità della configurazione.
In che modo Skyhigh garantisce la sicurezza degli ambienti ibridi e multi-cloud
Skyhigh supporta entrambi i modelli applicando un’unica politica di accesso e gestione dei dati, indipendentemente dal cloud su cui sono ospitate le applicazioni.
Skyhigh Hybrid SSE Mesh applica un’unica politica per l’accesso al Web, ai servizi SaaS, alle applicazioni private e agli strumenti di intelligenza artificiale su tutti i punti di applicazione, sia on-premise che nel cloud, indipendentemente dai provider cloud che ospitano le applicazioni. Ciò garantisce una politica di accesso degli utenti coerente; la configurazione dei carichi di lavoro tra diversi provider viene gestita dalla gestione della postura (posture management) anziché dall’SSE. Skyhigh CASB applica politiche unificate su numerosi servizi cloud; il suo registro cloud valuta i servizi in base ad attributi di rischio, tra cui la residenza dei dati, mentre Skyhigh DSPM individua i dati sensibili negli archivi cloud e SaaS.
Fonti
- NIST. SP 800-145: La definizione di cloud computing del NIST (settembre 2011). https://csrc.nist.gov/pubs/sp/800/145/final
- Flexera. Rapporto 2026 sullo stato del cloud. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
- Flexera. Comunicato stampa “2026 State of the Cloud” (18 marzo 2026; in tedesco). https://www.flexera.com/de/about-us/press-center/cloud-entwickelt-sich-vom-kostenfaktor-zum-werttreiber
- IBM e Ponemon Institute. Rapporto sul costo delle violazioni dei dati 2025. https://www-api.ibm.com/adobe/assets/urn:aaid:aem:607b9590-38e0-4c91-b433-aa8a17f5b5e8/original/as/cost-of-a-data-breach-2025-full-report.pdf
- NSA e CISA. Le dieci principali strategie di mitigazione dei rischi per la sicurezza nel cloud (7 marzo 2024). https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3699169/nsa-releases-top-ten-cloud-security-mitigation-strategies/