An enterprise security team is establishing key governance policies for customer-managed encryption keys (CMEK) managed in Google Cloud KMS. The team must revoke access to a compromised encryption key version used by Cloud Storage, enforce the principle of least privilege for the Cloud Storage Service Agent, and ensure that administrative actions cannot destroy key audit history or metadata. Which implementation plan correctly achieves these requirements while adhering to Cloud KMS operational constraints?
- Schedule destruction of the specific compromised Cloud KMS key version and grant the Cloud Storage Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific key, understanding that key rings and keys cannot be deleted.Cevap
- BDelete the entire Cloud KMS key ring using gcloud to immediately purge all key metadata and prevent any future access to encrypted storage objects.
- CGrant the primitive Editor role on the KMS project to the Cloud Storage Service Agent so that it can manage and access all encryption keys across all key rings automatically.
- DAdd an IAM deny policy at the key ring level to override the inherited encryption key access permissions granted to the service account at the organization level.
Cevap
Schedule destruction of the specific compromised Cloud KMS key version and grant the Cloud Storage Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific key, understanding that key rings and keys cannot be deleted.
In Google Cloud KMS, key rings and key names are immutable metadata records that cannot be deleted. To revoke access to compromised key material, administrators must disable or schedule destruction of the specific key version. To grant access to service accounts (such as the Cloud Storage Service Agent) following least privilege, the predefined role Cloud KMS CryptoKey Encrypter/Decrypter should be granted specifically on the required key.
Adım Adım Çözüm
Anahtar Kavram
Cloud KMS Key Lifecycle Management and Least Privilege IAM Access