Best practices for using CMEKs

This page outlines best practices for configuring encryption at rest with customer-managed encryption keys (CMEKs) on your Trusted Cloud resources. This guide is intended for cloud architects and security teams, and outlines best practices and decisions that you must make while you design your CMEK architecture.

This guide assumes that you're already familiar with Cloud Key Management Service (Cloud KMS) and customer-managed encryption keys.

Decide whether to use CMEK

We recommend that you use CMEK to encrypt data at rest in Trusted Cloud services if you require any of the following capabilities:

• Own your encryption keys.

• Control and manage your encryption keys, including choice of location, protection level, creation, access control, rotation, use, and destruction.

• Generate key material in Cloud KMS or import key material that is maintained outside of Trusted Cloud.

• Set policy regarding where your keys must be used.

• Selectively delete data protected by your keys in the case of off-boarding or to remediate security events (crypto-shredding).

• Create and use keys that are unique to a customer, establishing a cryptographic boundary around your data.

• Log administrative and data access to encryption keys.

• Meet current or future regulation that requires any of these goals.

If you don't require these capabilities, evaluate whether default encryption at rest with Google Cloud-powered keys is appropriate for your use case. If you choose to use only default encryption, you can stop reading this guide.

Design your CMEK architecture

When designing a CMEK architecture, you must consider the configuration of the keys you will use and how these keys are managed. These decisions influence your cost, operational overhead, and ease of implementing capabilities such as crypto-shredding.

The following sections discuss recommendations for each design choice.

Use a centralized CMEK key project for each environment

We recommend using a centralized CMEK key project for each environment folder. Don't create resources encrypted with CMEK in the same project where you manage Cloud KMS keys. This approach helps to prevent sharing of encryption keys across environments and helps to enable separation of duties.

The following diagram illustrates these concepts in the recommended design:

• Each environment folder has a Cloud KMS key project administered separately from application projects.
• Cloud KMS key rings and keys are provisioned in the Cloud KMS key project, and these keys are used to encrypt resources in the application projects.
• Identity and Access Management (IAM) policies are applied to projects or folders to enable separation of duties. The principal managing Cloud KMS keys in the Cloud KMS key project isn't the same principal that uses the encryption keys in application projects.

Create Cloud KMS key rings for each location

You must create Cloud KMS key rings in the locations where you deploy Trusted Cloud resources encrypted with CMEK.

• Regional and zonal resources must use a key ring and CMEK in the same region as the resource or in the global location.
• Global resources must use a key ring and CMEK in the global location.

Enforcing regional keys is one piece of a data regionalization strategy. By enforcing the use of key rings and keys in a defined region, you also enforce that resources must match the region of the key ring.

For workloads that require high availability or disaster recovery capabilities across multiple locations, it's your responsibility to assess the whether your workload is resilient in the event that Cloud KMS becomes unavailable in a certain region. For example, a Compute Engine persistent disk encrypted with a Cloud KMS key from region A can't be recreated in region B in a disaster recovery scenario where region A is unavailable. To mitigate risk of this scenario, you can plan for encrypting a resource with global keys.

Choose a key granularity strategy

Granularity refers to the scale and scope of each key's intended usage. For example, a key that protects several resources is said to be less granular than a key that protects only one resource.

Cloud KMS keys used for CMEK must be provisioned in advance before creating a resource that will be encrypted with the key, such as a Compute Engine persistent disk. You might choose to create very granular keys for individual resources or to create less granular keys for reuse among resources more broadly.

While there is no universally correct pattern, consider the following trade-offs of different patterns:

High granularity keys—for example, one key for each individual resource

• More control to safely disable key versions: Disabling or destroying a key version that is used for a narrow scope has lower risk of affecting other resources than disabling or destroying a shared key. This also means that using highly granular keys helps to reduce the potential impact of a key becoming compromised when compared with using low granularity keys.
• Cost: Using granular keys requires maintaining more active key versions when compared with a strategy that uses keys with lower granularity. Higher key granularity requires greater numbers of active key versions, which incurs additional costs.
• Operational overhead: Using highly granular keys might require administrative effort or additional tooling for automation to provision a large number of Cloud KMS resources and to manage access controls for service agents so they can only use the appropriate keys.

Low granularity keys—for example, one key for each application, for each region, and for each environment

• Requires care to safely disable key versions: Disabling or destroying a key version that is used for a broad scope requires more care than disabling or destroying a highly granular key. You must ensure that all resources encrypted by that key version are safely re-encrypted with a new key version before disabling the old key version. This also means that using low granularity keys can increase the potential impact from a key becoming compromised when compared with using high granularity keys.
• Cost: Using less granular keys requires fewer key versions to be created, which incurs lower costs.
• Operational overhead: You can define and pre-provision a known number of keys, with less effort required to ensure appropriate access controls.

Choose the protection level for keys

When creating a key, it's your responsibility to select the protection level that is appropriate for each key based on your requirements for the data and workloads encrypted with CMEK. The following questions can help you in your assessment:

1. Do you require any of the CMEK capabilities? You can review the capabilities listed at Decide whether to use CMEK on this page.

   • If so, continue to the next question.
   • If not, we recommend using S3NS default encryption.

2. Do you require either a FIPS 140-2 certification of level 2 or level 3 or that key material be stored outside of Trusted Cloud?

   • If so, we recommend CMEK with Cloud External Key Manager.
   • If not, we recommend using CMEK with software-backed keys.

Use Trusted Cloud-generated key material when possible

This section doesn't apply to Cloud EKM keys.

When you create a key, you must either allow Cloud KMS to generate the key material for you or manually import key material generated outside of Trusted Cloud. When possible, we recommend that you choose the generated option. This option does not expose the raw key material outside of Cloud KMS and automatically creates new key versions based on the key rotation period that you choose. If you require the option to import your own key material, we recommend that you assess the following operational considerations and risks of using the bring-your-own-key (BYOK) approach:

• Can you implement automation to consistently import new key versions? This includes both Cloud KMS settings to restrict key versions to import only, and automation outside of Cloud KMS to consistently generate and import key material. What is the impact if your automation fails to create a new key version at the expected time?
• How do you intend to securely store or escrow the original key material?
• How can you mitigate the risk of your process to import keys leaking the raw key material?
• What would the impact be to re-import a previously destroyed key because the raw key material was retained outside of Trusted Cloud?
• Does the benefit of importing key material yourself justify the increased operational overhead and risk?

Choose the right key purpose and algorithm for your needs

When you create a key, you must select the purpose and underlying algorithm for the key. For CMEK use cases, only keys with the symmetric ENCRYPT_DECRYPT purpose can be used. This key purpose always uses the GOOGLE_SYMMETRIC_ENCRYPTION algorithm, which uses 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata. When you use Autokey, these settings are automatically applied for you.

For other use cases such as client-side encryption, review the available key purposes and algorithms to choose the option most appropriate to your use case.

Choose a rotation period

We recommend that you assess the appropriate key rotation period for your needs. The frequency of key rotation depends on the requirements of your workloads based on sensitivity or compliance. For example, key rotation might be required at least once yearly to meet certain compliance standards, or you might choose a more frequent rotation period for highly sensitive workloads.

After rotating a symmetric key, the new version is marked as the primary key version and is used for all new requests to protect information. The old key versions remain available for use to decrypt any previously encrypted data protected with that version. When you rotate a key, data that was encrypted with previous key versions is not automatically re-encrypted.

Frequent key rotation helps limit the number of messages encrypted with the same key version, which helps to reduce the risk and consequences of a key becoming compromised.

Apply appropriate access controls

We recommend that you consider the principles of least privilege and separation of duties when planning access controls. The following sections introduce these recommendations.

Apply the principle of least privilege

When assigning permission for managing CMEKs, consider the principle of least privilege and grant the minimum permissions needed to perform a task. We strongly recommend that you avoid using basic roles. Instead, grant predefined Cloud KMS roles to mitigate risks of security incidents related to over-privileged access.

Plan for separation of duties

Maintain separate identities and permissions for those who administer your encryption keys and those who use them. NIST SP 800-152 defines a separation of duties between the cryptographic officer who enables and manages the services of a cryptographic key management system and a user who uses those keys to encrypt or decrypt resources.

When you use CMEK to manage encryption at rest with Trusted Cloud services, the IAM role to use encryption keys is assigned to the service agent of the Trusted Cloud service, not the individual user. For example, to create objects in an encrypted Cloud Storage bucket, a user needs only the IAM role roles/storage.objectCreator, and the Cloud Storage service agent in the same project (like service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.iam.gserviceaccount.com) needs the IAM role roles/cloudkms.cryptoKeyEncrypterDecrypter.

The following table lists which IAM roles are typically associated with which job function:

IAM role	Description	NIST SP 800-152 designation
roles/cloudkms.admin	Provides access to Cloud KMS resources, except for access to restricted resource types and cryptographic operations.	Cryptographic officer
roles/cloudkms.cryptoKeyEncrypterDecrypter	Provides ability to use Cloud KMS resources for encrypt and decrypt operations only.	Cryptographic Key Management System user
roles/cloudkms.viewer	Enables get and list operations.	Audit administrator

Enforce CMEK consistently

The following sections describe additional controls to help mitigate risks like inconsistent key usage or accidental deletion or destruction.

Enforce project liens

We recommend that you protect projects with liens to avoid accidental deletion. When a project lien is enforced, the Cloud KMS key project is blocked from deletion until the lien is removed.

Require CMEK keys

We recommend that you enforce CMEK usage across your environment using organization policy constraints.

Use constraints/gcp.restrictNonCmekServices to block requests to create certain resource types without specifying a CMEK key.

Require a minimum scheduled for destruction duration

We recommend that you set a minimum scheduled for destruction duration. Key destruction is an irreversible operation that can result in data loss. By default, Cloud KMS uses a scheduled for destruction duration (sometimes called a soft delete period) of 30 days before key material is irrecoverably destroyed. This provides some time to restore a key in the event of accidental destruction. However, it is possible for someone with the Cloud KMS Admin role to create a key with a scheduled for destruction duration as low as 24 hours, which might not be sufficient time for you to detect an issue and restore the key. The scheduled for destruction duration can only be set during key creation.

While a key is scheduled for destruction, it can't be used for cryptographic operations, and any requests to use the key fail. During this time, monitor audit logs to check that the key is not in use. If you want to use the key again, you must restore the key before the end of the scheduled for destruction period.

To ensure that all keys created adhere to a minimum scheduled for destruction duration, we recommend that you configure the organization policy constraint constraints/cloudkms.minimumDestroyScheduledDuration with a minimum of 30 days, or your preferred duration. This organization policy prevents users from creating keys with a scheduled for destruction duration less than the value specified in the policy.

Enforce allowed protection levels for CMEKs

We recommend that you enforce your requirements for key protection levels consistently across your environment using organization policy constraints.

Use constraints/cloudkms.allowedProtectionLevels to enforce that new keys, key versions, and import jobs must use the protection levels that you allow.

Configure detective controls for CMEKs

Trusted Cloud provides various detective controls for CMEKs. The following sections introduce how to enable and use these controls relevant for Cloud KMS.

Enable and aggregate audit logging

We recommend that you aggregate Cloud KMS Admin Activity audit logs (along with Admin Activity logs for all services) in a centralized location for all resources in your organization. This lets a security team or auditor review all activity related to creating or modifying Cloud KMS resources at once. For guidance on configuring aggregated log sinks, see aggregate and store your organization's logs.

Optionally, you can enable data access logs to log operations that use the keys, including encrypt and decrypt operations. When using CMEKs, this can generate substantial log volume and impact your costs because every operation from every service that uses CMEKs will create data access logs. Before enabling data access logs, we recommend that you define a clear use case for the additional logs and assess how your logging costs will increase.

Assess your compliance requirements

Different compliance frameworks have different requirements for encryption and key management. A compliance framework typically outlines the high-level principles and objectives of encryption key management, but is not prescriptive about the particular product or configuration that achieves compliance. It's your responsibility to understand the requirements of your compliance framework and how your controls, including key management, can meet those requirements.

For guidance about how Trusted Cloud services can help meet the requirements of different compliance frameworks, see the following resource:

• Protecting healthcare data on Trusted Cloud

Summary of best practices

The following table summarizes the best practices recommended in this document:

Topic	Task
Decide whether to use CMEK	Use CMEK if you require any of the capabilities enabled by CMEK.
Cloud KMS key projects	Use one centralized key project for each environment. Don't create Cloud KMS resources in the same project as the Trusted Cloud resources the keys protect.
Cloud KMS key rings	Create Cloud KMS key rings for each location where you want to protect Trusted Cloud resources.
Key granularity	Choose a pattern of key granularity that meets your needs for risk tolerance, cost, and operational overhead.
Protection level	Choose Cloud EKM if your key material must be stored outside of Trusted Cloud or if you need a FIPS 140-2 certification of level 2 or level 3. Otherwise, choose software keys. Review the guidance for selecting a protection level.
Key material	For key material hosted on Trusted Cloud, use Trusted Cloud-generated key material when possible. If you use imported key material, implement automation and procedures to mitigate risks.
Key purpose and algorithm	All CMEK keys must use the symmetric ENCRYPT_DECRYPT key purpose and the GOOGLE_SYMMETRIC_ENCRYPTION algorithm.
Rotation period	Use automatic key rotation to ensure that your keys are rotated on schedule. Choose and apply a rotation period that meets your needs, ideally no less than once per year. Use more frequent key rotation for sensitive workloads.
Least privilege	Grant the most limited predefined roles that allow your principals to complete their tasks. Don't use basic roles.
Separation of duties	Maintain separate permissions for key administrators and principals that use keys.
Project liens	Use project liens to prevent accidental deletion of your key projects.
Require CMEKs	Use the constraints/gcp.restrictNonCmekServices constraint.
Require a minimum scheduled for destruction duration	Use the constraints/cloudkms.minimumDestroyScheduledDuration constraint.
Enforce allowed protection levels for CMEKs	Use the constraints/cloudkms.allowedProtectionLevels constraint.
Enable and aggregate audit logging	Aggregate administrative activity audit logs for all resources in your organization. Consider whether you want to enable logging of operations using keys.
Assess compliance requirements	Review your Cloud KMS architecture and compare with any compliance requirements that you must adhere to.