La sovranità dei dati nella sicurezza del cloud ibrido
- La sovranità dei dati nel cloud riguarda le leggi che disciplinano i dati e chi può accedervi, non solo la loro ubicazione.
- Gli strumenti di sicurezza comportano un rischio per la sovranità, poiché decriptano il traffico, copiano le prove ed esportano i registri.
- Chieda dove avvengono le ispezioni, quali dati vengono trasmessi, dove sono conservati i registri e chi può accedere ai dati decriptati.
- L'ispezione locale, la registrazione dei dati con identificazione della sede di residenza e le chiavi controllate dal cliente possono soddisfare i requisiti di sovranità; convalidare ogni percorso di elaborazione e di accesso.
- Il quadro normativo dell’UE sulla sovranità nel cloud e il regolamento DORA rendono la sovranità un requisito misurabile in materia di appalti e conformità.
La sovranità dei dati nella sicurezza del cloud ibrido consiste nel garantire che i dati sensibili, comprese le copie e i metadati generati dai controlli di sicurezza, vengano trattati, archiviati e consultati esclusivamente secondo modalità accettabili per l’organizzazione proprietaria e le autorità di regolamentazione di riferimento. In un ambiente ibrido, ciò richiede una scelta ponderata riguardo alle funzioni di sicurezza da eseguire localmente e a quelle che possono essere eseguite nel cloud di un fornitore.
Il presente articolo fa parte della guida alla sicurezza del cloud ibrido. Si tratta di informazioni di carattere generale e non costituisce una consulenza legale. Si raccomanda di verificare i requisiti con i propri team legali e di conformità.
Residenza dei dati, sovranità dei dati e localizzazione dei dati
La residenza dei dati indica il luogo in cui i dati vengono archiviati; la localizzazione dei dati è un requisito legale che impone di conservarli all’interno del Paese; la sovranità dei dati, invece, riguarda le leggi che li regolano e i soggetti autorizzati ad accedervi.
| Termine | Cosa significa | Domanda di esempio |
|---|---|---|
| Residenza dei dati | Dove vengono fisicamente archiviati i dati | Il nostro database dei clienti si trova in una regione dell’UE? |
| Localizzazione dei dati | L'obbligo di legge che imponga che determinati dati rimangano all'interno di un determinato paese | Questa categoria di dati deve necessariamente rimanere all’interno del Paese? |
| Sovranità dei dati | Quali leggi disciplinano i dati e chi può imporne l’accesso o ottenerlo | Un'autorità straniera o un dipendente del fornitore può accedervi? |
La localizzazione è necessaria ma non sufficiente. È comunque possibile che il personale del fornitore, da altre località, abbia accesso ai dati archiviati nella regione; che tali dati siano oggetto di richieste in base a leggi straniere; oppure che vengano copiati in registri e sistemi di supporto situati in altri paesi.
Perché gli strumenti di sicurezza comportano un rischio per la sovranità
Gli strumenti di sicurezza comportano un rischio per la sovranità poiché gestiscono i dati più sensibili di un’organizzazione, spesso in forma non crittografata, e li copiano nei registri e nelle prove.
I principali punti di esposizione sono:
- Ispezione. Un gateway di sicurezza ( secure web gateway ) decrittografa il traffico TLS per analizzarlo. In quel momento, le credenziali, i dati personali e i documenti riservati risultano in chiaro ovunque sia in esecuzione il gateway.
- Copie a fini probatori. I motori DLP possono archiviare copie o estratti dei contenuti che hanno attivato una politica, affinché possano essere esaminati dagli investigatori.
- Log e dati di telemetria. URL, nomi di file, identità degli utenti e dettagli sui dispositivi vengono trasmessi alle piattaforme di registrazione e analisi, spesso situate nella regione centrale di un fornitore.
- Analisi delle minacce. I file sospetti possono essere inviati a sandbox nel cloud per essere sottoposti a test di esecuzione.
- Accesso all'assistenza. I tecnici del fornitore potrebbero essere in grado di visualizzare i dati dei tenant durante la risoluzione dei problemi.
Un’architettura di sicurezza esclusivamente basata sul cloud può quindi trasferire i dati oltre i confini nazionali anche quando le applicazioni e i sistemi di archiviazione dell’organizzazione non lo fanno mai.
Le quattro questioni relative alla sovranità per qualsiasi architettura di sicurezza
Quattro domande definiscono l’approccio alla sovranità di qualsiasi architettura di sicurezza: dove avviene l’ispezione, cosa esce dall’ambiente, dove risiedono i registri e chi può accedere ai dati sensibili.
1. Dove si svolge l’ispezione?
Identifichi ogni punto in cui il traffico viene decrittografato: dispositivi locali, punti di presenza nel cloud, controlli del browser e agenti sugli endpoint. L’ispezione locale consente di mantenere la porzione di un flusso regolamentato, soggetta a controlli locali, all’interno dell’infrastruttura dell’organizzazione stessa. Valuti separatamente eventuali inoltri verso servizi cloud e l’ubicazione delle prove relative agli incidenti. Le linee guida della NSA sull’ispezione TLS raccomandano di effettuare un’unica ispezione, all’interno della rete aziendale, al fine di limitare i punti in cui è presente testo in chiaro.
2. Cosa viene rilasciato nell’ambiente?
Elenchi ciò che lo stack di sicurezza invia all’esterno della Sua infrastruttura: payload completi, campioni di file per il sandboxing, prove relative a incidenti DLP, metadati o esclusivamente aggiornamenti delle politiche. Ciascuno di questi elementi può essere gestito in modo diverso.
3. Dove si trovano i file di log?
I log sono dati. I log di accesso associano le identità alle attività, mentre i log DLP possono contenere i contenuti sensibili stessi. Si deve decidere quali log possano uscire da quale giurisdizione e se i log possano essere archiviati localmente e inoltrati in modo selettivo a un sistema SIEM centrale.
4. Chi può accedere ai dati sensibili?
Identifichi chi può visualizzare i contenuti decriptati o le prove relative agli incidenti: i Suoi amministratori, il Suo fornitore di servizi gestiti, il personale di assistenza del fornitore di soluzioni di sicurezza o il fornitore di servizi cloud. Valuti quindi quali regimi giuridici potrebbero obbligare uno qualsiasi di essi a divulgarli. Il CLOUD Act statunitense, ad esempio, chiarisce che le autorità statunitensi possono richiedere ai fornitori con sede negli Stati Uniti di produrre i dati in loro possesso o sotto il loro controllo, indipendentemente dal luogo in cui sono archiviati.
Fattori normativi e relativi agli appalti
Le norme sul trasferimento dei dati previste dal GDPR, il quadro normativo dell’UE sulla sovranità nel cloud, il DORA e le normative settoriali stanno trasformando la sovranità da una semplice preferenza a un requisito imprescindibile.
Norme del GDPR in materia di trasferimenti. Ai sensi del capo V del GDPR, i trasferimenti di dati personali al di fuori dello Spazio economico europeo richiedono una decisione di adeguatezza, garanzie adeguate quali le clausole contrattuali tipo o una deroga specifica. La telemetria di sicurezza che include dati personali è soggetta alle stesse norme.
Quadro di riferimento dell’UE sulla sovranità nel cloud. Il quadro di riferimento della Commissione europea sulla sovranità nel cloud, presentato per la prima volta nell’ottobre 2025, valuta i fornitori di servizi cloud in base a otto obiettivi: strategici, giuridici e giurisdizionali, relativi ai dati e all’intelligenza artificiale, operativi, relativi alla catena di approvvigionamento, tecnologici, relativi alla sicurezza e alla conformità, nonché alla sostenibilità ambientale. Ai fornitori viene assegnato un «Livello di Garanzia dell’Efficacia della Sovranità» (SEAL) compreso tra 0 e 4. Nell’aprile 2026, la Commissione ha aggiudicato a quattro fornitori un contratto relativo al cloud sovrano del valore massimo di 180 milioni di euro, richiedendo come requisito minimo il SEAL-2, ovvero il livello di sovranità dei dati. Il quadro è stato elaborato per le istituzioni dell’UE, ma fornisce a ogni acquirente un vocabolario pratico relativo ai requisiti di sovranità.
DORA per gli enti finanziari. Il Digital Operational Resilience Act è in vigore dal 17 gennaio 2025. Esso impone agli enti finanziari soggetti alla normativa di gestire i rischi legati alle tecnologie dell’informazione e della comunicazione (TIC) derivanti da soggetti terzi, di tenere un registro degli accordi relativi ai servizi TIC e di predisporre piani per far fronte ai rischi di uscita e di concentrazione. I servizi di sicurezza che elaborano il traffico di una banca sono considerati servizi TIC ai sensi di tale normativa.
Normative settoriali e nazionali. Le organizzazioni operanti nei settori della sanità, della difesa, del settore pubblico e delle infrastrutture critiche devono spesso far fronte a ulteriori requisiti in materia di localizzazione o accreditamento.
Architettura cloud ibrida per il settore bancario
Le banche, in genere, conservano i dati relativi alla decrittografia e i registri sulla propria infrastruttura, mentre ricorrono a servizi cloud con restrizioni regionali per il personale che lavora da remoto e per le soluzioni SaaS.
Le banche illustrano chiaramente il problema della sovranità. Da un lato necessitano di soluzioni SaaS basate sul cloud e del lavoro da remoto, ma dall’altro conservano i dati finanziari dei clienti nel rispetto di rigorosi requisiti di vigilanza. Un modello ibrido tipico:
- Si raccomanda di mantenere i flussi regolamentati tra le filiali e la sede centrale nell’ambito delle misure di applicazione controllate dalla banca qualora sia richiesta l’elaborazione a livello locale, e di valutare separatamente eventuali servizi applicati nel cloud e l’archiviazione delle prove.
- Per il personale che lavora da remoto, si prega di utilizzare punti di presenza cloud limitati alle regioni approvate.
- Conservare i registri delle ispezioni dei punti vendita e le prove relative al DLP all’interno del Paese, inoltrando esclusivamente quanto richiesto dal SOC.
- Utilizzi chiavi gestite dal cliente e moduli di sicurezza hardware per l’autorità di certificazione di controllo.
- Si raccomanda di mantenere un unico insieme di criteri, in modo che l’applicazione delle politiche a livello locale e nel cloud risulti coerente agli occhi dei revisori.
- Si prega di inserire i dati del fornitore di servizi di sicurezza nel registro delle informazioni DORA, compresa la pianificazione dell’uscita.
Lo stesso schema si applica alle compagnie assicurative, agli istituti di pagamento e alle società di investimento.
Modelli architetturali a sostegno della sovranità
Sette modelli architetturali consentono di soddisfare la maggior parte dei requisiti di sovranità senza rinunciare ai servizi cloud.
| Modello | Di cosa tratta |
|---|---|
| Ispezione di sicurezza locale | I payload web decriptati rimangono nella vostra infrastruttura; il traffico inoltrato ai servizi applicati nel cloud non vi rimane |
| Punti di presenza regionali o nazionali | Ispezione del cloud limitata alle giurisdizioni autorizzate |
| Registrazione dei dati con considerazione della residenza | Log memorizzati localmente; inoltro selettivo |
| Chiavi gestite dal cliente e integrazione con HSM | Controllo dei certificati di ispezione e della crittografia |
| Indirizzi IP di uscita dedicati | Il traffico proviene da indirizzi di proprietà dell’organizzazione, in conformità con i requisiti in materia di giurisdizione e reputazione IP |
| Sandboxing in locale | File sospetti analizzati senza uscire dall'ambiente |
| Motore unico per le polizze | Trattamento coerente dei dati indipendentemente dal punto di applicazione |
Lista di controllo sulla sovranità per i fornitori di soluzioni di sicurezza
Utilizzi questa lista di controllo per verificare le dichiarazioni di sovranità di qualsiasi fornitore di soluzioni di sicurezza prima di procedere alla selezione dei candidati.
- È possibile eseguire tutte le ispezioni relative a una determinata classe di traffico sulla nostra infrastruttura?
- Quali elementi di dati vengono trasmessi di default dal nostro sistema e se è possibile disattivarli singolarmente?
- In quali paesi vengono conservati i registri, le prove e i dati telemetrici?
- Quali membri del personale del fornitore possono accedere ai dati dei clienti, da dove e previa quale autorizzazione?
- Quali leggi nazionali si applicano al fornitore e ai suoi sub-responsabili del trattamento?
- È possibile utilizzare il proprio HSM o il proprio sistema di gestione delle chiavi?
- Cosa continua a funzionare se il cloud del fornitore risulta irraggiungibile?
- Quali certificazioni sono applicabili (ad esempio FedRAMP, IRAP, BSI C5, SOC 2 Tipo II, CSA STAR)?
In che modo Skyhigh sostiene la sovranità dei dati
Skyhigh sostiene la sovranità dei dati mantenendo l’ispezione web e le chiavi di ispezione sull’infrastruttura del cliente, ove richiesto. Le prove relative agli incidenti di protezione dei dati sono conservate nel cloud di Skyhigh; si tratta di una questione distinta, da valutare alla luce dei Suoi requisiti in materia di sovranità.
Skyhigh Hybrid SSE Mesh mantiene il piano dati fisicamente in loco, laddove richiesto dalla normativa. La decrittografia SSL/TLS e l’ispezione web vengono eseguite localmente sul Secure Service Gateway, pertanto i payload web vengono decrittografati all’interno della vostra infrastruttura. I servizi applicati tramite il cloud Skyhigh, tra cui la protezione dei dati, l’ remote browser isolation, i controlli di sicurezza basati sull’intelligenza artificiale (AI), il CASB e la gestione dello stato di sicurezza dei dati, ricevono il traffico pertinente dal gateway; pertanto, vi invitiamo a valutare tali flussi alla luce dei vostri requisiti di residenza e sovranità. Lo ZTNA locale viene eseguito sui gateway dell’organizzazione stessa. Verifichi la protezione delle chiavi di ispezione, l’eventuale integrazione con HSM e il supporto per il sandboxing in loco per i prodotti e le versioni selezionati. L’IP di uscita dedicato e l’ancoraggio dell’IP di origine aiutano a controllare l’uscita del traffico ispezionato nel cloud, ma da soli non stabiliscono dove vengono elaborati i contenuti (Skyhigh Security). Il registro cloud della piattaforma valuta inoltre i servizi cloud in base alla residenza dei dati, ai termini legali e ad altri attributi, in modo che la politica possa indirizzare gli utenti verso servizi conformi.
Fonti
- Unione europea. Regolamento (UE) 2016/679 (Regolamento generale sulla protezione dei dati), Capitolo V. https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Unione europea. Regolamento (UE) 2022/2554 (Legge sulla resilienza operativa digitale). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Commissione europea. “Spiegazione del quadro normativo sul cloud sovrano” (1° giugno 2026). https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
- Commissione europea. «La Commissione promuove la sovranità nel settore del cloud attraverso appalti strategici» (17 aprile 2026). https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en
- Dipartimento di Giustizia degli Stati Uniti. Risorse relative al CLOUD Act. https://www.justice.gov/criminal/cloud-act-resources
- 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
- 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
- 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