La crittografia ha conquistato un posto rassicurante nel lessico della sicurezza aziendale. I dati sono cifrati a riposo, cifrati durante il trasferimento, protetti da servizi di key management e custoditi attraverso infrastrutture progettate per ridurre drasticamente il rischio di accessi non autorizzati. Sulla carta, la questione sembrerebbe quasi risolta. Nella realtà del cloud, però, la domanda strategicamente più importante arriva un passaggio dopo: chi può decidere che quei dati non debbano più essere decifrati?

È qui che la crittografia smette di essere soltanto una misura di sicurezza e diventa una questione di sovranità digitale.

Il problema non riguarda infatti esclusivamente la robustezza degli algoritmi utilizzati, ma la distribuzione dell’autorità all’interno dell’architettura. Già il NIST, analizzando il key management negli ambienti cloud, individuava una complessità ulteriore rispetto all’IT tradizionale proprio nella separazione tra proprietà del cliente e controllo delle infrastrutture sulle quali risiedono tanto le risorse protette quanto i sistemi di gestione delle chiavi.

Cifrare un dato non significa necessariamente controllarlo

La distinzione è meno semantica di quanto possa apparire. Un’organizzazione può avere dati perfettamente cifrati e, contemporaneamente, mantenere una forte dipendenza operativa dal soggetto che ospita quei dati, gestisce il servizio crittografico, applica le policy di accesso e rende possibile il processo di decifratura.

La crittografia protegge il contenuto. La gestione delle chiavi determina invece chi dispone del potere operativo necessario per renderlo nuovamente leggibile.

Per questo il dibattito sulla sovranità digitale non può fermarsi alla domanda “i nostri dati sono cifrati?”. Deve interrogare l’intera catena di controllo: chi genera le chiavi, dove vengono conservate, chi modifica le policy, chi può autorizzarne l’utilizzo, chi può revocarle, quali amministratori dispongono dei privilegi necessari e, soprattutto, cosa accade quando un’organizzazione decide di interrompere l’accesso.

Le linee guida ENISA sul cloud arrivano infatti a includere esplicitamente, tra le misure relative alla sicurezza delle chiavi, la segregazione dei compiti, i processi di recupero e la valutazione dei diversi modelli — provider-managed, client-managed o hold-your-own-key — in funzione del rischio associato ai dati e al business.

Il punto, quindi, non è semplicemente possedere una chiave. È capire quale autorità concreta quel possesso consenta di esercitare.

Customer-managed non significa automaticamente indipendente

Le customer-managed keys rappresentano un’evoluzione importante rispetto alla gestione completamente delegata al provider. Consentono al cliente di intervenire direttamente sul ciclo di vita delle chiavi, sulle autorizzazioni, sulla rotazione e, a seconda dell’implementazione, sulla loro disabilitazione o eliminazione.

Le piattaforme cloud distinguono chiaramente questi modelli. AWS, per esempio, permette al cliente di creare e amministrare proprie KMS key, controllandone policy, abilitazione, rotazione e cancellazione; Google associa alle CMEK il controllo su elementi quali lifecycle, autorizzazioni e versioni delle chiavi.

È un aumento sostanziale della capacità di governo, ma non necessariamente una separazione completa dei domini di controllo.

Se dati, workload, identità amministrative e servizio di key management rimangono all’interno dello stesso ecosistema tecnologico, l’organizzazione ha acquisito maggiore autonomia gestionale senza avere necessariamente costruito un confine indipendente.

Ed è precisamente questa distinzione che interessa un decisore: non quanto sia sofisticato il sistema crittografico, ma quanto sia realmente separata la capacità di autorizzare l’accesso rispetto all’infrastruttura che custodisce ed elabora il dato.

BYOK: portare la chiave non basta

Il modello Bring Your Own Key sposta ulteriormente questo confine. L’organizzazione può generare il materiale crittografico attraverso propri sistemi e successivamente importarlo nell’ambiente cloud. AWS descrive esplicitamente questa possibilità e consente anche di eliminare il materiale importato rendendo la chiave inutilizzabile finché esso non viene nuovamente fornito. Microsoft Azure prevede analogamente scenari BYOK nei quali chiavi protette da HSM possono essere generate esternamente e trasferite verso Key Vault.

Ma anche in questo caso la provenienza della chiave non coincide necessariamente con il controllo assoluto sulla sua operatività.

La domanda strategica diventa quindi: dopo l’importazione, dove avvengono le operazioni crittografiche e chi governa l’infrastruttura necessaria a eseguirle?

È una differenza fondamentale. Avere generato autonomamente una chiave aumenta il controllo sulla sua origine e può offrire garanzie rilevanti in determinati modelli di rischio, ma non equivale automaticamente a mantenere all’esterno del provider l’intera autorità crittografica.

La sovranità, ancora una volta, non deriva dall’etichetta utilizzata dall’architettura, ma dalla distribuzione concreta delle responsabilità.

Il vero salto è separare i domini di controllo

Il passaggio più interessante emerge quando il key management viene separato dall’infrastruttura che custodisce i dati.

I modelli basati su external key management introducono proprio questa discontinuità. Google Cloud EKM, per esempio, permette di utilizzare materiale crittografico custodito presso un sistema esterno: secondo la documentazione del servizio, le chiavi esterne non vengono memorizzate o mantenute in cache all’interno di Google Cloud e l’accesso può essere revocato attraverso il key manager esterno.

Da un punto di vista strategico cambia qualcosa di essenziale: il provider che conserva o processa il dato non dispone necessariamente, da solo, di tutti gli elementi necessari per renderlo utilizzabile.

Nasce così un principio molto più interessante della semplice “proprietà della chiave”: la separazione dell’autorità.

Dati, infrastruttura, identità, key management e autorizzazione alla decifratura possono appartenere a domini differenti, riducendo la concentrazione di potere tecnico in un unico soggetto. È lo stesso principio organizzativo che rende rilevanti segregazione dei ruoli, dual control e split knowledge nelle indicazioni di sicurezza sulla gestione delle chiavi.

Più controllo significa anche più responsabilità

Sarebbe però semplicistico trasformare l’esternalizzazione delle chiavi in una risposta universale.

Separare i domini introduce una conseguenza inevitabile: ciò che prima rappresentava una dipendenza dal provider diventa, almeno in parte, una responsabilità dell’organizzazione. Disponibilità del key manager, continuità operativa, disaster recovery, rotazione, procedure di emergenza e gestione degli errori diventano componenti critiche dell’architettura.

La documentazione di Google relativa agli external key manager esplicita chiaramente questo trade-off: se il servizio EKM non è disponibile, letture e scritture dei servizi integrati possono fallire. Il maggiore controllo sulla protezione del dato deve quindi essere bilanciato con requisiti più elevati di disponibilità e resilienza dell’infrastruttura crittografica.

È un passaggio fondamentale anche culturalmente. La sovranità digitale non consiste nel trasferire ogni responsabilità all’interno dell’azienda, né nel rifiutare per principio i servizi gestiti. Consiste nel decidere consapevolmente quali poteri non si vuole delegare, valutando il costo operativo necessario per conservarli.

Dal possesso della chiave al diritto di veto

È probabilmente questo il criterio con cui le organizzazioni dovranno leggere sempre più spesso le proprie architetture cloud e multi-provider.

Non soltanto chiedersi dove siano i dati, quale algoritmo li protegga o chi formalmente possieda la chiave, ma ricostruire la catena delle autorizzazioni fino alla sua conseguenza più concreta: chi dispone dell’ultima decisione sulla possibilità di decifrare un’informazione?

In questa prospettiva, la chiave crittografica diventa qualcosa di più di uno strumento di cybersecurity. Diventa una rappresentazione tecnica di un’autorità organizzativa.

E proprio per questo la fase successiva della sovranità digitale potrebbe spostare progressivamente l’attenzione dalla proprietà delle infrastrutture alla distribuzione dei poteri che le governano. In ambienti sempre più ibridi, interconnessi e multi-provider, infatti, controllare tutto sarà probabilmente impossibile e spesso persino inefficiente; diventerà invece essenziale stabilire quali decisioni debbano rimanere indipendenti dal singolo fornitore.

Perché il vero controllo non consiste necessariamente nell’avere fisicamente la chiave in mano. Consiste nell’avere, quando serve, il potere effettivo di dire no.

Chi può realmente autorizzare l’accesso ai dati più critici della tua organizzazione?