…and left most of European organizations hosting data with a US owned Cloud Service Provider (CSP) with questions about how to proceed - with the EU-US Privacy shield shattered. The Privacy Shield agreement was an obstacle regarding using PII in cloud solutions that was removed, after the Safe Harbor treaty was invalidated in 2015.
But not only is everyone back to before the Privacy Shield, the Schrems II verdict also has the effect, that data controllers, processors and supervisory authorities must now take immediate steps to satisfy new obligations which exceed the capability of Standard Contractual Clauses (SCCs) to address compliance. This means, that the SCCs cannot be used to ensure that protection of the personal data is not at the same level as required within EU and making the data transfer lawful. Well, at least in their current context.
And even though Microsoft assures that it is ok to continue using all their service, as can be read here in their EU Policy Blog, this leaves quite a few questions:
Assuring Customers About Cross-Border Data Flows (microsoft.com)
While we cannot depend on SCCs, it does not rule processing of PII in the Cloud. The European Data Protection Board (EUDB) advices, among other mitigating factors, to use technical measures to protect data. And the technological solutions are there. We know that proper encryption and pseudonymization of data are solutions that can be used comply with EU regulation. We will focus on data encryption in this blog and further we will focus on IaaS and PaaS, where our choices within the area of encryption are greatest.
Let’s encrypt the data, and we are good to go?
Looking into the data, there are three stages of data where encryption applies:
Data In use.
Data in use is getting more and more traction in the security environment, being the state of data, that usually previously were missing from the equation. With the “assume breach” trail of thoughts, this makes sense to include in the equation, and with the customers focusing, the cloud vendors are doing the same. Take Microsoft, they have launched Azure Confidential Computing service to deal with the issues in some scenarios. But this is something we might look deeper into in a later blog post.
Data in Transit.
Data that contains any confidential information, must always be encrypted in transit. This area has been a focus area for a significant amount of time, and Cryptographic protocols are in place to solve this issue. This being SSL/TSL or tunneling services, or both. But this is neither the focus area since this is not something that is changed significantly with the Schrems II ruling.
Data at rest.
In IaaS, data is often stored buckets (S3, Blob, Google Storage), but also Databases, VMs and Containers must be considered. Stored Data like data in transit has plenty of solutions to help. But this not as straight forward as it might seem. Let us take Azure again. Microsoft have their Azure Key Vault (AKV) integrated into their entire cloud service, making it an easy choice.
If Microsoft has your data, your keys generated within AKV, and for their service to function, decryption and encryption permissions, what exactly is the prohibiting them from using these keys to hand over data to authorities after receiving a US court order? Their service can decrypt data and display them, so what is holding them back?
Well, from what we can read, Microsoft, along with Google, Amazon and others, are fighting these secrecy orders, coming on request from government institutions in US as can be read in this blog at Microsoft:
Continued progress and support in fighting secrecy orders - Microsoft On the Issues
It sounds like they are fighting our fight, but if you are not sure that this is enough, then what else could be done?
The next idea, if you do not trust that Microsoft cannot decrypt and hand over your data, when receiving court orders, might be to use their Bring Your Own Key (BYOK) offering. This requires AKV HSM (Hardware Security Module), that went into public preview 2020, where they use HSM that is FIPS 140 2 level 3 certified. BYOK is a service were managing of the key lifecycle of Data Encryption Key (DEK) in your own solution instead of managed within AKV and having the entire process in Microsoft managed services. In this setup, after a DEK has been created outside Azure environment, the second step is to create a Key Encryption Key (KEK) in AKV, and use the KEK to encrypt the DEK, just to send the DEK to AKV HSM for storage.
Now both keys are within the HSM module, that is hosted by Microsoft. How do Microsoft services, such as AIP, continue to function, while protecting your data?
And how is my data protected in PaaS services like Azure SQL, where vendor is in full control of the system software?
These are some of the questions why it is not so straight forward to just encrypt your data with any solution, without further thoughts, and you are good to go.
Next chapter in the blog, we will explore the answers, and find possible solutions to the issue with Key management at cloud vendors…