Architettura di riferimento per la sicurezza del cloud ibrido

Un’architettura di riferimento per la sicurezza del cloud ibrido è un modello indipendente dal fornitore che illustra come i controlli di sicurezza si integrino tra l’infrastruttura on-premise, il cloud privato, il SaaS e il cloud pubblico. Viene utilizzata per pianificare le implementazioni, confrontare i fornitori, illustrare la progettazione della sicurezza ai revisori e misurare i progressi compiuti verso l’adozione del modello Zero Trust.

Il presente articolo fornisce un modello di riferimento completo: i principi di progettazione alla base dello stesso, i diagrammi logici e di implementazione, un elenco dei componenti, sei flussi di traffico, i confini di controllo, le considerazioni progettuali relative all’identità, alla registrazione, alla capacità e alla resilienza, una mappatura rispetto ai controlli CISA e NIST, cinque esempi di implementazione e un percorso di maturità con test di convalida.

Il presente articolo fa parte della guida alla sicurezza del cloud ibrido. Per una panoramica generale sull’infrastruttura degli ambienti ibridi, si veda “Architettura del cloud ibrido: componenti e modelli di implementazione”.

Principi di progettazione alla base del modello di riferimento

Il modello di riferimento si basa su quattro principi tratti dalle linee guida "zero trust" del NIST e della CISA.

1. Distinguere le decisioni dall’applicazione delle politiche. Il documento NIST SP 800-207 distingue il punto di decisione sulle politiche (PDP), che stabilisce se l’accesso sia consentito, dal punto di applicazione delle politiche (PEP), che abilita, monitora o interrompe la connessione. Un unico PDP, più PEP.
2. Non si deve concedere fiducia sulla base della posizione di rete. Il fatto di trovarsi sulla LAN aziendale non costituisce un motivo valido per tralasciare l’autenticazione o il controllo. Il documento NIST SP 800-215 descrive la scomparsa di un perimetro significativo come una caratteristica distintiva delle reti aziendali odierne.
3. Proteggete i dati in base alla classificazione, non alla posizione. I controlli seguono la classe di dati ovunque essa si sposti.
4. Si ipotizzi che qualsiasi singola dipendenza possa subire un’interruzione. I provider di identità, i servizi cloud e i collegamenti WAN smettono tutti di funzionare. L’architettura definisce cosa accade in tali circostanze.

La guida pratica SP 1800-35 del NIST , intitolata “Implementazione di un’architettura Zero Trust”, pubblicata nel giugno 2025 in collaborazione con 24 fornitori, illustra 19 esempi di implementazione di tali principi in ambienti sia on-premise che cloud e costituisce un utile complemento al presente modello.

Schemi architettonici

L'architettura di riferimento è descritta da due prospettive: una prospettiva logica dei suoi livelli e una prospettiva di implementazione relativa alla posizione in cui vengono eseguiti i componenti.

Architettura logica

L'architettura logica si articola su tre livelli: un livello di controllo centralizzato, un livello di applicazione distribuito e un livello di visibilità condiviso.

Il piano di controllo definisce la politica una sola volta. Il piano di applicazione la applica ovunque fluisca il traffico. Il piano di visibilità raccoglie i dati di telemetria da ogni punto di applicazione e reimmette i segnali di rischio nella politica.

Topologia di implementazione

La vista di distribuzione mostra dove è fisicamente in esecuzione ciascun punto di applicazione all’interno della sede centrale, delle filiali, delle regioni cloud e presso gli utenti remoti.

Riferimento ai componenti

Ogni componente ha un ruolo, una collocazione e una serie di requisiti specifici per i sistemi ibridi ben definiti.

Flussi di traffico

Sei flussi di traffico coprono la maggior parte delle infrastrutture ibride e ciascuno di essi dovrebbe disporre di un punto di applicazione documentato e di un punto di decodifica.

Flusso 1: Utente in ufficio che accede a Internet o a un servizio SaaS

L’utente effettua l’autenticazione tramite il provider di identità. Il traffico viene indirizzato al gateway locale, il quale lo decrittografa, lo sottopone a controllo per individuare eventuali minacce e applica le politiche relative al web e all’accesso; successivamente, inoltra le sessioni soggette a protezione dei dati al cloud del fornitore affinché vengano sottoposte a controllo in base alle stesse politiche. Si raccomanda di documentare la terminazione TLS e la ricrittografia lungo l’intero percorso ed evitare controlli ridondanti, in linea con le linee guida della NSA sulla gestione del rischio legato all’ispezione TLS.

Flusso 2: Utente remoto verso SaaS

L'agente endpoint o i controlli del browser indirizzano il traffico verso il punto di presenza cloud autorizzato più vicino. Si applica lo stesso insieme di criteri previsto nel Flusso 1. Il CASB aggiunge controlli specifici per il SaaS, quali le restrizioni relative ai tenant e il DLP a livello di attività.

Flusso 3: Dall’utente all’applicazione privata

L'accesso avviene tramite ZTNA, non tramite una VPN a livello di rete. Il servizio di accesso verifica l'identità, lo stato di sicurezza del dispositivo e la conformità alle politiche, quindi connette l'utente esclusivamente a un'applicazione autorizzata. Un'implementazione può avvalersi di un broker cloud per gli utenti remoti e di un gateway locale per le sessioni in loco supportate. Si prega di verificare la posizione del broker, i protocolli delle applicazioni, la visibilità delle sessioni e il percorso effettivo dei dati. Si veda " ZTNA on-premise per applicazioni private".

Flusso 4: Da carico di lavoro a carico di lavoro

Il traffico da servizio a servizio tra il data center e i carichi di lavoro IaaS utilizza l’identità del carico di lavoro, il protocollo TLS reciproco e le regole di segmentazione. La stessa fonte della politica definisce quali servizi possono comunicare tra loro.

Flusso 5: Dati inattivi nei servizi cloud

L'integrazione dell'API CASB e la scansione DSPM analizzano i servizi di archiviazione cloud e SaaS autorizzati alla ricerca di dati sensibili, condivisioni a rischio e autorizzazioni eccessive, per poi correggere tali criticità utilizzando la stessa classificazione applicata in tempo reale. Scoprite come DSPM e SSE operano in sinergia.

Flusso 6: Agenti IA e account di servizio

Gli agenti di intelligenza artificiale e i sistemi di automazione dispongono spesso di diritti di accesso a livello utente e richiamano API interne tramite connessioni di lunga durata, tra cui i WebSocket, che hanno origine all’interno della rete. Assegnate a ciascun agente una propria identità e autorizzazioni specifiche per ogni applicazione, instradate il suo traffico attraverso un punto di controllo locale e applicate il DLP a ciò che invia ai servizi di intelligenza artificiale esterni.

Limiti di controllo

I confini di controllo dovrebbero essere definiti in base a ciò che deve essere protetto, non in base alla posizione delle apparecchiature.

Il confine giurisdizionale viene spesso trascurato. Se il traffico decriptato, i registri di ispezione o le copie degli incidenti DLP escono dal territorio giurisdizionale, l’architettura potrebbe violare gli impegni in materia di residenza dei dati anche se i dati archiviati non vengono mai trasferiti. Si veda la sezione “Sovranità dei dati nella sicurezza del cloud ibrido”.

Sicurezza di rete per il cloud ibrido

La sicurezza di rete in un ambiente ibrido si sposta dalla protezione del perimetro alla protezione delle singole connessioni.

• Sostituire la fiducia diretta tra siti con la segmentazione e l’accesso per singola applicazione.
• Mantenete i tunnel crittografati (IPsec, GRE o interconnessioni private) tra i siti e le regioni cloud, ma non considerate l’appartenenza a un tunnel come un’autorizzazione.
• Indirizzate il traffico in modo mirato: proxy espliciti o file PAC per le reti aziendali gestite, agenti o controlli del browser per gli utenti in roaming, tunnel per le filiali.
• Stabilisca quale componente si occupi della decrittografia di ciascun flusso, in modo che nessun flusso venga decrittografato due volte.
• Registrare i dati in ogni punto di controllo e effettuare la correlazione a livello centrale.

Il documento NIST SP 800-215 esamina tali opzioni, tra cui lo ZTNA, la microsegmentazione, i perimetri definiti dal software e i modelli SASE (Secure Access Service Edge) che combinano servizi di rete e di sicurezza.

Considerazioni progettuali

Sono quattro gli aspetti progettuali che determinano se l’architettura funzioni nella pratica: identità, registrazione, capacità e comportamento in caso di guasto.

Architettura dell'identità

L’identità costituisce il primo elemento su cui si basa ogni decisione relativa all’accesso; pertanto, l’architettura di riferimento considera quattro tipi di identità come elementi di primaria importanza.

• Utenti aziendali. Un unico provider di identità autorevole, federato con ogni provider cloud e ogni applicazione SaaS, dotato di autenticazione a più fattori (MFA) resistente al phishing e di accesso condizionale. I dati relativi ai gruppi e ai ruoli dovrebbero provenire da un’unica fonte, in modo che i diritti di accesso non presentino discrepanze tra i diversi ambienti.
• Dispositivi. È necessario valutare l’identità e lo stato di sicurezza dei dispositivi (stato di gestione, livello delle patch, crittografia del disco, protezione degli endpoint) sia per gli utenti in sede che per quelli remoti.
• Carichi di lavoro e servizi. Le applicazioni e i servizi si autenticano reciprocamente tramite le identità dei carichi di lavoro e il protocollo TLS reciproco, anziché tramite segreti condivisi o posizione di rete.
• Agenti di intelligenza artificiale e automazione. Ciascun agente riceve una propria identità, diritti definiti in base a un ambito specifico e un responsabile umano, in modo che le sue azioni possano essere autorizzate, registrate e revocate in modo indipendente.

Vi sono due dettagli di progettazione che è facile trascurare. In primo luogo, le sessioni dovrebbero essere rivalutate quando il contesto cambia, ad esempio nel caso in cui un dispositivo non sia più conforme, anziché essere considerate affidabili fino alla loro scadenza. In secondo luogo, occorre definire un accesso di emergenza per gli amministratori che funzioni quando il provider di identità non è disponibile, con controlli rigorosi e avvisi relativi al suo utilizzo.

Registrazione e telemetria

La registrazione dei log in un’architettura ibrida deve supportare le attività di rilevamento, indagine e conformità, nel rispetto delle restrizioni relative alla destinazione dei dati.

• Cosa registrare. Ogni punto di applicazione delle politiche dovrebbe registrare l’utente, il dispositivo, l’applicazione o la destinazione, la decisione relativa alla politica, la regola a cui si è fatto riferimento e la classificazione dei dati in questione. Si raccomanda di utilizzare chiavi di correlazione comuni (ID utente, ID dispositivo, ID sessione) in modo da poter associare gli eventi provenienti dall’applicazione locale e da quella nel cloud.
• Dove raccoglierli. I raccoglitori locali presenti in ciascuna sede principale memorizzano innanzitutto gli eventi, per poi inoltrarli al SIEM centrale. Ciò garantisce la conservazione dei log in caso di interruzioni della rete WAN e consente l’inoltro selettivo.
• Cosa inoltrare. Inoltrare i metadati necessari ai fini dell’individuazione. Conservare le prove DLP complete e gli estratti dei contenuti nella giurisdizione in cui sono stati acquisiti, limitandone l’accesso agli investigatori autorizzati.
• Conservazione. Allineare la politica di conservazione ai requisiti normativi in base alla classe di dati e alla giurisdizione, e documentarla.
• Integrità. Proteggere i log da eventuali manomissioni e segnalare eventuali lacune, che possono indicare sia malfunzionamenti che attacchi.

Capacità e dimensionamento

I punti di applicazione locali devono essere dimensionati in base al traffico decriptato nei momenti di picco, che rappresenta la causa più comune di problemi di prestazioni nelle implementazioni ibride.

• Misuri il throughput di picco e le velocità di connessione per ogni sito, nonché la percentuale di traffico che verrà decrittografata. La decrittografia TLS richiede un'elevata potenza di calcolo.
• Dimensionate i cluster lasciando un margine di sicurezza per il failover, in modo che la perdita di un nodo non sovraccarichi gli altri.
• Si tenga conto dell’aumento del traffico crittografato, dei trasferimenti di file di grandi dimensioni e delle sessioni di intelligenza artificiale e collaborazione di lunga durata.
• Pianifichi in che modo aumentare la capacità. Gli appliance virtuali e containerizzati consentono una scalabilità più rapida rispetto all’hardware dedicato.
• Per quanto riguarda i punti di presenza nel cloud, verifichi con il fornitore la capacità regionale e le opzioni di failover, in particolare nei casi in cui i requisiti di residenza limitino le regioni che è possibile utilizzare.

Resilienza e comportamento in caso di guasto

Un’architettura di riferimento è incompleta finché non definisce cosa accade quando ciascuna dipendenza non funziona correttamente.

• Cloud del fornitore non disponibile: l’applicazione locale delle politiche relative al web e alle applicazioni private prosegue utilizzando le politiche memorizzate nella cache, mentre i servizi forniti dal cloud, tra cui la protezione dei dati, remote browser isolation, i controlli di sicurezza basati sull’intelligenza artificiale (AI), il CASB e la gestione dello stato di sicurezza dei dati, non vengono applicati fino al ripristino del percorso; gli utenti remoti vengono reindirizzati verso altri punti di presenza.
• Provider di identità non disponibile: si definisca se le sessioni esistenti debbano proseguire e se esista un’alternativa locale.
• In caso di interruzione della connessione WAN o di Internet: lo ZTNA locale garantisce il funzionamento dell’accesso in sede alle applicazioni locali.
• Errore del gateway locale: un nodo del cluster o un punto di presenza nel cloud subentra in base alla stessa politica.
• Fail-open o fail-closed: decidere in base alla classe di traffico e rendere lo stato visibile al personale operativo.

Per un piano di test, si veda “Resilienza dell’SSE ibrido: failover e ripristino ”.

Mappatura dei controlli secondo i standard CISA e NIST

L'assegnazione di ciascun componente a framework riconosciuti trasforma l'architettura di riferimento in un elemento probatorio per i revisori e in una lista di controllo per i responsabili dell'implementazione.

La tabella mette in corrispondenza i componenti con i pilastri del Modello di maturità Zero Trust della CISA e con le famiglie di controlli rappresentative contenute nella norma NIST SP 800-53 Rev. 5.

La presente mappatura costituisce un punto di partenza. Ciascuna organizzazione dovrebbe verificare l’applicabilità dei controlli in relazione al proprio quadro di riferimento e al proprio ambito normativo.

Esempi di implementazione

Lo stesso modello di riferimento si adatta ai diversi settori spostando i punti di applicazione, non ridefinendo la politica.

Esempio 1: Banca regionale

La sede centrale e i data center utilizzano gateway SWG e ZTNA locali, in modo che i dati dei clienti vengano decriptati e ispezionati esclusivamente su infrastrutture controllate dalla banca. Il traffico delle filiali utilizza dispositivi locali o tunnel verso il data center più vicino. Il personale remoto utilizza punti di presenza cloud limitati a località all’interno della stessa regione. I registri delle ispezioni rimangono all’interno del Paese. Questo modello soddisfa i requisiti DORA in materia di rischio ICT e quelli relativi alle terze parti per le istituzioni dell’UE, consentendo al contempo l’utilizzo di CASB cloud per i servizi SaaS.

Esempio 2: Azienda produttrice con reti OT

Un firewall di segmentazione separa le reti OT dello stabilimento dall’infrastruttura IT aziendale. I sistemi OT raggiungono solo destinazioni approvate per gli aggiornamenti e la telemetria tramite uno SWG locale. Gli ingegneri accedono ai sistemi dello stabilimento tramite uno ZTNA locale con controlli sullo stato di sicurezza dei dispositivi. In caso di guasto della rete WAN o di un servizio cloud, l’accesso allo stabilimento e le operazioni di ispezione proseguono a livello locale.

Esempio 3: Ente pubblico

Le reti classificate o disconnesse richiedono componenti espressamente supportati per il funzionamento senza servizi esterni. Le reti non classificate possono avvalersi di servizi cloud debitamente autorizzati per i lavoratori da remoto. Si raccomanda di documentare la sincronizzazione delle politiche, le identità, gli aggiornamenti e le dipendenze relative alle licenze, nonché di sottoporre le eccezioni specifiche dell’ambiente al controllo delle modifiche.

Esempio 4: Sistema sanitario regionale

La cartella clinica elettronica e i sistemi di imaging operano nei data center del sistema sanitario. Le postazioni cliniche negli ospedali utilizzano gateway locali, pertanto i dati dei pazienti presenti nel traffico web e SaaS vengono ispezionati in loco. I dispositivi medici si trovano in zone segmentate con accesso in uscita rigorosamente limitato. I medici che lavorano da remoto accedono alla cartella clinica elettronica tramite il broker ZTNA nel cloud, con requisiti relativi ai dispositivi gestiti; le regole DLP per le informazioni sanitarie protette si applicano in modo identico in entrambi i percorsi, a sostegno delle misure di sicurezza previste dalla norma HIPAA.

Esempio 5: Catena di negozi a livello mondiale

I punti vendita utilizzano piccoli gateway di filiale o tunnel verso gli hub regionali, con sistemi POS inseriti in un ambiente segmentato per i dati dei titolari di carte che raggiunge esclusivamente i gestori dei pagamenti. La navigazione del personale aziendale e dei punti vendita viene monitorata presso gli hub regionali o i punti di presenza nel cloud, con il traffico europeo limitato alle regioni dell’UE e i registri archiviati all’interno della regione. I sistemi dei punti vendita continuano a funzionare durante le interruzioni della rete WAN poiché la segmentazione locale e le regole di accesso non dipendono dal cloud. Ciò soddisfa i requisiti di segmentazione e registrazione previsti dallo standard PCI DSS.

Percorso di maturazione e convalida

Si raccomanda di avvalersi delle fasi di maturità definite dalla CISA per articolare l’implementazione in fasi e di ricorrere a test ripetibili per verificare il corretto funzionamento di ciascuna fase.

Percorso di maturazione

Le organizzazioni raramente implementano l’architettura di riferimento nella sua interezza in un’unica soluzione; il modello della CISA descrive quattro fasi (Tradizionale, Iniziale, Avanzata e Ottimale) che costituiscono una utile tabella di marcia.

Utilizzi il divario tra la fase attuale e quella successiva come base per un piano articolato in fasi.

Verifica dell'architettura

La qualità di un’architettura dipende dal suo comportamento verificato; pertanto, convalidi ogni flusso e ogni confine mediante test ripetibili.

• Inviare un URL notoriamente dannoso, un file di malware di prova e un documento di prova DLP attraverso ogni punto di applicazione e verificare che i risultati siano identici utilizzando il percorso cloud disponibile. Registrare il comportamento previsto dei controlli applicati nel cloud nel caso in cui tale percorso venga interrotto.
• Si assicuri che ogni flusso venga decrittografato esattamente una sola volta.
• Tentare di accedere a un’applicazione privata da un dispositivo in loco, da remoto e da un dispositivo non gestito, e verificare che i risultati siano quelli previsti.
• Blocchi l'accesso da un sito al cloud del fornitore e si assicuri che le misure di sicurezza locali continuino ad essere applicate.
• Si verifichi che i log provenienti da ogni punto di applicazione raggiungano il SIEM e che le regole di residenza siano rispettate.

In che modo Skyhigh si allinea all’architettura di riferimento

Skyhigh Hybrid SSE Mesh copre il piano di controllo (una console e un motore di policy con le policy implementate come codice), l’applicazione locale (dispositivi SWG on-premise con ispezione TLS locale e ZTNA locale), l’applicazione nel cloud (SWG, CASB, ZTNA e RBI nel cloud), i controlli a livello di browser e il DSPM (Skyhigh Security).

Per la protezione delle chiavi di ispezione e lo sandboxing in locale, si prega di verificare con Skyhigh le integrazioni supportate, le versioni dei prodotti e i requisiti di implementazione. Non si deve dare per scontato il supporto HSM per il gateway o il servizio prescelto.

Fonti

1. NIST. SP 800-207: Architettura Zero Trust (agosto 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST. SP 800-215: Guida alla sicurezza dell’infrastruttura di rete aziendale (novembre 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE. SP 1800-35: Implementazione di un’architettura Zero Trust (giugno 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
4. NIST. SP 800-53 Rev. 5: Misure di sicurezza e di tutela della privacy per i sistemi informativi e le organizzazioni. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA. Modello di maturità Zero Trust, versione 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA. Gestione dei rischi derivanti dall’ispezione del protocollo TLS (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. Unione europea. Regolamento (UE) 2022/2554 (Legge sulla resilienza operativa digitale). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. Dipartimento della Salute e dei Servizi Umani degli Stati Uniti (HHS) . Norma di sicurezza HIPAA. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. PCI Security Standards Council. PCI DSS v4.0.1 (archivio documenti). https://www.pcisecuritystandards.org/document_library/
10. Skyhigh Security. “Modernizzazione dell’ Secure Web Gateway Symantec Edge con Skyhigh Hybrid SSE Mesh” (15 luglio 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
11. Skyhigh Security. “L’adozione dell’ibrido è diventata più semplice grazie alla piattaforma Skyhigh SSE” (3 ottobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html