Oggi qualsiasi organizzazione impegnata nella selezione di tecnologie di sicurezza pone ai fornitori una domanda apparentemente semplice: la vostra piattaforma SASE supporta la sovranità dei dati? La risposta è quasi sempre la stessa: “sì”.
Il problema è che questa risposta, da sola, dice molto poco. I team di procurement spuntano una casella nei requisiti, ma qualche mese dopo, durante l’implementazione, emerge inevitabilmente una domanda più complessa: dove vengono realmente elaborati, archiviati e gestiti i miei dati e i relativi metadati?
La realtà è che il concetto di “Sovereign SASE” non corrisponde a una funzionalità specifica né a una certificazione universalmente riconosciuta. È, invece, un termine utilizzato per descrivere un insieme di capacità molto diverse tra loro, alcune realmente complete, altre decisamente più limitate.
Stabilire se una piattaforma soddisfi o meno i requisiti di sovranità di un’organizzazione dipende da esigenze precise e da aspetti architetturali che raramente emergono durante il processo di vendita.
Indice degli argomenti
La sovranità non riguarda solo dove sono conservati i dati
Quando si parla di residenza dei dati, la maggior parte delle organizzazioni si concentra su una sola domanda: dove vengono archiviati i dati? È certamente un aspetto importante, ma rappresenta soltanto una parte del problema.
In un contesto SASE, la sovranità si articola infatti in quattro dimensioni fondamentali:
- Trasporto di rete: il traffico rimane all’interno del Paese o attraversa infrastrutture internazionali?
- Elaborazione dei dati: le attività di ispezione, analisi e applicazione delle policy vengono eseguite localmente?
- Archiviazione locale: log, dati degli utenti ed eventi di sicurezza rimangono all’interno della giurisdizione richiesta?
- Governance dei metadati: le informazioni generate dai processi di sicurezza e monitoraggio restano anch’esse entro i confini nazionali?
È proprio quest’ultimo punto a rappresentare spesso la principale area grigia. Molti fornitori possono affermare correttamente che il traffico viene elaborato e che i log vengono conservati localmente.
Tuttavia, i metadati prodotti dalle attività di sicurezza vengono spesso trasferiti verso piattaforme globali condivise, al di fuori della giurisdizione richiesta.
Dal punto di vista tecnico, le dichiarazioni del vendor possono risultare corrette; dal punto di vista della sovranità, però, il quadro è ben diverso.
Il nodo critico: management plane e control plane
Le moderne architetture SASE si basano generalmente su diversi livelli infrastrutturali.
Da una parte troviamo i data plane, responsabili dell’ispezione del traffico, dell’applicazione delle policy e dell’instradamento delle connessioni. Dall’altra troviamo i management plane, che gestiscono amministrazione, configurazione, identità e funzioni operative.
Spesso i data plane sono distribuiti localmente. I management plane, invece, non sempre lo sono.
Ed è proprio all’interno di questi livelli che vengono eseguite molte delle attività che generano metadati sensibili, come la correlazione delle minacce, l’analisi avanzata dei contenuti o l’elaborazione post-evento.
Di conseguenza, il fatto che un fornitore disponga di un data center nel Paese non significa automaticamente che tutte le componenti della piattaforma siano soggette agli stessi requisiti di sovranità.
Per questo motivo, le organizzazioni dovrebbero richiedere una visione completa dell’architettura e comprendere con precisione dove vengono eseguite le diverse funzioni.
La sovranità digitale è multidimensionale
Anche Gartner interpreta la sovranità digitale come un concetto articolato su tre livelli distinti:
- Data sovereignty, relativa a dove i dati vengono trasportati, elaborati e archiviati.
- Operational sovereignty, che riguarda chi può accedere all’ambiente e con quali autorizzazioni, inclusi eventuali operatori del fornitore.
- Technological sovereignty ovvero il grado di controllo esercitato dall’organizzazione sull’infrastruttura sottostante, sulla crittografia e sulle modalità di deployment.
Un fornitore può soddisfare alcuni requisiti di sovranità dei dati e risultare invece carente sul piano operativo o tecnologico.
Potrebbe non offrire personale autorizzato a livello locale, non supportare la gestione diretta delle chiavi di cifratura da parte del cliente oppure non consentire implementazioni on-premises.
Ogni lacuna rappresenta un rischio diverso a seconda del contesto normativo e delle esigenze dell’organizzazione.
Per questo motivo la domanda corretta non è: “Supportate il Sovereign SASE?”. La vera domanda è: “Quali aspetti della sovranità coprite, a quale livello dell’architettura e con quali evidenze concrete?”.
Oltre gli slogan: serve trasparenza
La sovranità nel SASE non è una condizione binaria. Non esiste semplicemente un “sì” o un “no”.
Esiste piuttosto uno spettro di capacità, controlli e garanzie che devono essere valutati nel loro insieme.
Le organizzazioni che affrontano oggi sfide legate a conformità, protezione dei dati e resilienza digitale hanno bisogno di molto più di una dichiarazione commerciale.
Hanno bisogno di trasparenza architetturale, verificabilità e chiarezza operativa.
In definitiva, il partner giusto non è quello che promette genericamente la sovranità, ma quello che è in grado di dimostrare, con fatti e prove concrete, dove si colloca lungo ciascuna delle sue dimensioni.
Partecipa alla community