This post will discuss how to deploy encryption keys into a third-party cloud service. We illustrate the deployment options, along with the components of a solution. We will then walk through the process of getting a key from your on-premise Hardware Security Module (HSM) into a cloud HSM. We will discuss variations on using cloud-based HSM for all encryption operations, as well as cases where you instead delegate encryption operations to the cloud-native encryption service. We’ll close out with a discussion of software-based (non-HSM) key management systems running on IaaS cloud services.

There are two basic design approaches to cloud key management. The most common model is generally referred to as ‘BYOK’ (Bring Your Own Key). As the name implies you place your own keys in a cloud HSM, and use your keys with the cloud HSM service to encrypt and decrypt content. This model requires HSM to work, but does supports all cloud service models (SaaS, PaaS, and IaaS) so long as the cloud vendor offers an HSM service. 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 a multi-tenant IaaS cloud. Your vendors supplies either a server or a container image containing the software, and you configure and deploy it in your cloud environment.

Let’s jump into the specifics of each model, with some different ways each approach is used.

BYOK

Cloud platforms 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 – instead encryption is a transparent function handled on the customer’s 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 physically and digitally hardened against attack to ensure that keys are secure from tampering and difficult to misuse.

To incorporate HSM into a cloud service, cloud vendors typically offer an extension to their key management service. In some cases it’s a simple set of additional API, but in most cases a dashboard is provided with API for provisioning and key management. In some cases, particularly when you use the same type of HSM on-premise as your cloud vendor, the full suite of HSM functions may be available. So the amount of work you need to set up BYOK varies.

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

Exporting Keys

Those of you used to using HSM on-premise understand that typically keys remain fully protected within the HSM, never extracted from its protection. When vendors configure HSM they are seeded with information about the vendor and the customer. This process can be reversed, providing the ability to extract keys, but generally not to use outside the HSM – traditionally only to seed another appliance.

Key extraction is a manual process for most – if not all – HSM. It typically involves two or more security administrators providing credentials and a smart card or USB stick with a secure enclave to authenticate to the HSM, then requesting a new key for extraction. For most HSM extraction is similar: Once validation occurs, the HSM takes the customer’s 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 the data. These added data elements provide additional protections for the key, dictating where it can be un-encrypted and how it may be used.

Export of keys does not occur over any specific proxy, and is not performed synchronously with import on a destination HSM. Instead the encrypted information bundle is sent to the cloud service provider. A cloud HSM service likely leverages at least a 2-node HSM cluster, and each vendor implements their own integration layer, so key import specifics vary widely, as does the level of effort required. In general; once the customer has been provisioned for the cloud HSM service, they can import their master key via a dashboard, API, or command line. The customer’s master key bundle is used to create their intermediate keys as needed by their cloud key hierarchy, and those intermediate keys in turn are used to generate data encryption keys as needed. These encryption keys are copied into cloud HSM as needed.

Each cloud provider scales up and maintains redundancy in its own ways, and they typically do not typically publish details of how. Instead they provide service guarantees for uptime and performance. The good news is you no longer need to worry much about these specifics, because they are taken care of for you. Additionally, cloud service providers do not as a rule use Active/Standby HSM pairs, preferring a more scalable ‘cloud’ of many hardware modules, handling importation of customer keys as needed, so resiliency is likely better than whatever you have on-premise today.

Keep in mind that hardware-based key management support is still considered a special case by cloud service vendors. Not all customers demand it. And it is often not fully available as a self-service feature – there may be a manual sign-up process and availability in only specific regions or zones. Unlike built-in native encryption, HSM capabilities cost extra.

Once you have your installed in the cloud HSM service you can use it to encrypt data. But how this works varies between different cloud service models, so we will look at a couple common 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 performed inside the HSM. The native cloud encryption service may satisfy the requests on your behalf so encryption and decryption are transparent, but key access and encryption operations are performed fully within the HSM.

The graphic below illustrates what some cloud document services provided for BYOK. After your key is imported into the cloud (1), the key management interface installs your master key into the HSM, as we described earlier. As users upload documents to the cloud (2) the key management service requests a new data encryption key specific to the uploaded document (3). A new key is generated (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 customer’s master key and sent back to the customer for on-premise storage in their full key backup.

Of course there are differences between providers, but the basic framework is common. Other types of SaaS offerings, where encryption and decryption within the HSM is infeasible, use a slightly different process.

SaaS/PaaS HSM with Native Encryption

In some cases customers bring their own keys to the cloud, but the cloud provider uses derived data encryption keys for actual encryption and decryption, outside the HSM. For example, consider SaaS applications running complex reports, or PaaS services where the customer stores terabytes of information encrypted within a database. In such environments the volume of data to encrypt and decrypt can make dedicated encryption/decryption hardware infeasible or too expensive. The application and database are part of the underlying service, so the vendor has a choice of how and where to encrypt and decrypt.

Cloud vendors often use transparent columnar or disk encryption, with a customer encryption key derived from their master key. This key is supplied to memory-resident encryption services, so the customer master key never leaves the HSM. The number and type of data encryption keys the cloud service creates per customer varies, but one or more keys per data repository or user role is common. These in-memory encryption engines are protected from other services, which have tightly restricted access; sensitive memory including key storage is overwritten as soon as it is no longer needed.

The next graphic outlines what happens when when a user makes a request to a cloud service. (1) The user is first authenticated to the cloud. (2) After authentication the cloud service requests access on the user’s behalf from the key service. (3) The key management service requests a key from the HSM on the user’s behalf. (4) Assuming credentials validate and the request is authorized, the HSM returns the requested key to the key service. What happens at this point is cloud-specific. If the cloud service uses columnar data encryption the application or database decrypts data prior to presentation 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 physical media. Either way, these operations are transparent to users.

Multi-Cloud HSM

With these encryption and key management capabilities it does not matter if the customer’s application architecture uses a private cloud, a public cloud, a hybrid cloud, or is distributed across multiple clouds – the framework remains the same. You can leverage various cloud services and ensure you control data access using your own keys to encrypt and decrypt, allowing only your authorized users access to your keys. For example you could simultaneously run analytics on GCP, SharePoint on Azure, and web applications on AWS – each using data secured by your keys, controlled by your on-premise HSM cluster. This is the idea behind multi-cloud key management: leverage the agility and cost-effectiveness of cloud computing while protecting data from cloud administrators, hostile nation-states, law enforcement, and any other third parties. It extends your existing on-premise security controls, and is one of the few cases where on-premise security controls are fully suitable for cloud services.

BYO Key Manager

The other option for multi-cloud key management is to install your own key management server in 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 their data, software-based key management is suitable. 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 deployment.

Software Key Management

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

One downside is that you need to provide failover and replication yourself. Nor is the software model compliant with certain regulatory requirements, which mandate FIPS-certified hardware. But benefits include reduced cost compared to HSM, along with full control of key services, rather than delegating them to the cloud provider. You can import your own master keys, but more often customers generate new master keys for each cloud installation. Unique keys are provided to each cloud service by the key manager through API, so volume storage or databases can encrypt and decrypt as needed.

This graphic shows how one might deploy server images or containers within an IaaS region. Typically you would have a primary server in one zone or region and a backup in another. Replication and synchronization details are generally specific to the software you are using, but opening up a software-defined network connection between two servers is one way to allow them to communicate. Another is to use a shared persistent store, such as a database or “file bucket”, allowing each key server instance to pull updates periodically.

Secret Management

We have seen a new take on securing keys and other sensitive data elements in the cloud. We see a small number of organizations distribute secrets across multiple cloud user accounts in the cloud. This model is not limited to key management – encryption keys may be assigned to individual accounts, but access tokens, certificates, passwords, and other access credentials and configuration data are more common.

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

In IaaS clouds 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 just use key management? Because it does not address most types of secrets, is not flexile, typically offers more limited API integration capabilities, and is harder to set up than a simple encrypted vault. Simplicity and suitability are the reasons “secret management” is gaining traction despite current tools requiring considerable Do It Yourself (DIY) coding and integration. This trend is still an unusual outlier today, but growing quickly as a simple way to solve very real security problems for cloud software development and deployment.

Our next post will cover key issues to consider when selecting a deployment model, along with products to support it.