您可以使用组织政策限制条件在组织、项目或文件夹级层强制执行数据驻留要求。通过这些限制条件，您可以定义允许用户为受支持的服务创建资源的 Google Cloud 位置。对于数据驻留，您可以使用资源位置限制条件来限制新资源的物理位置。您还可以微调限制条件的政策，将多区域（例如 asia 和 europe）或单区域（例如 us-east1 或 europe-west1）指定为允许或拒绝的位置。
借助 VPC Service Controls，您可以使用 Cloud SQL Admin API 或 Cloud Storage API 来限制使用 Cloud SQL API 导入和导出数据，从而帮助您强制执行数据驻留。此限制有助于确保数据保留在您选择的网络位置内。您可以使用 VPC Service Controls 创建服务边界，从而定义可以从中访问服务的虚拟边界，防止数据移动到这些边界之外。即使用户根据您的 Google Cloud IAM 政策获得授权，您也可以强制执行此限制条件。
加密数据
Google Cloud 服务（包括 Cloud SQL）使用多种加密方法对静态和传输中的客户内容进行加密。加密工作会自动执行，无需客户采取任何操作。
若要控制 Google 支持和工程团队的访问权限，您可以使用 Access Approval。通过 Access Approval，您可以要求 Google 员工先获得您的明确批准，然后才能访问您在 Google Cloud 上的数据或配置（如需了解排除项，请参阅 Access Approval 排除项）。
Access Approval 是对 Access Transparency 提供的公开范围的补充，后者可在 Google 管理员与您的数据交互时生成近乎实时的审核日志。审核日志包括管理员的办公地点和访问原因。此外，您还可以针对有权访问您的数据或配置的管理员强制执行特定的属性，包括他们的地理区域以及其他与合规性相关的属性。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# Data residency overview\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/data-residency-overview \"View this page for the MySQL database engine\") \\| [PostgreSQL](/sql/docs/postgres/data-residency-overview \"View this page for the PostgreSQL database engine\") \\| SQL Server\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nThis page explains how to use Cloud SQL to enforce data residency requirements.\n\n*Data residency* refers to the physical location of data and the local\nregulations that govern how you store, encrypt, and access that data. As countries'\ndata protections and privacy regulations evolve, it's increasingly important that\nyou understand how to follow local data residency requirements and protect your\nusers' data.\n\nIn a traditional on-premises environment, various components integrate and handle\ndata residency. For example, a company can host a tokenization gateway as a Cloud\nAccess Security Broker (CASB) to secure application data before it's transmitted\noverseas.\n\nGoogle Cloud and its services, including Cloud SQL, integrate to help\nyou handle data residency by controlling the location of your data and access to\nthat data---by Google or by anyone.\n\nData residency in cloud computing\n---------------------------------\n\nThe following lists some data residency issues about which you should know:\n\n- 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.\n- 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?\n- 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.\n - What do you do if you want to decide where to store your data and encryption keys?\n - What happens if you want to determine the locations where users can access your data?\n\nGoogle Cloud services, including Cloud SQL, address some of these\nissues by letting you do the following:\n\n- 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.\n- Use the cross-region read replica feature for Cloud SQL to help you meet data residency standards for a designated region.\n- Control the network locations where users can access data, as well as control cloud administrators' access to this data.\n\nThere are three areas where Cloud SQL can help you meet the challenges of\ndata residency:\n\n- [Storing data](#storing-data): Configuring where your data is stored.\n- [Encrypting data](#encrypting-data): Controlling where your encryption keys are stored.\n- [Accessing data](#accessing-data): Controlling access to your data.\n\nStore data\n----------\n\nData residency involves storing personally identifiable information (PII) within\na particular region, where that data is processed in accordance with the\nregulations of that region.\n\nTo store data, you must meet a country's legal and regulatory demands, such as\ndata locality laws. For example, a country might mandate that any government-related\ndata be stored in that country. Or, a company might be contractually obligated to\nstore data for some of their customers in a different country. Therefore, a\ncompany has to meet the data residency requirements of the country where the data\nis stored.\n\nWith Google Cloud, you can configure where your data is stored, including\non backups. This includes letting you choose the [regions](/sql/docs/sqlserver/locations#location-r) where\nyou store your data. When you choose to configure resources in these regions for\nCloud SQL, Google stores your data at rest only in these regions, according to\nour [Service Specific Terms](/terms/service-terms).\nYou can select the region when you [create your instance](/sql/docs/sqlserver/create-instance), or you can edit the region by [editing an existing instance](/sql/docs/sqlserver/edit-instance).\n\nFor more information about backup locations, see [Custom backup locations](/sql/docs/postgres/backup-recovery/backups#custom-backup-location).\n\nYou can use organizational policy constraints to enforce data residency\nrequirements at the organization, project, or folder level. These constraints\nlet you define the Google Cloud locations where users can create\nresources for supported services. For data residency, you can limit the physical\nlocation of a new resource with the [resource locations constraint](/resource-manager/docs/organization-policy/defining-locations). You can also\nfine-tune policies for a constraint to specify multi-regions such as `asia`\nand `europe`, or regions such as `us-east1` or `europe-west1`,\nas allowed or denied locations.\n\n[VPC Service Controls](/vpc-service-controls/docs/overview)\nhelp you enforce data residency by letting you restrict the use of Cloud SQL APIs\nto import and export data using either the Cloud SQL Admin API or the Cloud Storage\nAPI. This restriction helps ensure that data stays within the network locations\nyou've selected. Using VPC Service Controls, you [create a service perimeter](/sql/docs/sqlserver/admin-api/configure-service-controls) that defines the virtual\nboundaries from which a service can be accessed, preventing data from being moved\noutside those boundaries. You can enforce this constraint even if the user is\nauthorized according to your [Google Cloud IAM policy](/iam).\n\nEncrypt data\n------------\n\nGoogle Cloud services, including Cloud SQL, encrypt customer content\nat rest and in transit using various encryption methods. Encryption is automatic,\nand no customer action is required.\n\nCloud SQL also lets you add another layer of encryption to data using [customer-managed encryption keys (CMEK)](/sql/docs/sqlserver/cmek).\nCMEK are intended for organizations that have sensitive or regulated data that\nrequires them to manage their own encryption keys. The CMEK feature lets you [use your own\ncryptographic keys](/sql/docs/sqlserver/configure-cmek) for data at rest in Cloud SQL. After you add CMEK,\nwhenever an API call is made, Cloud SQL uses your keys to access data.\n\nIf you want to store your CMEK in the regions where you deploy your services, then\nyou can use [Cloud Key Management Service (Cloud KMS)](/security-key-management).\nYou set the location of the key when you create the key. Or, to store those keys\ninside a physical hardware security module (HSM) that's located in the region\nthat you choose, use [Cloud HSM](/kms/docs/hsm).\n\nAnother way to choose where you want to store your CMEK is to use a third-party\nproduct. To store and manage keys in a third-party key management product that's\ndeployed outside of Google's infrastructure, you can use [Cloud External Key Manager (Cloud EKM)](/kms/docs/ekm).\n\nAccess data\n-----------\n\nWith Cloud SQL, you can control which users can access your data.\n\nTo control Google's access of support and engineering personnel, use [Access Approval](https://cloud.google.com/access-approval/docs/approve-requests). Access Approval lets you require Google\nemployees to get your explicit approval before they access your data or\nconfigurations on Google Cloud (for exclusions, see [Access Approval\nexclusions](https://cloud.google.com/access-approval/docs/overview#exclusions)).\n\nAccess Approval complements the visibility provided by [Access Transparency](/access-transparency), which generates near-real-time [audit logs](/sql/docs/sqlserver/audit-logging) when Google administrators interact with\nyour data. The audit logs include the office location of the administrator and\nthe reason for the access. You can also enforce specific attributes for\nadministrators who have access to your data or configurations---including their\ngeographic region and other compliance-relevant attributes.\n\n[Key Access Justifications](https://cloud.google.com/blog/products/identity-security/control-access-to-gcp-data-with-key-access-justifications) integrate with\nCloud KMS and Cloud EKM. Each time one of your keys is requested\nto encrypt or decrypt data, Key Access Justifications provides a detailed justification, along\nwith a mechanism for you to approve or deny key access using an automated policy\nthat you set.\n\nUsing Access Approval, Access Transparency, and Key Access Justifications with Cloud KMS and Cloud EKM,\nyou can deny Google the ability to decrypt your data. As a result, you're the\narbiter of access to your data.\n\nWhat's next\n-----------\n\n- For more information about Google Cloud data location commitments, see the Google Cloud [Service\n Specific Terms](/terms/service-terms).\n- To learn more about data residency in Google Cloud, see [Understanding your options for data residency, operational\n transparency, and privacy controls on Google Cloud](https://cloud.google.com/blog/products/identity-security/meet-data-residency-requirements-with-google-cloud).\n- 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, see [Trusting your data with Google Cloud](https://services.google.com/fh/files/misc/072022_google_cloud_trust_whitepaper.pdf).\n- Learn best practices for [data residency](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#control_data_residency) in the Google Cloud Well-Architected Framework."]]
