Analysis of the Portuguese ruling to suspend data transfers to the USA and possible implications for SaaS
Analysis of the INE/Cloudflare case where the Portuguese DPA order suspension of data transfers to the USA according the Schrems II ruling and reasoning about general implications for SaaS solutions.
In this post I analyse the recent INE/Cloudflare case according to Schrems II ruling, where the Portuguese DPA ordered suspension of all transfers of Portuguese census data to the USA. I then abstract the architecture pattern inherent to INE/Cloudflare situation and reason about possible implications for non-EEA SaaS in the future. I finalise the post by giving some examples of possible technical measures that can be implemented to provide the adequate level of protection when using SaaS services (whether non-EEA or EEA).
The INE/Cloudflare use case
Recently, the Portuguese Data Protection Authority (DPA) has ruled out that Statistics Portugal (INE in Portuguese) had to suspend all data transfers of the Portuguese census data to Cloudflare. The system used by INE relied on Cloudflare for Content Delivery Network (CDN), Web Application Firewall (WAF)and rate limit services. Portuguese census data contains religious preferences and health data of all Portuguese citizens.
Before we move forward, let’s first understand the high-level architectural design of such services and how they work.
Communication when using CDN services
Content Delivery Network (CDN) services refers to a group of servers, located in different geographic regions, that work together to provide a fast delivery of Internet content. CDN servers cache the web content like HTML pages, javascript files, etc. with the goal of improving websites performance. CDN services include protection against DDoS attacks, load-balancing and perform SSL offloading.
SSL-offloading
When a client needs to connect to a website hosted in some origin server, (1) the client browser establishes a secure connection (using TLS in the majority of the cases) to the CDN server, (2) the CDN server performs the SSL-offload and (3) in case the content is not cached in the server, the CDN establishes again another secure connection (again TLS) with the origin server to retrieve the content.
The client browser and the CDN connection rely on a certificate and private key controlled by the CDN provider — i.e., the CDN server certificate and key — while the connection between the CDN server and the origin server relies on a certificate and private key controlled by the origin server — i.e., the origin server certificate and key.
In case the client needs to send information to the origin server (e.g.: data resulting from filling in a website form), this data is also routed through the CDN server. For instance, (as in the picture above) if the client needs to fill in his/her name and home address, this data will be sent to the CDN server and only then to the origin server. The CDN server will be able to see the data in cleartext.
CDN servers are geolocated in different regions of the globe to reduce latency. Normally, the client browser connects to the nearest CDN node, but this is not guaranteed. So client data might live in an unencrypted form in the CDN server for a long while. Also the CDN provider is able to forward the data to any other server which is under its control.
Portuguese DPA considerations
After understanding how CDN services work, it becomes more clear why the Portuguese DPA requested INE to suspend all the census data transfers. In its deliberation document (english here) the DPA states the following main reasons:
- The census data can be routed through any of the CDN servers located in any of the 200 Cloudflare data centers. These data centers are located in more than 100 countries (including the USA), of which the majority does not provide the adequate level of protection according to GDPR requirements for data transfers (art. 45).
- The IP address of the INE census website was located in the USA and owned by Cloudflare.
- The TLS certificate and associated private key was in control of (and actually owned by) Cloudflare, therefore Cloudflare would be able to access all the communications (in cleartext) between Portuguese citizens and INE census website.
- At the time of the DPA deliberation (27 April, 2021) the INE had collected personal sensitive data of almost 6.5 million Portuguese citizens.
Also the DPA mentioned that, according to Schrems II ruling, the Data Processing Addendum which is based on the standard contractual clauses applicable to data transfers (2010/87/UE) is not sufficient (under the US legislation) to guarantee that Cloudflare will challenge or deny the request to access the data under FISA requests (i.e., requests to access the personal data exported by the INE).
Taking into account the points above, the Portuguese DPA considered then that the contractual and technical measures aforementioned did not offer the adequate level of protection of the census data.
Setting up a precedent (or maybe not)
This ruling may open a precedence in how similar cases are being handled. Moreover, if we consider this scenario in more general terms, this might mean that collection and subsequent export of personal data by Software as a Service (SaaS) applications might impose a problem when the SaaS vendor or solution are not based in the European Economical Area (EEA).
In order to understand the rational behind this statement, let’s try to abstract the pattern inherent to INE/Cloudflare architecture.
In the INE/Cloudflare case, the CDN service is the SaaS application and the INE census application is the destination application. In this architecture, the SaaS application is used to directly collect (personal) data from the end-user (data subject). Since SaaS applications are meant to provide some service that is not implemented by the destination application, SaaS can also be responsible for processing the data and subsequent storage. After that storage and processing by the SaaS application, the data may be sent to the destination application (or some other 3rd party application connected to the SaaS service). This typically means that the SaaS application can be responsible for all the data lifecycle processes: collection, processing, storage and transfer.
Since SaaS applications are managed and hosted by the SaaS vendor (blue rectangle in the picture), the vendor is then responsible (on-behalf of the data exporter), to provide adequate protection of the data. Note that the certificate keys (used to protect the data in transit) are managed and in control (owned) by the SaaS vendor. So the SaaS service has access to the data in the clear in order to processing it accordingly. If adequate measures for data protection are not in place, then data exports may not be possible.
Future considerations when using SaaS
As a follow up of the decision of the Portuguese DPA with regards to the INE/Cloudflare case, we may in the future consider the following points, when using a SaaS application to collect and process data of European citizens:
- Where is the SaaS application hosted (EEA or non-EEA). If the application is hosted in a non-EEA area, there is no guarantee that the data is protected according GDPR requirements, so you may need to apply additional safeguards for an adequate level of protection.
- Where is the SaaS vendor (service provider) original from (EEA or non-EEA). For instance, since the US Privacy Shield no longer provides adequate protection levels for exporting (personal) data from the EU to the US due to the Schrems II ruling, you may need to apply additional safeguards for an adequate level of protection when exporting data from EU to the USA.
- Where is the SaaS application accessible from. If the SaaS vendor is hosting the application within EU boarders, but is able to access it outside EU, then you need to apply additional safeguards for an adequate level of protection.
Applying additional safeguards
Certainly, there is no silver bullet when considering the application of additional safeguards. Also, in some cases, might not even be possible. But, as suggested by EDPB (EDPB guidelines for data transfers), application of additional safeguards or supplementary measures can be of the following nature (1) contractual, (2) organisational or (3) technical. If the combined supplementary measures allow you to reach the level of protection in accordance to Art. 46 of the GDPR, then may go ahead and continue using the (non-EEA) SaaS service.
Note that the preliminary EDBP guidelines specifically state that, in some cases, contractual and organisational measures are not enough to provide the adequate level of protection. Therefore, in those cases, the technical measures play a crucial role.
Technical supplementary measures for SaaS
Despite not always being possible to implement supplementary measures of technical nature, some technical solutions may exist for certain SaaS solutions. Examples of these measures are:
- Double Key Encryption (DKE) feature for Office365 — this is a feature that enables the customer to encrypt Office files (with an encryption key under his/her control) before send it to the SaaS vendor (Microsoft) environment. This feature is still somewhat immature yet because it breaks some functionality, however, the SaaS vendor is not able to access the content of the files (more information here). Some key management service vendors (a.k.a. HSM vendors) developed plugins that directly integrate with DKE (e.g.: Thales Luna DKE, nShield HSM DKE, etc.) .
- Tokenisation/Encryption Gateway services for SaaS — an example of such service is provided by Eperi Gateway service. This service allows encrypting and tokenising the data before sending it to the SaaS service. Eperi Gateway, in particular, integrates with a lot popular SaaS services and does not require re-designing or changing the SaaS application, which represents a huge competitive advantage when compared to similar services.
- General Format-Preserving Encryption services — as the name implies, the goal of Format-Preserving Encryption (FPE) services is to encrypt the data while preserving their original formatting, thus allowing the encrypted data to be stored and used in the same way as plaintext data. Encryption/Tokenisations Gateway services are just an example of FPE services. Some commercial products (like the ones from IBM) enable FPE by default (e.g.: IBM PCIe cards incorporate this functionality) and can be leveraged to encrypt the data before sending it to the SaaS application.
- Multi-party computation based services — these services are based on secure multi-party computation (SMPC) techniques which allow different parties to jointly process their inputs while keeping those inputs secret. Some solutions in the market, like Partisia, allow for instance, performing statistical data processing in a jointly manner without compromising data privacy. Integration of SMPC based solutions with SaaS applications, however, may require re-designing the SaaS service.
These solutions are just examples of the so call Privacy Enhancing Technologies (PETs).
Note that implementation of PETs might not always be cost-effective and before moving forward with one of them, one must always assess the pros/cons of such implementation. Moreover, for the INE/Cloudflare use case, none of the measures described above would (probably) be suitable, as they would most likely break the CDN functionality. Perhaps in the feature with new technological and scientific advances we can apply one of these measures (or new ones).
Conclusion
The decision of the Portuguese DPA to suspend the data transfers of the INE to Cloudflare, may open a precedence in how similar cases are being handled, more specifically, it may open a precedent on how (non-EEA) SaaS applications may process or store personal data.
Adoption of technical measures to protect personal data are urgent, as well as, and the development of new Privacy Enhancing Technologies (PETs) that natively integrate with SaaS solutions. At the same time, new SaaS services (or even the existing ones) may need to take into account in its design (or re-design) how one can protect personal data of data subjects and still provide the same functionality. PETs are more urgent than ever to keep the industry up and running and still be GDPR compliant.
Acknowledgements
I would like to specially thank Christiane Peters for the fruitful discussions over the past couple months, specially on commercial PETs. Her in depth knowledge and perspective did strengthen the content of this post.
Disclamer
It goes without saying, but please note that this post reflects my own analysis and perspective. I’m not a person with legal background and my analysis is mainly focused on the technical aspects of the use cases.
