Cos'e' un KMS#
Un Key Management System e' la console centralizzata che gestisce tutti i tipi di chiavi crittografiche dell'organizzazione da un unico punto. TPM gestisce le chiavi di una singola macchina. HSM gestisce le chiavi di un data center. Il KMS gestisce l'insieme di tutti i tipi di chiavi distribuite su centinaia di sistemi.
Centralizza la generazione, distribuzione, rotazione e revoca di tutte le chiavi crittografiche, applicando il principio fondamentale: le chiavi devono sempre stare fisicamente separate dai dati che proteggono.
TL;DR#
- Il KMS e' il layer di gestione sopra a TPM e HSM: non e' lui che esegue la crittografia, ma e' lui che decide chi puo' usare quale chiave, quando la chiave va ruotata, e registra ogni operazione.
- Il principio fondamentale e' la separazione fisica: se le chiavi vivono sullo stesso sistema dei dati cifrati, un attaccante che compromette il sistema ottiene entrambi. Il KMS separa i segreti dai dati.
- I KMS cloud moderni (AWS KMS, Azure Key Vault) usano envelope encryption: la chiave master non viene mai usata direttamente per cifrare dati bulk, ma solo per proteggere la DEK (data encryption key) che a sua volta cifra i dati reali.
Key Lifecycle#
Il ciclo di vita di una chiave crittografica ha fasi precise. Ogni fase ha implicazioni di sicurezza distinte e l'esame puo' chiederti cosa succede in ognuna.
| Fase | Descrizione | Rischio se gestita male |
|---|---|---|
| Generazione | Creazione della chiave con entropia sicura (TRNG, HSM) | Chiave debole o prevedibile se generata con PRNG software non sicuro |
| Distribuzione | Trasmissione su canale cifrato solo ai sistemi autorizzati | Intercettazione della chiave in transito (man-in-the-middle) |
| Uso | Audit log di ogni operazione crittografica | Uso non autorizzato non rilevato |
| Rotazione | Sostituzione periodica con nuova chiave | Finestra di esposizione indefinita se la chiave viene compromessa |
| Revoca | Invalidazione immediata in caso di breach o cambio ruolo | Accesso continuo a sistemi con chiave compromessa |
| Distruzione | Cancellazione sicura del materiale crittografico | Recupero della chiave da storage non sanificato |
Key Rotation#
La key rotation e' la pratica di sostituire periodicamente le chiavi crittografiche. E' il controllo che limita il danno quando una chiave viene compromessa.
La logica e' semplice: se una chiave e' esposta, l'attaccante puo' decifrare solo i dati cifrati con quella chiave nel periodo in cui era valida. Con rotazione frequente, quella finestra e' ristretta. Senza rotazione, una singola compromissione espone tutti i dati cifrati con quella chiave da quando e' stata generata.
flowchart LR
classDef key fill:#1d3557,stroke:#457b9d,stroke-width:2px,color:#fff
classDef breach fill:#9b2226,stroke:#ae2012,stroke-width:2px,color:#fff
classDef safe fill:#2a9d8f33,stroke:#2a9d8f,stroke-width:2px,color:#e9f5f4
classDef spacer fill:none,stroke:none,color:none
K1["🔑 Chiave 1 (gen - mar)"]:::key
K2["🔑 Chiave 2 (apr - giu)"]:::key
K3["🔑 Chiave 3 (lug - set)"]:::key
BREACH["⚠️ Chiave 2 compromessa"]:::breach
IMPACT["Dati apr-giu esposti"]:::breach
SAFE["Dati gen-mar e lug-set al sicuro"]:::safe
K1 --> K2
K2 --> K3
K2 --> BREACH
BREACH --> IMPACT
K1 --> SAFE
K3 --> SAFE
I KMS moderni automatizzano la rotazione. In AWS KMS e' configurabile con una singola policy (es. rotazione annuale automatica). In Azure Key Vault e' gestibile via lifecycle policy. La rotazione non interrompe i servizi: il KMS mantiene le vecchie versioni della chiave per decifrare i dati cifrati in precedenza, ma usa la nuova versione per cifrare i nuovi dati.
KMS = gestione centralizzata di tutte le chiavi. Il principio chiave: keys must be separate from the data they protect. Keyword: "automatic key rotation", "centralized key management", "key lifecycle" → KMS.
Envelope Encryption#
L'envelope encryption e' il pattern usato da AWS KMS, Azure Key Vault e praticamente tutti i KMS cloud per bilanciare sicurezza e performance. Non si cifra mai direttamente con la chiave master (CMK/KEK) perche' sarebbe troppo lento per dati bulk e creerebbe un single point of failure.
Il pattern: la CMK genera una DEK (data encryption key) usa-e-getta. La DEK cifra i dati reali. La CMK cifra la DEK. I dati cifrati e la DEK cifrata vengono salvati insieme. La CMK non lascia mai il KMS.
flowchart TD
classDef kms fill:#1d3557,stroke:#457b9d,stroke-width:2px,color:#fff
classDef dek fill:#457b9d,stroke:#a8dadc,stroke-width:2px,color:#fff
classDef data fill:#2b2d42,stroke:#8d99ae,stroke-width:2px,color:#fff
classDef stored fill:#2a9d8f33,stroke:#2a9d8f,stroke-width:2px,color:#e9f5f4
classDef spacer fill:none,stroke:none,color:none
CMK["🔑 CMK - Customer Master Key (resta nel KMS)"]:::kms
DEK["🗝️ DEK - Data Encryption Key (generata per questa operazione)"]:::dek
DATA["📄 Dati in chiaro"]:::data
ENC_DATA["📄 Dati Cifrati (con DEK)"]:::stored
ENC_DEK["🗝️ DEK Cifrata (con CMK)"]:::stored
STORED["💾 Salvati insieme nello storage"]:::stored
SP[" "]:::spacer
subgraph KMS_BOUNDARY ["KMS - La CMK non esce mai"]
SP
CMK
end
SP ~~~ CMK
CMK -->|1 - Genera| DEK
DEK -->|2 - Cifra| DATA
DATA -->|3 - Produce| ENC_DATA
CMK -->|4 - Cifra la DEK| ENC_DEK
ENC_DATA --> STORED
ENC_DEK --> STORED
Per decifrare:
- Recupera DEK cifrata dallo storage
- Chiama il KMS con la DEK cifrata
- Il KMS usa la CMK per decifrarla e restituisce la DEK in chiaro
- Usa la DEK per decifrare i dati
- Butta via la DEK in chiaro dalla memoria
La CMK non lascia mai il KMS. Il sistema che ha i dati non ha mai accesso diretto alla chiave master.
Dev parallel (AWS S3 con SSE-KMS):
aws kms encrypt --key-id alias/my-key --plaintext fileb://secret.txt. I dati in S3 cifrati con SSE-KMS usano envelope encryption: AWS genera una DEK per ogni oggetto, la usa per cifrare il file, poi cifra la DEK con la CMK e butta via la DEK in chiaro. Per decifrare serve prima chiamare KMS per ottenere la DEK.
Dev parallel (PHP/Node): In PHP/Node non si usa mai direttamente la CMK per cifrare dati bulk. Si usa envelope encryption: la CMK viene usata solo per proteggere la DEK, che a sua volta cifra i dati veri. Stessa logica di bcrypt con il salt: si separa la chiave dai dati, si delimita il raggio d'azione di ogni materiale crittografico.
AWS KMS e Azure Key Vault#
I due KMS cloud dominanti implementano gli stessi principi con interfacce diverse. L'esame SY0-701 li cita come esempi di KMS cloud.
| AWS KMS | Azure Key Vault | |
|---|---|---|
| Chiave master | CMK (Customer Master Key) | Key (+ Managed HSM tier) |
| Cosa gestisce | Solo chiavi (encrypt/decrypt) | Chiavi + Segreti + Certificati |
| HSM-backed | Si (CloudHSM per tier dedicato) | Si (Managed HSM) |
| BYOK | Si, importazione chiave | Si, importazione chiave |
| Integrazione | Tutti i servizi AWS (S3, EBS, RDS) | Tutti i servizi Azure (Storage, SQL, VM) |
Separazione delle Responsabilita'#
Il principio di separazione delle responsabilita' applicato alle chiavi crittografiche: chi cifra i dati non deve avere accesso alla chiave master. Questo e' il controllo che limita il blast radius in caso di compromissione di un singolo account o sistema.
In pratica:
- Il servizio applicativo ha permesso solo di usare la DEK per cifrare/decifrare dati
- Solo l'amministratore KMS puo' creare, ruotare o revocare le CMK
- L'audit log del KMS e' immutabile e separato dal sistema che usa le chiavi
Se le chiavi vivono sullo stesso sistema dei dati cifrati, un attaccante che compromette il sistema ottiene entrambi. Il KMS separa fisicamente i segreti dai dati: anche compromettendo l'applicazione o il database, l'attaccante non ha le chiavi per decifrare i dati.
Collegato a#
- crypto - Hub crypto: KMS e' il layer di gestione sopra gli algoritmi crittografici
- cryptography - Fondamenta teoriche delle chiavi che il KMS gestisce
- pki - PKI usa il KMS per gestire i certificati della CA
- ssl-tls - I certificati TLS gestiti dal KMS proteggono le connessioni HTTPS
- hashing - Differenza tra hashing (non invertibile) e cifratura simmetrica (invertibile con chiave)
