Architettura cloud ibrida: componenti e modelli di implementazione
- L'architettura cloud ibrida collega le risorse on-premise, del cloud privato e del cloud pubblico, in modo che operino come un unico ambiente.
- I suoi componenti fondamentali sono gli ambienti, la connettività tra di essi e cinque livelli che li abbracciano tutti.
- Il NIST definisce quattro modelli di implementazione del cloud, e il modello ibrido integra due o più infrastrutture distinte.
- Tra i modelli più diffusi figurano l’ibrido a più livelli, l’ibrido perimetrale, la continuità operativa e il cloud bursting, ciascuno con esigenze di sicurezza diverse.
- Una politica coerente in materia di identità e sicurezza in tutti gli ambienti è determinante per garantire che un’architettura ibrida rimanga gestibile e sicura.
L’architettura cloud ibrida è la struttura che collega l’infrastruttura on-premise di un’organizzazione, il cloud privato e i servizi di cloud pubblico, in modo che le applicazioni e i dati possano operare su tutte queste piattaforme come se costituissero un unico ambiente. Essa definisce quali carichi di lavoro vengono eseguiti in quale ambiente, in che modo gli ambienti si collegano tra loro e quali livelli condivisi (identità, gestione, sicurezza, dati e osservabilità) ne garantiscono la coerenza.
Il presente articolo illustra cos’è l’architettura cloud ibrida, i suoi componenti fondamentali, un diagramma di riferimento, i modelli di implementazione e i modelli architetturali utilizzati dalle organizzazioni, le modalità di integrazione degli ambienti, i vantaggi e i compromessi, tre esempi e le modalità di pianificazione di tale architettura. Per un’analisi approfondita della progettazione della sicurezza, si rimanda a “Sicurezza del cloud ibrido: architettura e best practice”.
Che cos’è l’architettura cloud ibrida?
L'architettura cloud ibrida combina due o più ambienti informatici distinti, in genere un'infrastruttura on-premise o privata e un cloud pubblico, e li integra tra loro in modo che i carichi di lavoro e i dati possano spostarsi da uno all'altro.
La definizione di cloud computing fornita dal NIST, contenuta nella norma 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 cloud ibrido comprende anche i data center tradizionali collegati al cloud pubblico e, sempre più spesso, siti periferici quali stabilimenti, negozi e filiali.
Il modello ibrido è ormai la norma per le grandi organizzazioni. Il rapporto “2026 State of the Cloud” di Flexera ha rilevato che il 73% delle organizzazioni gestisce infrastrutture ibride.
Componenti fondamentali dell'architettura cloud ibrida
Ogni architettura cloud ibrida presenta tre tipi di componenti: gli ambienti in cui vengono eseguiti i carichi di lavoro, la connettività tra di essi e i livelli condivisi che li abbracciano tutti.
| Componente | Cosa fa | Esempi tipici |
|---|---|---|
| Data center in sede | Esegue carichi di lavoro legacy, regolamentati, sensibili alla latenza o ad alto volume | Server virtualizzati, mainframe, array di archiviazione |
| Cloud privato | Offre un servizio self-service in stile cloud su un’infrastruttura dedicata | Piattaforme di virtualizzazione o di container gestite dall’organizzazione o da un fornitore di servizi di hosting |
| Cloud pubblico (IaaS e PaaS) | Fornisce risorse di elaborazione, archiviazione e servizi gestiti scalabili | Servizi di infrastruttura e piattaforma degli hyperscaler |
| Applicazioni SaaS | Fornisce applicazioni aziendali come servizio | Posta elettronica, collaborazione, CRM, sistemi per le risorse umane |
| Siti periferici | Elabora i dati in prossimità del luogo in cui vengono generati | Stabilimenti, negozi, cliniche, filiali |
| Connettività | Collega gli ambienti in modo sicuro e affidabile | VPN site-to-site, interconnessioni private, SD-WAN, Internet |
| Identità e accesso | Fornisce un'unica fonte di identità in tutti gli ambienti | Provider di identità federata, autenticazione a più fattori (MFA), identità dei carichi di lavoro |
| Gestione e coordinamento | Distribuisce e gestisce i carichi di lavoro in modo coerente | Infrastruttura come codice, Kubernetes, piattaforme di gestione ibride |
| Sicurezza | Garantisce il rispetto delle politiche relative all’accesso, alle minacce e ai dati in ogni contesto | Secure web gateway, ZTNA, CASB, DLP, DSPM, segmentazione |
| Dati e integrazione | Trasferisce e sincronizza dati e servizi | Replica, backup, API, streaming di eventi |
| Osservabilità | Mostra ciò che sta accadendo nei vari ambienti | Log, metriche, tracce, SIEM |
I fornitori di servizi cloud offrono inoltre soluzioni per l’esecuzione dei propri servizi all’interno delle strutture dei clienti. AWS Outposts estende l’infrastruttura e i servizi AWS alle sedi on-premise, mentre Azure Local, precedentemente noto come Azure Stack HCI, viene eseguito sull’hardware del cliente ed è gestito tramite Azure Arc. Queste piattaforme rendono l’ambiente on-premise più simile al cloud, ma non eliminano la necessità di livelli condivisi di identità, sicurezza e osservabilità.
Schema dell'architettura cloud ibrida
Uno schema di un'architettura cloud ibrida dovrebbe illustrare gli ambienti, la connettività tra di essi e i livelli che li abbracciano tutti.
La riga superiore mostra dove vengono eseguiti i carichi di lavoro. Il livello di connettività illustra in che modo tali ambienti comunicano tra loro. I cinque livelli sottostanti abbracciano tutti gli ambienti; se uno qualsiasi di essi venisse implementato separatamente in ciascun ambiente, l’architettura risulterebbe frammentata. Il livello di sicurezza è quello in cui la frammentazione comporta i costi maggiori, poiché l’adozione di politiche distinte per ciascun ambiente crea lacune che gli aggressori possono sfruttare. Per una visione specifica della sicurezza, si rimanda all’Architettura di riferimento per la sicurezza del cloud ibrido.
Modelli di implementazione del cloud ibrido
Il NIST definisce quattro modelli di implementazione del cloud, e quello ibrido è quello che combina gli altri.
| Modello di implementazione | Definizione (NIST SP 800-145) | Utilizzo tipico |
|---|---|---|
| Cloud privato | Infrastruttura messa a disposizione per l’uso esclusivo di un’organizzazione | Carichi di lavoro regolamentati o altamente personalizzati |
| Cloud comunitario | Infrastruttura condivisa da una comunità specifica con interessi comuni | Consorzi governativi o industriali |
| Cloud pubblico | Infrastruttura messa a disposizione per l’uso libero da parte del pubblico in generale | Servizi elastici e gestiti |
| Cloud ibrido | Due o più infrastrutture distinte collegate tra loro per garantire la portabilità dei dati e delle applicazioni | La maggior parte delle imprese |
In pratica, le organizzazioni realizzano architetture ibride in quattro configurazioni comuni:
- Data center e cloud pubblico: sistemi on-premise esistenti collegati a un unico hyperscaler.
- Cloud privato e cloud pubblico: una piattaforma interna modernizzata collegata ai servizi di cloud pubblico.
- Un modello ibrido all’avanguardia: data center centrale e cloud, oltre all’elaborazione locale presso stabilimenti, punti vendita o filiali.
- Multi-cloud ibrido: infrastruttura on-premise collegata a più di un fornitore di cloud pubblico. Si veda “Sicurezza del cloud ibrido rispetto al multi-cloud”.
Modelli comuni di architettura cloud ibrida
I modelli di architettura ibrida descrivono le modalità di ripartizione o duplicazione dei carichi di lavoro tra i vari ambienti, e ciascun modello comporta requisiti di sicurezza diversi.
Il Cloud Architecture Center di Google raggruppa i modelli di architettura ibrida e multicloud in modelli distribuiti, in cui parti del sistema vengono eseguite in ambienti diversi, e in modelli ridondanti, in cui lo stesso sistema viene duplicato in diversi ambienti.
| Modello | Come funziona | Considerazioni in materia di sicurezza |
|---|---|---|
| Ibrido a più livelli | I livelli rivolti ai clienti sono gestiti nel cloud; i sistemi di back-end rimangono in sede | Proteggere e verificare le API e i percorsi dei dati tra i livelli |
| Multicloud con partizioni | Carichi di lavoro o componenti diversi vengono eseguiti su diversi cloud pubblici | Garantire la coerenza dell’identità e delle politiche tra i vari fornitori |
| Analisi ibrida | I sistemi transazionali rimangono in sede; l’analisi dei dati viene eseguita nel cloud | Classificare e ridurre al minimo i dati prima che vengano trasmessi |
| Edge ibrido | I carichi di lavoro critici in termini di tempo o per l’attività vengono eseguiti localmente; il cloud si occupa del resto | Applicazione locale che continua a funzionare anche in caso di interruzione della connessione |
| Ambiente ibrido | Sviluppo e fase di test in un unico ambiente, produzione in un altro | Si proceda alla pulizia dei dati di test e si applichino gli stessi controlli in entrambi i casi |
| Continuità operativa | Un secondo ambiente funge da sito di ripristino | Replicare le politiche di sicurezza e le chiavi insieme ai dati |
| Cloud bursting | Durante i picchi di domanda, la capacità aggiuntiva proviene dal cloud | Le politiche devono adeguarsi automaticamente ai carichi di lavoro man mano che questi aumentano |
La maggior parte delle organizzazioni utilizza contemporaneamente diversi modelli; ecco perché è fondamentale disporre di un unico livello di sicurezza indipendente dall’ambiente.
Architettura di integrazione del cloud ibrido
L'architettura di integrazione del cloud ibrido definisce le modalità con cui reti, applicazioni, dati e identità si interconnettono tra i diversi ambienti.
Integrazione di rete. I modelli di rete sicura di Google per ambienti ibridi e multicloud descrivono diversi approcci: reti speculari per lo sviluppo e il collaudo, reti a maglia in cui tutti i sistemi possono comunicare tra loro, modelli “gated” in cui solo API selezionate vengono esposte tramite gateway in una o entrambe le direzioni, e modelli di “handover” in cui i sistemi on-premise trasmettono dati ai servizi cloud senza una connettività di rete estesa. I modelli “gated” seguono più da vicino il principio del privilegio minimo e rappresentano solitamente l’impostazione predefinita più sicura.
Integrazione delle applicazioni. Le API, pubblicate tramite gateway API, forniscono a ciascun ambiente un’interfaccia controllata anziché un accesso diretto ai sistemi di back-end.
Integrazione dei dati. La replica, il backup, i trasferimenti in batch e lo streaming degli eventi garantiscono la sincronizzazione dei dati. Ogni flusso deve essere classificato, crittografato e registrato.
Integrazione delle identità. Un unico provider di identità federato a ogni ambiente, con identità dei carichi di lavoro per i servizi e gli agenti di intelligenza artificiale, impedisce la formazione di silos separati di identità.
Integrazione della sicurezza. Le politiche relative agli accessi, alle minacce e ai dati dovrebbero essere definite una sola volta e applicate in ogni ambiente. Le linee guida “zero trust” del NIST, SP 800-207, separano il punto di decisione relativo alle politiche dai punti di applicazione delle stesse; si tratta del modello che rende possibile tale approccio in tutti gli ambienti.
Vantaggi e compromessi dell'architettura cloud ibrida
L'architettura cloud ibrida offre alle organizzazioni flessibilità e controllo, ma comporta una maggiore complessità che deve essere gestita con attenzione.
Vantaggi
- Assegnazione dei carichi di lavoro in base alle esigenze: eseguire ciascun carico di lavoro nell’ambiente in cui latenza, costi, normative e prestazioni risultano più adeguati.
- Controllo sui dati sensibili: mantenere i dati soggetti a normative e il relativo trattamento in sede, pur utilizzando servizi cloud altrove.
- Modernizzazione graduale: migrate le applicazioni per fasi anziché tutte in una volta.
- Resilienza: utilizzare un secondo ambiente per il ripristino e garantire il funzionamento delle operazioni locali in caso di interruzioni del servizio cloud o della rete WAN.
- Capacità elastica: aumentate la capacità cloud per far fronte ai picchi di domanda senza dover potenziare eccessivamente il data center.
- Bassa latenza a livello periferico: elaborazione dei dati in prossimità del luogo in cui vengono generati.
Compromessi
- Complessità operativa: un numero maggiore di ambienti, strumenti e competenze da gestire.
- Coerenza delle politiche: identità, sicurezza e derive di configurazione quando ciascun ambiente viene gestito separatamente.
- Lacune nella visibilità: registri e inventari distribuiti su diversi strumenti.
- Costi di rete e di trasferimento: il trasferimento dei dati tra diversi ambienti può risultare oneroso.
- Impatto maggiore in caso di violazione se non gestita: il rapporto IBM “Cost of a Data Breach Report 2025” ha rilevato che le violazioni che coinvolgono dati in più ambienti hanno comportato un costo medio di 5,05 milioni di dollari e hanno richiesto 276 giorni per essere individuate e contenute, il valore più elevato tra tutte le configurazioni di archiviazione.
Esempi di architetture cloud ibride
Gli stessi elementi si combinano in modo diverso a seconda del settore, come dimostrano questi tre esempi.
Esempio 1: Modello ibrido a più livelli per una banca
Le interfacce di banking online e mobile operano nel cloud pubblico per garantire elasticità. I sistemi bancari centrali rimangono nei data center della banca. Le interfacce raggiungono il sistema centrale esclusivamente tramite un gateway API e il traffico tra i livelli viene controllato su un’infrastruttura gestita dalla banca. I dipendenti utilizzano strumenti di collaborazione SaaS nel rispetto delle stesse politiche relative all’identità e ai dati applicate ai sistemi interni.
Esempio 2: Soluzione ibrida edge per un produttore
Ogni stabilimento gestisce i sistemi di produzione a livello locale, in modo che le operazioni possano proseguire anche in caso di interruzione della rete WAN. I dati dei sensori vengono sintetizzati a livello periferico e inviati ai sistemi di analisi nel cloud. Le reti di tecnologia operativa sono segmentate rispetto all’infrastruttura IT aziendale, e l’accesso remoto da parte dei tecnici avviene tramite un sistema di accesso “zero trust” specifico per ciascuna applicazione, anziché tramite VPN.
Esempio 3: Continuità operativa per un sistema sanitario
I sistemi clinici sono in esecuzione nei data center del sistema sanitario, con un ambiente di ripristino nel cloud pubblico. I dati, le chiavi di crittografia e le politiche di sicurezza vengono replicati congiuntamente, e il failover viene testato a intervalli regolari, in modo che il sito di ripristino sia protetto allo stesso modo del sito primario.
Aspetti relativi alla sicurezza nell'architettura cloud ibrida
La sicurezza in un’architettura ibrida funziona quando viene progettata come un unico livello che abbraccia tutti gli ambienti, anziché come un insieme di controlli distinti per ciascuno di essi.
- L’identità al primo posto: un unico fornitore di identità, autenticazione a più fattori (MFA) resistente al phishing e governance per gli account di servizio e gli agenti di intelligenza artificiale.
- Un’unica politica, molteplici punti di applicazione: definite una volta per tutte le regole relative all’accesso, alle minacce e ai dati e applicatele nel data center, nelle filiali, nel cloud e sui dispositivi.
- Posizionamento deliberato dell’ispezione: stabilite dove decriptare il traffico per ciascun percorso. Si veda “Ispezione TLS locale vs. ispezione TLS su cloud”.
- Una protezione dei dati che segue i dati: classifichi una sola volta e applichi il DLP su Web, SaaS, applicazioni private, endpoint e strumenti di intelligenza artificiale. Consulti la sezione “DLP in ambienti cloud e on-premise”.
- Residenza e sovranità: è necessario sapere in quale Paese si trovano le ispezioni, i registri e le chiavi, nonché chi gestisce tale infrastruttura e chi può essere obbligato ad accedervi. Si veda la sezione “Sovranità dei dati nella sicurezza del cloud ibrido”.
- Chiarezza in materia di responsabilità condivisa: le dieci principali strategie di mitigazione dei rischi per la sicurezza nel cloud definite dalla NSA e dalla CISA includono una strategia specifica per la complessità degli ambienti ibridi e multi-cloud.
Skyhigh Hybrid SSE Mesh applica questo modello all’accesso degli utenti e alla protezione dei dati, con l’applicazione delle politiche sia in locale che nel cloud gestita da un’unica console e da un unico motore di politiche.
Come progettare un'architettura cloud ibrida
La progettazione di un'architettura cloud ibrida parte dai carichi di lavoro e dai dati, non dalle scelte relative all'infrastruttura.
- Effettuare un inventario dei carichi di lavoro e dei dati. Registrare le dipendenze di ciascuna applicazione, il livello di sensibilità dei dati, i requisiti di latenza e i vincoli normativi.
- Decidete la soluzione più adeguata in base al carico di lavoro. Scegliete tra soluzione on-premise, cloud privato, cloud pubblico, SaaS o edge in base a tale inventario.
- Selezionare i modelli. Adattare i carichi di lavoro a modelli quali “ibrido a più livelli”, “ibrido edge” o “continuità operativa”.
- Progettate la connettività e l’integrazione. Privilegiate modelli di rete a livelli e l’integrazione basata su API rispetto alla connettività a livello piatto.
- Unificare l’identità. Federare un unico provider di identità a ciascun ambiente prima di migrare i carichi di lavoro.
- Progettate un unico livello di sicurezza e di policy. Definite le policy una sola volta e pianificate i punti di applicazione per ogni ambiente. Consultate l’Architettura di riferimento per la sicurezza del cloud ibrido.
- Pianificare l’osservabilità. Centralizzare i log e le metriche nel rispetto delle norme sulla residenza dei dati.
- Prevedete eventuali guasti. Definite i siti di ripristino, le modalità di failover e i programmi di test. Si veda la sezione “Resilienza dell’SSE ibrido”.
- Eseguite la migrazione in fasi. Trasferite i carichi di lavoro in ondate, prevedendo piani di rollback, e dismettete i componenti legacy in modo graduale.
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
- Google Cloud. Modelli di architettura ibrida e multicloud, Cloud Architecture Center. https://docs.cloud.google.com/architecture/hybrid-multicloud-patterns-and-practices
- Google Cloud. Modelli di architettura di rete sicura in ambienti ibridi e multicloud, Cloud Architecture Center. https://docs.cloud.google.com/architecture/hybrid-multicloud-secure-networking-patterns
- Google Cloud. Realizzate architetture ibride e multicloud utilizzando Google Cloud e il Cloud Architecture Center. https://docs.cloud.google.com/architecture/hybrid-multicloud-patterns
- AWS. AWS Outposts. https://aws.amazon.com/outposts/
- Microsoft. Documentazione locale di Azure. https://learn.microsoft.com/en-us/azure/azure-local/
- Microsoft. Panoramica su Azure Arc. https://learn.microsoft.com/en-us/azure/azure-arc/overview
- NIST. SP 800-207: Architettura Zero Trust (agosto 2020). https://csrc.nist.gov/pubs/sp/800/207/final
- 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/