Encryption for Rest, Transit and Use

Client-side and application-layer encryption architectures protect application payloads inside the customer environment before transmission to Google Cloud. The application encrypts or tokenizes sensitive fields first, and Google Cloud default encryption (opens in a new tab) at rest and in transit then protects only the resulting ciphertext or tokens. The design shifts plaintext visibility and key control from Google-managed services to customer-held keys and pipelines.

1.1Client-Side Envelope Encryption with Tink, DEKs, and KEKs

Client-side envelope encryption with Google Tink is a method where the application encrypts data locally with a data encryption key (DEK) and then protects that DEK with a key encryption key (KEK). The DEK performs bulk AES encryption of the payload, while the KEK wraps the DEK so the DEK is never stored in plaintext. Tink is compatible with BigQuery (opens in a new tab) Authenticated Encryption with Associated Data (AEAD) functions, so columns encrypted off-cloud can later be decrypted inside BigQuery.

The KEK is a symmetric customer-managed encryption key managed through Cloud Key Management Service (Cloud KMS) (opens in a new tab) with Identity and Access Management (IAM) roles and generated in Cloud HSM. The DEK can be generated locally by the application or generated as random bytes from Cloud HSM. Because the KEK remains under customer IAM control in Cloud HSM, Google storage and transport layers handle only ciphertext and a wrapped DEK, and plaintext is exposed only where KEK use is explicitly authorized.

Data flows from the customer application to BigQuery through an ordered envelope sequence:

1. Generate DEK: The application obtains a fresh DEK locally or from Cloud HSM for the sensitive payload or column.
2. Encrypt locally: The application encrypts the sensitive field with the DEK using Tink before the data leaves the customer trust boundary.
3. Wrap DEK with KEK: The application calls Cloud HSM to wrap the DEK with the symmetric CMEK KEK.
4. Store ciphertext plus wrapped DEK: The ingestion path writes ciphertext to a BigQuery data table and writes the wrapped DEK to a separate BigQuery key table.
5. Unwrap and decrypt on authorized read: BigQuery AEAD decryption unwraps the DEK with the KEK and then decrypts the protected column, but only after IAM authorizes use of the KEK.

1.2Field-Level Tokenization and De-identification with Sensitive Data Protection

Field-level tokenization with Sensitive Data Protection is an application-layer pipeline that replaces personally identifiable information (PII) with tokens before persisting data to storage. An ingestion pipeline reads raw data from Cloud Storage, passes the data through Sensitive Data Protection detectors and a Dataflow pipeline, and then writes tokenized output to a BigQuery warehouse. This approach lets analysts query dataset shape and non-sensitive fields without access to raw values such as credit card numbers and PINs.

The pipeline applies different transforms by data shape. For structured data, the pipeline uses record transformations based on fields to find and tokenize defined columns. For unstructured data, the pipeline uses information types (infoTypes) to detect categories such as credit card numbers across free text. De-identification itself uses a cryptographic key wrapped by Cloud HSM, so re-identification requires both access to the tokenized table and authorization to use the wrapping key.

Tokenization ownership shifts to application developers or to a platform team that builds a shared encryption pipeline for developers to call. Tokenization is not centrally enforceable as a landing-zone (opens in a new tab) control. Choose this model when a workload holds highly sensitive data that must not be used in its raw form, and avoid it when Cloud KMS with CMEK is sufficient because the extra encrypt and decrypt stages add cost, latency, and operational complexity.

1.3Key Separation, Decryption Control, and Column-Level Enforcement

Key separation and column-level enforcement control who can turn ciphertext or tokens back into readable PII after application-layer protection is applied. Ingestion uses distinct CMEK keys for the ingestion path shared by Dataflow and Pub/Sub, for the Sensitive Data Protection de-identification operation, and for each BigQuery warehouse in the non-confidential and confidential data projects. Each CMEK location must match the location of the resources that use it, rotation defaults to every 30 days, and organizations with external custody mandates can use Cloud External Key Manager (Cloud EKM) but then assume responsibility for rotation and availability.

Decryption depends on both IAM permission on the KEK and BigQuery column policy. Even after re-identification is possible, a column remains unreadable until the reader holds the Fine-Grained Reader role for its policy tag:

• 3_Confidential tag: Columns with very sensitive data such as full credit card numbers; access also grants access to 2_Private and 1_Sensitive columns.
• 2_Private tag: Columns with sensitive PII such as first name; access also grants access to 1_Sensitive columns but not to 3_Confidential columns.
• 1_Sensitive tag: Columns with non-public business data such as credit limit; access grants no access to 2_Private or 3_Confidential columns.

Untagged columns remain available to all users with warehouse access. The three protection tiers compare by where plaintext can appear and who controls the keys:

Key management models for data at rest in Google Cloud define who owns the key-encryption keys (KEKs), where key material lives, and who can control rotation and access. Google Cloud encrypts all stored data with envelope encryption (opens in a new tab), where a KEK wraps data-encryption keys (DEKs) that directly encrypt the data. Choosing Google-managed keys, Customer-Managed Encryption Keys (CMEK) (opens in a new tab), Customer-Supplied Encryption Keys (CSEK), or Cloud External Key Manager (Cloud EKM) determines the cryptographic boundary, operational overhead, and compliance posture for services such as Cloud Storage, BigQuery, and Compute Engine.

2.1Google-Owned and Google-Managed Default Encryption

Google-owned and Google-managed default encryption is the automatic, no-configuration baseline that protects all data at rest in Google Cloud. Keys are held in Keystore, Google Cloud's internal key management service, using AES-256 with FIPS 140-3 Level 1 validated modules. Keystore maintains a primary key version that encrypts new DEKs and a limited number of older versions that can still decrypt existing DEKs, and Google rotates most keys automatically.

Customers cannot view keys, manage rotation (opens in a new tab), or review key usage logs, and data from multiple customers may share the same KEK. This tier therefore provides no logical data separation through encryption and does not satisfy regulatory requirements for customer-managed keys. Choose default encryption when no cryptographic boundary, customer ownership, or key audit trail is required, since default encryption is free and requires no setup.

2.2Customer-Managed Encryption Keys with Cloud KMS

Cloud Key Management Service (Cloud KMS) (opens in a new tab) CMEKs are customer-owned KEKs that replace default encryption for CMEK-integrated services. A CMEK wraps the service's DEKs, and the service's service agent performs encrypt and decrypt operations transparently, so workloads access Cloud Storage objects, BigQuery tables, or Compute Engine disks the same way as with default encryption. The trust boundary shifts because data access now depends on both Identity and Access Management (IAM) permission to the resource and the service agent's roles/cloudkms.cryptoKeyEncrypterDecrypter permission on the key.

If that grant is revoked, or if the key is disabled or destroyed, the protected data becomes inaccessible, and some services can suffer permanent loss if the key stays unavailable. All CMEK keys must use the symmetric ENCRYPT_DECRYPT purpose with the GOOGLE_SYMMETRIC_ENCRYPTION algorithm. CMEKs are appropriate when regulatory or operational requirements demand any of the following capabilities:

• Own encryption keys with tightly restricted or no access by Google and keys unique to a customer.
• Control location, protection level, creation, access, rotation, use, and destruction of keys.
• Generate material in Cloud KMS or import externally generated material.
• Enforce policy on where keys may be used and require CMEK via organization policy.
• Selectively delete data by destroying the key, known as crypto-shredding, for off-boarding or incident response.
• Log administrative and data-access operations on keys for audit and sovereignty.

Using Cloud KMS incurs charges for active key versions and cryptographic operations, with no minimum commitment.

2.3Cloud KMS Autokey and Manual Provisioning

Manual CMEK provisioning requires administrators to plan key rings, keys, locations, and service-agent grants before developers can create protected resources. The ordered workflow for a CMEK-integrated service first creates the key infrastructure, then grants access, then attaches the key at resource creation:

1. Create or select key ring: Create a Cloud KMS key ring in a location near the resources to protect, in the same project or a separate key project for stronger separation of duties.
2. Create or import key: Create the Cloud KMS key that will serve as the CMEK in that ring.
3. Grant service agent access: Grant the service agent the CryptoKey Encrypter/Decrypter role on that specific key.
4. Attach key at resource creation: Configure the resource, such as a BigQuery table or Cloud Storage bucket, to use the CMEK.

Cloud KMS Autokey automates this workflow by delegating provisioning authority to the Cloud KMS service agent, so a developer requests a key as part of resource creation and receives a consistent key for that resource type. Autokey keys are AES-256 GCM keys in the multi-tenant hardware backend, co-located with the protected resource, rotated yearly, and provisioned with per-resource-type specificity and separation between key users and key managers. Autokey keys function identically to manually created Cloud HSM keys for CMEK integrations, key-usage tracking, and organization policies, and Autokey removes the need to run infrastructure-as-code with elevated key-creation privileges.

2.4Protection Levels and Key Material Source

Protection levels in Cloud KMS define the backend that stores and uses key material and the compliance properties that follow. The key ring location fixes where Cloud KMS creates, stores, and processes keys, and the protection level cannot be changed to bypass that regionality. For key material hosted in Google Cloud, Google-generated material is recommended because raw material never leaves Cloud KMS and new versions are created automatically on rotation, while bring-your-own-key (BYOK) import requires external generation, secure escrow, leak-resistant import automation, and planning for re-import of destroyed material.

Choose the protection level that matches where key material must reside and how much isolation is required:

• SOFTWARE: Software-backed keys for workloads with no hardware or external-storage requirement; operations use FIPS 140-2 Level 1 validated modules.
• HARDWARE multi-tenant Cloud HSM: Key material on Google Cloud-owned hardware security module (HSM) clusters shared with other customers; FIPS 140-2 Level 3 certified HSMs store the keys.
• HARDWARE single-tenant Cloud HSM: Key material on dedicated HSM partitions for workloads requiring single-tenant hardware isolation.
• EXTERNAL via Cloud EKM: Key material stored and managed in a third-party system outside Google infrastructure, maintaining separation between data at rest and keys while still allowing cloud compute and analytics.

Cloud EKM preserves external control and supports Key Access Justifications for approval-gated decryption, but availability now depends on the external key manager. Single-tenant HSM and EKM carry higher cost and operational overhead than software or multi-tenant HSM keys.

2.5Customer-Supplied Keys and External Management

CSEK and Cloud EKM cover cases where Cloud KMS does not hold the long-term key material. Customer-supplied encryption keys (CSEK) require the caller to supply raw key material with each Cloud Storage operation, and Google holds the material only in memory without permanent storage on its servers. CSEK applies to Cloud Storage, while CSEK for Compute Engine disks is deprecated, so new Compute Engine designs should use CMEK instead of CSEK.

Cloud External Key Manager (Cloud EKM) provides an EXTERNAL protection level where Cloud KMS calls out to an externally hosted key for encrypt and decrypt operations. Data flows from the CMEK-integrated service to Cloud KMS and then to the external manager for the cryptographic operation, so network reachability and external-system durability directly affect data availability. Choose Cloud EKM when policy requires keys to remain outside Google Cloud; choose CSEK only for Cloud Storage workloads that can supply and protect raw keys per request and accept the loss of centralized rotation, audit, and recovery controls.

The table trade-off is control versus overhead: default keys minimize work but offer no boundary, CMEK adds ownership and audit at the cost of IAM and rotation management, and EKM and CSEK maximize separation at the cost of external dependency and manual handling.

2.6Rotation Lifecycles, Granularity, and Destruction

Key rotation lifecycle in Cloud KMS centers on key versions, where a new primary version encrypts new DEKs while older enabled versions remain available to decrypt existing data. Best practice is automatic rotation on a defined period, ideally at least yearly, with more frequent rotation for sensitive workloads. Key granularity should isolate blast radius without creating unmanageable sprawl, either by assigning keys per environment, workload, or customer, or by letting Autokey provision the recommended per-resource-type specificity.

Imported BYOK keys need additional automation to restrict versions to import-only and to generate and import replacements on schedule. Rotation effect depends on the integrated service, because the CMEK is a KEK and each service manages its DEKs differently:

• Spanner: A new key version re-encrypts the DEK, so protection moves forward without recreating the resource.
• Cloud Storage: Only newly written objects use the new key version, so different key versions protect different subsets of data in the same bucket.
• BigQuery: Existing tables continue to use the key version present at creation and do not automatically re-encrypt, so the table must be recreated or re-encrypted to adopt the new version.

Destruction follows a scheduled for destruction soft-delete period, recommended at a minimum of 30 days, during which the key cannot perform cryptographic operations and requests using it fail. The duration is set only at key creation and can be as short as 24 hours if unrestricted, so the constraints/cloudkms.minimumDestroyScheduledDuration constraint should enforce the minimum. While a key is scheduled for destruction, audit logs should be checked for continued use, and the key must be restored before expiry to regain access.

2.7Governance, Guardrails, and Detective Controls

Key governance and storage placement determine separation of duties (opens in a new tab) and blast radius for Cloud Storage, BigQuery, and Compute Engine data. Centralized governance places all key lifecycles with a dedicated security or platform team for strict regulation or external-system control, while delegated governance lets application owners manage keys within guardrails such as organization policies and IAM deny policies. Dedicated-project storage holds keys for multiple applications in a central key project per environment and keeps keys in a different project than the data, while same-project storage keeps the key with the data it protects and requires removal of broad owner roles to preserve separation.

Least privilege requires granting only the narrowest predefined Cloud KMS roles, separating key administrators who rotate, disable, or destroy keys from principals and service agents who only encrypt and decrypt. Preventive guardrails include project liens to block accidental key-project deletion, constraints/gcp.restrictNonCmekServices to require CMEK, and constraints/cloudkms.allowedProtectionLevels to limit new keys and import jobs to approved backends. Detective controls aggregate Admin Activity audit logs centrally, enable data-access logs only with a defined use case because CMEK operations can generate large volume and cost, and monitor the key-usage and encryption-metrics dashboards, Cloud Monitoring alerts for scheduling destruction, and Security Command Center findings for public keys, owner-role violations, and separation-of-duties issues.

Enforcing cryptographic controls for data in transit and data in use means combining Google Cloud default network encryption with additional controls where traffic crosses trust boundaries or data is actively processed in memory. Google Cloud (opens in a new tab) encrypts and authenticates data in transit at one or more network layers when data moves outside physical boundaries controlled by Google, and all virtual machine (VM)-to-VM traffic within a Virtual Private Cloud (VPC) network and between peered VPC networks is encrypted. Data in use in memory is not encrypted by default, so sensitive workloads require Confidential Computing to create a hardware-isolated trusted execution environment (TEE).

3.1Google Default Protection for Data in Transit

Google default protection for data in transit covers traffic that stays inside Google's production network. VM-to-VM connections within VPC networks and peered VPC networks inside that network are integrity-protected and encrypted, and the Google Cloud virtual network encrypts, integrity-protects, and authenticates traffic between VMs. Traffic from the internet to Google services and from a VPC network to Google services terminates at the Google Front End (GFE), which provides distributed denial-of-service (DDoS) countermeasures and routes and load balances traffic to Google Cloud services.

From the GFE to a Google Cloud service, and from one Google Cloud service to another Google Cloud service, Google's infrastructure uses Application Layer Transport Security (ALTS) for authentication, integrity, and encryption. Default encryption is sufficient for internal workloads that remain inside Google's network. Additional protection is required when traffic leaves that boundary, specifically when internet ingress traffic enters a VPC network or when a connection extends to an on-premises environment.

3.2Encryption from End Users to Google Services and Customer Applications

Encryption from end users to Google services is terminated and negotiated at the GFE. The GFE terminates incoming HTTP(S), TCP, and TLS connections and routes them over Google's network to a Google Cloud service or to a customer application behind Cloud Load Balancing. Requests sent over HTTPS, HTTP/2, or HTTP/3 are secured with Transport Layer Security (TLS), implemented in the GFE with BoringSSL, a Google-maintained implementation whose BoringCrypto core is validated to FIPS 140-3 Level 1.

Encryption from end users to a customer application hosted on Google Cloud depends on whether traffic flows directly or through a load balancer. Traffic can route directly to the external IP address of the VM server that hosts the application, or through an external Application Load Balancer or external proxy Network Load Balancer with TLS. When a Layer 7 load balancer is used, the connection between the end user and the load balancer is encrypted using TLS by default when the client supports TLS, and the GFE terminates those TLS connections using Google-managed or self-managed certificates. Encryption between the load balancer and the backend VM must be configured separately as encryption from the load balancer to the backends.

3.3Application-Layer Encryption with TLS and Mutual TLS

Application-layer encryption with TLS and mutual TLS (mTLS) protects application-to-application traffic in the cloud beyond the network default. Apigee (opens in a new tab) supports TLS and mTLS configurations for API ingress, and Cloud Service Mesh provides mTLS for containerized applications on Google Kubernetes Engine (GKE) and Compute Engine. In Cloud Service Mesh, mTLS provides mutual authentication of client and server and encrypts communications in transit using certificates managed by the customer.

Application-layer encryption is configured by application teams using managed services such as managed certificates and Cloud Service Mesh, and it cannot be centrally enforced in the landing zone (opens in a new tab). Choose this control when applications require HTTPS or SSL traffic between components, such as a new internet-facing application running behind an external Application Load Balancer with Google-managed SSL certificates. Allow a limited exception during large-scale migration when legacy applications did not require encryption for internal on-premises traffic, since forcing modernization before migration can cause unacceptable delay.

3.4Encryption Across Hybrid Boundaries with VPN and Interconnect

Encryption across hybrid boundaries protects traffic flowing between Google Cloud and on-premises data centers. Cloud VPN uses IPsec to encrypt traffic over Virtual Private Network (VPN) connections, while Cloud Interconnect can use Media Access Control Security (MACsec) to encrypt traffic over direct physical Interconnect connections. Traffic from an on-premises environment to Google Cloud over Cloud Interconnect is not encrypted in transit by default, so MACsec must be explicitly configured.

Choose Dedicated Interconnect when high throughput and a direct physical connection are needed, such as for streaming large volumes of data, and use Cloud VPN with IPsec when an encrypted connection over the internet meets the requirement. In both cases, data flows from the on-premises network across the hybrid link to the VPC network, crossing from a customer-controlled physical boundary into Google's production network where default VPC and ALTS protections then apply.

3.5Protection for Data in Use with Confidential Computing

Protection for data in use with Confidential Computing keeps data encrypted in memory while it is being processed. A Confidential VM is a Compute Engine VM type that uses hardware-based memory encryption to help ensure data and applications cannot be read or modified while in use. Encryption keys are generated by and reside solely in dedicated hardware that is inaccessible to the hypervisor, which provides isolation, and the customer can verify the identity and state of the VM to detect tampering of key components, which provides attestation.

Together, hardware isolation and attestation form a TEE, and Confidential VM can be enabled whenever a new VM instance is created. Two services extend Confidential VM to broader platforms. Confidential GKE Nodes enforce the use of Confidential VM for all GKE nodes, so containerized workloads inherit memory encryption and attestation. Confidential Space uses Confidential VM to let multiple parties share sensitive data with a mutually agreed-upon workload while each party retains confidentiality and ownership of that data.

3.6Choosing a Confidential Computing Technology

Choosing a Confidential Computing technology determines the hardware mechanism, attestation model, and operational tradeoffs for a Confidential VM instance. The technology is determined by the selected machine type and central processing unit (CPU) platform, and the choice must balance performance, cost, and protection against hypervisor and physical-memory attacks. Encryption in transit (opens in a new tab) for standard networks is separate from specialized ultra-high performance interconnects for AI supercomputers, which use Inter-Chip Interconnect (ICI) for Tensor Processing Units (TPUs) and NVLink for GPUs.

AMD SEV offers high performance for demanding computational tasks, with performance ranging from identical to minimally different from a standard Compute Engine VM depending on workload. Unlike the other Confidential VM technologies, AMD SEV machines using N2D and C3D machine types support live migration. Intel TDX augments defense of the trust domain against attacks using physical access to platform memory, including offline dynamic random-access memory (DRAM) analysis and active DRAM interface attacks such as capturing, modifying, relocating, splicing, and aliasing memory contents. NVIDIA Confidential Computing must be paired with a CPU-based technology such as AMD SEV or Intel TDX to provide a comprehensive confidential environment for both CPU and GPU workloads.

Key Facts

• Client-side envelope encryption encrypts payloads with a DEK locally using Google Tink and wraps the DEK with a symmetric CMEK KEK in Cloud HSM, so Google layers handle only ciphertext and a wrapped DEK.
• Google-managed default encryption uses AES-256 keys in Keystore with automatic rotation, while CMEK gives customers ownership of unique keys, location and rotation control, crypto-shredding, and audit logging.
• Spanner re-encrypts its DEK when Cloud KMS rotates to a new primary version, while BigQuery tables stay on their original key version until recreated and Cloud Storage applies new versions only to newly written objects.
• VM-to-VM traffic inside a VPC or peered VPCs is encrypted by default, Cloud VPN uses IPsec, and Cloud Interconnect requires MACsec because it is not encrypted by default.
• Confidential Computing protects data in use with hardware-based memory encryption and attestation in a trusted execution environment, including Confidential VMs, Confidential GKE Nodes, and Confidential Space.