La sicurezza in Cloud ha raggiunto una certa maturit\u00e0, garantendo un’elevata affidabilit\u00e0 e consentendo di rispettare gran parte delle checklist di sicurezza con relativamente poco effort. Negli anni sono nati strumenti e best practices; si \u00e8 imparato a mettere in sicurezza il perimetro della rete virtuale, a gestire le identit\u00e0 in modo granulare e a fare ampio e diffuso uso della crittografia forte per cifrare i dati in transito e at rest.<\/p>\n\n\n\n
Eppure, per molto tempo, \u00e8 rimasto un punto cieco critico in questa fortezza digitale, un momento di inevitabile vulnerabilit\u00e0 in cui i dati, per essere effettivamente elaborati dai processori, devono essere in memoria non cifrati.In questo articolo si esplorer\u00e0 il concetto di Confidential Computing<\/strong>, il paradigma tecnologico che ha definitivamente chiuso questo gap di sicurezza, ridefinendo gli standard di protezione nel Cloud. Si vedr\u00e0 qual \u00e8 la complessa sfida tecnologica alla base della protezione dei dati durante l’elaborazione, perch\u00e9 i tradizionali container – su cui poggiano quasi tutte le architetture moderne \u2013 non sono sufficienti per i workload ultra- sensibili, e come AWS Nitro Enclaves<\/strong> offra una soluzione elegante e inattaccabile per creare vere e proprie “casseforti” crittografiche per le applicazioni pi\u00f9 critiche.<\/p>\n\n\n\n Per comprendere appieno l’importanza e l’impatto del Confidential Computing, \u00e8 necessario guardare l’intero ciclo di vita del dato attraverso la lente del cosiddetto Trilemma della Protezione Dati<\/strong>. Fino a poco tempo fa, gli strumenti a disposizione potevano risolvere con successo solo due di questi tre punti:<\/p>\n\n\n\n Il Confidential Computing<\/strong> \u00e8 l’insieme di tecnologie, sia hardware che software, progettate appositamente per proteggere questi Data in Use<\/em>. Utilizzando un isolamento profondo basato su componenti hardware specializzati, viene creato un TEE (Trusted Execution Environment)<\/strong>. Un TEE \u00e8 un ambiente di esecuzione sicuro, isolato a livello di processore, in cui i dati in chiaro e il codice che li elabora non possono essere n\u00e9 visti, n\u00e9 esfiltrati, n\u00e9 alterati in alcun modo dall’esterno. Nemmeno da chi detiene i privilegi massimi di amministrazione sull’infrastruttura sottostante.<\/p>\n\n\n\n Oggi, in un’era dominata dall’addestramento di modelli LLM proprietari e dalla Multi-Party Computation<\/em> (dove diverse aziende collaborano unendo i propri dataset sensibili per trarne insight, senza volerli per\u00f2 mostrare in chiaro ai partner), il Confidential Computing non \u00e8 pi\u00f9 una tecnologia di nicchia per enti governativi o bancari.<\/p>\n\n\n\n Facendo un passo indietro e analizzando esattamente la dinamica del problema che il Confidential Computing si prefigge di risolvere, in un’architettura Cloud basata su macchine virtuali (istanze EC2) che fanno girare flotte di Container orchestrati da piattaforme come Docker o Kubernetes, \u00e8 necessario porsi una domanda scomoda: chi oltre a me pu\u00f2 accedere al container?<\/p>\n\n\n\n La risposta \u00e8 l’amministratore di sistema dell’istanza ospitante, o per meglio dire, l’utente Root<\/strong>.<\/p>\n\n\n\n \u00c8 fondamentale interiorizzare che l’isolamento offerto dai Container \u00e8 di tipo puramente logico (basato su namespaces<\/em> e cgroups<\/em>), non fisico. Pi\u00f9 container che girano sulla stessa istanza EC2 condividono lo stesso Kernel e, in fin dei conti, la stessa RAM (sebbene sezionata a livello logico). Questo significa che se un malintenzionato – o anche solo un insider threat<\/em> come un dipendente corrotto, o un malware che ha compiuto una privilege escalation<\/em> – riesce ad ottenere i privilegi di Root sull’istanza che ospita i container, la partita della sicurezza \u00e8 persa.<\/p>\n\n\n\n Ma i container non sono il villain di questa storia, infatti, evitarli e ripiegare su processi eseguiti direttamente su un’istanza EC2 tradizionale non risolve il problema alla radice; anzi, espone a vettori d’attacco ancor pi\u00f9 diretti. In questo scenario, infatti, non \u00e8 nemmeno necessario che l’attaccante ottenga privilegi di Root a livello di sistema operativo. \u00c8 sufficiente compromettere il singolo utente di sistema con cui l’applicazione \u00e8 in esecuzione: sfruttando una falla di sicurezza nel codice (ci sono diversi tipi di attacco possibili), l’attaccante pu\u00f2 ottenere l’accesso legittimo alla porzione di memoria RAM assegnata a quel processo.<\/p>\n\n\n\n In entrambi i casi, una volta ottenuto l’accesso alla memoria, l’esito \u00e8 identico; \u00e8 possibile eseguire un dump completo della memoria RAM<\/strong> associata al processo bersaglio. In una frazione di secondo, si pu\u00f2 salvare su disco un file contenente esattamente tutto ci\u00f2 che un’applicazione stava elaborando in chiaro in quel momento. Analizzando poi il dump, l’attaccante pu\u00f2 estrarre svariate informazioni critiche e, magari, sensibili: token di sessione JWT attivi, password degli utenti, seed<\/em> crittografici per la generazione di codici TOTP, chiavi private SSL e informazioni di identificazione personale (PII).<\/p>\n\n\n\n Il concetto chiave qui \u00e8 il TCB<\/strong> (Trusted Computing Base<\/em>). Il TCB rappresenta l’insieme di tutte le entit\u00e0 hardware, software e umane di cui ci si deve “fidare” ciecamente per garantire la sicurezza del sistema. In uno scenario basato su container tradizionali, il TCB include l’infrastruttura del Cloud Provider, il livello di Hypervisor, l’intero sistema operativo Host, i demoni di orchestrazione (kubelet, dockerd) e tutti gli amministratori di sistema. Per workload realmente mission-critical e sensibili, questa platea potrebbe risultare eccessivamente ampia.<\/p>\n\n\n\n Per abbattere drasticamente questo TCB,<\/strong> entra in gioco AWS Nitro Enclaves<\/strong>. Questo servizio poggia sulle fondamenta della tecnologia AWS Nitro System, l’architettura hardware personalizzata di AWS che ha rivoluzionato il cloud computing disaccoppiando fisicamente le funzioni di rete, storage e gestione dalla CPU principale dell’istanza. Nitro Enclaves sfrutta questa architettura per permettere di “ritagliare” e creare partizioni totalmente isolate di CPU e Memoria direttamente da un’istanza EC2 “Parent” esistente.<\/p>\n\n\n\n Un’Enclave non va confusa con un container “pi\u00f9 sicuro” o una VM alleggerita; \u00e8 un paradigma architetturale e concettuale completamente diverso:<\/p>\n\n\n\n Se l’istanza EC2 Parent venisse totalmente compromessa da un hacker, l’attaccante troverebbe al massimo il software proxy che fa da ponte verso l’Enclave, ma il “motore” che macina i dati sensibili, insieme alle chiavi in chiaro e ai dati non cifrati, rimarrebbe custodito in una scatola nera impenetrabile.<\/p>\n\n\n\n Nonostante l’enorme complessit\u00e0 crittografica e l’isolamento hardware sottostante, AWS ha lavorato per rendere la Developer Experience<\/em> sorprendentemente semplice e accessibile grazie allo strumento a riga di comando nitro-cli. Il grande vantaggio per i team di sviluppo \u00e8 che non \u00e8 necessario imparare nuovi linguaggi o riscrivere le applicazioni da zero: il punto di partenza \u00e8 sempre un’immagine Docker standard.<\/p>\n\n\n\n Di seguito i tre passaggi essenziali per pacchettizzare e avviare un processo confidenziale.<\/p>\n\n\n\n Supponendo di avere un’applicazione containerizzata chiamata my-secure-app che contiene la logica per decifrare ed elaborare dati sensibili, il primo passo \u00e8 convertire la classica immagine Docker in un formato speciale e verificabile, chiamato EIF (Enclave Image Format<\/em>). Direttamente sull’istanza EC2 (precedentemente configurata tramite Launch Template per supportare le Enclaves), si lancia il comando di build:<\/p>\n\n\n\n Questo comando impacchetta l’applicazione insieme a un kernel Linux minimale, genera il file .eif risultante e, cosa fondamentale per la sicurezza, restituir\u00e0 a schermo le misurazioni dei PCR<\/strong>. Questi hash crittografici identificano in modo univoco l’ambiente appena creato. Questi specifici hash saranno quelli da configurare minuziosamente nelle Condition Keys<\/em> delle policy di AWS KMS per sbloccare l’Attestazione.<\/p>\n\n\n\n Una volta ottenuta l’immagine EIF, si pu\u00f2 avviare l’Enclave. Questo comando andr\u00e0 fisicamente a sottrarre i core della CPU e i megabyte di RAM dall’istanza Parent, assegnandoli esclusivamente al nuovo ambiente blindato:<\/p>\n\n\n\n Il parametro fondamentale qui \u00e8 –enclave-cid, che assegna un identificativo numerico (Context ID) all’Enclave. Si utilizzer\u00e0 questo specifico CID all’interno dell’istanza Parent per instaurare la comunicazione con l’Enclave attraverso il Vsock.<\/p>\n\n\n\n Per controllare che l’Enclave sia regolarmente in esecuzione (ricordando che l’ambiente \u00e8 isolato e non si possono usare i classici comandi di orchestrazione come docker ps o monitoraggi tradizionali), \u00e8 possibile interrogare l’allocatore Nitro lanciando:<\/p>\n\n\n\n Questo comando restituir\u00e0 lo stato dell’Enclave, l’uptime e le risorse allocate. Se a questo punto si provasse, simulando il comportamento di un attaccante, a spulciare nei processi attivi del sistema operativo dell’istanza Parent tramite ps aux, o a forzare un dump della RAM, non si troverebbe alcuna traccia del binario in esecuzione, n\u00e9 tanto meno dei dati in chiaro gestiti all’interno di my-secure-app.eif.<\/p>\n\n\n\n Il passaggio al Confidential Computing rappresenta un reale e profondo rafforzamento del paradigma di “Trust” tra i cloud provider, le aziende che sviluppano software e gli utenti finali che affidano loro le proprie informazioni pi\u00f9 intime.<\/p>\n\n\n\n Rimuovere definitivamente l’amministratore di sistema e l’infrastruttura sottostante dall’equazione della fiducia, riuscendo a blindare i dati anche e soprattutto mentre vengono elaborati, \u00e8 l’unica chiave per sbloccare nuovi casi d’uso rivoluzionari. Si pensi alla condivisione sicura di propriet\u00e0 intellettuale per l’addestramento collaborativo di modelli di Intelligenza Artificiale, o all’analisi incrociata di dati bancari condivisi tra istituti per la prevenzione delle frodi.<\/p>\n\n\n\n Con AWS Nitro Enclaves, costruire questi inespugnabili “caveau” digitali non \u00e8 pi\u00f9 un esperimento di laboratorio, ma \u00e8 diventato parte integrante e fluida del normale ciclo di sviluppo software.<\/p>\n\n\n\nOltre lo storage e la rete: cos’\u00e8 il Confidential Computing?<\/h2>\n\n\n\n
\n
L\u2019isolamento dei container NON protegge i dati in use<\/h2>\n\n\n\n
La soluzione: AWS Nitro Enclaves<\/h2>\n\n\n\n
\n
All’atto pratico: usare Nitro Enclaves<\/h2>\n\n\n\n
1. Preparazione dell’immagine<\/h4>\n\n\n\n
nitro-cli build-enclave \\\n --docker-uri my-secure-app:latest \\\n --output-file my-secure-app.eif\n<\/code><\/pre>\n\n\n\n2. Esecuzione dell’Enclave<\/h4>\n\n\n\n
nitro-cli run-enclave \\\n --eif-path my-secure-app.eif \\\n --cpu-count 2 \\\n --memory 1024 \\\n --enclave-cid 16\n<\/code><\/pre>\n\n\n\n3. Verifica dello stato<\/h4>\n\n\n\n
nitro-cli describe-enclaves<\/code><\/pre>\n\n\n\nConclusioni<\/h2>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n