Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
A Google Cloud architecture diagram showing a key administrator managing a CMEK in Cloud KMS through its lifecycle (create, rotate, disable/destroy), while IAM grants the service agent the cryptoKeyEncrypterDecrypter role so it can encrypt Cloud Storage data at rest, with every key operation recorded in Cloud Audit Logs.
A Google Cloud system architecture showing envelope encryption: a Data Encryption Key (DEK) encrypts customer data with AES-256, while a Key Encryption Key (KEK) in Cloud KMS wraps the DEK. The resulting ciphertext and wrapped DEK are stored together in a Cloud Storage bucket, so rotating the KEK re-wraps DEKs without re-encrypting data.
Google default encryption (GMEK) uses Google-managed keys with AES-256 and envelope encryption, requiring no customer setup but offering no key access logs or lifecycle control. Customer-managed encryption keys (CMEK) give organizations direct control over encryption keys through Cloud KMS or Cloud HSM, enabling key lifecycle management, separation of duties via IAM, and compliance with regulatory mandates.
Cloud External Key Manager (EKM) should be used when regulations demand that encryption keys never reside within Google Cloud infrastructure, providing root-of-trust custody outside Google. This is essential for strictest data sovereignty laws, jurisdictional isolation, and regulatory mandates that cannot be satisfied by CMEK or default encryption, despite increased operational complexity and potential latency.
Key Access Justifications (KAJ) is a feature that provides programmatic control and auditing over when Google services access your encryption keys for decryption. When enabled, KAJ sends a justification notice with a reason code such as CUSTOMER_INITIATED_ACCESS or GOOGLE_INITIATED_SERVICE, and organizations can set policies to allow or deny access based on these granular justifications, maintaining oversight while using managed cloud services like AlloyDB, Firestore, and Vertex AI.
Google Cloud automatically encrypts all customer data at rest using Google-managed encryption keys (GMEK). This default protection uses the AES-256 standard and is always active, providing a strong security baseline across services like storage and databases without any setup. The system uses envelope encryption, where a unique Data Encryption Key (DEK) encrypts each piece of data, and a master Key Encryption Key (KEK) protects the DEK itself; this design makes key rotation efficient.
Default encryption is ideal for general workloads where regulations do not require customer control over keys. It offers operational simplicity, standardized protection, and is cost-effective. However, the customer has no visibility into key access logs and cannot directly manage the keys' lifecycle. Therefore, workloads with strict data sovereignty or regulatory mandates cannot rely solely on default encryption.
Customer-Managed Encryption Keys (CMEK) give organizations direct control over the encryption keys used for their data at rest in Google Cloud, moving beyond Google's default management. This control is necessary for meeting regulatory compliance, data sovereignty, and granular security policy requirements. Implementing CMEK involves creating keys in Cloud Key Management Service (Cloud KMS) or Cloud HSM and then configuring GCP services to use these specific keys for encryption.
The design process focuses on managing the key lifecycle, including automated rotation and destruction (cryptographic shredding). It also enforces separation of duties through Identity and Access Management (IAM), carefully assigning roles like cloudkms.admin and cloudkms.cryptoKeyEncrypterDecrypter to different people or service accounts. The service agent for a GCP service (like the Compute Engine service account) must be granted the cloudkms.cryptoKeyEncrypterDecrypter role on the specific CMEK so the service can encrypt and decrypt data on the customer's behalf.
Operationally, you configure a resource, like a Cloud Storage bucket, to use a CMEK by specifying its full resource name. This ensures all new data written to that resource is encrypted under your key. A critical planning consideration is key availability and disaster recovery; this involves designing cross-region key replication and understanding the impact if a key becomes unavailable. Finally, you can enforce CMEK usage across projects using Organization Policies and audit all key-related actions through Cloud Audit Logs.
Cloud External Key Manager (EKM) allows organizations to keep their encryption keys in their own external key management systems, outside of Google Cloud entirely. This provides root-of-trust custody outside Google, which is essential for meeting the strictest data sovereignty laws, jurisdictional isolation, and regulatory mandates. Organizations connect their external key managers to Google Cloud via a VPC or the public internet.
Key Access Justifications (KAJ) is a feature that provides programmatic control and auditing over when Google services need to access your encryption keys for decryption. When enabled, KAJ sends a justification notice that must be approved before Google can proceed. Each request includes a specific reason code, such as CUSTOMER_INITIATED_ACCESS or GOOGLE_INITIATED_SERVICE. Organizations can set policies to allow or deny access based on these granular justifications, maintaining oversight even while using managed cloud services.
KAJ supports various services like AlloyDB, Firestore, and Vertex AI. Implementing Cloud EKM and KAJ involves weighing enhanced security and compliance control against increased operational complexity and potential latency compared to Google-managed or customer-managed keys. This architecture is chosen when regulations demand that encryption keys never reside within the cloud provider's infrastructure.
A financial enterprise is deploying sensitive workloads to Google Cloud and must satisfy strict data sovereignty and jurisdictional isolation regulations. The enterprise security policy requires that the root-of-trust encryption keys reside exclusively within on-premises Hardware Security Modules (HSMs) outside Google Cloud. Furthermore, all cryptographic communication between Google Cloud services and the on-premises key management systems must traverse private network paths without traversing the public internet, while supporting automated failover between dual on-premises data centers.
Which Cloud External Key Manager (Cloud EKM) architecture should the organization implement?
StudyCerts
StudyCerts