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