Principles are not enough to trust the cloud – enterprises need data privacy by design

In the noble cause of protecting the rights of their enterprise customers’ data against the interference of external actors, some of the big Cloud Service Providers (CSPs), such as Amazon, Google, and Microsoft decided to join forces to establish the “Trusted Cloud Principles”.

While we should celebrate this major step forward for digital privacy, this is not really solving the fundamental issue related to data privacy and confidentiality. The “Trusted Cloud Principles” seems to be an inevitable consequence of something that CSPs have not been able to successfully provide “by default” to customers: privacy control mechanisms by design.

It is high time for CSPs, together with their ecosystem partners, to create viable technical solutions for their customers to truly create a trusted cloud environment, and not just principles and aspirations.

Enterprises must control their keys and become the sole gatekeepers of their data kingdom

The first principle states that “Governments should seek data directly from enterprise customers rather than cloud service providers”. Well, the only way to force governments to do that is to actually remove the ability for CSPs to access their sensitive or regulated information. No need for them to act as the middleman and this principle will just become obsolete, as removing that capability will de facto release CSPs from such burden.

But a fundamental problem exists: the cloud has been built on an architectural model where CSPs have in many cases full capability to access customers’ data with no or little oversight by enterprise customers. It is part of the fabric of the cloud, and changing this model has significant organizational, financial, and technical implications.

Where encryption keys reside and who has access to them is actually the cornerstone for building a real trusted cloud environment. And most CSPs control the encryption master keys to enterprise customers’ data kingdom by default, giving them almost unlimited power to consume data.

“Hold Your Own Key” trust model enables more privacy controls, but the operationalization remains quite challenging

One of the highest level of control and protection over cryptographic keys comes from the “Hold Your Own Key” encryption model (HYOK), allowing organizations to retain the physical ownership and logical control of encryption keys. In that encryption model, sensitive information is encrypted before entering the cloud and keys are not transferred to the CSPs.?

Moving to such a trust model appears to be a good way to retain exclusive control, but it requires organizations to deploy an additional infrastructure layer on top of CSPs' existing stacks that act as a proxy between them and the CSPs’ storage systems.

Enabling a truly multi-cloud and customer-owned key management environment is challenging as organizations need to consolidate multiple management systems from different hardware security module (HSM) vendors, different cloud key management systems (KMS) and cloud HSMs, as well as keys used in home-grown solutions. As a result, effectively orchestrating such operations can quickly become a very daunting task. A few vendors are aiming to tackle such problem by providing virtualized cryptography solutions to facilitate the management and orchestration of encryption keys.

It is also important to note that many cloud products and services are actually incompatible with such model, with no or very limited use cases. Insulating the service provider from the content can prove to be technically challenging especially for SaaS applications, with many web applications not fully supported.

Compromising on performance, support and innovation should not be the price to pay for getting back control of data

Organizations have the perception that holding and managing encryption keys could break functionalities, and CSPs do not do too much to provide assurance that this will not happen.

Performance and human errors remain a major concern for potential adopters. The fact that CSPs will have to communicate with a segregated infrastructure, via an external service over the Internet, can lead to problems with reliability, availability, and latency.

There is also an “indirect” threat that enabling such model will potentially impact the ability of organizations to leverage the power of CSPs for compute and analytics. CSPs flagship products and services, such as monitoring and analytics services, require continuous data access and therefore cannot be effectively used if access is restricted.

From a support perspective, CSPs will need a support contract with the external key management partners as they can only provide support for issues in their own services, forcing enterprises to work with support on both sides to troubleshoot interoperability issues.

More control should not come with more complexity and costs for enterprises

The total cost of ownership coupled with an inherent operational complexity and technical limitations are still acting as inhibitors for organization to embark in such initiatives. The barriers to entry for enabling a true trusted cloud appears to be too high at the moment.

Moving to a highly customer-controlled environment to protect data increases the complexity of IT architecture and operations. Way more responsibilities will be pushed back from CSPs to enterprises and partners, and this will come with increased costs. Operational costs will increase as more experts and support personnel will be required to deploy and maintain such environment.

The compelling business case of migrating workload to the cloud to save cost and simplify operations is now becoming a horror movie with cost increase and complexity back into the agenda. A difficult pill to swallow for senior executives.

“Confidential Computing” is the long-awaited solution, but aspirations must be converted into robust and scalable solutions

The Confidential Computing Consortium (CCC) advocates the adoption of data-in-use encryption as a new standard for cloud security. The aspirational goal is to make “confidential compute” a native component of all cloud services.

Confidential computing basically prevents data access from cloud service providers by keeping data protected throughout its lifecycle and under the control of enterprise customers only.

Azure Confidential Computing by Microsoft, Confidential VMs by Google and AWS Nitro System by Amazon are just a few of the Confidential Computing initiatives aiming to help customers protect their code and data from the operators of the underlying cloud infrastructure, in other words, themselves.

But the challenge is to ensure alignment between all CSPs in order to provide compatible and easy to deploy technical solutions to customers. And this is not an easy task if they don’t actively and openly work together. Also, the concept of homomorphic encryption has been around for many decades with few real “operationalization” progress. The fact that we are still talking about it today is an indication of the technical challenges involved in adopting Confidential Computing as the new gold standard.

Bottom-line: Data-centric security must be enabled by design – CSPs and their ecosystem partners should double down their effort to make it happen.

The time is running out. Enterprises cannot afford anymore to maintain the status quo and must put the necessary pressure on CSPs and their ecosystem partners to create a trusted cloud environment. Enterprises need robust and scalable native privacy controls to become the sole gatekeepers of their data kingdom. Playing the fear card that such model could offset the benefits of workload migration to the cloud and potentially hinder innovation and efficiency is not an acceptable response anymore from CSPs.

Opinions expressed are solely my own and do not necessarily express the views or opinions of my employer.