Multi-Cloud Key Management: Service and Deployment Options

In this section we will discuss how to deploy your encryption keys into a third-party cloud service. We will illustrate what the deployment options look like, and the components that comprise a solution. We will then walk you through the process of getting the key from your on-premise Hardware Security Module (HSM) into the cloud HSM. We will discuss some of the variations on using the cloud-based HSM for all encryption operations, and cases where you will delegate encryption operations to the cloud-native encryption service. And we will close out this section with a discussion of software (i.e.: non-HSM) based key management systems run atop IaaS cloud services.

There are two basic design approaches to cloud key management. The first, and the far most common model, is generally referred to as ‘BYOK’, or ‘Bring Your Own Key’. As the name implies you are placing your own key into the cloud HSM, and using your key(s) in conjunction with the cloud HSM service to encrypt and decrypt content. This model requires the use of HSMs to work, but it does supports all cloud service models (e.g.: SaaS, PaaS, IaaS) where the cloud vendor offers HSM support. The second model is software based key management. In this case you run the same key management software you currently use on premise, but in this case you run it in multi-tenant IaaS cloud. Vendors supply either a server or container image containing the software package, and you configure and deploy it into your cloud environment.

Let’s jump into the specifics of each model, and look at some of the different ways these approaches are used.


Cloud platforms used for commercial services offer encryption as an option for data storage and communications. With most cloud environments – especially SaaS – encryption is built-in and occurs by default for all tenants as part of the service. To keep things simple the encryption and key management interfaces are not exposed, rather it is a transparent function there on the customers behalf. For select cloud services where stronger security is required, or regulations demand their use, Hardware Security Modules are provided as an option. These modules are both physically and digitally hardened from attacks to ensure that keys are secure, cannot be tampered with, and very, very difficult to misuse.

To incorporate HSMs into their service, the cloud vendors commonly offers an extension to their key management service. In some cases it’s a simple set of additional API calls, but in most cases a dashboard in addition to APIs that help with provisioning and key management tasks. In specific cases, most notably when you use the same type of HSM on-premise that the cloud vendor does, that the full suite of HSM functions are provided for you. As such, the amount of work you need to set up HSMs for BYOK will vary.

Let’s take a closer look at the process of getting your keys into the cloud.

Exporting Keys

For those of you used to using HSMs on premise, you understand that typically keys are to remain fully protected within the HSM, and not be extracted from the protections that hardware device provides. When vendors first configure HSMs they are seeded with information about the vendor and the customer. This process can be done in reverse, with HSMs providing the ability to extract keys, but not for use outside of the HSM, rather to seed another appliance.

Key extraction is a manual process for most – if not all – HSMs. It typically involves two or more security administrators providing credentials, and the use of a smart card or USB stick with a secure enclave to authenticate to the HSM, and then requesting a new key for extraction. And for most HSMs the extraction is similar: Once validation occurs, the HSM takes the customers master key and bundles it with information specific to the HSM vendor and the customer, and in some cases information specific to usage rights for the key, then encrypts this data. These added data elements provide additional protections for the key, dictating where it can be un-encrypted and how it may be used.

The movement of keys does not occur over any specific proxy and is not done synchronously with a destination HSM. Rather the encrypted bundle of information is sent to the cloud service provider. Each cloud service may leverage different HSMs, and each vendor implements their own integration layer, so specifics of getting the key into hardware – and the amount of work required – vary across clouds. In general, once the customer has been provisioned by the cloud vendor with the HSM service, they can import their master key via a dashboard, API calls or a command line interface. Their master key bundle is now used to create any specific customer master keys for their cloud-key hierarchy, and from those data encryption keys as needed. These derived keys are copied into cloud HSMs as needed in the customers region.

Each cloud provider scales-up and maintains redundancy in different ways, and do not typically publish the specific details on how. What they do provide is service guarantees on uptime and performance. The good news is you no longer need to worry about specifics as this facet is taken care of for you. And as cloud service providers do not simply have ‘Hot and Cold’ HSMs, rather a cloud of many HSMs, importing customer keys where needed, resiliency is likely better than what you have on-premise today.

Keep in mind that hardware based key management support is stil considered a special case by cloud service vendors. Not all customers demand it. And in many cases it is not fully available as a self-service feature, rather there is a special sign-up process, may be available only in specific regions or zones, and that use of the service – given the special supporting hardware – costs extra.

Now that you have your keys installed into the cloud HSM, you can now beging using it to encrypt data. But how this occurs varies between different cloud service models, so we will look at a couple common BYOK cases.

SaaS with HSM Encryption

With many SaaS services, if you contract for a cloud-based HSM service, all encryption operations on your behalf are done inside the HSM. While the cloud-native key service may perform the requests on your behalf – so that encryption and decryption operations occur transparently – key access and the encryption operations are performed fully in the HSM.

The following graphic illustrates what some of the cloud document storage/management services provide for BYOK. After your key is imported into the cloud (1), the key management interface installs your keys into the HSM, much like the process we described earlier. Now, as users upload documents to the cloud (2) the key management service requests a new data encryption key (3) specific to the uploaded document. A new key is created (4), and the uploaded document is encrypted prior to being stored in the cloud. In some cases the newly derived encryption key is now encrypted under the customers master key, and send back to the customer for on-premise storage, ensuring the customer has a backup of all keys.

Obviously there are some difference between providers, but this is the basic framework. For other types of SaaS offerings, where encryption and decryption within the HSM is infeasible, we outline a slightly different process.

SaaS/PaaS HSMs with Native Encryption

There are cases where customers bring their own keys to the cloud, but the cloud provider uses derived data encryption keys outside the HSM. For example, consider SaaS applications that run complex reports, or PaaS services where the customer stores terrabytes of information encrypted within a database. For these environments, the sheer volume of encryption operations makes it infeasible – or cost prohibitive – to perform all encryption operations within hardware. As the application and database is part of the underlying service, the vendor chooses how and where to encrypt data.

Commonly cloud vendors will use transparent columnar or disk encryption, using a data encryption key specific to one customer, and derived from the customers master key. This key is what is supplied to the memory resident encryption services as the customers master key never leaves the HSM. The number and type of data encryption keys the cloud service creates per custom will vary, but one or more keys per data repository or user role is common. The in-memory encryption engines are protected from other services such that only they can access encryption keys, and that memory is over-written once they are no longer in use.

The following graphic outlines how when a user makes a requires to a cloud service that they are first authenticated (1) to the cloud. Once authenticated the cloud service will request access (2) from the key service on the users behalf. The key management service requests a key on the users behalf (3). Given the proper credentials and user role, the key is returned (4) to the key service. What happens at this point is cloud specific. If the cloud service uses columnar data encryption, application or database requests decrypt data prior to presenting it to the user. If the cloud service uses volume encryption, the key is supplied when the disk is mounted, and used to decrypt disk blocks as they are read from the physical media. In either case, these operations occur transparently to the user.

Multi-Cloud HSMs

With these capabilities it does not matter if the customer uses private, hybrid or multi-public cloud architecture; the basic framework will remain the same. You can leverage cloud services and ensure you control access to data by using your keys to encrypt data, and only allowing your users to access those keys to decrypt. You could – for example – run analytics servers on Google’s GCP, and Sharepoint service on Microsoft Azure and web applications on AWS simultaneously, each using data secured by your keys sourced from your on-premise key management server. This is the core idea behind Multi-Cloud key management: Leverage the agility and cost-effectiveness of cloud computing while ensuring data cannot be inspected by cloud administrators, hostile nation-states, courts via subpoena, or any other third party. It provides you an extension of your existing on-premise security controls, and one of the few cases where on-premise security controls are fully suitable for cloud services.

BYO Key Managers

The other class of Multi-Cloud key management is to bring and install your own key managemt server into the cloud. For customers who do not use advanced hardware for key management on-premise, but want to ensure the cloud provider does not own – or cannot be compelled to turn over – keys that encrypt your data, software based key management are a suitable option. In fact, if you are already comfortable with software based key management, bringing your own software to the cloud may be your first choice. Let’s take a closer look at the deployment model.

Software Key Management

Software-based key management is simply means running your own key management application in the cloud. This option is only suitable for IaaS as you will need to install and configure your own servers to perform key management functions, but this approach provides most of the benefits hardware security modules. The core functions are key generation, key storage, key rotation and API interfaces need to orchestrate use in the cloud.

It comes with the downside that you will need to provide your own failover and replication model. Nor does the software model meet regulatory requirements which mandate FIPS certified hardware. But the benefits are reduced cost associated with HSMs while maintaining full control of key service instead of delegating this to the cloud provider. You can either import your own master keys, but more commonly customers generate master keys specific to their cloud installations. Key are provided to different cloud services from the key manager through API calls, so volume storage or databases can decrypt data as needed.

The graphic presented here shows how one may deploy server images or containers within a IaaS region. Typically you will have a primary server in one zone or region, and a backup in another region. Replication and synchronization is typically specific to the software you are using, but opening up a software define network connection between the two servers is one way to allow them to communicate. Another is to use persistent store, such as a database or ‘file bucket’, allowing each of the key server instances to pull updates periodically.

Secrets Management

Recently we have witnessed a new take on securing keys and other sensitive data elements in the cloud. We are seeing a small number of organizations distribute secrets across multiple cloud user accounts in the cloud. This model is not limited to key management; while encryption keys may be stored, access tokens, certificates, passwords and other access credentials or configuration data are more common.

The principle use case arose from ‘DevOps’ and similar approaches to automating software builds, software testing and IT deployments. Given the natural tendency to automate and orchestrate within cloud services, the use of automated software build servers, container management systems and other tools it gaining traction. But by their very nature these tasks are to run independently, without human intervention, but need passwords and access certificates. Commonly developers and IT just put encryption keys and passwords in configuration files where they are easily stolen. Rather than allow critically sensitive data sit in unsecured files, these secrets are placed into an encrypted ‘vault’. The vault contents can be accessed programmatically, and may be shared by one or more users in a group.

For IaaS cloud, the deployment model looks very similar to software based key management. There are typically one or more servers for users to connect to, with replication performed over a dedicated network connection, database, or even secured file. Why not use key management? It does not deal with the diverse types of secrets, does not offer the flexibility or full API integration capabilities, and it is harder to set up than a simple encrypted vault. Simplicity and suitability of purpose are the reasons ‘secrets management’ is gaining traction despite current tools requiring much in the way of Do It Yourself (DIY) coding and integration work. This trend should be considered a very small fragment of the overall market today but growing quickly as the approach is a simple way to solve an existing security problems for software development in the cloud.

In our next post we will cover some key issues to consider when selecting one of the above deployment models and the products that support it.

– Adrian Lane
(0) Comments
Subscribe to our daily email digest

from Multi-Cloud Key Management: Service and Deployment Options


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s