Data security (encryption and key management)

Design and Manage Cryptographic Key Lifecycles Using Cloud KMS and HSM

Cloud Key Management Service (Cloud KMS) and Cloud HSM are Google Cloud's services for creating, storing, and managing cryptographic encryption keys throughout their lifecycle. Cloud HSM provides hardware security modules that meet FIPS 140-2 Level 3 certification for organizations with strict compliance needs. Both services implement envelope encryption, where a data encryption key (DEK) encrypts the data itself, and a separate key encryption key (KEK) encrypts (wraps) the DEK. This hierarchy allows Google to manage large numbers of keys securely.

Key Rings, Crypto Keys, and Key Versions

The key management hierarchy in Cloud KMS has three levels. A key ring is a logical container that groups related crypto keys together, often organized by application or environment. Each crypto key can have multiple key versions, where each version is a distinct cryptographic key that can be in an active, pending, or disabled state. When a new version is created, it becomes the primary version for encryption, while older versions remain available only for decryption of data they previously encrypted. This versioning approach supports key rotation without data loss, because both old and new versions remain functional for their respective purposes.

Key Rotation and Lifecycle Management

Key rotation limits the amount of data protected by a single key, reducing the potential impact of key compromise. Cloud KMS supports both automatic and manual rotation schedules; Google recommends a rotation period of typically 90 days for most use cases. When rotation occurs, a new key version is automatically created, and the previous version remains available for decryption. The full key lifecycle extends from generation through rotation to destruction. Organizations must define rotation periods, establish destruction procedures, and maintain audit trails of all key operations to prevent data loss while maintaining security.

IAM Access Control and Separation of Duties

Access to cryptographic keys is controlled through Identity and Access Management (IAM) policies. Google recommends limiting the number of principals who can use cryptographic keys to three or fewer. The principle of separation of duties means that users who manage keys should be different from those who use them for encryption and decryption. Cloud KMS provides predefined roles such as Cloud KMS Admin, CryptoKey Encrypter/Decrypter, and CryptoKey Viewer to implement granular access control. Organizations should create separate projects for key management and data storage to strengthen security boundaries and ensure that key administrators cannot directly access the data those keys protect.

Customer-Managed Encryption Keys (CMEK) and Compliance

Customer-managed encryption keys (CMEK) give organizations full control over their encryption keys while using Google Cloud's infrastructure for key operations. CMEK integrates with services such as BigQuery, Cloud Storage, Compute Engine, Spanner, and Vertex AI. For compliance, Cloud KMS supports FIPS 140-2 validated hardware through Cloud HSM. The Cloud External Key Manager (Cloud EKM) feature allows organizations to keep key material in customer-controlled environments, addressing data sovereignty requirements.

Cloud KMS Autokey and Advanced Features

Cloud KMS Autokey automates the provisioning of customer-managed encryption keys when resources are deployed. Key rings and keys are generated on-demand, and service accounts are automatically granted the necessary IAM roles for encryption and decryption. Autokey follows Google's recommended practices, including using the Cloud HSM protection level, proper key granularity, and appropriate rotation schedules. Organizations can use Autokey alongside manually-created keys, providing flexibility while ensuring all keys meet organizational security standards.

Evaluate and Implement Encryption Methods for Data at Rest and in Transit

Encryption in Google Cloud is applied by default to protect data both at rest and in transit. For data at rest, Google uses multiple layers of encryption, including storage system-level and storage device-level encryption. Each logical chunk of data is encrypted with a unique data encryption key (DEK), which is then wrapped by a key encryption key (KEK) stored centrally – this is envelope encryption. Data in transit is automatically encrypted when it moves outside Google's physically secured network boundaries, and internal traffic between Google Cloud services also uses encryption with integrity protection.

Customers have several options for managing encryption keys, balancing control with operational overhead:

Encryption key model	Key management responsibility	Recommended use
Google-managed keys	Google fully manages the key lifecycle	Default for most use cases without specific compliance requirements
Customer-managed keys (CMEK)	Customer creates, rotates, and controls key lifecycle via Cloud KMS or Cloud HSM	Required when regulatory compliance mandates customer control
Customer-supplied keys (CSEK)	Customer provides their own key material directly	Legacy option; Cloud External Key Manager (Cloud EKM) is now the recommended alternative for externally stored keys

When implementing encryption for specific Google Cloud services, each service has its own capabilities. Cloud Storage, BigQuery, Cloud SQL, and Spanner all support CMEK for data at rest. Data can be further protected using client-side encryption libraries such as Tink before ingestion, or via column-level encryption within BigQuery. For data in transit, services can be configured to enforce TLS, and network traffic can be secured using Cloud VPN, Cloud Interconnect, or VPC Service Controls to define secure perimeters.

The choice of encryption method directly affects security posture and compliance. A robust encryption strategy reduces the attack surface, acts as an audit chokepoint, and ensures that even if data is exposed, it remains unreadable without the corresponding keys. Proper implementation involves defining key management policies, assigning roles and responsibilities, and using tools such as Security Command Center for monitoring and Cloud Audit Logs for tracking access and cryptographic operations.

Secure Data Processing Pipelines with Encryption and Envelope Encryption

Securing data processing pipelines in Google Cloud requires a defense-in-depth approach using envelope encryption. Data is encrypted with a Data Encryption Key (DEK), which is then wrapped and protected by a Key Encryption Key (KEK) managed centrally in Cloud Key Management Service (Cloud KMS) or Cloud HSM. This layered strategy ensures that if an attacker compromises a physical storage system, they cannot read the underlying information without authorized access to both the wrapped key and the central key manager.

For analytical workloads, security is implemented directly within data processing engines. Cloud Dataflow and Cloud Dataproc both support Customer-Managed Encryption Keys (CMEK), allowing organizations to maintain full lifecycle control over the keys used to encrypt pipeline states, temporary files, and virtual machine disks. During the ingestion phase, Dataflow pipelines can integrate with Sensitive Data Protection to tokenize, de-identify, or encrypt individual database columns before storing them in BigQuery.

When importing sensitive records from external or on-premises environments, client-side encryption ensures end-to-end protection. Organizations can use the Tink encryption library to secure confidential column values locally before sending them over the network. To secure the communication path itself, Cloud VPN or Cloud Interconnect establishes an encrypted, private tunnel to Google Cloud. This combined approach ensures that data remains unreadable to unauthorized entities from the moment it leaves the local network until it is processed in the cloud.

Administering key lifecycles is critical for maintaining a strong security posture. The standard lifecycle management workflow involves the following ordered steps:

1. Create Keys: Generate cryptographically strong keys using certified hardware security modules.
2. Assign Authority: Restrict key access to specific service accounts based on the principle of least privilege.
3. Rotate Keys: Schedule automatic key rotation every thirty days to limit potential data exposure.

Correctly executing these steps ensures that organizations protect their most critical data processing assets while meeting strict compliance requirements.

Key Facts

• Envelope encryption in Google Cloud uses a Data Encryption Key (DEK) to encrypt data and a Key Encryption Key (KEK) managed in Cloud KMS or Cloud HSM to wrap the DEK.
• Cloud KMS organizes keys in a hierarchy of key rings, crypto keys, and key versions, with key rotation creating new primary versions while older versions remain available for decryption.
• Google-managed keys are the default encryption model, while Customer-Managed Encryption Keys (CMEK) give customers full control via Cloud KMS or Cloud HSM, and Cloud External Key Manager (Cloud EKM) allows key material to be stored externally.
• Cloud Dataflow and Cloud Dataproc support CMEK to encrypt pipeline states and temporary files, and pipelines can integrate with Sensitive Data Protection for column-level tokenization or encryption.
• Client-side encryption using the Tink library combined with Cloud VPN or Cloud Interconnect provides end-to-end encryption for data moving from on-premises environments to Google Cloud.