8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM

Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM

Core Principle: Google Cloud enforces a multi-layered, defense-in-depth cryptographic model protecting data across all three states: at rest, in transit, and in use. By default, 100% of customer data stored on Google Cloud is encrypted using AES-256 with zero administrative configuration required. For enterprise compliance, architects leverage Cloud KMS, Cloud HSM, Cloud EKM, and Confidential Computing to retain absolute cryptographic custody, enable crypto-shredding, and protect memory payloads.

---

Google Cloud Default Encryption: At Rest, In Transit & In Use

Google Cloud provides automated, zero-overhead encryption across its global infrastructure without requiring customer intervention or licensing fees.

+-----------------------------------------------------------------------------------+
|                    GOOGLE CLOUD DEFAULT ENCRYPTION ARCHITECTURE                   |
+-----------------------------------------------------------------------------------+
|  DATA AT REST      |  - 100% encrypted by default using AES-256 (or AES-128)      |
|                    |  - Storage chunks encrypted at the storage sublayer          |
|                    |  - Multi-tier envelope encryption (DEK wrapped by KEK)       |
+--------------------+---------------------------------------------------------------+
|  DATA IN TRANSIT   |  - External: TLS 1.3 / HTTPS terminated at Google Front Ends |
|                    |  - Inter-Data Center: Hardware-level MACsec / WAN encryption |
|                    |  - Internal Service-to-Service: ALTS (mutual auth + AES-GCM)  |
+--------------------+---------------------------------------------------------------+
|  DATA IN USE       |  - Confidential Computing (AMD SEV / SEV-SNP memory encrypt)  |
|                    |  - Memory encrypted in hardware via ephemeral CPU AES keys   |
+-----------------------------------------------------------------------------------+

1. Data at Rest Encryption

• Chunk-Level Encryption: Every file written to Google Cloud (Cloud Storage, Persistent Disk, BigQuery, Cloud Spanner) is automatically broken into individual storage chunks. Each chunk is encrypted with its own ephemeral Data Encryption Key (DEK) using AES-256 (or AES-128) in Galois/Counter Mode (GCM).
• Google-Managed Keys: By default, Google manages the Key Encryption Keys (KEKs) that wrap and protect the DEKs, rotating them regularly and storing them within Google's internal Key Management Service.

2. Data in Transit Encryption

• External to Google Cloud: Network traffic between external clients and Google Cloud services is encrypted using TLS 1.2 or TLS 1.3 and terminated at the global Google Front End (GFE) points of presence.
• Internal Private Backbone: Network traffic moving between Google data centers over Google's global fiber backbone is encrypted at the physical/data link layer using MACsec and encapsulated within Google's proprietary routing infrastructure.
• Application Layer Transport Security (ALTS): For internal RPCs communicating between microservices across Google's infrastructure, Google uses ALTS—a custom mutual-authentication and transport encryption protocol providing authenticated and encrypted channels using AES-128-GCM.

3. Data in Use (Confidential Computing)

• Standard hypervisors and host operating systems have visibility into virtual machine RAM. To eliminate this vector, Confidential Computing uses hardware-based memory encryption to protect data while being actively processed by CPUs.

Comparison of Encryption States & Protocols

---

Envelope Encryption Mechanics (DEK vs. KEK)

Encrypting multi-gigabyte or terabyte files directly with a centralized key management service introduces massive network latency and creates a catastrophic bottleneck. Google Cloud solves this using Envelope Encryption.

+-----------------------------------------------------------------------------------+
|                         ENVELOPE ENCRYPTION WRITE FLOW                            |
+-----------------------------------------------------------------------------------+
|  1. Storage Engine generates local, ephemeral Data Encryption Key (DEK)          |
|  2. Raw Data Chunk + DEK  ====(AES-256 Local Encrypt)====> Encrypted Data Chunk    |
|  3. DEK  ====(Send to Cloud KMS via TLS)====> Cloud KMS wraps DEK with KEK       |
|  4. Cloud KMS returns Wrapped DEK (Encrypted DEK)                                |
|  5. Encrypted Data Chunk + Wrapped DEK stored together on disk                   |
|  6. Raw DEK is immediately purged from host memory                               |
+-----------------------------------------------------------------------------------+

+-----------------------------------------------------------------------------------+
|                         ENVELOPE ENCRYPTION READ FLOW                             |
+-----------------------------------------------------------------------------------+
|  1. Storage Engine reads Wrapped DEK from storage metadata                       |
|  2. Wrapped DEK  ====(Send to Cloud KMS via TLS)====> Cloud KMS unwraps DEK      |
|  3. Cloud KMS checks IAM permissions on KEK -> Decrypts DEK using KEK             |
|  4. Cloud KMS returns raw DEK to storage engine over TLS                          |
|  5. Encrypted Data Chunk + raw DEK ====(AES-256 Local Decrypt)====> Plaintext    |
|  6. Raw DEK is purged from host memory                                            |
+-----------------------------------------------------------------------------------+

Architectural Benefits of Envelope Encryption

1. Performance & Scalability: Bulk data is encrypted and decrypted locally at wire speed directly on the storage node. Only tiny 256-bit DEKs traverse the network to Cloud KMS.
2. Security & Key Isolation: The master Key Encryption Key (KEK) never leaves the boundary of Cloud KMS or Cloud HSM. Even if an attacker gains physical access to the storage disks, the wrapped DEK cannot be decrypted without IAM access to the KEK.
3. Fast Re-encryption & Key Rotation: When a KEK is rotated, existing data chunks do not need to be re-encrypted. Only the small wrapped DEK needs to be re-wrapped with the new KEK version, or new writes simply adopt the newest KEK version.

---

Cloud Key Management Service (Cloud KMS) Architecture

Cloud KMS is a cloud-hosted key management service that allows organizations to generate, use, rotate, and destroy cryptographic keys across multi-region, regional, and global scopes.

+-----------------------------------------------------------------------------------+
|                            CLOUD KMS HIERARCHY MODEL                              |
+-----------------------------------------------------------------------------------+
|  ORGANIZATION / FOLDER                                                            |
|    └── PROJECT                                                                    |
|          └── LOCATION (e.g., global, us-central1, europe-west1)                  |
|                └── KEY RING (Logical collection; inherits IAM; cannot be deleted) |
|                      └── CRYPTOKEY (Defines purpose, rotation schedule, HSM/Soft) |
|                            ├── CRYPTOKEYVERSION 1 (Enabled / Disabled / Destroyed)|
|                            ├── CRYPTOKEYVERSION 2 (Primary - used for encryption) |
|                            └── CRYPTOKEYVERSION 3 (Pending destruction)           |
+-----------------------------------------------------------------------------------+

Key Hierarchy & Lifecycle States

• Key Rings: Organize keys within a specific GCP region or multi-region. Key rings cannot be deleted after creation to preserve cryptographic audit trails, but individual keys within them can be destroyed.
• CryptoKey Purpose: Keys are created for specific cryptographic operations:
  • Symmetric Encryption/Decryption: AES-256-GCM (used for CMEK across Google Cloud services).
  • Asymmetric Signing/Verification: RSA (2048, 3072, 4096-bit) and Elliptic Curve (ECDSA P-256, P-384, Secp256k1).
  • Asymmetric Decryption: RSA-OAEP encryption.
  • Message Authentication Codes (MAC): HMAC-SHA256.
• CryptoKeyVersion States:
  • Enabled: Available for cryptographic operations.
  • Disabled: Temporarily revoked; existing data cannot be decrypted until re-enabled.
  • Destroy scheduled: Placed in a configurable soft-delete destruction window (default 24 hours to 30 days).
  • Destroyed: Key material is permanently and irreversibly purged from KMS infrastructure.

Protection Levels: Software vs. HSM vs. EKM vs. CSEK

[!CAUTION] Customer-Supplied Encryption Keys (CSEK) Danger: With CSEK, Google never stores the encryption key on disk or in Cloud KMS. The customer supplies the 256-bit AES key string directly in the HTTP request headers (x-goog-encryption-key). If the customer loses or forgets this key, Google cannot recover the data under any circumstances, resulting in permanent, unrecoverable data loss.

---

Customer-Managed Encryption Keys (CMEK) Enterprise Integration

CMEK bridges Google Cloud managed services (Compute Engine, BigQuery, Cloud Storage, Cloud SQL, Pub/Sub, Dataproc, GKE) with Cloud KMS, empowering enterprise security teams to retain control over key rotation, IAM permissions, and instant data revocation.

+-----------------------------------------------------------------------------------+
|                             CMEK SERVICE AGENT WORKFLOW                           |
+-----------------------------------------------------------------------------------+
|  1. Admin provisions Cloud KMS Key: projects/sec-proj/locations/us/keyRings/k1... |
|  2. Admin discovers Service Agent for target service:                             |
|     - Cloud Storage: service-PROJECT_NUM@gs-project-accounts.iam.gserviceaccount.com|
|     - BigQuery:      bq-PROJECT_NUM@bigquery-encryption.iam.gserviceaccount.com   |
|     - Compute Engine:service-PROJECT_NUM@compute-system.iam.gserviceaccount.com   |
|  3. Admin grants IAM Role on Key: roles/cloudkms.cryptoKeyEncrypterDecrypter     |
|  4. Target resource configured with KMS Key URI                                  |
|  5. Target service automatically calls KMS to unwrap DEK during reads/writes      |
+-----------------------------------------------------------------------------------+

Service-Specific CMEK Integration Details

• Compute Engine Persistent Disks: When a CMEK key encrypts a persistent disk, the Compute Engine Service Agent requires roles/cloudkms.cryptoKeyEncrypterDecrypter. If the key is revoked or disabled, the VM immediately crashes or halts disk I/O.
• Cloud Storage: CMEK can be set as a default key at the bucket level or passed per-object. New objects inherit the default key.
• BigQuery: Tables, datasets, and query destination tables can be encrypted with CMEK. When querying a CMEK-encrypted table, the BigQuery Service Agent calls Cloud KMS to decrypt the underlying storage blocks.
• Cloud SQL: CMEK encrypts the underlying storage volume, backups, and read replicas. Key rotation in Cloud SQL requires creating a new key version and applying it to the instance.

Crypto-Shredding & Instant Revocation

• Instant Revocation: By disabling the primary CryptoKeyVersion or revoking the IAM roles/cloudkms.cryptoKeyEncrypterDecrypter binding from the Service Agent, all read/write operations immediately fail across the associated GCP services.
• Crypto-Shredding: To permanently destroy petabytes of distributed data instantaneously across all backups and replicas, security administrators schedule the destruction of the KMS CryptoKey. Once destroyed, the encrypted data blocks become cryptographically unreadable noise, fulfilling strict compliance sanitization mandates (e.g., GDPR Right to be Forgotten).

CMEK Organizational Policy Constraints

To enforce CMEK across an entire GCP organization and prevent developers from creating unencrypted or Google-managed resources, security teams deploy Organization Policies:

• constraints/gcp.cmekPolicy: Mandates CMEK for specific services.
• constraints/gcp.restrictCmekCryptoKeyProjects: Restricts the specific KMS projects from which CMEK keys can be selected, preventing the use of unauthorized or external keyrings.

---

Confidential Computing Architecture

Confidential Computing is a breakthrough hardware security technology that encrypts data in memory (RAM) while it is being processed, preventing the cloud hypervisor, host OS, and system administrators from inspecting customer memory space.

+-----------------------------------------------------------------------------------+
|                         CONFIDENTIAL COMPUTING ARCHITECTURE                       |
+-----------------------------------------------------------------------------------+
|  GUEST VM MEMORY SPACE (Encrypted with hardware AES-128/256 key)                 |
|  +-----------------------------------------------------------------------------+  |
|  |  Application Data  |  In-Memory Secrets  |  Decrypted PII / Financial Data  |  |
|  +-----------------------------------------------------------------------------+  |
|                                        |                                          |
|                          (AMD Secure Processor HW Layer)                          |
|                                        v                                          |
|  HYPERVISOR / GOOGLE HOST OS (CANNOT READ GUEST RAM)                             |
|  +-----------------------------------------------------------------------------+  |
|  |  KVM Hypervisor  |  Host Linux Kernel  |  Host Root Admin (No Visibility!)  |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Hardware Technologies & Implementations

1. AMD SEV (Secure Encrypted Virtualization): Generates an ephemeral, hardware-managed AES encryption key for each virtual machine. Memory is automatically encrypted when written to DRAM and decrypted when fetched into CPU caches.
2. AMD SEV-SNP (Secure Nested Paging): Adds strong memory integrity protection to prevent hypervisor-based replay attacks, memory corruption, and unauthorized page remapping.
3. Confidential VMs: N2D and C2D Compute Engine machine types supporting Confidential VM mode with zero code refactoring and negligible performance overhead (<2-4%).
4. Confidential GKE Nodes: Enforces memory encryption across all Kubernetes worker nodes and pods, ensuring multi-tenant pod memory isolation from the underlying node hypervisor.
5. Confidential Space: A specialized, hardened container execution environment enabling multi-party collaborative data analytics (e.g., competing banks training joint anti-fraud ML models) where neither party can access the other's raw dataset or proprietary algorithm.

---

Secret Manager: Architecture, IAM Governance & Rotation

Secret Manager is a fully managed, centralized storage service designed specifically for sensitive configuration metadata such as database passwords, API tokens, private SSH keys, and TLS certificates.

+-----------------------------------------------------------------------------------+
|                            SECRET MANAGER ARCHITECTURE                            |
+-----------------------------------------------------------------------------------+
|  SECRET CONTAINER: "projects/prod-app/secrets/db-primary-password"               |
|  ├── IAM Policy: Granted to service-account@prod-app.iam.gserviceaccount.com      |
|  ├── Replication: Automatic (Multi-Region) or User-Managed (Specific Regions)     |
|  ├── Rotation Policy: Rotates every 30 days -> Pub/Sub Topic -> Cloud Run/Func   |
|  └── VERSIONS:                                                                    |
|        ├── Version 1: DESTROYED                                                   |
|        ├── Version 2: DISABLED                                                    |
|        ├── Version 3: ENABLED (Current Active Secret Payload)                     |
|        └── "latest" alias -> Resolves dynamically to Version 3                   |
+-----------------------------------------------------------------------------------+

Key Architectural Characteristics

• Payload Limits: Designed for objects up to 64 KiB (for larger binary files, use Cloud Storage with CMEK).
• Automatic Replication: Secrets can be replicated automatically across Google Cloud geographies or constrained to specific regulatory regions via user-managed replication policies.
• Granular IAM Roles:
  • roles/secretmanager.secretAccessor: Permits reading the secret's payload value (secretmanager.versions.access).
  • roles/secretmanager.secretVersionManager: Permits adding and managing versions.
  • roles/secretmanager.admin: Grants full administrative control over secret metadata and IAM policies.
• Automated Secret Rotation: Configured with a next_rotation_time and rotation_period. When the rotation timestamp is reached, Secret Manager publishes a message to a Cloud Pub/Sub topic, triggering a Cloud Function or Cloud Run service to provision new database credentials and upload a new secret version.
• GKE Native Integration: The Secret Store CSI Driver mounts secrets directly from Secret Manager into Kubernetes Pods as local in-memory volumes (tmpfs), preventing credentials from being exposed in container environment variables or plain text config maps.

---

Concrete Architectural Scenario: Multi-Tier FinTech Security Architecture

Scenario Profile

• Client: Global FinTech processing credit card tokenization and ACH transfers.
• Requirements: FIPS 140-2 Level 3 cryptographic custody; instant data revocation capability; protection of cardholder data in memory from hypervisor access; automated 30-day rotation of database connection credentials; long-term compliance audit logging.

[ Web/API Tier ] ----> [ Payment Processing Microservice on GKE ]
                             - Confidential GKE Nodes (AMD SEV Memory Encrypted)
                             - Secret Store CSI Driver (Mounts DB Secret from Secret Manager)
                                         |
                                         +-----> [ Cloud SQL & Cloud Storage ]
                                                     - Encrypted with CMEK (Cloud HSM)
                                                     - FIPS 140-2 Level 3 Certified
                                                     - Instant Revocation via IAM

Architecture Blueprint

1. Cryptographic Key Storage: Cloud KMS configured with Cloud HSM (FIPS 140-2 Level 3) in us-central1. Separate CMEK keys are created for Cloud Storage buckets and Cloud SQL databases.
2. Data in Use Protection: GKE worker nodes deployed as Confidential GKE Nodes using AMD SEV-SNP to protect cardholder memory payloads during payment parsing.
3. Credential Management: Database passwords stored in Secret Manager with automated 30-day rotation triggered via Cloud Pub/Sub and Cloud Functions, mounted into GKE pods using the Secret Store CSI Driver.
4. Revocation & Compliance: In the event of a security incident, the security team disables the Cloud HSM CryptoKeyVersion, immediately cutting off all database and storage I/O.

---

[!IMPORTANT] Exam Watch: When a scenario requires compliance with FIPS 140-2 Level 3 hardware standards, you must select Cloud HSM. If the requirement states that the customer must hold the root keys exclusively in their own on-premises data center or external key vault, select Cloud EKM (External Key Manager). If the question asks to protect data in memory from hypervisor inspection, select Confidential VMs / Confidential Computing.