Description
Long-lived encryption keys can leave more data dependent on one key version. Configure automatic rotation for Cloud KMS symmetric encryption keys according to the required schedule. Rotation creates a new primary version; it does not re-encrypt existing data or automatically disable earlier versions.
Potential impact
- Compromise of a key version can affect data encrypted with that version.
- Treating rotation alone as revocation of a compromised key can leave necessary response actions undone.
Remediation
- Set rotation_period according to your cryptographic policy. Use 7776000s if a 90-day period is required; asymmetric keys need a separate rotation process.
- Check use of earlier versions and whether data needs re-encryption. If a key is compromised, restrict access and disable the affected versions as appropriate, first assessing recovery and the ability to decrypt existing data.
Examples
These excerpts compare the rotation period for the same key. 100000s is an example, not a recommended interval for every environment.
Before
hcl
resource "google_kms_crypto_key" "crypto_key" {
name = "crypto-key-example"
key_ring = google_kms_key_ring.keyring.id
rotation_period = "77760009s"
lifecycle {
prevent_destroy = true
}
}
After
hcl
resource "google_kms_crypto_key" "crypto_key" {
name = "crypto-key-example"
key_ring = google_kms_key_ring.keyring.id
rotation_period = "100000s"
lifecycle {
prevent_destroy = true
}
}
Explanation:
- Before: A long rotation period is configured. Check whether it meets actual policy and data-use requirements.
- After: A shorter period is configured. This change does not by itself handle existing data or earlier key versions.