Schrems II: Confidential Computing as an additional safeguard?
I am not going to claim expert level knowledge regarding the Schrems II verdict, but I’ll give it a go in this post exploring the use of confidential computing as an additional measure to adequately protect personal data.
The EU-US Privacy Shield invalidation left most European organizations hosting data with a US owned Cloud Service Provider with a lot of questions of how to proceed with both their ongoing cloud effort and future cloud efforts. In Norway (where I live) we have even seen large initiatives in f.ex health tech being put on hold or redesigned as on-premises solutions due to the consequences of Schrems II.
The invalidation of the Privacy Shield agreement means that the data controllers, processors and supervisory authorities must take actions to satisfy obligations which exceed the capability of Standard Contractual Clauses (SCCs) to address compliance. The SCCs alone aren’t enough to ensure that the level of protection of personal data is at the same level as required within EU and doesn’t make the data transfer lawful - unless specific considerations of the data transfer and the efficiency of the measures taken are done.
The European Data Protection Board has come with guidance on measures that supplement transfer tools to ensure compliance to the EU level of protection of personal data. The recommendation include a roadmap, which includes the question whether supplementary measures can fill the gaps in protecting transfer of personal data. The three major technical steps that are recommended are:
- Encryption: Strong state of the art encryption provides adequate protection given that the encryption keys are managed correctly
- Pseudonymazation: Explisitly allowed by GDPR providing the additional data needed to reconstitute the personal data is adeqately protected
- Multi party computing: Protocols the split the data into parts that can be processed independently without any of the processors being able to assemble any personal data
Of these three steps - the focus of cloud vendors has been encryption and solutions to enable the customers to utilize encryption in an adequately fashion.
Data at rest, in transit and in use
The foundational fear in using public cloud services in context of Schrems II is the fear of personal data being transferred to countries outside EU where both the cloud provider itself and also of course the authorities or government agencies could make use of this data in some way. Historically - we’ve only had encryption for data at rest and data in transit. The “new” focus area which has gained momentum since the Schrems II ruling is to also have your data encrypted when it is being processed, both in memory and on CPUs.
Data at rest: Data is often stored in buckets (Azure Blob Storage, S3, Google Storage) and also VMs, containers and databases. This data could be encrypted so that no one can read the data when stored on these mediums. Note that to be able to implement this in a good way implies good key management - that is, do not rely on the cloud provider managing your keys. This way the cloud provider may be able to decrypt your data. So take care to utilize customer managed key-options.
Data in transit: When data is in transit it must be encrypted. This is solved through TLS or tunneling services - or maybe both.
Data in use: If you have implemented good measures for data at rest and in transit you are still vulnerable when your data is processed. After Schrems II the use of what has become known as Confidential Computing has really taken off. The gist of it is that computation is performed in a hardware-based Trusted Execution Environment (TEE).
Confidential Computing
Confidential Computing involves, as mentioned above, protecting data in use within a “trusted execution environment” (TEE). This safeguards the data from outside viewing or interference.
From Microsofts documentation: TEEs prevent unauthorized access or modification of applications and data while they are in use, thereby increasing the security level of organizations that manage sensitive and regulated data. The TEEs are a trusted environment that provides a level of assurance of data integrity, data confidentiality, and code integrity. The confidential computing threat model aims at removing or reducing the ability for a cloud provider operator and other actors in the tenant’s domain to access code and data while being executed.
So then - use Azure Confidential Computing and you are home free?
Unfortunately it’s not that easy. What is offered in Azure at this point is:
- Confidential VMs to protect your applications data and code in use
- Confidential Computing nodes or enclave aware containers on Azure Kubernetes Service
- Always Encrypted with secure enclaves in Azure SQL
You also have supporting services like Microsoft Azure Attestation and Azure Key Vault Managed HSM. Also some services are in preview, like:
- Trusted Launch which gives secure boot, virtual trust platform module and boot integrity monitoring which protects against kits, rootkits and kernel-level malware
- Azure Confidential Ledger - a tampe-proof register for storing sensitive data for record keeping and auditing or for data transparency in multi-party scenarios.
- Confidential Inference ONNX Runtime - a ML inference server that restricts the ML hosting party from accessing both the inferencing request and its response
You have to take care how you design your solutions if from a risk perspective transferring data outside EU is something your organization is concerned about. Getting your data encrypted at rest and in transit is perhaps a feasible task for most organizations when using a public cloud service. Having the data also protected in use severely limits your options when designing your landing zones. But then again - taking a risk-based approach you might be comfortable with data in use being unencrypted and viewable. This is what makes this matter not only black or white - but in any case you must have all these perspectives in mind when implementing solutions on any public cloud platform.