Analisi tecnica

Perché il PSN non garantisce la sovranità digitale

La cifratura e il confidential computing sono misure di sicurezza reali e utili. Sono anche, da sole, incapaci di produrre sovranità su un cloud controllato da un'altra giurisdizione — e l'agenzia francese per la cybersicurezza lo mette per iscritto.

Ogni affermazione qui sopra è documentata più avanti, con il rimando alla fonte primaria e, dove la fonte è un file, una copia archiviata. Chi vuole controllare invece di credere cominci da come verificare questa analisi.

La difesa più forte del programma, e perché non regge

Messo di fronte alla questione della sovranità, il programma cloud pubblico italiano risponde con due misure tecniche, e sono quelle che mette avanti per prime. Vale la pena enunciarle nella loro versione più forte, perché entrambe sono reali.

Fonte: Manuale Utente Secure Public Cloud Azure, ed. 04/04/2025 (PDF, 64 pp.) · pagina servizi con Cloud Service Provider

Prese insieme, queste due sarebbero una risposta seria: le chiavi sono fuori dalle mani del fornitore, e il dato è illeggibile perfino mentre viene elaborato. Se reggesse, la questione giurisdizionale si dissolverebbe in larga parte.

Le ragioni tecniche che stanno dietro a queste quattro frasi — perché un dato debba essere in chiaro per essere elaborato, perché la custodia esterna delle chiavi non possa impedirne l'uso imposto, e perché l'attestazione verifichi il software e non il luogo — sono esposte nella Parte II. Chi accetta le quattro citazioni può andare direttamente alla tabella delle cinque offerte.

Che cos'è il Polo Strategico Nazionale, e che cosa promette

Il Polo Strategico Nazionale è l'infrastruttura su cui le amministrazioni pubbliche italiane stanno spostando i propri sistemi, finanziata con i fondi europei per la ripresa. Esiste per portare in poche strutture presidiate i server sparsi in migliaia di enti pubblici.

Ma il programma non è presentato solo come consolidamento. Le sue stesse pagine promettono che le amministrazioni accederanno ai servizi «in piena sicurezza, autonomia e sovranità». Questa pagina esamina quella seconda parola — perché è quella che porta un significato giuridico, e perché nei documenti del programma stesso risulta significare altro.

Fonte: Manuale Utente Secure Public Cloud Azure, ed. 04/04/2025, sezione sul servizio di backup

Letto con precisione, questo non è una definizione di sovranità — ed è proprio questo il punto. Il passaggio si trova nella sezione che descrive il servizio di backup, e afferma che uno dei due requisiti di quel servizio è «legato alla sovranità del dato», soddisfatto da una replica mensile. Chi obiettasse che si tratta semplicemente di un obiettivo di punto di ripristino avrebbe ragione sul meccanismo.

Come verificare questa analisi

Questa pagina è scritta per essere controllata, non creduta. Ogni citazione proviene da un documento che abbiamo scaricato e letto per intero, non da resoconti di seconda mano. Chi lavora in sicurezza o infrastrutture deve poter riprodurre ogni reperto in autonomia, e questa sezione spiega come.

Le tre convenzioni che usiamo, e che cosa significano

Riprodurre le due scansioni

I due reperti quantitativi di questa pagina sono ricerche full-text, ed entrambe si possono rifare in pochi minuti.

1. Le 161 pagine. Si scarichino i quattro documenti collegati nella sezione 1 — convenzione di concessione, guida alla convenzione, caratteristiche tecniche dei servizi e manuale utente del livello su Azure — se ne estragga il testo e si cerchino: CLOUD Act, extraterritoriale, nazionalità, capogruppo, paese terzo, controllo societario, immunità, legge straniera.

   Una trappola di metodo in cui siamo caduti, e in cui cadrete anche voi. Lo strato testuale della guida alla convenzione si estrae senza spazi: una ricerca ingenua di software di base restituisce zero, falsamente. Si normalizzino via gli spazi bianchi dal testo estratto prima di cercare, altrimenti si riportano assenze che non esistono.

2. Il catalogo francese. Si scarichi il catalogo ufficiale dei prodotti e servizi qualificati collegato nella sezione 8 e vi si cerchino Oracle, Microsoft, Amazon, AWS, Polo Strategico.

Lo standard probatorio che applichiamo a noi stessi

Queste dodici regole governano ciò che su questa pagina si può e non si può concludere. Sono pubblicate perché un lettore possa controllare se le abbiamo rispettate.

1. Una pagina commerciale non dimostra una proprietà tecnica se non è accompagnata da specifiche, da un audit o da una clausola contrattuale.
2. Un documento generico del fornitore non dimostra l'implementazione concreta dentro questo programma.
3. L'assenza di una parola non dimostra l'assenza di una regola.
4. La presenza di una connessione o di una dipendenza non dimostra l'accesso ai contenuti.
5. La capacità di aggiornare il software è rilevante, ma è cosa distinta dalla capacità attuale di leggere i dati.
6. Una qualificazione non è una garanzia assoluta e va descritta nel suo perimetro.
7. «Non documentato» non equivale a «inesistente».
8. «Mitigato» non equivale a «eliminato».
9. «Tecnicamente possibile» non equivale né a «giuridicamente autorizzato» né a «effettivamente avvenuto».
10. «Giuridicamente ordinabile» non equivale a «tecnicamente eseguibile senza ulteriori modifiche».
11. Ogni affermazione temporale deve portare la propria data.
12. Ogni confronto deve dichiarare se gli oggetti confrontati siano realmente comparabili.

Registro delle fonti — file, dimensioni e impronte

Ogni file qui sotto è archiviato nel repository del progetto. L'impronta SHA-256 consente a chiunque di verificare di stare esaminando lo stesso documento che abbiamo esaminato noi, e non una revisione successiva.

Le «161 pagine» citate in tutta la pagina sono i quattro documenti contrattuali e operativi: 53 + 11 + 33 + 64. Gli altri file del registro sostengono reperti specifici e sono citati dove vengono usati.

Documenti che non abbiamo letto, e che cosa cambierebbero

Il corpus esaminato è contrattuale e operativo. Non comprende i documenti di strategia cloud nazionale, che risultano riconoscere il rischio derivante da ordinamenti extra-UE. Quel riconoscimento non è in discussione qui, e questa pagina non sostiene che la domanda non sia mai stata posta in Italia — al contrario, l'Italia è coautrice dei criteri europei di immunità nel 2021.

Dove sono conservate le fonti

Le pagine commerciali cambiano e i PDF vengono ritirati. Ogni file citato qui è stato archiviato nel repository del progetto, perché la prova non dipenda dalla permanenza in rete dei siti dei fornitori. I collegamenti puntano all'originale; la copia archiviata è la riserva.

Parte I

1. Perché questo riguarda l'Italia: il Polo Strategico Nazionale

Il programma cloud pubblico italiano — il Polo Strategico Nazionale, PSN — offre esattamente queste due misure come propria protezione, sul livello erogato dalle region pubbliche degli hyperscaler.

2. «PSN Managed» sono due architetture diverse sotto un nome solo

Il livello più protetto del cloud pubblico italiano è presentato come un servizio unico. La sua stessa pagina dice altro, in una frase:

«Il servizio si basa su due tecnologie: Google Assured Workload e Oracle Alloy.» — «Queste infrastrutture sono ospitate in region italiane oppure all'interno dei Data Center del Polo Strategico Nazionale.»

Fonte: PSN, PSN Managed Public Cloud · listino servizi, 04/2026 · Guida alla Convenzione, 08/2025

Quell'«oppure» regge tutto il peso. Non sono due fornitori dentro un'architettura: sono due architetture opposte, e una sola delle due sta dentro i data center del PSN.

Il listino del PSN conferma entrambe le metà: sul versante Google riporta una voce di listino chiamata «Sovereign Controls», descritta come la possibilità di «impostare delle policy all'interno di GCP». La sovranità come voce di listino, e come impostazione di policy.

3. Le cinque offerte, una accanto all'altra

La prima colonna è il metro: l'unica delle cinque che possiede una qualificazione di sovranità. Tutto ciò che le sta a destra non ce l'ha.

Fonte: Google, Italy Data Boundary by PSN · France Data Boundary by S3NS · listino PSN 04/2026

4. Il confronto, requisito per requisito

Il cloud pubblico italiano è erogato in tre livelli, con tre gradi di controllo molto diversi — tutti promossi con la stessa parola. Questa tabella li mette a confronto con i requisiti che il quadro francese misura davvero. Ogni casella sul PSN viene da documenti scaricati e letti per intero: la convenzione di concessione, la guida alla convenzione, le caratteristiche tecniche dei servizi e il manuale utente del livello su Azure — 161 pagine.

Sul metodo. Dove una casella dice «non documentato» intendiamo esattamente questo: abbiamo letto i documenti e non l'abbiamo trovato — che è cosa diversa dall'affermare che non esista. Dove una casella dice «zero occorrenze», abbiamo eseguito una ricerca full-text su tutti e quattro i documenti e ne riportiamo l'esito. La distinzione è voluta.

5. Perché la Francia è avanti — e non per la ragione che si dice

La differenza vera non sta nella purezza dei fornitori. Sta nel fatto che la Francia ha scritto un requisito che si può misurare, e l'Italia non ne ha scritto alcuno. Tre verifiche, ciascuna delle quali o è soddisfatta o non lo è: dove è stabilita l'azienda, chi ne controlla il capitale, da dove il servizio è amministrato.

È tutto qui il divario, e non è un divario di tecnologia, di bilancio o di competenza ingegneristica. L'Italia ha ottimi data center, operatori capaci e un vero programma di consolidamento. Ciò che non ha è una frase in un documento vincolante che dica che cosa un fornitore debba essere per custodire i dati più sensibili dello Stato. La Francia quella frase l'ha scritta. Scriverla non è costato nulla. Ha cambiato il mercato.

E c'è un dettaglio che rende il confronto ancora più netto. Non è che l'Italia non ci abbia pensato. Nel 2021 l'Italia è coautrice, con Francia, Germania e Spagna, della proposta europea che introduceva l'immunità dalle leggi straniere nella certificazione cloud dell'Unione. Quei requisiti sono stati rimossi nel marzo 2024. L'Italia ha chiesto la regola a Bruxelles — e negli stessi cinque anni non l'ha mai scritta in casa propria, nell'unico strumento che non dipendeva dal voto di nessun altro.

6. Oracle Alloy, con le parole di Oracle

Prima, ciò che va riconosciuto. Alloy è davvero un realm separato, con «un proprio control plane», «fisicamente e logicamente separato» dal cloud pubblico Oracle. Il PSN dichiara due region, rete esclusiva senza internet pubblico, tutti i dati nei propri data center, cifratura secondo le specifiche dell'autorità nazionale. Sul piano dell'infrastruttura è più di quanto offra il Data Boundary di Google.

E il lessico che Oracle usa per il partner non lascia dubbi: l'operatore «rivende servizi cloud Oracle» e gestisce «il ciclo di vita del proprio business di rivendita cloud». Un dettaglio che dice molto: il post Oracle intitolato «Expanding Control & Flexibility» per gli operatori Alloy riguarda valute multiple e rinnovi contrattuali. Il controllo che viene ampliato è commerciale.

Fonte: Oracle, Alloy Overview · oracle.com/cloud/alloy · Alloy Business Reporting

Aggiornamenti: chi fa che cosa, detto con precisione

La pagina prodotto Oracle dice che l'operatore «può gestire in autonomia tutte le attività operative standard, come il patching di base e gli aggiornamenti dei servizi», e può contare sui «team Oracle per troubleshooting, upgrade non standard, risoluzione dei disservizi ed escalation». Il VP Dedicated Cloud di Oracle lo sintetizza: è «di fatto un'intera region OCI che il team dell'operatore può gestire, mantenere e potenziare in autonomia, assistito dagli upgrade e dal supporto di Oracle».

E ciò che l'operatore ottiene sulle modifiche è una dashboard che «fornisce visibilità sui cambiamenti di servizio OCI schedulati e completati, inclusi quelli di emergenza, mitiganti, normali e di routine». I verbi sono osservativi dall'inizio alla fine. Nessuna approvazione, nessun rifiuto, nessun differimento risulta documentato.

Operator Access Control — reale, e con tre buchi dichiarati

Oracle offre un meccanismo davvero più forte di qualunque cosa ci sia nel pacchetto Google: il cliente può approvare o negare l'accesso dei dipendenti Oracle, con limiti di tempo, registrazione di tutti i comandi e, se richiesto, dei tasti premuti. Va riconosciuto.

Fonte: Oracle, Operator Access Control — overview

Il cancello controlla le persone. Non controlla l'automazione che gira come root.

Due riserve oneste. L'Operator Access Control è documentato per Exadata Cloud@Customer e Compute Cloud@Customer, non per Alloy nel suo insieme — il PSN usa Exadata sulla piattaforma Alloy, quindi è pertinente, ma non sosteniamo che copra tutto. E l'affermazione più forte di Oracle — «un operatore Oracle Alloy mantiene il pieno controllo dei dati e delle applicazioni» — è una dichiarazione aziendale che non abbiamo potuto verificare, della stessa natura del «non è mai successo» di Microsoft.

7. Amazon: Nitro Enclaves, e dov'è davvero il confine

Amazon è il quarto fornitore cloud integrato nel cloud pubblico italiano: il listino del PSN registra l'«integrazione 4° cloud service provider AWS» nel 2024, e descrive il Secure Public Cloud come basato sui servizi pubblici «degli hyperscaler Microsoft Azure, Google Cloud, AWS e Oracle, con region in territorio italiano». La domanda vale quindi anche qui.

Da che cosa protegge Nitro Enclaves — nella documentazione di AWS

Nitro Enclaves è una tecnologia di isolamento davvero ben costruita. Il suo modello di minaccia documentato è enunciato con precisione, e vale la pena leggerlo due volte:

«i dati e le applicazioni dentro l'enclave non possono essere acceduti da processi, applicazioni o utenti (root o admin) dell'istanza padre» — «Il Nitro Hypervisor garantisce che l'istanza padre non abbia accesso alle vCPU e alla memoria isolate dell'enclave.»

Due dettagli ulteriori, dalla stessa pagina. La vita dell'enclave è legata all'istanza: «Le enclave sono attive solo mentre l'istanza padre è in stato running. Se l'istanza padre viene arrestata o terminata, le sue enclave sono terminate.» Chi controlla l'hypervisor controlla l'interruttore. E l'attestazione è integrata con AWS KMS — il servizio di chiavi gestito da AWS.

Fonte: AWS, What is Nitro Enclaves? · European digital sovereignty

Il sistema Nitro: la dichiarazione più forte dei quattro fornitori, e ciò che la sostiene

AWS afferma che il sistema Nitro «fornisce un confine di sicurezza fisico e logico tale che nessuno, inclusi i dipendenti AWS, può accedere ai carichi di lavoro o ai dati dei clienti». È la dichiarazione più netta fra quelle dei tre fornitori, e merita di essere affrontata con le prove, non con una smentita.

La dichiarazione poggia su un audit esterno del sistema Nitro. Quell'audit dichiara quattro limiti propri:

• l'auditor è stato pagato da AWS;
• è una revisione del progetto senza test — l'auditor dichiara di non poter attestare che l'implementazione corrisponda al progetto;
• mette fuori dal proprio perimetro il piano di controllo EC2, l'hypervisor, il firmware e le Nitro Card;
• e non fornisce alcuna garanzia rispetto a modifiche tecniche future «scelte o imposte».

Una valutazione indipendente non finanziata da AWS — Trail of Bits — formula il residuo senza giri di parole: «devi fidarti completamente di AWS».

La struttura europea, e che cosa dice il registro delle imprese

Sul piano societario Amazon ha fatto più di Google e Oracle in Italia, e va riconosciuto. AWS ha annunciato «una nuova capogruppo e tre controllate costituite in Germania», una direzione composta da «cittadini UE residenti nell'UE» e un consiglio consultivo di quattro cittadini UE «fra cui almeno un membro indipendente non affiliato ad Amazon», «legalmente obbligato ad agire nell'interesse dell'AWS European Sovereign Cloud». Prima region: Brandeburgo.

Siamo poi andati a cercare quella società nel registro delle imprese tedesco, su due servizi di registro indipendenti. L'iscrizione è Amtsgericht Potsdam, HRB 40853:

Fonte: Registro delle imprese — Amtsgericht Potsdam, HRB 40853 · annuncio AWS sulla governance

La «nuova capogruppo europea» è un veicolo societario preesistente, costituito nel 2021 e denominato Amazon Germany Holdco 1 GmbH fino al luglio 2025, con il capitale minimo di legge di 25.000 euro e un oggetto sociale di partecipazione in altre società. E l'amministratrice presentata come il volto della governance europea ha cessato la carica nel giro di circa sei mesi.

E la frase sul non essere mai successo — scritta meglio di quella di Microsoft

La formulazione di Amazon è che dal 2020 «non ci sono state richieste di dati ad AWS che abbiano portato alla divulgazione di contenuti archiviati fuori dagli Stati Uniti da clienti aziendali o governativi al governo statunitense».

Tre restrizioni in una riga sola. Non dice che non ci siano state richieste: dice che nessuna ha portato alla divulgazione. Copre solo i contenuti fuori dagli Stati Uniti. E solo i clienti aziendali o governativi. È la stessa classe di affermazione esaminata nella sezione 12 — ed è inverificabile per la stessa ragione: il divieto di dirlo è esso stesso legge.

Due reperti ulteriori, per completezza. L'annuncio AWS sulla governance dell'European Sovereign Cloud non tratta in alcun punto il CLOUD Act: come nei documenti italiani, la questione giurisdizionale non riceve una risposta debole — non viene posta. E nel catalogo ufficiale dei prodotti qualificati dell'agenzia francese, Amazon e AWS compaiono zero volte: né qualificati né in istruttoria. Microsoft ha costituito Bleu ed è entrata in istruttoria; Google ha costituito S3NS ed è arrivata alla qualificazione. Amazon ha costituito una GmbH tedesca e non l'ha portata alla qualificazione francese.

8. Chi ha una qualificazione di sovranità, e chi no

L'agenzia francese pubblica un catalogo ufficiale dei prodotti e servizi qualificati. Lo abbiamo letto per intero — 130 pagine — e vi abbiamo cercato.

Fonte: ANSSI, catalogo dei prodotti e servizi qualificati (PDF, 130 pp.) · elenco dei prestatori in istruttoria

Le sedici offerte attualmente in istruttoria dicono altrettanto: Adista, Bleu SAS, BLUE, Cegedim, Cloud Temple, Ecritel, Free Pro, GIP Mipih, ITS Integra, NumSpot, NRB, Orange Business, OVH, Prolival, Scaleway, Scalingo. Bleu — l'impresa di Microsoft, Orange e Capgemini — è in quell'elenco. Oracle no.

Microsoft, sulla stessa strada, ha costituito Bleu — capitale francese di controllo — ed è entrata in istruttoria. Google ha costituito S3NS con Thales ed è arrivata alla qualificazione, intestata a Thales Cloud Sécurisé: il titolare è il socio europeo di controllo. Oracle ha annunciato una discussione.

9. I quattro fornitori, e il punto in cui coincidono

Ciascuno dei quattro fornitori usati dal cloud pubblico italiano ha costruito qualcosa di reale, e ciascuno ha tracciato un confine di sicurezza. Letti uno per volta i quattro sembrano diversi. Letti uno accanto all'altro, escludono quattro soggetti diversi — e nessuno dei quattro esclude lo stesso.

9.1 Come le mitigazioni stesse creano l'esposizione

È la parte che sfugge più facilmente, ed è il punto più affilato di questa pagina. La legge statunitense raggiunge i dati che si trovano in possesso, custodia o controllo del fornitore. Ognuna di queste mitigazioni, per funzionare, deve creare un nuovo oggetto — e quell'oggetto finisce esattamente in quella condizione.

9.2 Che cosa hanno in comune i quattro quando parlano

Lo schema si ripete anche nel linguaggio. Ogni fornitore fa un'affermazione forte, e ogni affermazione è vera come è scritta — e più stretta di come suona.

• Microsoft, sotto giuramento: «No, non posso garantirlo, ma, ancora una volta, ciò non si è ancora mai verificato.» La prima metà è l'ammissione; la seconda è inverificabile per costruzione.
• Amazon: «nessuna richiesta di dati che abbia portato alla divulgazione di contenuti archiviati fuori dagli Stati Uniti da clienti aziendali o governativi». Tre restrizioni in una riga.
• Oracle: «un operatore Oracle Alloy mantiene il pieno controllo dei dati e delle applicazioni» — una dichiarazione aziendale, accanto a una pagina di documentazione che esclude l'automazione root dai controlli di accesso.
• Google, in un documento scritto per le scuole: «esaminiamo con attenzione ciascuna richiesta». Esaminiamo con attenzione. Non: rifiutiamo.

E un silenzio che pure condividono: nell'annuncio ufficiale sulla governance dell'AWS European Sovereign Cloud, nelle pagine Google sui data boundary e in 161 pagine di documenti contrattuali italiani, la legge statunitense non viene mai discussa. La questione giurisdizionale non riceve una risposta debole. Non viene posta.

Parte II — le misure tecniche

Una risposta tecnica a una domanda giuridica

I fornitori soggetti al CLOUD Act — Microsoft, Google, Amazon — non sono rimasti fermi. Hanno investito molto, e in modo visibile, in ciò che viene messo sul mercato come sovranità: entità giuridiche europee, region nazionali, personale operativo locale, gestione esterna delle chiavi, enclave cifrate, perimetri dedicati ai dati dell'Unione. Alcune di queste cose sono ingegneria seria, fatta da persone competenti, e in questa pagina ciascuna verrà riconosciuta per quello che vale.

Vale la pena essere chiari sul perché stia accadendo. Non è un ripensamento: è una risposta commerciale a un'esposizione giuridica. Le amministrazioni pubbliche europee hanno cominciato a fare una domanda scomoda, la Francia l'ha scritta dentro un referenziale di certificazione, e il mercato ha prodotto delle risposte. È un fatto sano — ed è anche il punto in cui nasce il problema.

La tabella qui sotto è la mappa di questa pagina. A sinistra ogni misura e ciò che risolve davvero — perché ciascuna risolve qualcosa di reale. A destra il punto in cui si richiude su sé stessa, con il rimando alla sezione che la esamina. Si legga la colonna di destra dall'alto in basso: ci si accorge che la ragione è sempre la stessa, detta in sei modi diversi.

Si rilegga il modello di minaccia: un amministratore ostile. Non un attaccante esterno, non un altro cliente sulla stessa macchina — chi gestisce la piattaforma. È esattamente la situazione che crea un ordine giudiziario emesso sotto una giurisdizione straniera: un fornitore che non è malintenzionato, ma è obbligato — e a cui è vietato dirlo.

10. Un dato esiste in tre stati. La cifratura ne copre due.

È tutto qui l'argomento tecnico, e sta in una tabella. Non è materia controversa: è il modo in cui funzionano i computer.

Chi controlla l'hypervisor e la macchina fisica controlla quell'istante. Può sospendere una macchina virtuale e riversarne la memoria su disco; può farne uno snapshot; può leggere i registri della CPU. Nulla di esotico: è ordinaria amministrazione della piattaforma, la stessa capacità che si usa ogni giorno per la migrazione a caldo, il debug e i backup.

11. Che cos'è il confidential computing — e che cosa ottiene davvero

Il confidential computing è la risposta dell'industria alla terza riga di quella tabella. Il processore crea un'enclave cifrata e isolata — un Trusted Execution Environment — la cui memoria è cifrata con una chiave custodita nel silicio e, in linea di principio, non disponibile all'hypervisor. Le implementazioni principali sono Intel TDX, AMD SEV-SNP e ARM CCA. Un meccanismo chiamato attestazione remota dovrebbe permettere al cliente di verificare crittograficamente che il proprio carico di lavoro giri davvero dentro una di queste enclave.

12. Quattro ragioni per cui non produce sovranità

12.1 Il modello di minaccia esclude proprio la nostra minaccia

Il confidential computing è progettato contro un operatore curioso e contro i clienti vicini di macchina. Non è progettato contro un operatore determinato, che controlla il firmware e la catena di fornitura e che ha tempo. La conclusione dell'ANSSI su quello scenario è la frase in cima a questa pagina. E l'ANSSI aggiunge che cosa fare invece: gli utenti «devono evitare di girare su infrastrutture condivise gestite da fornitori di cui non possono fidarsi».

Un ordine giudiziario non rende malintenzionato un fornitore. Lo rende obbligato — che, nel modello di minaccia, è la stessa cosa.

Si noti la parola prerequisito. L'ANSSI non presenta il fornitore affidabile come un'alternativa alla tecnologia: lo presenta come la precondizione senza la quale sulla tecnologia non ci si dovrebbe affidare affatto. L'ordine dei fattori è l'opposto di quello implicito in ogni offerta di «cloud sovrano» costruita su un fornitore a controllo estero.

12.2 Non soddisfa lo standard di sovranità — secondo l'agenzia che lo ha scritto

La sezione 19.6 di SecNumCloud è la clausola di immunità: il requisito che un fornitore qualificato sia al riparo dalle leggi extraterritoriali non europee — attraverso la sede, il controllo del capitale e il luogo da cui il servizio è amministrato. Quella clausola l'ha scritta l'ANSSI. Ed è l'ANSSI a dire che il confidential computing non la soddisfa.

È il fatto più importante di questa pagina. Ogni argomento che proponga il confidential computing in sostituzione dei requisiti giurisdizionali è già smentito dall'autorità che quei requisiti li ha inventati.

12.3 Chi gestisce la piattaforma decide se è acceso

Il confidential computing non è una proprietà del dato. È una configurazione della piattaforma: un tipo di macchina da selezionare, una funzionalità da abilitare, un firmware da tenere aggiornato. Il soggetto che decide se l'enclave è attiva, per quali carichi di lavoro e dopo quale aggiornamento, è lo stesso soggetto da cui l'enclave dovrebbe proteggere.

È per questo che le formule usate dai fornitori pesano tanto. Quando un servizio è descritto come dotato di confidential computing «ove attivato», la protezione è stata resa condizionale — e la condizione non è nelle mani del cliente.

12.4 Una debolezza trovata nel modo in cui l'attestazione viene legata al canale

L'intera costruzione poggia sull'attestazione remota: senza, il cliente non ha modo di sapere se l'enclave è reale. Il reperto che segue non invalida l'attestazione in generale — riguarda un modo molto diffuso di legare l'evidenza di attestazione a un canale TLS. Nel 2026 un gruppo guidato da Muhammad Usama Sardar (TU Dresden), con Mariam Moustafa e Tuomas Aura, ha dimostrato che l'attestazione eseguita dentro l'handshake TLS può essere sconfitta con un attacco di inoltro. Nella sintesi che ne ha dato The Register:

«Una connessione destinata a un server può essere silenziosamente reindirizzata verso una macchina diversa e compromessa che esegue software identico, ovunque nel mondo, senza che il client se ne accorga mai.»

Il protocollo verifica l'integrità del software, non la sua collocazione. La vulnerabilità è registrata come CVE-2026-33697 (CVSS 7.5) e ha riguardato sistemi già in produzione. La ricerca è pubblicata come Identity Crisis in Confidential Computing (AsiaCCS 2026) e Intra-handshake.fail (ESORICS 2026). E sulla possibilità di correggerla, il lavoro conclude che la protezione piena «potrebbe non essere possibile» con l'attestazione dentro l'handshake così com'è oggi progettata, senza rompere proprietà del TLS 1.3.

12.5 E l'affermazione commerciale che l'ANSSI corregge di persona

L'ANSSI osserva che la tecnologia «è spesso presentata dai fornitori commerciali come una soluzione per eseguire carichi di lavoro remoti con lo stesso livello di riservatezza e integrità di un'installazione locale, cioè resistente a un attacco fisico» — e poi afferma senza giri di parole: «gli attacchi fisici sono esplicitamente fuori dal perimetro del modello di sicurezza».

Chi possiede l'edificio ha accesso fisico alle macchine. Il modello di sicurezza del confidential computing non copre quel caso, e lo dichiara.

13. E le chiavi? Lo stesso problema, un piano più sotto

La seconda risposta tecnica che viene di solito offerta è la gestione delle chiavi: il cliente custodisce le chiavi di cifratura fuori dal perimetro del fornitore, tipicamente in un modulo hardware di sicurezza. I modelli hanno un nome — BYOK (bring your own key), HYOK e gestione esterna delle chiavi — e differiscono per quanto la chiave resti lontana dalla piattaforma.

Anche questo è reale, e anche questo va riconosciuto prima di criticarlo. Chiavi custodite in un HSM controllato dal cliente eliminano davvero una classe di esposizione: i blocchi memorizzati non si leggono copiando un disco, un operatore non può curiosare in un archivio, e una chiave si può revocare.

Un paragone che regge: potete tenere la chiave della cassaforte in tasca vostra, in un altro Paese. Ma se la cassaforte è nel palazzo di qualcun altro, e chiedete al suo personale di aprirla e leggervi il documento, il luogo in cui sta la chiave non è ciò che determina chi può leggere quel documento. La gestione esterna delle chiavi cambia chi deve essere obbligato, e quanto la cosa sia visibile. Non cambia se il testo in chiaro esista dentro il perimetro del fornitore.

Quella sola frase liquida l'argomento secondo cui la custodia esterna delle chiavi produrrebbe sovranità. La chiave è vostra; le mani che la usano no. La fiducia nel fornitore non viene eliminata dall'architettura: viene spostata da «fidarsi che custodisca il dato» a «fidarsi che usi la chiave solo come richiesto». Per un fornitore che ha il dovere giuridico di ottemperare a un ordine straniero, è la stessa fiducia.

13.1 Dove esattamente il BYOK smette di funzionare, passo per passo

Vale la pena seguire la chiave lungo un'operazione ordinaria, perché il punto non è sottile una volta vista la sequenza. Si supponga che un'amministrazione tenga un archivio cifrato nel cloud del fornitore, con la chiave in un proprio modulo hardware.

Il modulo esterno delle chiavi non è quindi una barriera alla lettura del dato. È un interruttore che decide se il sistema funziona. Il suo potere reale è fermare tutto — che è una proprietà vera e preziosa, e anche molto grossolana: un'amministrazione non può revocare la propria chiave ogni volta che sospetta qualcosa, perché revocarla significa spegnere il servizio.

E l'ANSSI segnala la stessa trappola dal lato opposto, quello della disponibilità: far dipendere la piattaforma da una chiave esterna introduce un modo di guasto che «può causare l'indisponibilità dell'intero sistema». L'esternalizzazione delle chiavi compra un interruttore d'emergenza e lo paga in fragilità — ma non compra riservatezza nei confronti di chi gestisce la piattaforma.

Un beneficio reale, che va nominato perché è l'argomento più forte della parte avversa, esiste: revocare una chiave esterna è un atto osservabile. Il cliente che ritira la chiave si accorge che l'accesso si è fermato. È una proprietà vera — ma è una proprietà sugli accessi futuri, e non serve a nulla contro un'acquisizione già avvenuta e che un ordine di riservatezza vieta a chiunque di menzionare.

14. Perché una misura tecnica non può risolvere un problema giuridico

È la parte che vale la pena capire anche saltando tutto il resto di questa pagina, e richiede circa un minuto.

Ogni misura di sicurezza mai costruita presuppone un avversario che deve aggirare qualcosa. La cifratura presuppone qualcuno che non ha la chiave. Il controllo degli accessi presuppone qualcuno senza credenziali. La segregazione di rete presuppone qualcuno dalla parte sbagliata di un confine. Il confidential computing presuppone qualcuno che deve evadere da un'enclave. Tutte funzionano alzando il costo di aggirare le regole del sistema.

Fonte: Google, Monitor an Assured Workloads folder for violations

È per questo che la domanda «quale misura tecnica protegge dal CLOUD Act?» non ha risposta. È come chiedere quale serratura protegga dalla chiave del padrone di casa. La serratura non è difettosa. La domanda è puntata sullo strato sbagliato.

E spiega perché sommare misure non aiuta. La difesa in profondità moltiplica il lavoro di un attaccante che deve sconfiggere ogni strato a turno. Non produce nulla quando tutti gli strati sono amministrati dallo stesso soggetto, perché quel soggetto non deve sconfiggerli: li configura.

15. Le obiezioni, una per una

Sono le risposte che un fornitore o un programma di cloud pubblico può legittimamente dare. Ognuna è riportata nella forma più forte che sappiamo darle, e poi affrontata. Dove l'obiezione ha in parte ragione, lo diciamo.

16. Sette scenari, graduati

Un verdetto binario — sovrano o non sovrano — è più facile da scrivere e più facile da confutare. Segue la stessa evidenza organizzata per scenario di minaccia, perché il programma si comporta in modo molto diverso da uno all'altro. In tre dei sette si comporta bene: non è una concessione, è il risultato.

17. Le migliori argomentazioni a favore del programma

Un'analisi che presenta solo la propria tesi non è un'analisi. Seguono le argomentazioni più forti che un difensore competente del cloud pubblico italiano potrebbe portare, enunciate nel modo migliore che sappiamo — e poi affrontate con ciò che le prove sostengono, e soltanto quello.

18. Che cosa si potrebbe fare — sei misure, in ordine di praticabilità

Una critica che non offre alternative è commento. Quel che segue è ordinato per quanto presto ciascuna misura potrebbe essere adottata, e ognuna poggia su uno strumento che esiste già. Nessuna richiede di abbandonare i fornitori attuali.

19. La conclusione, detta con cura

Presentare queste misure come sovranità non è un errore tecnico. È un errore di categoria: rispondere a una domanda giuridica con un manufatto ingegneristico. Quelle misure sono una mitigazione. Non sono un'immunità — e l'agenzia che l'immunità l'ha definita lo ha messo per iscritto.