Jump to Content
Security & Identity

New data sovereignty controls for EU customers

October 6, 2021
https://storage.googleapis.com/gweb-cloudblog-publish/images/Google_Cloud_security.max-2600x2600.jpg
Christopher Johnson

Group Product Manager

Joseph Valente

Product Manager

Try Google Cloud

Start building on Google Cloud with $300 in free credits and 20+ always free products.

Free trial

European organizations—in both the public and private sectors—want a cloud provider that can meet their requirements for security, privacy, and digital sovereignty, without compromising on functionality or innovation. As part of our ‘Cloud. On Europe’s Terms.’ initiative, we’ve been working diligently to provide solutions to meet customers’ needs in this area, with capabilities built into our public cloud platform and, more recently, with our announcements to provide sovereign cloud solutions powered by Google Cloud to be offered through trusted partners like T-Systems in Germany and Thales in France

Today, we’re excited to announce the preview of another option for our European customers with data sovereignty requirements: a set of sovereign controls, provided through Assured Workloads, which help automate the deployment and enforcement of capabilities on Google Cloud Platform for: 

  • European Union data residency

  • Cryptographic control over data access, including customer-controlled encryption keys; and

  • Google Cloud customer support delivered by EU personnel from an EU location (coming soon).

These controls are set on a per-workload basis, ensuring that they can be applied and enforced  selectively where sovereignty requirements exist. Let’s look at each capability in more detail:

European Union Data Residency

European Union Data Residency allows customers to specify one of five Google Cloud Regions in the EU (in Belgium, Germany, Poland, Finland, or the Netherlands) in which their data will be stored and ensure it remains there. To accomplish this, we implement a Google Cloud Platform (GCP) Organization Policy constraint that restricts customer data to being stored in one of the specified EU Regions. The policy is configured automatically upon creation of a workload, reducing the risk of misconfiguration that could result in data inadvertently being stored outside of EU regions. 

As described in our earlier blog posts on this topic, the ability to enforce data residency within the EU satisfies some European customers’ current sovereignty requirements. However, it does not address control over administrative access to data which is not customer-initiated, e.g., accidental access or access resulting from jurisdictionally-required government requests. To address these cases, customers need capabilities that make them the ultimate arbiter of access to their data through cryptographic control, and customer support operations must also be considered - both of which are also addressed by our solutions. 

Cryptographic Control Over Data Access

Cryptographic control over data access is achieved through the use of Key Access Justifications (KAJ) together with our Cloud External Key Manager (EKM). 

Key Access Justifications, now in GA, gives customers the ability to deny Google administrators access to their data for any reason, even in situations typically exempted from customer control, such as outages or responses to third-party data requests. It does this by providing customers a clear reason why data is being decrypted, which they can use to programmatically decide whether to permit decryption and thus allow access to their data. 

Using Key Access Justifications together with Cloud External Key Manager, customers receive:

  • Visibility into every request for an encryption key that permits data (e.g., a Cloud Storage bucket) to change state from at-rest to in-use, with a justification for that request. 

  • A mechanism to explicitly approve or deny decryption using the key in the context of that request, using an automated policy that they set (via third-party functionality), and

  • A commitment from Google Cloud to protect the integrity of our controls and the justifications.

https://storage.googleapis.com/gweb-cloudblog-publish/images/How_Key_Access_Justifications_works.max-1200x1200.jpg
How Key Access Justifications works

What this means is that there is no way for Google to decrypt customer data-at-rest without customer approval, which customers can withhold for any reason. For example, a customer may deem a justification does not fit with their policy, or requires further approval from their security, privacy or legal teams. 

Customers are the ultimate arbiters of access to their data because:

  • Data is always encrypted-at-rest

  • Encryption keys needed to decrypt the data are stored and managed outside of Google’s technical infrastructure if Cloud EKM is used

  • Decrypting customer data requires a call outside of Google for the customer’s externally-managed key via Cloud EKM

  • Customers can expect every request to come with a justification, and can block requests programmatically for any reason they deem necessary (using a capability within supported third party external key managers)

  • Reasons for key requests are detailed so that customers can understand what is happening to their data (for example CUSTOMER_INITIATED_SUPPORT when the customer submits a support ticket and access to their data is required to troubleshoot the issue)

Cloud External Key Manager is integrated with third-party key management products from Equinix, Fortanix, Ionic, Thales and Unbound. Currently Fortanix, Ionic and Thales support the use of Key Access Justifications.

Key Access Justifications is GA for BigQuery, Spanner, PubSub and Google Kubernetes Engine, Preview for Google Compute Engine/Persistent Disk, Google Cloud Storage, and Cloud SQL, covering the transition from data-at-rest to data-in-use in Google Cloud services which typically store customers most sensitive data assets.

European Support

Data sovereignty requirements may extend into customer support services: some customers require transparency and control when raising a support case or in the course of obtaining technical assistance. To meet this requirement, we are expanding our existing Assured Support offering to the EU. Customers will be enabled to obtain support from EU personnel from an EU location. These controls extend to site reliability engineers and support personnel. 

The Assured Support offering is coming soon and will be offered to customers as a part of Assured Workloads for EU. 

Additional options to meet expanded Digital Sovereignty requirements

We recognize that there will be customers for whom the availability of these controls may not be sufficient to meet all their digital sovereignty requirements. Customers may have additional operational sovereignty needs focused on the independent operation and verification of these controls. Trusted partners can play this role, layering on additional oversight to strengthen operational sovereignty assurances, and partners can continue to evolve and strengthen capabilities and assurances over time independent of the platform.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Available_options_for_sovereign_controls.max-1100x1100.jpg
Available options for sovereign controls over Google Cloud services

For many organizations, however, the ability to meet data sovereignty requirements for specific workloads will be a meaningful step forward in their digital sovereignty journey. If you have interest in Assured Workloads for EU on Google Cloud, please fill out this interest form.

We will continue to strengthen and develop capabilities for digital sovereignty, with the ongoing goal of giving customers a range of choices to meet their sovereignty needs as they pursue digital transformation.

Posted in