您可以在機構、專案或資料夾層級，使用機構政策限制強制執行資料落地規定。您可以透過這些限制條件，定義使用者可為支援的服務建立資源的 Google Cloud 位置。如要限制資料落地位置，可以使用資源位置限制，限制新資源的實際位置。您也可以微調限制的政策，將多區域 (例如 asia 和 europe) 或區域 (例如 us-east1 或 europe-west1) 指定為允許或拒絕的位置。
VPC Service Controls 可讓您限制使用 Cloud SQL API，透過 Cloud SQL Admin API 或 Cloud Storage API 匯入及匯出資料，進而強制執行資料落地。這項限制可確保資料只會留存在您選擇的網路位置。使用 VPC Service Controls 建立服務範圍，定義服務可存取的虛擬邊界，防止資料移出這些邊界。即使使用者已根據 Google Cloud IAM 政策獲得授權，您仍可強制執行這項限制。
加密資料
Google Cloud 服務 (包括 Cloud SQL) 會使用各種加密方法，將靜態和傳輸中的客戶內容加密。加密程序完全自動，客戶無須採取任何行動，
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：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."]]
