Tackle multi-cloud key management challenges with KMaaS

Cloud challenges traditional secrets management approaches

Hardware security modules (HSMs) for internal usage historically helped secure secrets by providing a tamper-resistant, secure physical location where they could be stored. Likewise, encryption key management, often in the form of services, helped provide a central, secure repository for key and secret storage.

The cloud, however, has exacerbated the challenges of secrets management. The traditional methods have somewhat less utility because cloud abstracts lower levels of the technology substrate.

Consider an application fielded into an IaaS, for example. Everything below the OS is supplied by the provider. Implementation of physically attached services, such as HSMs, are out of the customer's direct control. Thus, a customer can employ cloud-based HSM offerings made available by the cloud service provider but not others.

For PaaS and SaaS, HSM is not an option, barring those available from the service provider. The infrastructure is out of scope as well. This means key management services via API from the cloud provider, for example, are also inaccessible from a customer point of view.

Many cloud service providers offer options to help with cloud secrets management -- for example, Azure provides Key Vault, AWS provides Key Management Service and Google Cloud Platform provides Cloud Key Management Service. Each of these offerings can help address the secure storage of secrets within a given cloud provider's context.

While these provider-supplied services work well, they are specific to the cloud provider in use, and they all differ in the interface supplied to the customer.

So, what happens when customers need a secrets management service to span multiple cloud providers or a hybrid environment? IT leaders must be aware of how multi-cloud key management addresses these challenges and how to implement it successfully to protect hybrid and multi-cloud infrastructure.

Multi-cloud key management-as-a-service capabilities

Multi-cloud key management is about extending key management capabilities into environments where multiple different clouds are in use. Cloud key management-as-a-service (KMaaS) models emerged to provide this capability as a rapidly provisioned, cloud-based service.

Depending on the KMaaS offering, keys can be requested via Key Management Interoperability Protocol -- a standard for requesting keys from a key management server -- via a REST API using vendor-supplied stub modules, such as Public-Key Cryptography Standard 11, which employ the key management service.

One advantage of this is it normalizes the interface to the key management mechanism. Thus, applications using the underlying key manager become more portable. The mechanism an application component uses to request access to keys or other secrets will be the same in an application hosted in a data center today, for example, even if that component moves to the cloud tomorrow. This is true whether an organization bursts to a public cloud for disaster recovery or demand reasons or migrates it to the public cloud or between public clouds. This bolsters security by minimizing the need to reissue secrets when moving between environments or export secrets for transmission to another location.

In addition to standardization of the programmatic interface, KMaaS also standardizes administration. Administrative elements -- such as billing, approval flows, maintenance of key inventories and other tasks -- are centralized. This enables central visibility and reduced overhead associated with training staff on administrative workflows.

4 multi-cloud KMaaS implementation considerations

IT leaders need to recognize that using a KMaaS tool does not automatically mean the organization's usage will be secure. It is important to thoroughly vet and validate KMaaS options.

When approaching the KMaaS marketplace, there are four criteria to keep in mind:

1. Make sure mechanisms to store and retrieve keys are conducive to the organization's usage from an architectural point of view. For example, organizations intending to deploy a Java application might prioritize vendors that supply a Java Cryptography Extension
2. Consider how components and applications will connect to the service, in addition to the performance and security requirements associated with the customer's usage. Even using a REST API -- arguably the most ubiquitous mechanism for interfacing with the service -- will require connectivity to the key management service from the location where the key is needed. There are other cases where this is not required -- for example, a protected virtual private cloud without direct outbound connectivity. Customers in this situation need to figure out a mechanism to enable it to connect, proxy the request, use vendor-supplied components that can cache or explore alternative means.
3. Inventory existing secrets that will be stored in the KMaaS. If there is already an on-premises key management service in place, examine what is stored in it and how those secrets are being used. This prior evaluation can help IT leaders set expectations about how difficult it will be to shift usage and determine which access methods will work best. Pay special attention to how access requests will be validated and approved and how key rotation and expiry will be handled, in addition to other special requirements.
4. Recognize that current multi-cloud key management processes may not be equivalent. Pay special attention to situations where replacing existing components is not possible or necessary. For example, organizations using a physical HSM today will likely find keys stored there are not exportable. This is the default for most HSMs since cryptographic operations are performed in the device itself. This means that a key never leaves the boundaries of the HSM, whereas a key manager -- KMaaS or otherwise -- does not behave this same way. Some organizations may have legitimate security or usage requirements for which this is advantageous. Understanding why keys are protected the way they are is an important element in deciding the right approach based on business risks and needs.