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.
Professional Cloud Security Engineer
Gauge your current knowledge
Gauge your current knowledge
StudyCerts
StudyCerts