L’encryption at rest e il modello CMEK

Su Google Cloud ogni dato at rest è cifrato di default, senza alcuna configurazione, con chiavi gestite interamente da Google (Google-managed encryption keys). È il livello base: soddisfa molti requisiti ma non dà al cliente controllo sul ciclo di vita della chiave. Quando compliance o policy interne richiedono che sia il cliente a governare la chiave, si passa alle customer-managed encryption key (CMEK) con Cloud KMS. Con CMEK la chiave vive in un key ring dentro un progetto — idealmente un progetto dedicato alla sicurezza, separato dai workload — e il cliente ne controlla creazione, rotazione, disabilitazione e distruzione. Il modello resta envelope encryption: la CMEK è una key encryption key che protegge le data encryption key, non cifra i dati byte per byte. Revocando l’accesso alla CMEK si rendono di fatto illeggibili i dati cifrati.

Cloud HSM e Cloud EKM: dove vive la chiave

Cloud KMS espone diversi protection level dietro la stessa API. Le chiavi software coprono la maggior parte dei casi. Quando un requisito impone hardware certificato, Cloud HSM ospita e usa la chiave in hardware security module validati FIPS 140-2 Level 3: la key material non lascia mai il confine dell’HSM. È la risposta tipica agli scenari “serve FIPS 140-2 Level 3” o “la chiave deve essere non estraibile in hardware”.

Cloud External Key Manager (Cloud EKM) risponde a un requisito diverso: tenere la chiave fuori da Google. La key material risiede presso un external key management partner e Google la invoca via API; se il cliente stacca l’accesso, Google non può decifrare. È la scelta quando la compliance richiede separazione dal cloud provider o “hold your own key” fuori dall’infrastruttura Google. Da non confondere con Cloud HSM (chiave in hardware ma dentro Google) né con la CMEK software.

Rotazione, separazione dei ruoli e CMEK sui servizi

La key rotation limita la quantità di dati protetti da una singola versione di chiave e riduce l’impatto di una compromissione. Cloud KMS supporta la rotazione automatica a intervalli e quella manuale on-demand; le versioni precedenti restano disponibili per decifrare i dati storici finché non vengono disabilitate o distrutte. Il principio di ruotare periodicamente resta valido anche per HSM ed EKM.

Sulle chiavi si applica IAM con separazione dei ruoli secondo least privilege: chi amministra la chiave (Cloud KMS Admin) non deve poterla usare per cifrare/decifrare, e chi la usa (Encrypter/Decrypter) non deve poterla gestire o distruggere. Questa separation of duties è un pattern d’esame ricorrente. Le CMEK si applicano ai servizi: Cloud Storage a livello di bucket, BigQuery a livello di dataset o tabella, Compute Engine su dischi persistenti e immagini. Ogni servizio usa un proprio service agent a cui va concesso l’accesso alla chiave; senza quella grant l’operazione fallisce. Le organization policy possono inoltre imporre CMEK come guardrail preventivo sull’intera organization.

Encryption in transit

Google protegge il traffico in transito. Dentro la rete Google i dati scambiati tra i servizi sono cifrati o autenticati automaticamente; verso l’esterno il traffico viaggia su TLS. Per i propri workload il cliente rafforza la difesa con TLS terminato sui load balancer, managed certificates e mTLS/service mesh per l’autenticazione servizio-a-servizio. Encryption in transit ed encryption at rest sono controlli complementari, non alternativi: difesa in profondità.

Trappole tipiche d’esame

  • Serve FIPS 140-2 Level 3 → Cloud HSM: non basta la CMEK software; occorre il protection level HSM. Cloud EKM non è la risposta a un requisito “hardware FIPS”.
  • La chiave deve stare fuori da Google → Cloud EKM: Cloud HSM tiene la chiave in hardware ma pur sempre dentro Google; solo EKM la mantiene presso il partner esterno.
  • Revocare l’accesso ai dati rapidamente → disabilita/revoca la CMEK: disabilitare o distruggere la key version rende i dati illeggibili, senza doverli cancellare uno per uno.
  • Key admin che cifra e decifra → separa i ruoli: assegna Encrypter/Decrypter a chi usa la chiave e Admin a chi la gestisce; mai concentrare entrambi sullo stesso principal.
  • CMEK impostata ma il servizio fallisce → grant al service agent: ogni servizio (Cloud Storage, BigQuery, Compute Engine) ha un service account dedicato che deve avere l’accesso alla chiave.
  • Imporre CMEK su tutta l’organization → organization policy: è un guardrail preventivo; IAM da solo non obbliga i team a usare CMEK.