In a series of three technical articles, Google Cloud has recently discussed how to trust cloud providers, covering the concepts of customer trust, security key management and scenarios where keeping encryption keys off the cloud may be necessary.
The first article tries to define what trust is and how the definition is much broader than cyber security, and bigger than security, privacy, and compliance. Starting with the paradox "to trust cloud computing more, you need the ability to trust it less", Anton Chuvakin, head of solutions strategy at Google Cloud, explains:
To be able to trust cloud computing, you need to be able to trust it less. A paradox? Not really! (...) 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.
Highlighting as well the risk of a "security theater", the measures and controls that make one feel secure without delivering any measurable risk reduction, he adds:
This logic applies even for cases where a public cloud environment is measurably more secure than an old on-premise environmentyet on-premises somehow feels more secure and hence more trusted.
In the second article the focus is on common data security mistakes involving encryption, like encrypting the data and failing to secure the encryption keys or leaving the keys close to data, making data breaches more likely. The authors suggest not to focus only on compliance but to think first how to implement the security model:
Sometimes, an investigation revealed that encryption was implemented for compliance and without clear threat model thinkingkey management was an afterthought or not even considered. One could argue that the key must be better protected than the data it encrypts (or, more generally, that the key has to have stronger controls on it than the data it protects). If the key is stored close to the data, the implication is that the controls that secure the key are not, in fact, better.
Among the recommendations, Google Cloud suggests making an inventory of the keys and note how far or close they are to the data as well as handling software and hardware encryption keys using a managed KMS like Google Cloud KMS.
The third and final article covers instead encryption keys off the cloud. According to Anton Chuvakin and Il-Sung Lee, senior product manager at Google Cloud, there are three scenarios where keeping the keys off the cloud may be necessary or outweighs the benefits of cloud-based key management: regional regulations and concerns, centralized encryption key control in hybrid deployments and keys used during migration processes, when the encryption keys are the last data to go to the cloud. Requirements might also change during ongoing projects, as the authors warn:
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.
If the examples in the articles are focused on Google Cloud products, with scenarios discussing Google Cloud External Key Manager and Confidential VMs, the ideas behind the series are vendor agnostic and can be applied to AWS or Azure. As Sergio Werner, head of cloud services center of excellence at Capgemini, tweets:
Even though the article brings forward the Google answer, the paradox is well put and general. All the questions on compliance and lock-in comes down to where one puts the cursor on trust.
Mark Ryland, director office of the CISO at AWS, and Quint Van Deman, global business development manager at AWS, recently wrote an article about zero trust architectures on AWS. Other whitepapers and reports on cloud trust can be found among the Cloud Security Alliance research publications.
View post:
The Cloud Trust Paradox According to Google Cloud - InfoQ.com
