The cloud trust paradox: 3 scenarios where keeping encryption keys off the cloud may be necessary

As we discussed in “The Cloud trust paradox: To trust cloud computing more, you need the ability to trust it less” and hinted at in “Unlocking the mystery of stronger security key management,” there are situations where the encryption keys must be kept away from the cloud provider environment. While we argue that these are rare, they absolutely do exist. Moreover, when these situations materialize, the data in question or the problem being solved is typically hugely important.

Here are three patterns where keeping the keys off the cloud may in fact be truly necessary or outweighs the benefits of cloud-based key management.

Scenario 1: The last data to go to the cloud

As organizations migrate data processing workloads to the cloud, there usually is this pool of data “that just cannot go.” It may be data that is the most sensitive, strictly regulated or the one with the toughest internal security control requirements.

Examples of such highly sensitive data vary by industry and even by company. One global organization states that if they present the external key approach to any regulator in the world, they would be expecting an approval due to their robust key custody processes. Another organization was driven by their interpretation of PCI DSS and internal requirements to maintain control of their own master keys in FIPS 140-2 level 3 HSMs that they own and operate.

This means that risk, compliance or policy reasons make it difficult if not impossible to send this data set to the public cloud provider for storage or processing. This use case often applies to a large organization that is heavily regulated (financial, healthcare and manufacturing come to mind). It may be data about specific “priority” patients or data related to financial transactions of a specific kind. 

However, the organization may be willing to migrate this data set to the cloud as long as it is encrypted and they have sole possession of the encryption keys. Thus, a specific decision to migrate may be made involving a combination of risk, trust, as well as auditor input. Or, customer key possession may be justified by customer interpretation of specific compliance mandates.

Now, some of you may say “but we have data that really should never go to the cloud.” This may indeed be the case, but there is also general acceptance that digital transformation projects require the agility of the cloud, so an acceptable, if not entirely agreeable solution must be found.

Scenario 2: Regional regulations and concerns

As cloud computing evolves, regional requirements are playing a larger role in how organizations migrate to the cloud and operate workloads in public cloud. This scenario focuses on a situation where an organization outside of one country wants to use a cloud based in a different country, but is not comfortable with the provider having access to encryption keys for all stored data. Note that if the unencrypted data is processed in the same cloud, the provider will access the data at one point anyhow.  Some of these organizations may be equally uncomfortable with keys stored in any cryptographic device (such as an HSM) under logical or physical control of the cloud provider. They reasonably conclude that such an approach is not really Hold Your Own Key (HYOK). 

This may be due to issues with regulations they are subject to their government, or all of the above. Furthermore, regulators in Europe, Japan, India, Brazil and other countries are considering or strengthening mandates for keeping unencrypted data and/or encryption keys within their boundaries. Examples may include specific industry mandates (such as TISAX in Europe) that either state or imply that the cloud provider cannot have access to data under any circumstances, that may necessitate not having any way for them to access the encryption keys.  However, preliminary data indicates that some may accept the models where the encryption keys are in a sole possession of a customer and located in their country, and hence off the cloud provider premises (while the encrypted data may be outside). 

Another variation is the desire to have the keys for each country specific data set in the respective country under the control of that country's personnel or citizens. This may apply to banking data and will necessitate the encryption keys for each data set being stored in each country. An example may be a bank that insists that all their encryption keys are stored under one particular mountain in Switzerland. Yet another example covers the requirements (whether regulatory or internal) to have complete knowledge and control over administrators to the keys, and a local audit log of all key access activity.

As Thomas Kurian states here, “data sovereignty provides customers with a mechanism to prevent the provider from accessing their data, approving access only for specific provider behaviors that customers think are necessary. Examples of customer controls provided by Google Cloud include storing and managing encryption keys outside the cloud, giving customers the power to only grant access to these keys based on detailed access justifications, and protecting data-in-use. With these capabilities, the customer is the ultimate arbiter of access to their data.”

Therefore, this scenario allows organizations to utilize Google Cloud while keeping their encryption keys in the location of their choice, under their physical and administrative control.

Scenario 3: Centralized encryption key control

With this use case, there are no esoteric threats to discuss or obscure audit requirements to handle. The focus here is on operational efficiency. As Gartner recently noted, the need to reduce the number of key management tools is a strong motivation for keep all the keys within one system to cover multiple cloud and on-premise environments.

It may sound like a cliche, but complexity is very much the enemy of security. Multiple “centralized” systems for any task—be it log management or encryption key management—add complexity and introduce new points for security to break.

In light of this, a desire to use one system for a majority of encryption keys, cloud or not, is understandable. Given that few organizations are 100% cloud-based today for workloads that require encryption, the natural course of action is to keep all the keys on-prem. Additional benefits may stem from using the same vendor as an auxiliary access control and policy point. A single set of keys reduces complexity and a properly implemented system with adequate security and redundancy outweighs the need to have multiple systems.

Another variant of this is a motivation to retain an absolute control over data processing by means of controlling the encryption key access. After all, if a client can push the button and instantly cut off the cloud provider from key access, the data cannot possibly be accessed or stolen by anybody else.

Finally, centralizing key management gives the cloud user a central location to enforce policies around access to keys and hence access to data-at-rest.

Next steps

To summarize, these scenarios truly call for encryption keys being both physically away from the cloud provider,  away from their physical and administrative control. This means that a customer managed HSM at the CSP location won’t do. 

• Please review Unlocking the mystery of stronger security key management for a broader review of key management in the cloud.

• Assess your data risks in regards to attackers, regulations, geopolitical risks, etc.

• Understand the three scenarios discussed in this post and match your requirements to them. Apply threat model thinking to your cloud data processing and see if you truly need to remove the keys from the cloud.

Review services covered by Google EKM and partners to deliver encryption key management for keeping the keys away from the cloud, on premises (Ionic, Fortanix, Thales, etc).