Il problema della protezione delle informazioni in cloud è sempre più sentito anche dagli stessi cloud provider. Che non abbandonano certamente il concetto della responsabilità condivisa con i clienti. Ma che sanno di dover offrire servizi e funzioni che siano "blindati" di per sé. Magari non interesseranno a tutte le aziende. Ma certamente a quelle che gestiscono dati sensibili. O che operano in settori in cui la compliance è indispensabile.

La riposta generica più efficace a questa necessità di protezione delle informazioni è l'utilizzo massivo della cifratura. Ma per i cloud provider si pone un problema particolare. Ossia la necessità di proteggere - insieme all'azienda cliente - non solo i dati memorizzati in cloud o che transitano da/verso il cloud stesso. Sono da proteggere anche i dati che un workload sta gestendo in un dato momento. Che si trovano quindi nelle aree di memoria RAM assegnate a quel workload. Un compito che è tutto del cloud provider.

La protezione nativa delle informazioni in uso è possibile, grazie ai cosiddetti Trusted Execution Environment (TEE). Molti processori generalisti sono affiancati da coprocessori dedicati a creare una "enclave" sicura - appunto un TEE - in cui conservare e cifrare i dati di cui la CPU stessa ha bisogno. Per sicurezza, questi coprocessori operano in maniera indipendente dal processore principale e hanno un proprio sistema operativo minimale e mirato. In questo modo, anche compromettendo il sistema operativo di base e "conquistando" la CPU, i dati conservati nel (o nei) TEE sarebbero al sicuro.

Il confidential computing

Questo approccio oggi viene comunemente definito di confidential computing. Ed è implementato per vari tipi di piattaforme. I processori ARM hanno la tecnologia TrustZone, quelli Intel le Software Guard Extension (SGX), quelli AMD la tecnologia Secure Encrypted Virtualization (SEV). Uno dei problemi attuali del confidential computing nel suo complesso è che queste implementazioni specifiche dei TEE sono sensibilmente diverse fra loro. Il che obbliga gli sviluppatori interessati a chiedersi quale tecnologia di base eventualmente avranno a disposizione per proteggere i dati in memoria.

I due approcci più comuni in cloud sono prevedibilmente quelli di Intel e AMD. Il primo vede come parte attiva la singola applicazione. È questa che crea l'enclave TEE e gestisce lo spostamento dei dati da e verso l'area cifrata. Un grado di controllo elevato, che porta però lo svantaggio di dover modificare e ricompilare una applicazione perché utilizzi le funzioni SGX. La tecnologia SEV di AMD è meno granulare, ma più comoda. In estrema sintesi, prevede la cifratura di tutta la memoria "vista" da una macchina virtuale. Così una applicazione virtualizzata in VM non deve essere modificata. Ma la protezione dei dati è meno sicura: chi accede alla VM accede anche alle sue informazioni.

Trasporre questa visione del confidential computing nelle infrastrutture cloud è di fatto trasparente per l'utente. Il cloud provider deve solo dare la possibilità di associare i workload che gestiscono dati sensibili a macchine virtuali eseguite da processori con enclave cifrati. Microsoft Azure lo permette da un paio d'anni, usando le tecnologie Intel. Google Cloud ha attivato, in versione ancora preliminare, la gestione di macchine virtuali basate su processori AMD Epyc con tecnologia SEV.
Per Google Cloud va in particolare notato che le nuove cosiddette Confidential VM derivano da una versione precedente di macchine virtuali "protette": le Shielded VM. Per le macchine virtuali "schermate" sono attive diverse funzioni che ne garantiscono l'affidabilità e l'integrità nel tempo. Ad esempio l'autenticazione dei moduli che vengono lanciati nella fase di boot della VM, che devono identificarsi tramite firma digitale. Basarsi sulle Shielded VM fa sì che i punti deboli del confidental computing secondo AMD siano ridotti al minimo, se non proprio eliminati.

Verso l'unificazione?

Sarà possibile arrivare ad un approccio più omogeneo per il confidential computing? La volontà c'è, ma è un po' presto per pensarci. Innanzitutto perché l'utilizzo esteso delle enclavi TEE è ancora di là da venire. Non è da molto che i processori riescono ad eseguire le applicazioni con cifratura dei dati "in uso" a prestazioni vicine a quelle delle applicazioni che non cifrano le informazioni. Sinora, chi ha avuto interesse ad usare i Trusted Execution Environment è stato anche disposto a sobbarcarsi la modifica e l'ottimizzazione delle applicazioni.

La spinta ad approcci comuni viene proprio dalla diffusione del cloud per applicazioni di qualsiasi tipo. Sono i cloud provider ad avere la necessità di gestire con più semplicità le enclavi sicure. Per rispondere alle esigenze dei loro clienti. Non è un caso che i fondatori del giovane Confidential Computing Consortium siano prevalentemente nomi legati al cloud (Alibaba, Baidu, Google Cloud, IBM, Microsoft, Red Hat, Swisscom, Tencent) e non produttori di chip (ci sono solo Arm e Intel, oltre alla già citata IBM).

La strada verso un confidental computing "indipendente" non sembra però breve, nonostante i nomi in gioco. L'unico vero progetto open source in questo campo è Enarx, che ha già dimostrato di poter eseguire codice per le piattaforme AMD e Intel. Ma che è ancora ad uno stadio poco più che iniziale di sviluppo.