이 페이지에서는 PostgreSQL용 AlloyDB를 구성하여 데이터 상주 요구사항을 적용하는 방법을 설명합니다.
데이터 상주 개요
데이터 상주란 데이터의 물리적 위치와 해당 데이터를 저장, 암호화, 액세스하는 방법을 관리하는 현지 규정을 의미합니다. 국가의 데이터 보호 및 개인 정보 보호 규정이 발전함에 따라 현지 데이터 상주 요구 사항을 준수하고 사용자 데이터를 보호하는 방법을 이해하는 것이 더욱 중요해졌습니다.
기존 온프레미스 환경에서는 데이터 상주를 처리하도록 다양한 구성요소를 구성합니다. 예를 들어 회사에서 토큰화 게이트웨이를 클라우드 액세스 보안 브로커 (CASB)로 호스팅하여 해외로 전송하기 전에 애플리케이션 데이터를 보호할 수 있습니다.
클라우드 컴퓨팅 서비스는 데이터를 오프프레미스에 저장하므로 클라우드 컴퓨팅에는 자체 데이터 상주 문제와 질문이 있습니다. 여기에는 다음과 같은 내용이 포함되어 있습니다.
회사의 클라우드 관리자가 데이터의 물리적 위치를 모르면 로컬 규제도 모릅니다. 각 위치의 데이터 상주 정책을 조사하려면 관리자가 데이터 센터의 위치를 알아야 합니다.
회사의 클라우드 관리자 및 제공업체는 허용되는 위치를 설정하는 서비스 수준 계약 (SLA)을 사용하여 클라우드 서비스에서 데이터 저장에 사용할 수 있는 지역 범위에 대한 제한을 적용할 수 있습니다.
사용자의 데이터, 클라우드 프로젝트에서 사용하는 모든 서비스 및 리소스가 호스트 국가의 데이터 상주 규정을 준수하는지 확인해야 합니다.
AlloyDB의 데이터 상주
데이터 상주에서는 개인 식별 정보 (PII) 또는 기타 민감한 정보가 특정 리전의 법률 및 규정을 준수하는 방식으로 특정 리전 내에 저장됩니다.
데이터를 저장하려면 현지의 데이터 법률과 같은 국가의 법률 및 규제 요구를 충족해야 합니다. 예를 들어 정부 관련 데이터는 해당 국가에 저장해야 하거나 회사에서 계약에 의해 일부 고객의 데이터를 다른 국가에 저장해야 하는 경우도 있습니다. 따라서 회사는 데이터가 저장되는 국가의 데이터 상주 요구사항을 충족해야 합니다.
AlloyDB는 데이터 위치를 지정하고 AlloyDB에서 사용할 수 있는 위치를 제한하여 데이터 상주 요구사항을 충족하도록 지원합니다.
위치 선택
Google Cloud를 사용하면 데이터를 저장할 위치를 선택할 수 있습니다. 여기에는 데이터를 저장하는 리전 선택이 포함됩니다.
이러한 리전에서 AlloyDB 리소스를 구성하면 Google에서는 서비스별 약관에 따라 해당 리전에만 저장 데이터를 보관합니다. 클러스터를 만들 때 리전을 선택할 수 있습니다. 클러스터에 대해 생성된 모든 인스턴스와 백업은 클러스터와 동일한 리전에 저장됩니다.
리소스 위치 제약조건
조직 정책 제약조건을 사용하여 조직, 프로젝트 또는 폴더 수준에서 데이터 상주 요구사항을 적용할 수 있습니다. 이러한 제약조건을 사용하면 사용자가 지원되는 서비스의 리소스를 만들 수 있는 Google Cloud 위치를 정의할 수 있습니다. 데이터 상주를 위해 리소스 위치 제약조건을 사용하여 새 지원되는 AlloyDB 리소스의 물리적 위치를 제한할 수 있습니다.
제약조건의 정책을 미세 조정하여 us-east1 또는 europe-west1과 같은 리전을 허용 또는 거부 위치로 지정할 수도 있습니다. 기존 위치 위반은 Security Health Analytics를 사용하여 발견한 후 해결할 수 있습니다.
다음 단계
Google Cloud 데이터 위치 약정에 대한 자세한 내용은
Google Cloud 서비스별 약관을 참고하세요.
[[["이해하기 쉬움","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-05(UTC)"],[[["\u003cp\u003eData residency refers to the physical location of data and the local regulations governing its storage, encryption, and access.\u003c/p\u003e\n"],["\u003cp\u003eAlloyDB for PostgreSQL allows you to specify the location of your data, helping you meet data residency requirements by constraining which locations are available.\u003c/p\u003e\n"],["\u003cp\u003eYou can select specific regions for data storage when creating AlloyDB clusters, ensuring your data is stored at rest only within those designated areas.\u003c/p\u003e\n"],["\u003cp\u003eOrganizational policy constraints can be used to enforce data residency requirements at the organization, project, or folder level, limiting where users can create AlloyDB resources.\u003c/p\u003e\n"],["\u003cp\u003eThe Cloud Asset Inventory (CAI) service can help you view and monitor the locations of resources across different services, including AlloyDB, for compliance with data residency requirements.\u003c/p\u003e\n"]]],[],null,["# Enforce data residency requirements\n\nThis page explains how to configure AlloyDB for PostgreSQL to enforce data residency\nrequirements.\n\nOverview of data residency\n--------------------------\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\ncountries' data protections and privacy regulations evolve, it's increasingly\nimportant that you understand how to follow local data residency requirements\nand protect your users' data.\n\nIn a traditional on-premises environment, you configure various components to\nhandle data residency. For example, a company can host a tokenization gateway as\na cloud access security broker (CASB) to secure application data before it's\ntransmitted overseas.\n\nBecause a cloud computing service stores your data off-premises, cloud computing\nintroduces its own data residency issues and questions. These include the\nfollowing:\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 research the data residency policies for each location, administrators need to know where the data centers are.\n- A company's cloud administrators and providers might use service-level agreements (SLAs) that establish allowed locations, requiring restrictions on the range of regions that the cloud service can use for data storage.\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\nData residency for AlloyDB\n--------------------------\n\nData residency involves storing personally identifiable information (PII) or\nother sensitive information within a particular region, in a way that meets that\nregion's laws and regulations.\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\ngovernment-related data be stored in that country. Or, a company might be\ncontractually obligated to store data for some of their customers in a different\ncountry. Therefore, a company has to meet the data residency requirements of the\ncountry where the data is stored.\n\nYou can use the [Cloud Asset Inventory (CAI)](/asset-inventory) service to view\nand monitor the locations of resources across [services supported by\nit](/asset-inventory/docs/supported-asset-types), which includes\nAlloyDB.\n\nAlloyDB helps you with your data residency requirements by\nletting you specify the location of your data, and constrain which locations\nthat AlloyDB makes available.\n\n### Location selection\n\nWith Google Cloud, you choose where your data is stored. This includes letting\nyou choose the [regions](/alloydb/docs/locations) where you store your data.\nWhen you configure AlloyDB resources in these regions, Google\nstores your data at rest only in these regions, according to our [Service\nSpecific Terms](/terms/service-terms). You can select the region when you create\nyour cluster. Any instances and backups created against a cluster is stored in\nthe same region as the cluster.\n\n### Resource locations constraint\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 resources for\nsupported services. For data residency, you can use the [resource locations\nconstraint](/resource-manager/docs/organization-policy/defining-locations) to\nlimit the physical location of new [supported AlloyDB\nresources](/resource-manager/docs/organization-policy/defining-locations-supported-services#AlloyDB).\nYou can also fine-tune policies for a constraint to specify regions, such as\n`us-east1` or `europe-west1`, as allowed or denied locations. Existing location\nviolations can be [discovered using Security Health\nAnalytics](/resource-manager/docs/organization-policy/defining-locations#vulnerability_findings_and_remediation)\nand then remediated.\n\nWhat's next\n-----------\n\n- For more information about Google Cloud data location commitments, see the\n Google Cloud [Service Specific Terms](/terms/service-terms).\n\n- To learn more about data residency in Google Cloud, see [Understanding your\n options for data residency, operational transparency, and privacy controls\n on\n Google Cloud](/blog/products/identity-security/meet-data-residency-requirements-with-google-cloud).\n\n- To learn more about how Google Cloud protects customer data throughout its\n lifecycle, and how Google Cloud provides customers with transparency and\n control over their data, see [Trusting your data with\n Google Cloud](https://services.google.com/fh/files/misc/072022_google_cloud_trust_whitepaper.pdf).\n\n- Learn about best practices for [data residency](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#control_data_residency)\n and [data sovereignty](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#recommendations_to_manage_your_data_sovereignty)."]]