This topic is an overview for how to enforce data residency requirements for data using Cloud SQL.
Data residency refers to the physical location of data and the local regulations that apply to the data.
In a traditional on-premises environment, data residency is integrated and handled by various components. For example, a company can host a tokenization gateway as a Cloud Access Security Broker (CASB) to secure application data before it's transmitted overseas. On Google Cloud, data residency is handled by various Google Cloud services, including Cloud SQL.
It's important for Google Cloud to support data residency because geography is becoming increasingly relevant to privacy. By ensuring respect for regional privacy differences, data residency helps improve regional privacy for your customers.
Data residency in cloud computing
The following lists some data residency issues about which you should know:
- If a company's users don't know the data's physical location, then they won't know the local regulations. To be able to research the data residency policies for each location, users need to know where the data centers are.
- The company's users and providers can use service-level agreements (SLAs) to establish allowed locations. However, what if your data must be stored 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 these issues by letting you do the following:
- Set your data's storage location. 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 ensure that 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.
The preceding features of Cloud SQL give you control over the location of your data and access to that data—by Google or by anyone.
There are three areas where Cloud SQL can help you meet the challenges of data 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.
Each area is covered in greater detail in the sections that follow.
Data residency involves storing personally identifiable information (PII) within a particular region, where that data is processed in accordance with the regulations of that region.
Part of storing data is meeting a country's legal and regulatory demands, such as data locality laws. For example, a country may mandate that any government-related data be stored in that country. Or, a company may be contractually obligated to store data for some of their customers in a different country. Therefore, it's imperative to meet the data residency requirements of the country where the data is stored.
With Google Cloud, you can configure where your data is stored, including on backups. This includes giving you the ability to choose the regions where you store your data. When you choose to configure resources in these regions for Cloud SQL, Google stores your data at rest only in these regions, as per our Service Specific Terms. You can select the region when you create your instance, or you can edit the region by editing an existing instance.
For more information about backup locations, see Custom backup locations.
You can use organizational policy constraints to enforce data residency requirements at
the organization, project, or folder level. These constraints let you define the allowed Google Cloud locations where users can create resources for supported services. For data residency, you can limit the physical location of a new resource with the resource locations constraint. You can also fine-tune policies for a constraint to specify multi-regions such as
europe, or regions such as
europe-west1 as allowed or denied locations.
Another feature that helps you enforce data residency is VPC Service Controls. VPC Service Controls let you restrict the use of Cloud SQL APIs to import and export data using either the Cloud SQL Admin API or the Cloud Storage API. This restriction ensures that data stays within the network locations you have selected. Using VPC Service Controls, you create a service perimeter that defines the virtual boundaries from which a service can be accessed, preventing data from being moved outside those boundaries. You can enforce this constraint even if the user is authorized according to your Google Cloud IAM policy.
Google Cloud services, including Cloud SQL, encrypt customer content at rest and in transit using a variety of encryption methods. Encryption is automatic, and no customer action is required.
Cloud SQL also lets you add another layer of encryption to data using customer-managed encryption keys (CMEK). CMEK are intended for organizations that have sensitive or regulated data that requires them to manage their own encryption key. The CMEK feature lets you use your own cryptographic 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 your CMEK stored in the regions where you deploy your services, then you can use Cloud Key Management Service (Cloud KMS). You set the key's location when you create the key. Or, to store those keys inside a physical hardware security module (HSM) that's located in the region that you choose, use Cloud HSM.
Another way to choose where you want to store your CMEK is to use a third-party product. To store and manage keys in a third-party key management product that's deployed outside of Google infrastructure, you can use Cloud External Key Manager (Cloud EKM).
With Cloud SQL, you can control which users can access your data.
To control Google support and engineering personnel's access, use Access Approval. Access Approval lets you require Google employees to get your explicit approval before they access your data or configurations on Google Cloud (for exclusions, see Access Approval exclusions).
Access Approval complements the visibility provided by Access Transparency, which generates near-real-time audit logs when Google administrators interact with your data. The audit logs include the office location of the administrator and the reason for the access. You can also enforce specific attributes for administrators who are allowed to access your data or configurations—including the geographic region from which they are operating and other compliance-relevant attributes.
Finally, Key Access Justifications work seamlessly with Cloud KMS and Cloud EKM. Each time one of your keys is requested to encrypt or decrypt data, Key Access Justifications provides a detailed justification, along with a mechanism for you to approve or deny key access using an automated policy that 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 are the arbiter of access to your data.
Putting it all together
Google Cloud and its services, including Cloud SQL, work together to give you control over the location of your data and access to that data—by Google or by anyone. With these considerations addressed, you can confidently build mission-critical workloads on Google Cloud.