GeoKey Manager: la chiave è locale. I dati, non necessariamente.

C’è una parola che nei pannelli cloud funziona benissimo: “regione”. Basta selezionarla e sembra che tutto, improvvisamente, abbia smesso di attraversare confini. La chiave è in Europa, il dato è in Europa, il problema è risolto. Peccato che un sistema distribuito non ragioni per checkbox: ragioni per chiavi, processi, percorsi di rete e punti in cui il contenuto torna leggibile.

Il 23 ottobre 2026 Cloudflare ha annunciato in closed beta un GeoKey Manager post-quantum che limita geograficamente l’uso delle chiavi di decifratura. L’architettura è interessante non perché mette un’etichetta geografica sulla crittografia, ma perché prova a rendere quel vincolo una proprietà tecnica verificabile. E, soprattutto, perché mostra dove finisce quella proprietà.

La domanda utile non è soltanto “dove si trova la chiave?”. È: chi può usarla, in quale contesto, dove termina la connessione e dove viene elaborato il testo in chiaro? Sono domande diverse. Confonderle è un modo piuttosto efficiente di costruire un sistema apparentemente conforme e realmente difficile da governare.

Il dato cifrato può viaggiare ovunque. La capacità di aprirlo no

In una rete edge globale distribuire configurazioni e materiale cifrato è normale: serve a mantenere prestazioni e disponibilità. La nuova architettura descritta da Cloudflare separa proprio questi due piani. Quicksilver può distribuire globalmente le chiavi private dei clienti già cifrate, insieme ai metadati che indicano servizio, regione ed epoca. La regional root key necessaria a sbloccarle segue invece un percorso separato, verso i soli nodi autorizzati.

La radice regionale è un segreto simmetrico da 256 bit. Da quella radice vengono derivate chiavi specifiche per servizio, regione e generazione temporale. Un nodo che riceve il materiale cifrato ma non possiede la radice corretta non può eseguire l’unwrapping previsto. Non è un blocco basato sulla buona volontà del software applicativo: è una dipendenza crittografica che impedisce l’operazione quando manca il materiale giusto.

Questo non rende innocuo il furto delle chiavi radice, né garantisce che ogni componente della piattaforma rispetti automaticamente la stessa frontiera. Significa però che distribuzione e capacità di decifrare non sono più la stessa cosa. È un principio riutilizzabile anche in sistemi molto più piccoli di una rete mondiale.

Post-quantum non significa cambiare l’etichetta dell’algoritmo

Per il percorso Cloudflare One descritto nell’annuncio, il wrapping usa HPKE con un meccanismo ibrido che combina ML-KEM-768 e X25519, derivazione HKDF-SHA-256 e cifratura autenticata AES-256-GCM. ML-KEM è standardizzato nel NIST FIPS 203; HPKE è descritto nella RFC 9180. La combinazione ibrida mira a mantenere la confidenzialità se almeno uno dei due componenti di scambio rimane sicuro, nei limiti delle assunzioni del protocollo.

Qui va evitato un equivoco: la standardizzazione di un algoritmo non equivale alla certificazione dell’intero servizio. Il NIST definisce ML-KEM; non certifica, con quel documento, il provisioning di Cloudflare, la correttezza dei controlli geografici o la gestione operativa delle chiavi. Queste proprietà richiedono evidenze differenti: test, configurazioni, controlli d’accesso, audit e osservabilità.

La minaccia “harvest now, decrypt later” spiega l’urgenza: un attaccante può raccogliere oggi materiale cifrato e sperare di decifrarlo in futuro. La crittografia ibrida affronta quella classe di rischio. Non risolve, da sola, un servizio che elabora plaintext nel posto sbagliato.

Tre confini diversi: chiave, TLS e plaintext

Il punto architetturale decisivo è questo: il luogo in cui si usa una chiave privata non coincide necessariamente con quello in cui il traffico viene decifrato e trattato. Nella documentazione di Geo Key Manager Cloudflare descrive anche il caso in cui un data center senza la chiave privata richiede un’operazione crittografica a un data center autorizzato, stabilisce poi una chiave di sessione e può elaborare la connessione. La localizzazione della chiave privata, quindi, non basta per dedurre dove avvenga ogni elaborazione del traffico.

Cloudflare distingue infatti Geo Key Manager da Regional Services e dagli altri controlli della Data Localization Suite. Il primo governa dove una chiave può essere custodita e usata; i secondi regolano quali data center possono decifrare, ispezionare e processare determinate richieste. Anche la collocazione di log e analytics è un ulteriore piano, non una conseguenza automatica del primo.

Una chiave geograficamente confinata è un controllo. La sovranità dei dati è il risultato di più controlli che devono reggere insieme, anche quando il sistema cambia stato.

Questo è il motivo per cui la frase “i nostri dati restano in Europa” non dovrebbe mai essere accettata come descrizione tecnica sufficiente. Bisogna chiedere quali dati, quale fase del trattamento, quali componenti e quali eccezioni operative. Altrimenti si scambia la posizione di un segreto per la posizione di un processo.

L’identità geografica di un server è un problema operativo

Una regione non è un elenco di macchine inciso nella pietra. I nodi entrano ed escono dalla flotta, vengono spostati, sostituiti, riconfigurati. Nel disegno presentato da Cloudflare, l’identità hardware supportata da TPM, l’inventario Zinc e il servizio di provisioning contribuiscono a stabilire quali nodi possano ricevere le radici regionali. I server autorizzati le caricano nel Linux kernel keyring anziché salvarle stabilmente su disco.

Il dettaglio importante non è il nome del componente. È la dipendenza fra identità della macchina, appartenenza alla regione e diritto di usare la chiave. Se uno dei tre elementi non è affidabile, il vincolo geografico rischia di diventare un attributo dichiarativo. Se l’inventario è sbagliato, anche una crittografia impeccabile può autorizzare il nodo sbagliato.

La stessa logica ricorre in altre architetture: nel caso di isolamento multi-tenant, per esempio, non basta dire che due carichi sono separati. Occorre sapere quale risorsa condividono, chi può attraversare il confine e quale evento invalida la separazione.

Fail-closed: la sicurezza si vede quando qualcosa manca

Secondo il disegno pubblicato, se un nodo non dispone delle radici regionali richieste o i metadati di servizio, regione ed epoca non corrispondono, l’operazione viene rifiutata. In alcuni casi il servizio delle chiavi non si avvia proprio. È il comportamento fail-closed: meglio un errore osservabile che una decifratura effettuata fuori dai limiti previsti.

È anche il punto in cui il marketing della disponibilità incontra il costo reale delle garanzie. Un controllo che viene disattivato quando la rete è sotto pressione non è un controllo affidabile; è una preferenza. Ma un controllo che rifiuta correttamente una richiesta deve essere accompagnato da metriche, procedure di recovery e test dei guasti, altrimenti l’operatività diventa opaca.

Lo stesso principio vale per le patch di sicurezza: non basta poter mostrare una versione corretta, bisogna dimostrare che sia quella effettivamente attiva. È una distinzione che ho affrontato anche parlando di runtime PHP e patch realmente in esecuzione. Infrastrutture diverse, stesso problema: un requisito dichiarato non è una proprietà verificata.

Rotazione e compromissione: quanto è grande il danno possibile?

La gerarchia delle chiavi semplifica la distribuzione, ma introduce un trade-off da non nascondere. Una chiave applicativa derivata può coprire più clienti dello stesso servizio, nella stessa regione e nella stessa epoca; la compromissione di una radice regionale ha un perimetro potenzialmente più ampio. La scelta di condividere una radice riduce la complessità, non elimina il blast radius.

Cloudflare distingue rotazione soft, che consente una transizione controllata tra epoche, e rotazione hard, che punta a ritirare completamente il materiale precedente. La domanda per chi valuta il sistema non è se “supporta la rotazione”, ma quanto tempo resta valido un segreto precedente, chi può ancora usarlo e come si prova che non sia più accettato. Sono proprietà che richiedono procedure di emergenza e prove, non soltanto una pagina di configurazione.

Le domande che farei prima di firmare un requisito di localizzazione

Una verifica seria partirebbe dal diagramma dei flussi, non dalla brochure. Chiederei dove avvengono l’unwrapping delle chiavi, la terminazione TLS, l’ispezione, l’esecuzione delle regole applicative e la produzione dei log. Poi chiederei come viene attestata l’identità dei nodi, con quale frequenza cambia la membership regionale e che cosa accade durante una revoca o un guasto.

Infine pretenderei un test negativo: provare a usare una chiave da un nodo non autorizzato, forzare un’epoca non valida, togliere una radice necessaria e osservare il rifiuto. Non per sfiducia preconcetta verso il fornitore, ma perché una garanzia tecnica che non viene esercitata nel caso peggiore resta un’affermazione. E le affermazioni non sono un piano di sicurezza.

Una beta interessante non è ancora una garanzia di produzione

Al 23 ottobre 2026 il nuovo GeoKey Manager post-quantum è annunciato in closed beta, con disponibilità generale prevista per il primo trimestre 2027. La documentazione pubblica include anche funzionalità di generazioni precedenti: non bisogna attribuire retroattivamente a tutte le installazioni CDN il nuovo modello ibrido. Cloudflare dichiara inoltre che l’integrazione di questa architettura post-quantum con il percorso CDN esistente è ancora in sviluppo.

Non ho trovato nelle fonti esaminate un audit indipendente dell’intera implementazione che permetta di trasformare i dettagli descritti dal fornitore in una certificazione universale. Questo non sminuisce il progetto: ne definisce correttamente lo stato. Un’architettura può essere convincente prima di essere generalmente disponibile; la maturità operativa, però, si misura quando i confini reggono su una flotta reale, durante aggiornamenti, incidenti e rotazioni.

La lezione va oltre Cloudflare. La localizzazione non è un punto sulla mappa: è una proprietà dell’intero percorso del dato. La crittografia può rendere quel percorso molto più controllabile. A patto di non confondere il luogo in cui vive una chiave con il luogo in cui vive il problema.