Overview

This page explains how to use Cloud SQL to enforce data residency requirements.

Data residency refers to the physical location of data and the localregulations that govern how you store, encrypt, and access that data. As countries'data protections and privacy regulations evolve, it's increasingly important thatyou understand how to follow local data residency requirements and protect yourusers' data.

In a traditional on-premises environment, various components integrate and handledata residency. For example, a company can host a tokenization gateway as a CloudAccess Security Broker (CASB) to secure application data before it's transmittedoverseas.

Google Cloud and its services, including Cloud SQL, integrate to helpyou handle data residency by controlling the location of your data and access tothat data—by Google or by anyone.

Data residency in cloud computing

The following lists some data residency issues about which you should know:

• If a company's cloud administrators don't know the physical location of the data, then they don't know the local regulations. To be able to research the data residency policies for each location, administrators need to know where the data centers are.
• The company's cloud administrators and providers can use service-level agreements (SLAs) to establish allowed locations. However, what if you have to store your data in a region that differs from the terms of the SLA?
• Users must ensure that their data, and all of the services and resources that they use in their cloud projects, follow the data residency regulations of the host country.
  • What do you do if you want to decide where to store your data and encryption keys?
  • What happens if you want to determine the locations where users can access your data?

Google Cloud services, including Cloud SQL, address some of theseissues by letting you do the following:

• Set the storage location of your data. You can select the region when you create your Cloud SQL instance, or you can edit the region by editing an existing instance.
• Use the cross-region read replica feature for Cloud SQL to help you meet data residency standards for a designated region.
• Control the network locations where users can access data, as well as control cloud administrators' access to this data.

There are three areas where Cloud SQL can help you meet the challenges ofdata residency:

• Storing data: Configuring where your data is stored.
• Encrypting data: Controlling where your encryption keys are stored.
• Accessing data: Controlling access to your data.

Store data

Data residency involves storing personally identifiable information (PII) withina particular region, where that data is processed in accordance with theregulations of that region.

To store data, you must meet a country's legal and regulatory demands, such asdata locality laws. For example, a country might mandate that any government-relateddata be stored in that country. Or, a company might be contractually obligated tostore data for some of their customers in a different country. Therefore, acompany has to meet the data residency requirements of the country where the datais stored.

With Google Cloud, you can configure where your data is stored, includingon backups. This includes letting you choose theregions whereyou store your data. When you choose to configure resources in these regions forCloud SQL, Google stores your data at rest only in these regions, according toourService Specific Terms.You can select the region when youcreate your instance, or you can edit the region byediting an existing instance.

For more information about backup locations, seeCustom backup locations.

You can use organizational policy constraints to enforce data residencyrequirements at the organization, project, or folder level. These constraintslet you define the Google Cloud locations where users can createresources for supported services. For data residency, you can limit the physicallocation of a new resource with theresource locations constraint. You can alsofine-tune policies for a constraint to specify multi-regions such asasiaandeurope, or regions such asus-east1 oreurope-west1,as allowed or denied locations.

VPC Service Controlshelp you enforce data residency by letting you restrict the use of Cloud SQL APIsto import and export data using either the Cloud SQL Admin API or the Cloud StorageAPI. This restriction helps ensure that data stays within the network locationsyou've selected. Using VPC Service Controls, youcreate a service perimeter that defines the virtualboundaries from which a service can be accessed, preventing data from being movedoutside those boundaries. You can enforce this constraint even if the user isauthorized according to yourGoogle Cloud IAM policy.

Encrypt data

Google Cloud services, including Cloud SQL, encrypt customer contentat rest and in transit using various encryption methods. Encryption is automatic,and no customer action is required.

Cloud SQL also lets you add another layer of encryption to data usingcustomer-managed encryption keys (CMEK).CMEK are intended for organizations that have sensitive or regulated data thatrequires them to manage their own encryption keys. The CMEK feature lets youuse your owncryptographic keys for data at rest in Cloud SQL. After you add CMEK,whenever an API call is made, Cloud SQL uses your keys to access data.

If you want to store your CMEK in the regions where you deploy your services, thenyou can useCloud Key Management Service (Cloud KMS).You set the location of the key when you create the key. Or, to store those keysinside a physical hardware security module (HSM) that's located in the regionthat you choose, useCloud HSM.

Another way to choose where you want to store your CMEK is to use a third-partyproduct. To store and manage keys in a third-party key management product that'sdeployed outside of Google's infrastructure, you can useCloud External Key Manager (Cloud EKM).

Access data

With Cloud SQL, you can control which users can access your data.

To control Google's access of support and engineering personnel, useAccess Approval. Access Approval lets you require Googleemployees to get your explicit approval before they access your data orconfigurations on Google Cloud (for exclusions, seeAccess Approvalexclusions).

Access Approval complements the visibility provided byAccess Transparency, which generates near-real-timeaudit logs when Google administrators interact withyour data. The audit logs include the office location of the administrator andthe reason for the access. You can also enforce specific attributes foradministrators who have access to your data or configurations—including theirgeographic region and other compliance-relevant attributes.

Key Access Justifications integrate withCloud KMS and Cloud EKM. Each time one of your keys is requestedto encrypt or decrypt data, Key Access Justifications provides a detailed justification, alongwith a mechanism for you to approve or deny key access using an automated policythat you set.

Using Access Approval, Access Transparency, and Key Access Justifications with Cloud KMS and Cloud EKM,you can deny Google the ability to decrypt your data. As a result, you're thearbiter of access to your data.

What's next

• For more information about Google Cloud data location commitments, see the Google CloudService Specific Terms.
• To learn more about data residency in Google Cloud, seeUnderstanding your options for data residency, operationaltransparency, and privacy controls on Google Cloud.
• To learn more about how Google Cloud protects customer data throughout its lifecycle, and how Google Cloud provides customers with transparency and control over their data, seeTrusting your data with Google Cloud.
• Learn best practices fordata residency in the Google Cloud Well-Architected Framework.