Per gran parte della storia dell’informatica, i dati sono stati protetti in due stati: a riposo, con la crittografia del disco, e in transito, con TLS. Il terzo stato, i dati in uso, restava in chiaro nella memoria nel momento stesso in cui una CPU li toccava. Chiunque avesse il controllo dell’host, dell’hypervisor o l’accesso fisico alla macchina poteva leggerli. Per i workload regolamentati e sovrani in Europa, quella lacuna è l’intero problema.
Il confidential computing la colma. Combinato con primitive di isolamento moderne come le microVM, cambia ciò che puoi credibilmente promettere riguardo a un workload: che chi gestisce l’infrastruttura non può leggere i dati, che puoi dimostrarlo crittograficamente e che il tutto gira sotto la legge UE su suolo UE. Questo articolo affronta entrambe le metà della storia, gli standard e l’hardware che ne stanno alla base, e una lettura onesta di dove si trovi davvero la tecnologia nel 2026.
Cos’è il confidential computing
Il confidential computing protegge i dati mentre vengono elaborati, eseguendoli all’interno di un Trusted Execution Environment (TEE) basato su hardware. Il TEE cifra la memoria in modo trasparente e isola il workload da tutto ciò che gli sta intorno, incluso il sistema operativo host, l’hypervisor, gli altri tenant e lo stesso personale dell’operatore cloud. Questa è la crittografia in uso, il terzo stato mancante.
La conseguenza pratica conta più del meccanismo. In un TEE attestato correttamente, l’entità che gestisce l’hardware non può vedere il tuo testo in chiaro. Un hosting provider, un hyperscaler o un team di piattaforma interno diventa tecnicamente incapace di leggere ciò che gira dentro l’enclave, non semplicemente vincolato per contratto a non farlo. Per i workload il cui threat model include l’operatore, o in cui una giurisdizione estera potrebbe costringere quell’operatore, si tratta di un cambiamento categorico.
Perché conta per sovranità e GDPR
Sovranità dei dati e residenza dei dati sono cose diverse. La residenza è dove i byte risiedono fisicamente. La sovranità è quali leggi li governano e chi può legittimamente imporre l’accesso. La sola residenza dei dati nell’UE non impedisce a una società madre extra-UE di essere soggetta a richieste legali extraterritoriali.
Il confidential computing rafforza l’argomento della sovranità a livello tecnico. Quando i dati vengono elaborati dentro un TEE e le chiavi di decrittazione vengono rilasciate solo dopo l’attestazione verso chiavi detenute al di fuori del controllo dell’operatore, l’operatore non può produrre testo in chiaro leggibile, a prescindere dalla richiesta legale che gli viene notificata. Sii preciso sullo stato normativo: nessuna autorità europea per la protezione dei dati ha ancora riconosciuto il confidential computing come misura supplementare autonoma ai sensi dell’Articolo 46(2) del GDPR. Trattalo come una solida difesa in profondità che migliora concretamente una Transfer Impact Assessment, non come la soluzione miracolosa per la conformità. L’inquadramento onesto è quello credibile.
L’hardware: SEV-SNP, TDX, CCA
Oggi tre produttori di CPU offrono confidential computing a livello di VM, ciascuno proteggendo un’intera macchina virtuale invece di chiederti di riscrivere le applicazioni per una piccola enclave:
- AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) cifra la memoria della VM per singolo guest e aggiunge protezione dell’integrità, così che un hypervisor malevolo non possa rimappare, riprodurre o manomettere la memoria del guest. Ampiamente disponibile sulle piattaforme server.
- Intel TDX (Trust Domain Extensions) crea “trust domain” isolati a livello hardware con memoria cifrata e isolamento dall’hypervisor, oltre a un’attestazione remota integrata. In commercio sulle recenti generazioni Xeon.
- ARM CCA (Confidential Compute Architecture) introduce i “Realm”, ambienti isolati a livello hardware per codice e dati. È il più recente dei tre e punta dritto all’edge e all’ecosistema dei server ARM, anche se la disponibilità su larga scala è ancora indietro rispetto a x86.
Il modello di enclave più datato, Intel SGX, protegge una piccola porzione di un’applicazione invece di un’intera VM. Resta rilevante per segreti con ambito ristretto ma è più difficile da adottare rispetto agli approcci a livello di VM descritti sopra. La scelta giusta dipende dal tuo silicio, dal tuo partner cloud o hardware e dal tuo workload, che è esattamente il tipo di decisione che una consulenza vendor-neutral dovrebbe prendere con te anziché a favore di un prodotto.
L’attestazione è la parte portante
Un TEE è utile solo se puoi dimostrare che un workload sta girando dentro uno genuino e non modificato prima di affidargli dei segreti. Quella prova è l’attestazione remota, ed è la parte che la maggior parte dei team sottovaluta.
Il modello mentale vendor-neutral proviene dall’architettura IETF RATS (RFC 9334), che definisce tre ruoli: l’Attester produce evidenze firmate sul proprio ambiente, il Verifier confronta quelle evidenze con valori di riferimento noti come affidabili, e il Relying Party rilascia chiavi o dati solo a fronte di un esito positivo. In pratica il flusso si presenta così: il TEE genera evidenze firmate dall’hardware, un verifier conferma il firmware e le misurazioni, e solo allora un key broker rilascia i segreti necessari a decrittare i dati o a scaricare un modello. Nessuna attestazione valida, nessuna chiave.
Lo stack software open source
L’hardware confidenziale ha bisogno di software per essere utilizzabile in ambienti cloud-native. Lo sforzo open source di riferimento è Confidential Containers (CoCo), un progetto CNCF che esegue ogni pod Kubernetes dentro il proprio TEE e standardizza il confidential computing a livello di pod. CoCo copre i principali backend hardware (SEV-SNP, TDX, SGX, IBM Secure Execution) e si abbina al progetto Trustee per l’attestazione, incluso un Key Broker Service che vincola il rilascio dei segreti a un’attestazione positiva. CoCo si basa su Kata Containers, descritto più avanti, per il suo runtime isolato in VM. Esistono altre implementazioni open nello stesso spazio, e la forza dell’ecosistema sta nel fatto che i pattern di attestazione e rilascio delle chiavi stanno convergendo su standard condivisi anziché sull’API di un singolo vendor.
MicroVM e isolamento sicuro
Il confidential computing risponde a “l’operatore può leggere questo?”. Le microVM rispondono a una domanda correlata ma distinta: “se un workload viene compromesso, può raggiungere gli altri?”. Sono complementari, non intercambiabili.
Il container Linux standard condivide il kernel dell’host. Una sola fuga dal kernel, come la CVE-2024-21626 in runc, e il raggio d’azione è l’intero nodo. Per codice davvero multi-tenant o non fidato, un kernel condiviso è una parete troppo sottile. Le alternative:
- Firecracker è un VMM minimale scritto in Rust, costruito appositamente per il serverless. Avvia una microVM in circa 125 ms con un footprint di pochi MB per VM, riducendo il modello dei dispositivi all’essenziale. È noto per alimentare AWS Lambda e Fargate.
- Cloud Hypervisor è un altro VMM moderno in Rust, con un modello dei dispositivi più ricco di Firecracker e ampio supporto hardware. È il backend predefinito di Kata Containers.
- Kata Containers fa sì che l’isolamento di livello VM si percepisca come quello dei container: ogni pod gira in una VM leggera dietro un’interfaccia OCI/Kubernetes standard. Supporta Cloud Hypervisor, Firecracker e QEMU come backend, così da regolare il compromesso tra isolamento e compatibilità.
- gVisor segue un percorso diverso, un kernel in user-space che intercetta le syscall. Niente VM completa, overhead inferiore alla virtualizzazione, forte isolamento per molti casi multi-tenant, con alcuni limiti di compatibilità per i workload con molte syscall.
Dove si colloca ciascuno
Abbina lo strumento al workload, non all’hype:
- SaaS multi-tenant e Kubernetes condiviso: Kata Containers o gVisor per confinare i tenant dietro una barriera netta.
- Sandbox ad avvio rapido e funzioni serverless: Firecracker, dove dominano i cold start sotto il secondo e la densità.
- CI sicura ed esecuzione di codice non fidato: microVM per eseguire build arbitrarie o codice dei clienti senza fidarsene.
- Isolamento dell’inferenza AI: una barriera VM dedicata per modello o per tenant, così che un percorso di inferenza compromesso non possa fare pivot.
I due livelli si impilano. Puoi eseguire un pod Kata o CoCo la cui VM sottostante è essa stessa una VM confidenziale su SEV-SNP o TDX, ottenendo da un unico deployment sia la cecità dell’operatore sia l’isolamento dei tenant.
Inferenza AI confidenziale
Il driver in più rapida crescita è l’AI. Inviare prompt, documenti recuperati o dati di fine-tuning a un LLM significa esporre parte del proprio materiale più sensibile a chi esegue l’inferenza. L’AI confidenziale riduce quell’esposizione.
La NVIDIA H100 è stata la prima GPU con un TEE hardware: in modalità confidenziale protegge codice e dati sulla GPU con VRAM cifrata e una root of trust on-die, e si abbina a una VM CPU confidenziale (SEV-SNP o TDX) così che i dati restino cifrati end-to-end tra CPU e GPU. L’attestazione si estende alla GPU, perciò un relying party può verificare sia l’ambiente CPU sia quello GPU prima di rilasciare i pesi del modello o i dati. L’overhead pubblicato è contenuto, nell’ordine di una percentuale a una cifra sul throughput per molti workload di inferenza LLM, più un costo di attestazione una tantum all’avvio. Il risultato: prompt e output restano privati persino dall’host, e l’esecuzione è verificabile crittograficamente. Per le organizzazioni europee che vogliono l’AI moderna senza inviare dati regolamentati in un ambiente opaco, questo è il ponte.
Maturità onesta e compromessi
È potente, ma non è gratis né compiuto:
- La maturità varia nettamente. SEV-SNP e TDX sono pronti per la produzione; ARM CCA e parti dell’ecosistema GPU TEE sono più indietro. Il tooling, soprattutto la parte infrastrutturale dell’attestazione, è ancora in fase di maturazione.
- L’attestazione è lavoro operativo. Verifier, valori di riferimento e key broker sono la parte difficile, e li gestisci tu o il tuo partner.
- L’overhead prestazionale è reale ma di solito piccolo. Metti in conto qualche punto percentuale, di più per i pattern memory-bound o I/O-intensive, e fai il benchmark del tuo workload.
- Non è una casella di conformità da spuntare. Rafforza una postura GDPR e di sovranità; non sostituisce la revisione legale, la governance delle chiavi e un’architettura complessiva solida.
- Le barriere di fiducia si spostano, non spariscono. Continui a fidarti della root of trust del vendor del silicio e della tua logica di verifica. Sappi cosa c’è nella tua trusted computing base.
FAQ
Il confidential computing sostituisce la crittografia a riposo e in transito? No. Aggiunge il terzo stato, in uso, e funziona insieme agli altri due.
L’operatore cloud può comunque leggere i miei dati dentro un TEE? Con un’attestazione corretta e il controllo esterno delle chiavi, no. L’operatore non può produrre testo in chiaro leggibile, che è il vantaggio di sovranità fondamentale.
Mi serve hardware confidenziale per usare le microVM? No. Firecracker, Cloud Hypervisor, Kata e gVisor offrono un forte isolamento su hardware standard. Il confidential computing è un livello separato che puoi aggiungere sopra.
È conforme al GDPR out of the box? Rafforza la conformità e le Transfer Impact Assessment come difesa in profondità, ma nessuna DPA dell’UE lo ha confermato come misura supplementare autonoma. Trattalo come uno dei tanti controlli solidi.
Su quale CPU dovrei standardizzarmi? Dipende dal tuo stack, dai tuoi partner e dal tuo workload. Valutiamo SEV-SNP, TDX e CCA rispetto ai tuoi requisiti reali anziché spingere un’unica opzione.
Dove si colloca Rapid Solutions
Siamo una consulenza di ingegneria vendor-neutral e un partner di servizi gestiti, non un cloud provider. Progettiamo ed eseguiamo workload confidenziali, isolati a livello hardware, su fondamenta open source, con residenza dei dati e sovranità UE integrate fin dall’inizio, e ci adattiamo allo stack che hai già invece di vincolarti al nostro. Che tu stia valutando SEV-SNP rispetto a TDX, mettendo in piedi Confidential Containers con un’attestazione adeguata, isolando workload multi-tenant con Kata o Firecracker, o eseguendo inferenza AI confidenziale, ti aiutiamo a farlo correttamente e a dimostrare che funziona.