Hold Your Own Key: i tuoi dati in AWS e Azure, le tue chiavi in Europa

Hold Your Own Key: il cloud chiede, tu decidi

Sia AWS sia Microsoft pubblicano un modo per tenere la chiave fuori dalla propria infrastruttura.

AWS KMS External Key Store (XKS) ti permette di creare chiavi KMS il cui materiale vive in un gestore di chiavi esterno. Azure Key Vault Managed HSM External Key Management (EKM) fa lo stesso per i servizi Azure che supportano chiavi gestite dal cliente.

L'idea è semplice. I tuoi dati restano dove sono: in S3, EBS, Azure Storage o Azure SQL. Ma ogni volta che il cloud deve cifrare o decifrare una chiave dati (su AWS), oppure avvolgerla o svolgerla (su Azure), deve chiamare il tuo gestore di chiavi e chiedere. La chiave vera e propria non entra mai nel provider cloud.

Così ottieni qualcosa che la cifratura predefinita non può darti: un interruttore fuori dal cloud. Se togli l'accesso, il cloud non riesce più ad aprire le sue chiavi dati e i tuoi dati in quel cloud diventano illeggibili. Non cancellati, non spostati: chiusi a chiave, finché non decidi diversamente.

Cosa aggiunge QuantumAPI

QuantumAPI implementa le specifiche pubbliche di proxy di AWS XKS e Azure EKM. Crei una chiave esterna in QuantumAPI, ci colleghi il tuo archivio di chiavi AWS o il tuo Managed HSM e da quel momento AWS o Azure chiedono a QuantumAPI ogni volta che serve quella chiave. Ecco cosa ottieni dalla nostra parte:

• Una chiave custodita nell'UE. Il materiale della chiave viene generato e conservato da QuantumAPI, un'azienda europea, su infrastruttura nell'UE. AWS e Microsoft non lo ricevono mai.
• Chiavi nate dalla casualità quantistica. Le chiavi esterne sono generate con entropia quantistica fornita da un servizio QRNG (attualmente l'ANU QRNG della Australian National University). Se la sorgente quantistica non è disponibile, subentra un generatore crittografico standard (CSPRNG). In entrambi i casi la sorgente effettivamente usata viene registrata su ogni chiave, quindi un fallback non viene mai nascosto.
• Protezione post-quantistica a riposo. La tua chiave è conservata cifrata sotto una catena di chiavi protetta da ML-KEM-768 (FIPS 203), lo standard post-quantistico del NIST.
• Ogni chiamata registrata. Ogni operazione compare nel tuo registro di attività delle chiavi: chi l'ha chiesta (il principal IAM su AWS, il pool Managed HSM su Azure), tramite quale servizio, l'esito e la latenza.
• Un interruttore di emergenza. Disattiva una chiave o scollega un archivio dal portale e QuantumAPI inizia subito a rifiutare le richieste di quel cloud.
• Prezzi a consumo. Ogni operazione sulla chiave andata a buon fine conta come una chiamata API del tuo piano. Le chiavi esterne e gli archivi sono gratuiti e illimitati, come ogni altra chiave in QuantumAPI.

Su AWS c'è un vantaggio in più. KMS usa la doppia cifratura: cifra prima dentro AWS, poi con la tua chiave esterna. Né AWS né QuantumAPI possono decifrare i tuoi dati da soli. Il protocollo di Azure funziona diversamente (QuantumAPI avvolge direttamente la chiave dati), quindi per Azure non facciamo questa affermazione.

Cosa non fa (e preferiamo dirlo noi per primi)

La sicurezza post-quantistica è tutto il nostro marchio, quindi sarebbe facile chiamarlo «AWS post-quantistico». Non lo è, e non lo venderemo così.

I protocolli del cloud sono classici. Il traffico tra AWS o Azure e il nostro proxy usa ciò che definiscono i provider: TLS, AES-256 e, su Azure, certificati client basati su RSA. Nessuno negozia ML-KEM oggi. AES-256 regge bene contro i computer quantistici; lo scambio di chiavi classico di TLS no, e quella parte la controlla il client del provider cloud, non noi. Il tuo bucket S3 o il tuo account Azure Storage non diventa resistente ai computer quantistici grazie a questa funzione. Post-quantistico è il modo in cui noi conserviamo la tua chiave.

Non è un HSM. La versione 1 è un gestore di chiavi software, senza certificazione FIPS 140-3. Se le tue policy richiedono un HSM certificato, non è ancora il prodotto giusto per te.

L'interruttore blocca le nuove richieste, non le chiavi in cache. Alcuni servizi cloud tengono le chiavi dati in memoria per un certo tempo (S3 Bucket Keys, dischi collegati, Azure Storage). Quelli continuano a funzionare finché il servizio non chiede di nuovo. La revoca raggiunge tutto entro la durata di quella cache, non nello stesso secondo.

È una preview. Se il cloud non raggiunge QuantumAPI, non può usare la tua chiave e i dati che ne dipendono restano inaccessibili. È proprio il senso di HYOK, ed è anche il motivo per cui ti chiediamo di partire con carichi di test o non critici. Non siamo partner certificati di AWS o Microsoft, e Google Cloud non è supportato.

Come funziona

Dal punto di vista del cloud, QuantumAPI è semplicemente un gestore di chiavi esterno. Una richiesta tipica va così:

1. Un'applicazione legge un file da S3, oppure si avvia un database su Azure SQL. Il servizio cloud ha bisogno della sua chiave dati.
2. AWS KMS o Azure Managed HSM invia una richiesta firmata al proxy di QuantumAPI: «decifra questo con la chiave X» (AWS) o «svolgi questo con la chiave X» (Azure).
3. QuantumAPI verifica chi chiama (la firma AWS o il certificato client Azure), che la chiave appartenga a quella connessione e che né la chiave né la connessione siano state disattivate.
4. Se tutto torna, QuantumAPI esegue l'operazione AES-256 con la tua chiave e restituisce il risultato. La chiamata finisce nel tuo registro di attività delle chiavi e conta come una chiamata API.
5. Se hai usato l'interruttore, QuantumAPI rifiuta e il cloud non riesce ad aprire la chiave dati.

Per chi è e come provarlo

Gli archivi di chiavi esterni sono pensati per aziende europee regolamentate che lavorano su AWS o Azure e devono dimostrare chi controlla l'accesso ai propri dati. Pensa a DORA e alle sue regole sul rischio dei fornitori ICT per le entità finanziarie, a NIS2 per i soggetti essenziali e importanti, o al dibattito sui trasferimenti internazionali previsto dal GDPR aperto dalla sentenza Schrems II. HYOK da solo non ti rende conforme, ma ti dà una risposta concreta e verificabile alla domanda «il nostro provider cloud può leggere i nostri dati senza di noi?».

Un esempio ipotetico: una compagnia assicurativa europea conserva le polizze in S3, a Francoforte. Il suo team rischi vuole togliere le chiavi dalle mani del provider e avere traccia di ogni accesso. Con un archivio di chiavi esterno, il bucket usa una chiave KMS appoggiata a QuantumAPI. Ogni decifratura compare con il ruolo IAM e il servizio che l'ha chiesta e, se un giorno la compagnia deve togliere l'accesso, una sola azione in QuantumAPI ferma le nuove decifrature.

Vuoi il controllo completo? Installalo nel tuo data center. Se il motivo stesso di HYOK è che nessun altro controlli le tue chiavi, la configurazione più solida non è il nostro SaaS: è QuantumAPI installato on-premises, nel tuo data center. Il gestore di chiavi, il suo database, la generazione di casualità (la sorgente quantistica o il suo fallback), il registro di audit e l'interruttore restano sotto il tuo controllo, e nessun terzo, nemmeno noi, sta in mezzo. Il supporto agli archivi di chiavi esterni arriverà nell'edizione on-premises; oggi non è ancora disponibile. La preview SaaS è il modo più rapido per provare l'idea già adesso. L'on-premises mantiene lo stesso modello a consumo: chiamate API e spazio di archiviazione, mai per utente né per chiave.

Il compromesso, detto chiaramente: se lo gestisci tu, anche la disponibilità è tua. Se il tuo proxy si ferma, il cloud non può decifrare i tuoi dati. Vale in entrambe le direzioni, ed è il prezzo del controllo completo.

Cosa abbiamo misurato. Il 24 ottobre 2026 abbiamo testato il percorso Azure da capo a fondo con un vero Azure Key Vault Managed HSM in North Europe. L'ekm-connection check di Azure ha identificato QuantumAPI, i cicli di wrap e unwrap hanno funzionato, scollegando in QuantumAPI il successivo unwrap di Azure è fallito subito con «disconnected in QuantumAPI» (il Managed HSM non mette in cache gli unwrap) e ricollegando l'accesso è tornato. Dentro QuantumAPI, ogni wrap o unwrap ha richiesto circa 2-14 ms con la chiave già in cache e circa 100 ms alla prima chiamata, quella che carica la chiave. È solo il tempo di elaborazione dalla nostra parte: il percorso di rete fino al cloud si aggiunge, e il totale deve restare entro il budget di 250 ms del cloud, motivo per cui il servizio deve girare vicino alle regioni cloud che serve. Il proxy AWS XKS è implementato ma non è ancora stato testato dal vivo contro AWS; pubblicheremo quei risultati quando li avremo.

Gli archivi di chiavi esterni sono disponibili in preview in QuantumAPI 0.25.0. La configurazione passo passo per AWS e Azure è su docs.quantumapi.eu. Se vuoi avviare un pilota o parlare del tuo caso, scrivici: preferiamo conoscere le tue esigenze ora, mentre la funzione sta ancora prendendo forma.