KMS on My personal blog

Crittografia dei dati nel cloud

Tue, 28 Jul 2026 09:00:00 +0200

Perché conta

La cifratura è l’ultima rete di sicurezza: quando l’identità, la rete e la configurazione hanno fallito e un attaccante mette le mani sui dati, la cifratura decide se trova informazioni o solo rumore. Nel cloud è quasi sempre disponibile, spesso attiva di default, e costa poco o nulla in prestazioni grazie all’accelerazione hardware. La domanda non è più “cifrare sì o no”, ma dove, come, e soprattutto chi tiene le chiavi.

I due fronti: a riposo e in transito

  flowchart LR
    subgraph REST["A riposo (at rest)"]
        DB[(Disco / DB / storage)]
        DB -.cifrato con.-> K1[Chiave dal KMS]
    end
    subgraph TRANSIT["In transito (in transit)"]
        C[Client] -->|TLS| S[Servizio]
    end
    style K1 fill:#fde2e4,stroke:#e63946

A riposo: dischi, database, storage a oggetti, backup, snapshot. Si appoggia alla crittografia a busta del KMS vista prima: i dati sono cifrati con chiavi dati, le chiavi dati con la master.
In transito: ogni byte che viaggia in rete, protetto da TLS. Vale non solo verso Internet ma anche dentro la tua rete cloud: tra servizi, verso il database, tra microservizi. “Rete privata” non significa “rete fidata”.

Chi tiene le chiavi: il vero controllo

Chi controlla la chiave controlla i dati. Le opzioni, dalla più comoda alla più controllata:

Chiavi gestite dal provider   → comode, zero gestione, il provider può tecnicamente accedervi
Chiavi gestite da te nel KMS  → tu decidi rotazione, revoca e policy d'uso (raccomandato)
BYOK (bring your own key)     → importi la tua chiave nel KMS del provider
HYOK / external key           → la chiave resta fuori dal cloud, sotto il tuo controllo totale

Per la maggior parte dei casi, chiavi tue gestite nel KMS del provider è il giusto equilibrio: controlli policy, rotazione e revoca (revocare la chiave rende i dati illeggibili all’istante, un “interruttore d’emergenza” potente), senza l’onere operativo di custodire hardware. BYOK e chiavi esterne servono a requisiti di compliance o sovranità del dato più stringenti.

La cifratura non sostituisce il controllo d’accesso

Un equivoco frequente: “i dati sono cifrati, quindi sono al sicuro”. La cifratura a riposo protegge contro chi ruba il supporto fisico o un backup — non contro chi ha i permessi IAM per leggere i dati attraverso il servizio, perché per lui la decifratura è trasparente. Un bucket cifrato ma pubblico resta un data breach. La cifratura è complementare al controllo d’accesso, non un suo sostituto.

Domanda: se il provider offre la cifratura a riposo attiva di default e gestisce lui le chiavi, perché dovrei complicarmi la vita con chiavi mie nel KMS? I dati sono già cifrati.

Perché "cifrati con chiavi del provider" e "cifrati con chiavi tue" proteggono da minacce diverse, e la differenza conta proprio nei casi che ti tengono sveglio la notte. Con le chiavi gestite dal provider ottieni la protezione base — se qualcuno ruba un disco fisico dal data center, trova rumore — ed è già meglio di niente. Ma non ottieni tre cose. Primo, il controllo della revoca: con una chiave tua puoi, in caso di incidente o sospetto, revocarla e rendere i dati immediatamente illeggibili a chiunque, incluse applicazioni compromesse che avevano i permessi — è un interruttore d'emergenza che le chiavi del provider non ti danno. Secondo, la separazione dei poteri: con chiavi tue, l'accesso ai dati richiede sia il permesso sul servizio sia il permesso sulla chiave KMS, due controlli IAM distinti che puoi affidare a ruoli diversi — così nessuna singola identità, da sola, decifra tutto. Terzo, la garanzia verso terzi e la compliance: molti requisiti normativi e contrattuali chiedono che il cliente, non il provider, controlli le chiavi; con chiavi tue hai log d'uso delle chiavi, policy esplicite e la possibilità di dimostrare chi può decifrare cosa. Sul "complicarmi la vita": gestire una chiave nel KMS del provider è questione di pochi clic o poche righe di IaC — non stai custodendo hardware, stai solo spostando la proprietà logica della chiave dal provider a te. Il costo è minimo, il controllo che guadagni è sostanziale. Le chiavi del provider vanno bene per dati a basso rischio; per tutto ciò che conta, le chiavi tue sono lo standard ragionevole.

Conclusione

Cifrare a riposo e in transito è la rete di sicurezza finale, ma il controllo vero sta nelle chiavi: gestirle tu nel KMS dà revoca, separazione dei poteri e compliance, mentre la cifratura resta complementare — mai sostitutiva — del controllo d’accesso. Il servizio dove questi principi si scontrano più spesso con la realtà degli incidenti è lo storage a oggetti, i famigerati bucket. È il prossimo capitolo, sicurezza dello storage a oggetti.

Gestione dei segreti e KMS

Tue, 21 Jul 2026 09:00:00 +0200

Perché conta

L’identità dei workload elimina le chiavi del cloud, ma restano i segreti che il cloud non gestisce per te: la password del database, il token dell’API di pagamento, la chiave di un partner, un certificato privato. Metterli in chiaro nel codice, in un file .env committato, o in una variabile d’ambiente leggibile da chiunque ispezioni il processo, è un errore classico e devastante. Servono due strumenti distinti ma collegati: un secrets manager per custodire i segreti, e un KMS per gestire le chiavi che li cifrano.

Secrets manager: la cassaforte

Un secrets manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) conserva i segreti cifrati a riposo, li espone solo a identità autorizzate via IAM, ne tiene le versioni e può ruotarli automaticamente.

  flowchart LR
    APP[Applicazione] -->|"chiede il segreto<br/>(autenticata via IAM)"| SM[Secrets Manager]
    SM -->|"segreto decifrato<br/>in memoria, a richiesta"| APP
    SM -.cifra/decifra con.-> KMS[(KMS)]
    style SM fill:#fde2e4,stroke:#e63946

Il valore non sta più nel codice: l’applicazione lo chiede a runtime, autenticandosi con la sua identità di workload. Così il segreto si cambia senza ridistribuire l’app, e ogni accesso è tracciato.

KMS e la crittografia a busta

Il KMS (Key Management Service) non conserva i tuoi dati: gestisce le chiavi. Il meccanismo centrale è la crittografia a busta (envelope encryption): invece di cifrare gigabyte di dati con la chiave master (che non lascia mai il KMS), si genera una chiave dati usa-e-getta, con questa si cifrano i dati, e si conserva solo la chiave dati a sua volta cifrata dalla master.

1. KMS genera una Data Key  → in chiaro (DK) + cifrata dalla master (DK_enc)
2. Cifri i dati con DK      → poi CANCELLI DK dalla memoria
3. Salvi insieme ai dati:   DK_enc  (la chiave dati cifrata)
4. Per decifrare: mandi DK_enc al KMS → ti ridà DK → decifri → scarti DK

Formalmente, con dati $D$, chiave dati $K$ e chiave master $M$:

$$ C = \text{Enc}K(D), \qquad K{enc} = \text{Enc}_M(K) $$

si archivia la coppia $(C, K_{enc})$ e la master $M$ resta sempre dentro il KMS. Il vantaggio: la chiave master, la più preziosa, non esce mai e non tocca mai i dati; ruotarla o revocarla ha effetto immediato; e i permessi d’uso delle chiavi passano per l’IAM, quindi puoi dire chi può decifrare cosa senza dare a nessuno la chiave in mano.

Rotazione: il segreto che cambia

Un segreto che non cambia mai è un segreto che, se trapela, resta valido per sempre. La rotazione periodica — automatica dove possibile — limita la finestra d’esposizione. I secrets manager moderni ruotano le credenziali di database generando la nuova, aggiornandola sul database e nel segreto in modo coordinato, senza downtime.

Domanda: se l'applicazione deve comunque leggere il segreto in chiaro per usarlo, e un attaccante che compromette l'app può leggerlo dalla memoria, a cosa serve tutta l'infrastruttura di secrets manager e KMS?

Serve a moltissimo, perché cambia completamente la superficie e la durata dell'esposizione, anche se è vero che nessun sistema può nascondere un segreto all'applicazione che lo deve usare. Senza secrets manager, il segreto è esposto ovunque e sempre: nel codice sorgente (quindi in Git, nella cronologia, in ogni clone, in ogni fork), nei file di configurazione, nelle immagini dei container, nei backup, nei log di deploy. Un attaccante non ha bisogno di compromettere l'app in esecuzione: gli basta trovare il repository, un backup o un'immagine. Con il secrets manager, il segreto esiste in chiaro solo in memoria, nel processo vivo, per il tempo d'uso: per rubarlo devi compromettere quel processo specifico in quel momento, che è enormemente più difficile che trovare una stringa in un file. In più ottieni tre cose che il segreto in chiaro non dà: tracciamento (sai chi e quando ha letto il segreto, quindi un accesso anomalo si vede), rotazione (se sospetti una fuga, cambi il segreto in un punto solo e tutte le app lo prendono nuovo, senza ridistribuire nulla), e controllo d'accesso (solo le identità autorizzate via IAM lo leggono, non "chiunque abbia accesso al filesystem"). Sul KMS il discorso è ancora più netto: la chiave master non entra mai nella memoria dell'applicazione — l'app manda al KMS la chiave dati cifrata e riceve quella in chiaro, ma la master resta nel modulo hardware del provider, irraggiungibile anche se l'app è completamente compromessa. La sicurezza perfetta non esiste; ridurre l'esposizione da "sempre, in mille posti" a "solo in memoria, nel momento d'uso, tracciata e revocabile" è esattamente il lavoro che conta.

Conclusione

I segreti inevitabili vanno in un secrets manager — cifrati, versionati, ruotabili, serviti a runtime all’identità autorizzata — e il KMS gestisce le chiavi con la crittografia a busta, tenendo la master sempre al sicuro. Questo meccanismo di cifratura non riguarda solo i segreti: è la base per proteggere tutti i dati a riposo e in transito. È il tema della crittografia dei dati nel cloud, prossimo capitolo.