About customer-managed encryption keys (CMEK)
Using customer-managed encryption keys (CMEK) ensures that your issuer switch data is protected with a key that you control and manage in Cloud Key Management Service (KMS).
This page describes CMEK for the issuer switch. For more information about CMEK in general, including when and why to enable it, see the Cloud KMS documentation.
- Data access control: administrators can rotate, manage access to, and disable or destroy the key used to protect data in issuer switch.
- Auditability: if you enable audit logging for Cloud KMS API in your project, all actions on the key, including those performed by the issuer switch, are logged and viewable in Cloud Logging. Cloud EKM keys support Key Access Justification, which adds a justification field to all key requests. With select external key management partners, you can automatically approve or deny these requests, based on the justification.
- Performance: there are no changes to the issuer switch performance.
There are no additional costs for using CMEK with the issuer switch.
You are billed by Cloud KMS for both the cost of the key and any cryptographic operations on that key (whenever the issuer switch uses the key for encryption/decryption). We expect those costs to be minimal based on the expected number of cryptographic operations generated by the issuer switch. For more information, see Cloud KMS pricing.
What is protected with CMEK?
The issuer switch uses your Cloud KMS key to protect data at rest. This includes data stored in any underlying infrastructure systems that the issuer switch uses.
To use CMEK for the issuer switch, you must create a new key for CMEK and share the key's resource name with Google when the issuer switch instance is being provisioned. See Set up your issuer switch instance.
The issuer switch APIs, such as those that are used to list or export transaction, manage rules and so on, are exactly the same when CMEK is enabled on the issuer switch. Applications don't need to specify keys or encryption configs when reading or writing data. All encryption is handled by the service.
Key management operations are performed using Cloud KMS. The issuer switch cannot detect or act upon any key changes until they are propagated by Cloud KMS. Some operations, such as disabling or destroying a key, can take up to 3 hours to propagate; changes to permissions usually propagate much faster.
Once the issuer switch instance is created, the issuer switch calls Cloud KMS about every 5 minutes to make sure that the key is still valid.
If the issuer switch detects that your Cloud KMS key has been disabled
or destroyed, an operation to make your issuer switch instance inaccessible begins
immediately. Any subsequent calls to the issuer switch instance return a
KMS key required by the
resource is not accessible.
If the issuer switch's calls to Cloud KMS detect that a formerly disabled key has been re-enabled, Cloud KMS restores access to the issuer switch instance automatically.
How is an unavailable key status handled?
In rare scenarios, such as during periods when Cloud KMS is unavailable, the issuer switch may be unable to retrieve the status of your key from Cloud KMS.
If your issuer switch instance is protected by a key that is enabled at the time at which the issuer switch is first unable to communicate with Cloud KMS, the issuer switch continues to support full operations on a best-effort basis for a period of up to 1 hour, to minimize the impact of any such incident on your workload.
After an hour, if the issuer switch is still unable to connect with Cloud KMS, the issuer switch goes offline as a protective measure. The data in your issuer switch remains inaccessible until your issuer switch instance can reconnect with Cloud KMS and Cloud KMS responds that the key is active.
Conversely, if your issuer switch instance is protected by a key that is disabled at the time at which the issuer switch is first unable to communicate with Cloud KMS, your issuer switch instance remains inaccessible until it is able to reconnect to Cloud KMS and you have re-enabled your key.
External key considerations
When you use a Cloud EKM key, Google has no control over the availability of your externally-managed key in the external key management partner system.
If an externally-managed key is unavailable, the issuer switch continues to support full operations using a cached version of the key, for up to one hour.
After an hour, if the issuer switch is still
unable to connect with Cloud KMS, the issuer switch goes offline as a protective measure. Calls to the issuer switch instance will fail
External key error: Could not find a key
resource at the key URI.
See the Cloud External Key Manager documentation for more considerations when using external keys.
You can audit the requests that the issuer switch sends to Cloud KMS on your behalf in Cloud Logging, if you have enabled audit logging for the Cloud KMS API in your project. These Cloud KMS log entries are visible in Cloud Logging.