GCP – New Google Cloud whitepaper: Getting the most out of your Cloud Key Management Service

The cliché that “encryption is easy, but key management is hard,” remains true:  encryption key management is still a challenge for many large organizations. Add in cloud migration of many sensitive workloads, which necessitates encryption, and the challenges have become more acute.

Cloud, however, also holds the potential for making encryption key management more performant, secure, and compliant—and even easier to manage. Done right, cloud-based key management can improve trust in cloud computing. 

However, it will only achieve these goals if it’s done transparently. Google Cloud Security recently published a whitepaper titled “Cloud Key Management Service Deep Dive”, to help you get the most out of your cloud key management.

The paper focuses on the inner workings of Google’s Cloud Key Management Service (Cloud KMS)  platform and the key management capabilities that are currently generally available (GA). These options provide a range of control and cloud integration options to help you protect the keys and other sensitive data that you store in Google Cloud, in the way that’s right for you.

Moving to the cloud can help to eliminate some security vulnerabilities and shift responsibility for some areas of security. To proceed confidently, you need to understand how cloud key management affects key control, access control and monitoring, data residency, and durability. You’ll also want to understand the architecture and security posture of Google Cloud’s key management options.

Continue reading to see highlights from our recent “Cloud Key Management Service Deep Dive”, whitepaper:

• “The Cloud KMS platform lets Google Cloud customers manage cryptographic keys in a central cloud service for either direct use or use by other cloud resources and applications.”

• “Cloud KMS cryptographic operations are performed by FIPS 140-2–validated modules. Keys with protection level SOFTWARE, and the cryptographic operations performed with them, comply with FIPS 140-2 Level 1. Keys with protection level HSM, and the cryptographic operations performed with them, comply with FIPS 140-2 Level 3.”  Despite its age, FIPS-140-2 Level 3 remains the standard for some of the cryptography clients ask for; and it also gets mapped to other mandates like PCI DSS.

• “Key material, however, cannot be accessed by Cloud KMS API jobs, and 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. Key material is additionally encrypted with a Master Key in Root KMS, which cannot be directly accessed by any individual.”  This clarifies that you, the customer, are the ones that have access to and control of your keys.   

• This is a very useful security reminder; good encryption really does mean that if you lose the key, you cannot ever get the data back. Not even your cloud provider can get that data for you, after a certain amount of time.

• Specifically, “After it’s scheduled for destruction, a key version is not available for cryptographic operations. Within the 24-hour period, the user can restore the key version so that it is not destroyed.” Note that this is critical for some encryption use cases.

• “The data underlying each Cloud KMS datastore remains exclusively within the Google Cloud region with which the data is associated. ”  This matters a lot for customers in some regions, where they may have strict data and key residency or even key sovereignty requirements.

• “The Cloud HSM service provides hardware-backed keys to Cloud KMS. It offers customers the ability to manage and use cryptographic keys that are protected by fully managed Hardware Security Modules (HSMs) in Google data centers. The service is highly available and auto-scales horizontally. ” Yes, we really did make this work – it is based on trusted hardware yet it auto-scales with your cloud!  Using Cloud HSM uses FIPS 140-2 Level 3 compliant HSMs, to meet compliance requirements. But Cloud HSM is not just a 1:1 replacement – it eliminates the effort and risk associated with scaling, failover, availability of HSMs, and also is fully integrated with Google services.

• “Eligible customers may optionally choose to enable Access Transparency logs, which provide them with logs of actions that Google employees take in your Google Cloud organization.” This boosts the level of transparency for cloud key management and ultimately serves to make our cloud more worthy of your trust. This also makes our system much more resilient vs several classes of potential insider threats.

• “You may want to import your own keys 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.” Admittedly, this makes key management more complicated, but if this is an external requirement, Google Cloud KMS allows you to support this.

• “For single, dual, or multi-region locations, Cloud KMS creates, stores, and processes your customer software- and hardware-backed keys and key material only in that location. ” This means that if you want the encryption key to never leave a particular cloud region, you can be assured this is the case. This is a big deal for customers who have requirements for data residency.

For more context on encryption and compliance, check out our recent blog post, Lost in translation: encryption, key management, and real security. And be sure to download the full paper to learn more about how Google Cloud does key management, how our key management is implemented securely, and how it can help you achieve your security goals.