Professional Cloud Security Engineer

Evaluate and Implement Key Management Models for Data at Rest

Key Management Tiers and Decision Criteria

Google Cloud encrypts all data at rest by default using Google-managed encryption keys, but organizations often require greater control to satisfy strict compliance and governance requirements. Depending on the level of operational control and sovereignty needed, security teams can select between three primary customer-managed alternatives:

• Customer-Managed Encryption Keys (CMEK) store keys inside Cloud Key Management Service (Cloud KMS) and offer software-backed, hardware-backed (Cloud HSM with FIPS 140-2 Level 3 validation), or external protection levels.
• Customer-Supplied Encryption Keys (CSEK) require the client to supply raw cryptographic keys with every API call to Cloud Storage or Compute Engine, ensuring Google never stores the key material.
• External Key Management (Cloud EKM) keeps key material inside a third-party key manager outside Google Cloud, providing the highest level of regulatory sovereignty at the cost of dependency on external network latency and availability.

Access Control, Lifecycle, and Service Integration

Integrating customer-managed keys across services such as BigQuery, Cloud Storage, and Cloud SQL requires precise alignment between network regions and security policies. The Cloud KMS key must reside in the exact same region or multi-region as the resource it protects to prevent cross-region operational failures. In addition, the target service's Google-managed service agent must hold the roles/cloudkms.cryptoKeyEncrypterDecrypter role on the specific key resource.

Managing the key lifecycle involves balancing automated key rotation policies with disaster recovery controls. Disabling or destroying a key immediately renders all data encrypted with that key permanently inaccessible, establishing a hard cryptographic erasure boundary. Security administrators must audit key access logs continuously and monitor key rotation lifecycles to protect operational availability while maintaining defense in depth.

Enforce Cryptographic Controls for Data in Transit and Data in Use

Network Encryption in Transit

Securing data in transit requires layered cryptographic controls that span external, hybrid, and internal network boundaries. Organizations use Cloud VPN with IPsec tunnels or Cloud Interconnect with MACsec to maintain confidentiality across hybrid and multi-cloud links. Internal traffic between Google Cloud services is automatically authenticated and encrypted using Application Layer Transport Security (ALTS) alongside modern TLS configurations. For administrative sessions, routing user traffic through Identity-Aware Proxy (IAP) provides context-aware authentication and end-to-end encryption before traffic reaches backend compute instances.

Hardware-Rooted Memory Protection for Data in Use

While transit and storage controls protect static and moving data, encryption in use safeguards active memory during live computation. Confidential Computing creates hardware-based Trusted Execution Environments (TEEs) that isolate workloads from the underlying host operating system and hypervisor without requiring application code changes. Organizations deploy Confidential VMs or Confidential Space to process sensitive datasets across several hardware-isolated architectures:

• AMD SEV and SEV-SNP provide hardware-based memory encryption that prevents memory-remapping and replay attacks.
• Intel TDX establishes isolated trust domains that shield runtime memory from active physical inspection.
• NVIDIA Confidential Computing extends hardware-level TEE protections to GPU memory for secure machine learning workloads.

Cryptographic trust extends across storage and hardware components through verified roots of trust. Administrators can enable confidential modes for Hyperdisk Balanced to isolate block storage cryptographic operations inside a hardware enclave. Integrated hardware roots of trust like Titan and Caliptra continuously verify platform integrity and provide attestation proofs before sensitive workloads execute.

Design Client-Side and Application-Layer Encryption Architectures

Envelope Encryption with Cryptographic Libraries

Client-side encryption safeguards data before it ever reaches cloud infrastructure, giving organizations full control over application payloads. Google recommends using the Tink cryptographic library, which provides uniform APIs across multiple programming languages to simplify complex cryptographic tasks. Tink enforces standard cryptographic practices and prevents common implementation errors when encrypting data before writing it to databases or object stores.

At the core of this pattern is envelope encryption, which optimizes performance and key management at scale:

1. The application generates a unique Data Encryption Key (DEK) locally to encrypt a specific data chunk or payload.
2. The local DEK is wrapped (encrypted) using a centralized Key Encryption Key (KEK) managed inside Cloud KMS.
3. The application stores the encrypted DEK alongside the encrypted ciphertext and discards the plaintext DEK from memory.
4. When reading data, the application sends the wrapped DEK to Cloud KMS to unwrap it with the KEK, allowing local decryption of the payload.

Field-Level Encryption and Sensitive Data De-identification

When applications store structured records in analytical platforms like BigQuery, field-level encryption protects sensitive fields without requiring whole-table encryption. BigQuery uses Authenticated Encryption with Associated Data (AEAD) functions and keysets to encrypt and decrypt individual columns directly within SQL queries. This approach ensures that only analysts with specific key access can read cleartext values, while unauthorized users see only ciphertext.

For broader compliance needs, Sensitive Data Protection provides advanced de-identification techniques that preserve data utility for analytical workloads:

• Tokenization substitutes sensitive values with reversible surrogate tokens while maintaining original format structures.
• Format-Preserving Encryption (FPE) encrypts fields such as credit card or national identification numbers while keeping their original character set and length.
• Cryptographic hashing, masking, bucketing, and date-shifting provide irreversible or generalized transformations for non-reversible anonymization.

These de-identification transformations can be combined with CMEK-backed keys and automated across enterprise data pipelines using Dataflow templates, creating a scalable compliance architecture.