ZDNet has recently published an interesting article related to Public Cloud and GDPR related data jurisdiction – US Cloud act.
Article is about digital sovereignty as more than half of European business with over 1,000 employees are using a public cloud platform, mostly AWS & Azure that dominate the Cloud market, IBM that dominates hybrid-cloud and VM Ware which is a major player in a private Cloud.
Reason to worry about is US Cloud act that enables US law enforcement to unilaterally demand access to EU citizen’s cloud data, even if data is stored outside the United States (e.g. in EU region).
On the other side, EU citizens should be protected with GDPR data.
Obviously we have two laws which overlap each other, and that results with conflict over private & sensitive data jurisdiction stored in the Cloud.
While more about private data jurisdiction you can find on the following link:
, the article triggered another question which is the main topic of this article:
Who else could read your private & sensitive data stored in Cloud?
Mentioned article namely implies two facts:
- besides owner of private & sensitive data (company or person) and SaaS (Software as a Service) vendor, Public Cloud vendor (no matter of IaaS or PaaS architecture model) might also be able to read your private data within Compute Engine (alias Virtual Machine) without your knowledge
- In theory US Cloud act enables US law enforcement to unilaterally demand access to EU citizen’s cloud data (similar request Cloud vendor can receive from other government as well)
To translate this into more technical terms: no matter which region/zone you choose when creating your Cloud environment (like some generic EU 1 or 2 or 5), your data might still be accessed without your knowledge from third party without your knowledge.
While for those who have already implemented SaaS architecture style it’s obvious how SaaS vendors can read all of your sensitive data as you have no control under the application code, infrastructure and data, question is how Public Cloud vendors could read your sensitive data?
Technically speaking, Public Cloud vendors are the owner of infrastructure (alias DC – data centers) which means they can perform many actions like:
- to redirect and/or decrypt your network
- shut down your Compute Engines (alias VM’s – virtual machines)
- clone your Compute Engines
- might read the data inside your Compute Engines (which depends on encryption implementation details)
- find out who and from where is connecting etc.
Point about possibility to penetrate inside your Cloud Compute Engine is in fact interesting, as Cloud companies might receive a legitimate request to inspect your sensitive data.
We have two types of Cloud management platform software: Open-source and propriety.
From Open-source space we have OpenShift and OpenNebula (used by Oracle Cloud).
IBM has propriety Cloud Management based on Tivoli/WebSphere, but it also uses Open-source Cloud Foundry for PaaS, and with acquisition of Red Hat, OpenShift for IaaS.
Amazon AWS, Microsoft Azure and Google Cloud Platform are propriety/closed source.
To be able to read your data, some generic Cloud company should be able to read your generated keys.
By default Cloud providers can offer network and file system encryption, but those two are very easy to override in case attack is comited by insider.
Besides that, there are many layers of protection (e.g.KMS service, Hardware Secure Modules…), but fact that all those services are controlled by the Cloud provider (in majority of cases within propriety Cloud management platform), imply theoretically you might develop code that can allow you to store generated keys to be able to support government requests supported by law.
Since Cloud brings faster development and availability of new technologies (IoT, AI, Machine Learning…) for which you might not have appropriate knowledge within your company, you definitely want to use all goodies offered by Cloud, but on the other side you still want to maintain a full control.
If that is your case, you have only one path you should follow:
Hybrid-cloud approach + client side (inside the company’s data center) encryption/anonymization of private & sensitive data before sending in a Cloud for processing and/or storing.
The only exception of that rule is Private Cloud Appliance (Cloud installed within your Data Center), which is accepted as a standard for large enterprises where security matters.
As this is a very hot topic, I’ll leave it for a future post.
Even if you follow all mentioned advices, you still might be affected by a data breach from external vendor/contractor side, especially if you overlook to check network connections between on-premise and Cloud part of application and to additionally inspect code that will be deployed (remember that the most dangerous thing in IT world is a fake feeling that your IT asset is secured).
Hybrid cloud + client side encryption is the only way (besides on-premise and Private Cloud Appliance) to be pretty much sure that Cloud & SaaS provider won’t have access to your sensitive data (You know famous quotes – the only secure server is one that has no network connection, which is turned off and stored under the 10 meters thick layer of concrete surrounded by security guards).
It can be said that elasticity and scalability while retaining enterprise flexibility and full control are the main reasons why a Private Cloud Appliance & Hybrid cloud approach are used the most from all others architecture styles for a large enterprises.
Private Cloud Appliance & Hybrid cloud approach is a statement of direction of many mayor players such as IBM/RedHat, Oracle, VM Ware, Amazon and many others who really understands large enterprises.
I wrote already about it under the Best Cloud architecture for a large enterprises on the following link:
Are privacy & security fears mentioned earlier justified?
In Verizon’s 2017 report you can find that 24% of all breaches are committed by insiders which includes contractors and SaaS vendors.
In 2019 report, percentage of incidents that fall under the insider and privilege misuse increased to 30%.
Current reports you can find on the following links:
In IBM 2019 report you can find that average time to identify and contain a breach is 279 days, 4.9% increase over the 2018.
Here are the links:
By now you should understand that Cloud in general is based on balance between trust and risk from one side and progress on the other side.
In case you are in finance/banking, telco or similar business with high security demands and frightening fines in case of data breach (up to 4% of annual global revenue or €20 million whichever is greater), the only way to secure your sensitive data in the Cloud is by performing anonymization/encryption in your data center before data leave your data center, or to stay with on-premise solution that can also be deployed in a Private Cloud (Appliance).
By performing client-side encryption (along with code and integration layer inspection), you can be pretty sure that hackers, SaaS vendor, Cloud vendor or even governments won’t be able to read your sensitive data stored in a Cloud without your knowledge, and you’ll maintain almost the same level of security as on-premise.
In most cases that implies hybrid-cloud or classical on-premises architecture deployed in Private Cloud Appliance or on private company’s servers without Cloud.
Such approach automatically reject all SaaS based solutions as client side encryption would crippled functionality of SaaS application (e.g. not possible to search encrypted data, not possible to decrypt data shown in GUI…).
SaaS architecture by default cannot fulfil any of top priority security requests imposed by large enterprises and regulators especially in finance/healthcare and similar industries, and is more suitable for smaller companies, especially where you don’t need to store sensitive (PII) data in a Cloud.
Therefore it’s not surprise that of the 350 companies surveyed, 74% had moved an application into the public Cloud, and then for a variety of reasons and circumstances, decided to move it back into their on-premises or private cloud infrastructure.
More on the following link: