Cloud Key Management Service deep dive

This content was last updated in July 2023, and represents the status quo as of the time it was written. Google's security policies and systems may change going forward, as we continually improve protection for our customers.

Google Cloud works off the fundamental premise that Google Cloud customers own their data and should control how it is used.

When you store data with Google Cloud, your data is encrypted at rest by default. When you use the Cloud Key Management Service (Cloud KMS) platform, you can gain greater control over how your data is encrypted at rest and how your encryption keys are managed.

The following table describes the different types of Google Cloud keys.

Type of key	Key management	Key sharing	Automatic rotation	Pricing
Default encryption key	These keys are solely managed by Google.	Data from multiple customers might use the same key encryption key (KEK).	Yes, see Default encryption at rest.	Free.
Cloud KMS keys	These keys are controlled by the customer.	Unique to a customer.	Yes for symmetric encryption, no for asymmetric keys. See Key rotation.	See Cloud Key Management Service pricing.

This document focuses on the inner workings of the Cloud KMS platform. These options help you protect the keys and other confidential data that you store in Google Cloud. This document is intended for technical decision makers who need details about Cloud KMS architecture, infrastructure, and features. This document assumes that you have a basic understanding of encryption concepts and cloud architectures.

Cloud KMS design pillars

With Cloud KMS, Google's focus is to provide a scalable, reliable, and performant solution, with the widest spectrum of options that you can control. Cloud KMS is supported by the following five design pillars:

• Customer control: Cloud KMS lets you control your own software and hardware keys for encryption and signing. This pillar includes support for bring-your-own-keys (BYOK) and hold-your-own-keys (HYOK).
• Access control and monitoring: With Cloud KMS, you can manage permissions on individual keys and monitor how the keys are used.
• Regionality: Cloud KMS offers regionalization out of the box. The service is configured to create, store, and process keys only in the Google Cloud location that you select.
• Backups: To help guard against data corruption and to verify that data can be decrypted successfully, Cloud KMS periodically scans and backs up all key material and metadata.
• Security: Cloud KMS offers strong protection against unauthorized access to keys and is fully integrated with Identity and Access Management (IAM) and Cloud Audit Logs controls.

Sources and management options for key materials

The Cloud KMS platform lets you manage cryptographic keys in a central cloud service for direct use or for use by other cloud resources and applications.

The following diagram shows the Google Cloud portfolio for keys, arranged from Google-controlled key material to customer-controlled key material.

The options that are shown in the preceding diagram are the following:

• Default encryption: All data that is stored by Google is encrypted at the storage layer using the Advanced Encryption Standard (AES) algorithm, AES-256. We generate and manage the keys for default encryption, and customers don't have access to the keys or control of key rotation and management. Default encryption keys might be shared among customers. For more information, see Default encryption at rest.

• Cloud KMS with software-generated keys: Using Cloud KMS, you can control the keys that are generated by Google. The Cloud KMS software backend gives you the flexibility to encrypt or sign your data with either a symmetric or asymmetric key that you control.

• Cloud KMS with hardware-generated keys (Cloud HSM): Using Cloud KMS with the Cloud HSM backend, you can own keys that are generated and stored in Google-owned and operated hardware security modules (HSMs). If you require a hardware-protected key, you can use the Cloud HSM backend to help ensure that your symmetric and asymmetric keys are only used in FIPS 140-2 Level 3–validated HSMs.

• Cloud KMS with key import: To satisfy BYOK requirements, you can import your own cryptographic keys that you generate yourself. You can use and manage these keys outside of Google Cloud, and use the key material in Cloud KMS to encrypt or sign data that you store in Google Cloud.

• Cloud KMS with external key manager (Cloud EKM): To satisfy HYOK requirements, you can create and control keys that are stored in a key manager that is external to Google Cloud. You then set up the Cloud KMS platform to use the external keys to help protect your data at rest. You can use these encryption keys with a Cloud EKM key. For more information about external key management and Cloud EKM, see Reference architectures for reliable deployment of Cloud EKM services.

You can choose to use keys that are generated by Cloud KMS with other Google Cloud services. Such keys are known as customer-managed encryption keys (CMEK). The CMEK feature lets you generate, use, rotate, and destroy encryption keys that help protect data in other Google Cloud services.

Encryption concepts and key management at Google

This section defines some terms for key management in the context of Google's multi-layered key management infrastructure.

Key rings, keys, and key versions

The following diagram illustrates key groupings, and shows key rings, and keys with a single primary version and multiple previous versions.

The key concepts that are shown in the preceding diagram are the following:

• Key: A named object representing a cryptographic key that is used for a specific purpose. The key material—the actual bits used for cryptographic operations—can change over time as you create new key versions. You can assign IAM allow policies at the key level in the resource hierarchy.

  The key purpose and other attributes of the key are connected with and managed using the key. Thus, the key is the most important object for understanding KMS usage.

  Cloud KMS supports both asymmetric keys and symmetric keys. A symmetric key is used for creating or validating MAC signatures or for symmetric encryption to protect some corpus of data. For example, you can use AES-256 in GCM mode to encrypt a block of plaintext. An asymmetric key can be used for asymmetric encryption or asymmetric signing. For more information, see Supported purposes and algorithms.

• Key ring: A grouping of keys for organizational purposes. A key ring belongs to a Google Cloud project and resides in a specific location. Keys inherit allow policies from their key ring. Grouping keys with related permissions in a key ring lets you grant, revoke, or modify permissions to those keys at the key-ring level without you needing to act on each key individually. Key rings provide convenience and categorization, but if the grouping of key rings isn't useful to you, you can manage permissions directly on keys. Tags let you conditionally allow or deny policies based on whether a resource has a specific tag. You can apply tags at the key ring level in the resource hierarchy.

  To prevent resource name collisions, you cannot delete a key ring or key. Key rings and keys don't have billable costs or quota limitations, so their continued existence doesn't affect costs or production limits.

• Key metadata: Resource names, properties of KMS resources such as allow policies, key type, key size, key state, and any data derived from keys and key rings.

• Key version: The key material associated with a key at some point in time. The key version is the resource that contains the actual key material. Versions are numbered sequentially, beginning with version 1. When a key is rotated, a new key version is created with new key material. The same logical key can have multiple versions over time, which means that your data is encrypted using different key versions. Symmetric keys have a primary version. By default, the primary version is used for encryption. When Cloud KMS performs decryption using symmetric keys, it automatically identifies which key version is needed to perform the decryption.

Software key hierarchy

The following diagram illustrates the key hierarchy for Cloud KMS and Google's internal Keystore. Cloud KMS uses Keystore, which is Google's internal key management service, to wrap Cloud KMS-encrypted keys. Envelope encryption is the process of encrypting one key using another key, in order to securely store it or transmit it over an untrusted channel. Cloud KMS uses the same root of trust as Keystore.

The key hierarchy that is shown in the preceding diagram is the following:

1. A data encryption key (DEK) encrypts the data chunks.
2. A key encryption key (KEK) is used to encrypt, or wrap, the DEK. All Cloud KMS platform options (software, hardware, and external backends) let you control the KEK. KEKs are stored in Cloud KMS.
3. A KMS master key encrypts the KEK. The KMS master key is stored in Keystore. There is a separate KMS master key in Keystore for each Cloud KMS location. KEKs in Cloud KMS are protected by the location's KMS master key. Each Cloud KMS server fetches a copy of the KMS master key during startup as a hard dependency, and a new copy of the KMS master key is retrieved every day. The KMS master key is re-encrypted periodically.
4. The KMS master key is protected by the keystore master key in Keystore.
5. The keystore master key is protected by the root keystore master key.

For more information about Keystore, see Key management in the Encryption at rest paper.

Key operational constraints

Cloud KMS operates within the following constraints:

• Project: Cloud KMS resources belong to a Google Cloud project, just like all other Google Cloud resources. You can host data in a project that is different from the project in which your Cloud KMS keys reside. To support the best practice of separation of duties between the key administrators and data administrators, you can remove the owner role from the key project.
• Locations: Within a project, Cloud KMS resources are created in a location. For more information about locations, see Geography and regions.
• Consistency: Cloud KMS propagates operations on keys, key rings, and key versions using strong consistency or eventual consistency. For more information, see Cloud KMS resource consistency.

Cloud KMS platform overview

The Cloud KMS platform supports multiple cryptographic algorithms and provides methods to encrypt and digitally sign using external-, hardware-, and software-backed keys. The Cloud KMS platform is integrated with Identity and Access Management (IAM) and Cloud Audit Logs so that you can manage permissions on individual keys and audit how they are used.

The preceding diagram shows the following main components of the Cloud KMS platform:

• Administrators access key management services by using the Cloud console or the Google Cloud CLI.

• Applications access key management services by implementing the REST API, gRPC, or client libraries. Applications can use Google services that are enabled to use CMEK. CMEK in turn uses the Cloud Key Management Service API. If your application uses PKCS #11, you can integrate it with Cloud KMS using the library for PKCS #11.

• The Cloud KMS API lets you use software, hardware, or external keys. Both software-based and hardware-based keys use Google's redundant backup protections.

• If you use hardware keys, FIPS 140-2 Level 3 certified HSMs in Google Cloud store the keys. For more information about our certification, see Certificate #4399.

• Cloud KMS uses Google's internal datastore to store encrypted customer key material. This datastore is highly available and supports many of Google's critical systems. See Datastore protection.

• At regular intervals, the independent backup system backs up the entire datastore to both online and archival storage. This backup allows Cloud KMS to achieve its durability goals. See Datastore protection.

FIPS 140-2 validation

Cloud KMS cryptographic operations are performed by our FIPS 140-2-validated modules. Keys with the SOFTWARE protection level, and the cryptographic operations performed with them, comply with FIPS 140-2 Level 1. These cryptography operations use BoringCrypto, which is a Google-maintained, open-source cryptographic library. Keys with the HSM protection level, and the cryptographic operations performed with them, comply with FIPS 140-2 Level 3.

Google infrastructure dependencies

Cloud KMS platform elements run as production Borg jobs. Borg is Google's large-scale cluster manager for handling API serving jobs and batch jobs.

For information about the security of our physical and production infrastructure, see the Google infrastructure security design overview.

Cloud KMS API serving jobs

Cloud KMS API serving jobs are production Borg jobs that serve customers' requests to manage and use their keys. Cloud KMS API serving jobs also process deferred actions from customer requests, like rotating keys on schedule, creating asymmetric keys, and importing keys. These serving jobs run in every Google Cloud region where Cloud KMS is available. Each job is associated with a single region and is configured to only access data from systems geographically located within the associated Google Cloud region.

Cloud KMS batch jobs

The Cloud KMS platform also maintains a number of batch jobs that run as production Borg jobs on various schedules. Batch jobs are region-specific and only aggregate data from, and run within, the associated Google Cloud region. Tasks that these jobs perform include the following:

• Count active keys for customer billing.
• Aggregate resources from the public protocol buffer API for Cloud KMS and forwarding the metadata to Cloud Asset Inventory. Resources in this context are any resources that Cloud KMS manages—for example, keys and key rings.
• Aggregate all resources and reporting information for business analytics.
• Snapshot data for high availability.
• Validate that all data stored in the underlying datastore is uncorrupted.
• Re-encrypt customer key material when the KMS Master Key is being rotated.

Cloud KMS key snapshotter

To maintain high availability, the Cloud KMS platform maintains a redundant datastore in each instance of the shared service that hosts the Cloud KMS API server tasks. Each shared service deploys its own instance of the snapshotter service. This redundancy makes services highly independent so that a failure in one zone has a limited effect on other zones. When the Cloud KMS API job needs to perform a cryptographic operation, it queries the primary datastore along with the local snapshotter jobs in parallel. If the primary datastore is slow or unavailable, the response may be served from a snapshot, if the snapshot is no more than two hours old. Snapshots are created as the output of a batch job that runs continuously for each region. Snapshots reside in the cloud region associated with the key material.

Client-server communications

Google uses Application Layer Transport Security (ALTS) to help provide security for client-server communications that use Google's remote procedure call (RPC) mechanism.

For more information, see Service-to-service authentication, integrity, and encryption.

Cloud KMS platform architecture

This section describes architectural details about the security of key materials and datastore protection.

Security of key materials

In Cloud KMS, the key material is always encrypted at rest and in transit. Key material is decrypted only in the following cases:

• When the customer is using it.
• When Google's internal key that is used to protect customer key material is being rotated or checked for integrity.

Customer requests to Cloud KMS are encrypted in transit by using TLS between the customer and the Google Front End (GFE).

Authentication occurs between all Cloud KMS jobs, both within and between Google data centers.

Google's policy is to ensure that jobs use only source code that has been built, tested, and reviewed in a verifiable manner. Binary Authorization for Borg (BAB) enforces this policy at the operational level.

Cloud KMS API jobs can access key metadata (for example, the allow policy or the rotation period). A Google employee with a valid, documented business justification (such as a bug or a customer issue) can also access key metadata. These access events are logged internally, and logs pertaining to data that is covered by Access Transparency are also available to qualified customers.

Decrypted key material cannot be exported or viewed through the API interface or another user interface. No Google employee has access to unencrypted customer key material. Additionally, key material is encrypted with a master key in Keystore, which cannot be directly accessed by any individual. On an HSM, key material is never accessed in a decrypted state by Cloud KMS API jobs.

Datastore protection

The datastore for Cloud KMS is highly available, durable, and protected.

Availability. Cloud KMS uses Google's internal datastore, which is highly available and supports a number of Google's critical systems.

Durability. Cloud KMS uses authenticated encryption to store customer key material in the datastore. Additionally, all metadata is authenticated using a hash-based message authentication code (HMAC) to ensure it hasn't been altered or corrupted at rest. Every hour, a batch job scans all key material and metadata and verifies that the HMACs are valid and that the key material can decrypt successfully. If any data is corrupted, Cloud KMS engineers are immediately alerted so that they can take action.

Cloud KMS uses several types of backups for the datastore:

• By default, the datastore keeps a change history of every row for four days. In an emergency, this lifetime can be extended to provide more time to remediate issues.
• Every hour, the datastore records a snapshot. The snapshot can be validated and used for restoration, if needed. These snapshots are kept for four days.
• Every day, a full backup is copied to disk and to archival storage.

The Cloud KMS team has documented procedures for restoring backups to mitigate data loss when a service-side emergency occurs.

Backups. Cloud KMS datastore backups are located in their associated Google Cloud region. These backups are all encrypted at rest. Access to data in backups is gated based on access justifications (such as a ticket number that you filed with Google support), and human access is logged in Access Transparency logs.

Protection. At the Cloud KMS application layer, your key material is encrypted before it is stored. Engineers with access to the datastore don't have access to plaintext customer key material. Additionally, the datastore encrypts all data that it manages before writing to permanent storage. Therefore access to underlying storage layers, including disks or archival storage, doesn't allow access to even the encrypted Cloud KMS data without access to the datastore encryption keys, which are stored in Keystore.

Rotation policy. Key rotation is part of the generally accepted best practices for the handling of key material. A rotation policy exists for the keys used to protect Cloud KMS datastores. A key rotation policy is also applied to the Keystore master keys that wrap the Cloud KMS master keys. The Keystore master key has a scheduled ciphertext maximum age of 90 days with a client cached key maximum age of one day. Cloud KMS refreshes the KMS master keys in KMS tasks every 24 hours and re-encrypts all customer keys on a monthly basis.

Data residency. The data underlying each Cloud KMS datastore remains exclusively within the Google Cloud region with which the data is associated. This applies to locations that are multi-regions as well, for example, the us multi-region.

Key availability after creation

Cloud KMS allows a key to be used immediately after the Cloud KMS datastore commits the transaction that creates the key and after the storage layer acknowledges its creation.

Key backend

When you create a key with Cloud KMS, you can choose a protection level to determine which key backend creates the key and performs all future cryptographic operations on that key. The backends are exposed in the Cloud KMS API as the following protection levels:

• SOFTWARE: Applies to keys that may be unwrapped by a software security module to perform cryptographic operations.
• HSM: Applies to keys that can only be unwrapped by HSMs that perform all cryptographic operations with the keys.
• EXTERNAL or EXTERNAL-VPC: Apply to external key manager (EKM). EXTERNAL-VPC lets you connect the EKM to Google Cloud over a VPC network.

Cloud KMS software backend: SOFTWARE protection level

The protection level SOFTWARE applies to keys whose cryptographic operations are performed in software. This section describes the details of how this level is implemented.

Algorithmic implementations

For software keys, Cloud KMS uses the BoringCrypto module (BCM) within Google's BoringSSL implementation for all related cryptographic work. The BCM is FIPS 140-2 validated. The Cloud KMS binary is built against FIPS 140-2 Level 1–validated Cryptographic Primitives of this module. The most current algorithms covered by this module are listed on Key purposes and algorithms, and include encrypt, decrypt, and sign operations with AES256-GCM symmetric and RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 asymmetric cryptographic keys.

Random number generation and entropy

When generating encryption keys, Cloud KMS uses BoringSSL. FIPS 140-2 requires that its own PRNGs be used (also known as DRBGs). In BoringCrypto, Cloud KMS exclusively uses CTR-DRBG with AES-256. This provides output for RAND_bytes, the primary interface by which the rest of the system gets random data. This PRNG is seeded from the Linux kernel's RNG, which itself is seeded from multiple independent entropy sources. This seeding includes entropic events from the data center environment, such as fine-grained measurements of disk seeks and inter-packet arrival times, and Intel's RDRAND instruction where available. For more information about the behavior of the random number generator for BoringSSL (FIPS-compliant mode), see the RNG design.

Cloud HSM backend: HARDWARE protection level

Cloud HSM provides hardware-backed keys to Cloud KMS. It lets you use cryptographic keys that are protected by fully managed, FIPS 140-2 Level 3 certified HSMs in Google data centers. Cloud HSM is highly available and provides elastic scale, just like Cloud KMS. No application changes are required for existing Cloud KMS customers as they can access the Cloud HSM backend using the same API and client libraries as Cloud KMS. For more information about the Cloud HSM backend, see Cloud HSM architecture.

Cloud EKM: EXTERNAL protection level

Cloud EKM lets you encrypt data using off-cloud encryption keys that remain in your control.

Keys with the EXTERNAL and EXTERNAL_VPC protection levels are stored and managed in an external key management system. For more information, see Reference architectures for reliable deployment of Cloud EKM services.

Key import

You might want to import your own keys that you created on-premises or in an EKM into your cloud environment. For example, you might have a regulatory requirement that the keys used to encrypt your cloud data are generated in a specific manner or environment. Key import lets you import these keys and meet your regulatory obligations. To extend your signing capabilities to the cloud, you can also import asymmetric keys.

As part of key import, Cloud KMS generates a public wrapping key which is a public/private key pair, using one of the supported import methods. Encrypting your key material with this wrapping key protects the key material in transit.

You use the public wrapping key to encrypt the key to be imported on the client. The private key that matches the public key is stored within Google Cloud and is used to unwrap the public key after it reaches the Google Cloud project. The import method that you choose determines the algorithm that is used to create the wrapping key. After your key material is wrapped, you can import it into a new key or key version on Cloud KMS.

You can use imported keys with the HSM or SOFTWARE protection level. For Cloud HSM, the private key portion of the wrapping key is available only within Cloud HSM. Restricting the private key portion to Cloud HSM prevents Google from unwrapping your key material outside of Cloud HSM.

Customer-managed encryption keys (CMEK)

By default, Google Cloud encrypts all customer data stored at rest, with Google managing the keys used for encryption. For some Google Cloud products, you can instead use Cloud KMS to manage the keys used for encryption. CMEK can be used for external-, software-, and hardware-backed keys. Cloud KMS lets you control many aspects of keys (such as creating, enabling, disabling, rotating, and destroying keys) and manage appropriate IAM permissions on them. To enforce a recommended separation of duties, Cloud KMS includes several predefined IAM roles that have specific privileges and limitations and can be granted to specific users and service accounts.

Rotating the Cloud KMS key doesn't re-encrypt the data in the associated CMEK service. Instead, newly created resources are encrypted using the new key version, which means that different versions of a key protect different subsets of data. For example, BigQuery doesn't automatically rotate a table encryption key when the Cloud KMS key associated with the table rotates. Existing BigQuery tables continue to use the key version with which they were created. New BigQuery tables use the current key version. For more information, see the documentation for each product.

CMEK organization policies provide greater control over how CMEK is used within your projects. These policies let you control both the services and projects that hold keys allowed for CMEK.

Google Cloud supports CMEK for many services, including Cloud Storage, BigQuery, and Compute Engine. See CMEK integrations for the full list of CMEK integrations and CMEK-compliant services. Google continues to invest in CMEK integration for other Google Cloud products.

Lifecycle of a Cloud KMS request

This section describes the lifecycle of a Cloud KMS request, including a discussion of the destruction of key material. The following diagram shows a client requesting access to Cloud KMS service instances in us-east1 and us-west1, and how the requests are routed using the Google Front End (GFE).

The steps in this lifecycle include the following:

1. A customer, or a job running on behalf of a customer, composes a request to the Cloud KMS service, https://cloudkms.googleapis.com. DNS resolves this address to an anycast IP address of the GFE.
2. The GFE provides public IP hosting of its public DNS name, denial of service (DoS) protection, and TLS termination. When the customer sends their request, it is generally routed to a GFE near to the customer, regardless of which location the customer's request is targeted for. GFEs handle the TLS negotiation and, using the request URL and parameters, determine what Global Software Load Balancer (GSLB) routes the request.
3. There is a separate GSLB target for each Cloud KMS region. If the request arrives at Google in us-east1, and the request is destined for us-west1, the request is routed between the us-east1 and us-west1 data centers. All communication between data centers is encrypted in transit using ALTS, which mutually authenticates the GFE and Cloud KMS jobs.
4. When the request reaches the Cloud KMS job, it is first processed by a framework that handles much of the work common to all Google Cloud services. This framework authenticates the user and performs a number of checks to verify the following:
   • The customer has a valid credential and can be authenticated.
   • The project has the Cloud KMS API enabled and has a valid billing account.
   • The quota is sufficient to run the request.
   • The customer is on the allowlist to use the relevant Google Cloud region.
   • The request isn't rejected by VPC Service Controls.
5. After these checks pass, the framework forwards the request and credential to Cloud KMS. Cloud KMS parses the request to determine what resources are being accessed, and then checks with IAM to see whether the caller is authorized to make the request. IAM also tells Cloud KMS whether the request occurrence should be written to audit logs.
6. After the request is authenticated and authorized, Cloud KMS calls its in-region datastore backends to fetch the requested resource. After the resource is fetched, the customer key material is decrypted for use.
7. With the key material, Cloud KMS then performs the cryptographic operation, forwarding the wrapped version of the key to either the Cloud KMS software backend, Cloud HSM backend, or the Cloud EKM backend, depending on the protection level of the key.
8. After the cryptographic operation is completed, the response is sent back to the customer along the same type of GFE-to-KMS channel as the request.
9. As the response is returned, Cloud KMS also triggers some events asynchronously:
   • Audit and request logs are filled and queued to be written.
   • Reports are sent for billing and quota management purposes.
   • If the request updated the metadata of a resource, the change is sent to Cloud Asset Inventory through batch job updates.

End-to-end data integrity

Cloud KMS lets you calculate checksums for keys and key materials to help ensure that they aren't corrupted. These checksums help protect you from data loss that might be caused by hardware corruption or software corruption. Helper libraries let you verify key integrity. You can use helper libraries to verify key integrity by providing checksums to Cloud KMS, which are verified by the server. Also, these libraries let you receive checksums to verify response data on the client.

End-to-end data integrity helps protect your environment from threats such as the following:

• Corruption during transit; such as in the stack between when data is sent and when it gets protected by TLS.
• Issues in any intermediate proxies between your endpoint and KMS (for example, for incoming requests).
• Faulty crypto operations, machine memory corruption, or HSM corruption in the Cloud KMS architecture.
• Corruption during communication with an external EKM.

For more information, see Verifying end-to-end data integrity.

Destruction of key material

Key material is considered to be customer data, so the approach described in Data deletion on Google Cloud also applies to Cloud KMS. Key material is destroyed on request, when the Scheduled for destruction period is complete and backups expire. The key material that is still present in backups (after the scheduled for destruction period is over) can only be used for regional disaster recovery, and not for restoring individual keys. This process isn't guaranteed for copies of imported keys that exist outside of Cloud KMS control.

By default, keys in Cloud KMS spend 30 days in the Scheduled for destruction (soft deleted) state before the key material is logically deleted from the system. You can change this duration. For more information, see Variable duration of the Scheduled for destruction state.

Although key material is destroyed, keys and key rings cannot be deleted. Key versions also cannot be deleted, but key version material can be destroyed so that the resources can no longer be used. Key rings and keys don't have billable costs or quota limitations, so their continued existence doesn't affect costs or production limits.

After a key version is scheduled for destruction, the key version isn't available for cryptographic operations. Within the pending delete period, you can restore the key version so that it isn't destroyed.

If you delete an imported key by mistake, you can re-import it. For more information, see Re-importing a destroyed key.

To avoid accidentally deleting a key, consider the following best practices:

• Create a custom KMS role that doesn't include the cloudkms.cryptoKeyVersions.destroy permission.
• Change the destroy_scheduled_duration field to a longer period of time.

• Monitor and add alerts for key destruction events. For example, create the following Cloud Logging filter:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Create processes that disable the key for a couple days before the key is deleted.

Cloud KMS platform operational environment

The operational environment for the Cloud KMS platform includes data storage and security policies, access restrictions, and risk mitigation strategies that are designed to optimize reliability, durability, and availability while safeguarding key material. This section discusses the service's operating structure, responsibilities for operations team members, authentication mechanisms, and auditing and logging protocols. This section applies to both the software- and hardware-backed key capabilities.

Software engineers, site reliability engineers, and system operators

Software engineers are responsible for partnering with other stakeholders such as product managers and site reliability engineers (SREs) to design the system and write much of the code and tests for the Cloud KMS service. The code includes the main job that serves customer requests, as well as secondary jobs for activities such as data replication and billing. SREs also might write code. However, software engineers and SRE duties are separated; SREs are primarily responsible for maintaining the production environment for Cloud KMS jobs. SREs measure and achieve reliability through engineering and operations work.

System operators are responsible for the build-and-release process, monitoring, alerting, and capacity planning for Cloud KMS. They are the first responders to customer issues and outages for Cloud KMS. As an example, system operators leverage tooling and automation to minimize manual systems work so that they can focus on efforts that bring long-term value.

The duties for system operators are defined in standard operating procedures. System operators don't access customer key material while performing their duties.

Regionality of Cloud KMS resources

To help you meet any key residency requirements, you can create Cloud KMS resources in one of four types of Google Cloud locations:

• A region location consists of zones in a specific geographical place, such as Iowa.
• A dual-region location consists of zones in two specific geographical places, such as Iowa and South Carolina.
• A multi-region location consists of zones spread across a general geographical area, such as the United States.
• The global location consists of zones spread around the world. When you create your Cloud KMS resources in the global location, they are available from zones worldwide.

Locations represent the geographical regions where requests to Cloud KMS for a given resource are handled, and where the corresponding cryptographic keys are stored.

For more information on available Cloud KMS locations, see Cloud KMS locations.

Cloud regions and data centers

A Google Cloud region contains a specific data center or a specified set of data centers, determined by its designation as a single-region, dual-region, multi-region, or global. For more information on Google Cloud regions, see Google Cloud locations.

Each data center contains racks of machines for computing, networking, or storage of data.These machines run Google's Borg infrastructure.

Google data centers have strict physical security requirements. Any physical space that might contain user data requires entryways with badge readers and iris scanners that are used to authenticate entrants. Doors aren't held open for multiple people; each person must authenticate themselves individually. Bags aren't permitted to be brought in or out of these areas, unless they are clear bags that are explicitly authorized after inspection by security personnel. Special permission is required to bring in or out any electronic device that might transmit or record data.

Key residency

Some industries require that cryptographic keys reside in a specific location. Cloud KMS has data location terms with assurances on data residency. As introduced in Regionality of Cloud KMS resources, Cloud KMS offers four types of regional locations to help you meet those requirements.

For single, dual, or multi-region locations, Cloud KMS creates, stores, and processes your software- and hardware-backed keys and key material only in that location. Storage and data processing systems that Cloud KMS uses are configured to only use resources within the Google Cloud region that is associated with the key material. Key material created in dual-region or multi-region locations doesn't leave the boundaries of the selected locations.

For the global region, there are no regionality guarantees specified.

Cloud KMS doesn't guarantee residency for key metadata, usage logs, or for key material in transit. Key metadata includes resource names; properties of Cloud KMS resources such as key type, key size, and key state; IAM policies; and any data derived from metadata.

When using CMEK, the following Cloud KMS geographic restrictions apply to your keys regardless of the custom, dual-region, or multi-region locations that you choose in other Google Cloud products that support CMEK:

• For a specific region: Because the region of a customer-managed KMS key must always correlate to the region of the resource it protects in a given Google Cloud service, residency restrictions for single-region keys and resources are guaranteed to be compatible and enforced.
• For dual-region or multi-region locations: Users can select Google-defined multi-regions for their keys and Google Cloud resources to guarantee residency compliance. To ensure this geographic residency, make sure that your regions in other products line up with your chosen Cloud KMS regional location.

The following table summarizes residency of key material for Cloud KMS.

Region type	At rest, in use
Single region	Resident
Dual-region or multi-region	Resident in the regions that constitute the dual or multi-region

Regionality monitoring

Google's internal data monitoring services actively monitor key residency. Cloud KMS sends alerts to SRE team members if it detects accidental misconfigurations, or if key material leaves the boundaries of its configured region, is stored in the wrong region, or is accessed from the wrong region.

High availability

Cloud KMS can help simplify your availability requirements based on the regions that you select. The more granular the location, the more redundancy you have to build. For applications with higher levels of availability, use multi-region locations rather than trying to build your own replication system of keys. You must balance the built-in redundancy capabilities with your data regionalization needs.

Authentication and authorization

Cloud KMS accepts a variety of authentication mechanisms, such as OAuth2, JWT, and ALTS. Whatever the mechanism, Cloud KMS resolves the provided credential to identify the principal (the entity which is authenticated and is authorizing the request), and calls IAM to see whether the principal is authorized to make the request and whether an audit log is written.

Cloud KMS uses an internal version of the public Service Control API for many aspects of service management. Before a Cloud KMS job handles a request, it first sends a check request to the Service Control API, which enforces many controls common to all Google Cloud services, such as the following:

• Checking whether you activated the Cloud KMS API and have an active billing account.
• Checking whether you haven't exceeded your quota, and reporting quota usage.
• Enforcing VPC Service Controls.
• Checking whether you are on the allowlist for applicable private cloud regions.

Quota management

Cloud KMS has usage limits, called quotas, on requests made to the service. Cloud KMS contains the following quotas:

• Cryptographic requests quotas for operations such as encrypt, decrypt, or sign.
• Read requests quotas for operations such as getting key metadata or getting an IAM policy.
• Write requests quotas for operations such as creating a key or setting an IAM policy.

These quotas are charged to the project that is associated with the caller. These quotas are also global, which means that they are applied for the caller's KMS usage across all regions and multi-regions. These quotas are evaluated for all protection levels.

Cloud HSM and Cloud EKM have additional quotas for cryptographic operations. These quotas must be satisfied in addition to the cryptographic requests quota. Cloud HSM and Cloud EKM quotas are charged to the project where the key resides, and the quotas are enforced for each location.

Consider the following examples:

• Calling decrypt with a software key in asia-northeast1 requires one unit of (global) cryptographic requests quota.
• Creating an HSM key in us-central1 requires one unit of write requests quota and no HSM quota.
• Calling encrypt with an EKM key in europe requires one unit of (global) cryptographic requests quota, and one unit of external KMS requests quota in europe.

For more information about the type of quotas available, see Quotas on the usage of Cloud KMS resources. You can view your quota limit in the Cloud console. The initial quotas limits are soft limits that you can request be adjusted based on your workload needs.

Logging

Three types of logs are associated with Cloud KMS: Cloud Audit Logs, Access Transparency logs, and internal request logs.

Cloud Audit Logs

Cloud KMS records your activity in Cloud Audit Logs. You can view these logs in the Cloud console. All admin activity—for example, creating or destroying a key—is recorded in these logs. You can also choose to enable logging for all other actions that use a key—for example, using a key to encrypt or decrypt data. You control how long you wish to retain the logs and who may view the logs.

Access Transparency logs

Eligible customers might choose to enable Access Transparency logs, which provide them with logs of actions that Google employees take in your Google Cloud organization. Access Transparency logs, alongside the logs from Cloud Audit Logs, can help you answer questions about who did what, where, and when.

You can integrate Access Transparency logs with your existing security information and event management (SIEM) tools to automate your audits of these actions. These logs are available in the Cloud console alongside your Cloud Audit Logs.

Access Transparency log entries include the following types of details:

• The affected resource and action.
• The time of the action.
• The reasons for the action. Examples of reasons include customer-initiated support (with a case number), Google-initiated support, third-party data requests, and Google-initiated review requests.
• Data about who is acting on the data (for example, the Google staff member's location).

Internal request logs

Request logs store a record for every request sent to the Cloud KMS platform. This record contains details about the type of request (such as API method or protocol), and the resource being accessed (such as resource name, key algorithm, or key protection level). These logs don't store customer plaintext, ciphertext, or key material. Before new types of data are added to these logs, a team that specializes in privacy reviews must approve changes to the data that is logged.

Log entries are permanently deleted when the configured time to live (TTL) has expired.

Cloud KMS SREs and engineers in the on-call rotation can access request logs. Human access to logs and any access that returns customer data requires a valid and documented business justification. With some specific exceptions, human access is logged and accessible to qualifying customers in Access Transparency logs.

Monitoring

Cloud KMS integrates with Cloud Monitoring. This integration lets you monitor, build dashboards, and create alerts on many Cloud KMS operations. For example, you can monitor when keys are scheduled for destruction or monitor and adjust Cloud KMS quotas when cryptographic operations are past a threshold you define. For more information about the available Cloud KMS metrics, see Using Cloud Monitoring with Cloud KMS.

In addition, Security Command Center has built-in KMS vulnerability detectors. These detectors help ensure that your projects which include keys follow our recommended best practices. For more information about the KMS vulnerability detector, see Vulnerability findings for Cloud KMS.

What's next

• To learn more about Cloud KMS, explore the following resources:
  • Cloud KMS documentation
  • Cloud HSM documentation
• For information about using your own encryption keys in Google Cloud, see Customer-managed encryption keys (CMEK).
• Learn how Google is preparing for a post-quantum world.
• To learn more about Google infrastructure security, see Google infrastructure security design overview.
• For general information on Google Cloud security, see the Security section of the Google Cloud website.