GCP – The Cloud trust paradox: To trust cloud computing more, you need the ability to trust it less

At their core, many cloud security and, in fact, cloud computing discussions ultimately distill to trust. This concept of trust is much bigger than cyber security, and even bigger than a triad of security, privacy, and compliance.

For example, trust may involve geopolitical matters focused on data residency and data sovereignty. At the same time, trust may even be about the emotional matters, something far removed from the digital domain of bits and bytes, going all the way to the entire society.

In a decade since the rise of cloud computing, a lot of research has been generated on the topic of cloud trust. Today, the very concept of “using public cloud” is inseparably connected to “trusting your cloud provider.” 

One of the clear themes that emerged was that to be able to trust cloud computing, you need to be able to trust it less.

A paradox? Not really! 

Imagine you have two choices:

1. Trust a cloud provider that has a lot of well-designed data security controls.

2. Trust a cloud provider that has a lot of well-designed data security controls and an ability to let you the customer hold the encryption key for all your data (without any ability of the provider to see the key).

For sure, security, privacy and compliance controls contribute to trust in cloud computing in general and your cloud provider in particular. However, it is still easier to trust if you can trust less. 

Moreover, there is additional magic in this: I bet that simply knowing that your cloud provider is working in the direction of reducing the amount of trust you need to place in them will probably make you trust them more. This is true even if you don’t use all the trust-requirement-reducing features, such as Google Cloud External Key Manager that allows a customer to keep their key encryption keys on premises and to never have them come to Google Cloud, or Confidential VMs that encrypts the sensitive data during processing [a good read on this topic). Note that this logic applies even for cases where a public cloud environment is measurably more secure than an old on-premise environment—yet on-premises somehow feels more secure and hence more trusted.

This means that building technologies that allow organizations to benefit from cloud computing, while decreasing the amount of trust they need to place into the provider controls (both technical and operational) is of huge importance. 

However, such technologies are not only about the notional trust benefits—let’s speak about specific threat models. To list a few, the threats that are addressed by this particular example of trust-requirement-reducing technology—our EKM. These are (in our opinion):

1. Accidental loss of encryption keys by the provider (however this is unlikely) is mitigated by EKM; because the provider does not have the keys, it cannot lose them whether due to a bug, operational issue or any other reason.

2. Along the same line, a misconfiguration of native cloud security controls can, in theory, lead to key disclosure. Keeping the key off the cloud and in the hands of a cloud customer will reliably prevent this (at the cost of a risk of key being lost by a client).

3. A rogue provider employee scenario is also mitigated as said rogue employee cannot ever get access to the encryption key (this is also mitigated by a cloud HSM route)— admittedly, this is even more unlikely.

4. Finally, if some entity requests that a provider surrender the keys to a particular client’s data, this becomes impossible because said keys are not in provider’s possession (here, we will leave this as an exercise to the reader to decide how unlikely that may be).

Operationally, protections such as EKM make sense for a subset of sensitive data. For example, an organization may process sensitive data in the cloud, and only apply such trust reduction  (or, better: “trust externalization”) for some of the data that is truly the most sensitive.

As we established, such trust-requirement-reducing technologies are not only about security threats. Their contribution to compliance is also significant: they can help meet any requirement for a cloud customer to maintain the possession of encryption keys and also to any mandate to separate keys from data.

In fact, trust in the cloud is further enhanced by letting the customer have direct control over key access. Specifically, by retaining control of the keys, a cloud customer gains an ability to cut off cloud data processing by preventing key access. Again, this is important for both actual threats and security/trust signalling.

Furthermore, here is an interesting edge case: you may trust your cloud provider, but not the country where they are located or under whose laws they operate. This is where trust again moves outside of the digital domain into a broader world. Our trust-requirement-reducing approach works here as well; after all, if nobody outside of a customer has the keys, nobody can compel any 3rd party (including a cloud provider) to reveal the keys and, hence, the sensitive data.

Now, a trick question: won’t there be a challenge of needing to trust the provider to build the “trust reducing controls” correctly? Yes. However, we think there is a big difference between “just trust us” and “here is the specific technology we build to reduce trust; trust we built it correctly because of these reasons.” In other words, trust us because we let you trust us less.

Finally, some thoughts to keep this going:

• Be aware that trust is much broader than security, compliance, and privacy.

• Keep in mind that it is easier to trust a cloud provider that enables you to trust them less.

• Specific threat models still matter—trust improvement alone probably won’t make people adopt new technologies.

• Watch this fun Google Cloud NEXT OnAir presentation on this topic.

• Finally, add “trust reduction” to your security arsenal: you can secure system components, sure, but you can also architect the system in such a way that you need to trust the components less. Win!