本文說明建議的 VPC Service Controls 部署架構。本文適用於網路管理員、安全架構師和雲端營運專業人員，他們在 Google Cloud 上執行及運作大規模的正式版部署作業，並希望降低敏感資料遺失的風險。
由於 VPC Service Controls 保護機制會影響雲端服務功能，建議您事先規劃啟用 VPC Service Controls，並在架構設計期間考量 VPC Service Controls。請務必盡可能簡化 VPC Service Controls 設計。建議您避免使用多個重疊範圍、安全範圍網路專案或非軍事區安全範圍，以及複雜存取層級的安全範圍設計。
使用常見的統一週邊
相較於使用多個區隔的周邊，單一大型周邊 (稱為通用統一週邊) 可提供最有效的資料外洩防護。
此外，統一的常見安全防護範圍可降低管理負擔，有助於負責建立及維護安全防護範圍的團隊。由於範圍內的服務和網路資源可自由通訊，並具備必要的 IAM 和網路控制項權限，因此負責範圍管理的團隊主要會關注南北向存取，也就是從網際網路存取範圍內資源的行為。
[[["容易理解","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,["# Design and architect service perimeters\n\nThis document describes recommended VPC Service Controls deployment architectures.\nThis document is for network administrators, security architects, and cloud\noperations professionals who run and operate large, production scale deployments\non Google Cloud and who want to mitigate the risk of sensitive data loss.\n\nBecause VPC Service Controls protection affects cloud services\nfunctionality, we recommend that you plan the enablement of\nVPC Service Controls in advance, and consider VPC Service Controls\nduring architecture design. It's important to keep VPC Service Controls\ndesign as simple as possible. We recommend that you avoid perimeter designs that\nuse multiple bridges, perimeter network projects or a [DMZ perimeter](/vpc-service-controls/docs/share-across-perimeters),\nand complex access levels.\n\nUse a common unified perimeter\n------------------------------\n\nA single large perimeter, referred to as a *common unified perimeter*, provides\nthe most effective protection against data exfiltration compared to using\nmultiple, segmented perimeters.\n\nA common unified perimeter also provides the benefit of lower management\noverhead for the teams responsible for perimeter creation and maintenance.\nSince services and network resources within a perimeter can communicate freely\nwith the necessary IAM and network controls permissions, the\nteams responsible for perimeter management will primarily be concerned with\nnorth-south access, which is access from the internet to resources inside the\nperimeter.\n\nWhen an organization uses multiple smaller perimeters, perimeter management\nteams must devote resources to managing east-west traffic between an\norganization's perimeters in addition to north-south traffic from outside the\norganization. Depending on the size of the organization and the number of\nperimeters, this overhead can be considerable. We recommend that you layer your\nperimeter with additional security controls and best practices, such as ensuring\nthat resources within the VPC network don't have direct internet egress.\n\nService perimeters aren't intended to replace or reduce the need for\nIAM controls. When you are defining access controls, we recommend\nthat you ensure that the principle of least privilege is followed and\n[IAM best practices](/iam/docs/using-iam-securely) are applied.\n\nFor more information, see [Creating a service\nperimeter](/vpc-service-controls/docs/create-service-perimeters).\n\n### Use multiple perimeters in one organization\n\nCertain use cases might require multiple perimeters for an organization. For\nexample, an organization that handles healthcare data might want one perimeter\nfor high-trust, non-obfuscated data and a separate perimeter for lower-tier,\nde-identified data to facilitate sharing with external entities while still\nprotecting the high-trust data.\n\nIf your organization wants to comply with standards such as [PCI DSS](/security/compliance/pci-dss), you\nmight want to have a separate perimeter around your regulated data.\n\nWhen data sharing is a primary use case for your organization, consider using\nmore than one perimeter. If you produce and share lower-tier data like\nde-identified patient health data, you can use a separate perimeter to\nfacilitate sharing with outside entities. For more information, see reference\npatterns for [secure data exchange](/vpc-service-controls/docs/secure-data-exchange#share-anonymized-data-with-partner-org).\n\nAdditionally, if you use your Google Cloud organization to host independent,\nthird-party tenants such as partners or customers, consider defining a\nperimeter for each tenant. If you consider data movement from from one of these\ntenants to another to be exfiltration, we recommend that you implement a\nseparate perimeter.\n\nPerimeter design\n----------------\n\nWe recommend that you enable all protected services when you create a perimeter,\nwhich helps reduce operational complexity and minimize potential exfiltration\nvectors. Because leaving APIs unprotected increases possible exfiltration vectors,\nthere should be reviews and justifications if your organization opts to protect\none API and not another.\n\nAll new projects should go through the\n[review and qualification process](#review-qualify-projects) that is\ndescribed in the following sections. Include in the perimeter all the projects\nthat pass the qualification conditions.\n\nMake sure that there isn't a path to the private VIP from any of the VPCs in\nthe perimeter. If you allow a network route to `private.googleapis.com`, you\nnegate VPC Service Controls protection from insider data exfiltration. If\nyou must allow access to a non-supported service, try to isolate the use of\nunsupported services into a separate project, or move the entire workload outside\nthe perimeter.\n\n### Review and qualify projects\n\nA typical enterprise has many projects that represent workloads and high-level\nconstructs such as control planes, data lakes, business units, and lifecycle\nstages. In addition to organizing these projects and components into folders,\nwe recommend that you qualify them to be inside or outside of a\nVPC Service Controls perimeter. To make the qualification, consider the\nfollowing questions:\n\n- Is there a component that has a hard dependency on a\n [service that VPC Service Controls doesn't support](/vpc-service-controls/docs/supported-products)?\n\n VPC Service Controls enforcement is unambiguous, so this type of\n dependency might not function in a perimeter. We recommend that you modify\n the workload to isolate the requirement for unsupported services into a\n separate project, or move the workload out of the perimeter altogether.\n- Is there a component that has no sensitive data and doesn't consume\n sensitive data from other projects?\n\nIf you answered yes to any of the preceding questions, we recommend that you\ndon't put the project into a perimeter. You can work around this, as discussed\nin the [Allowlist design](/vpc-service-controls/docs/access-level-design)\ntopic. However, we recommend that you minimize perimeter complexity.\n\nWhat's next\n-----------\n\n- Learn how to [create a service perimeter](/vpc-service-controls/docs/create-service-perimeters).\n- Learn how to test the impact of a perimeter using the [dry run mode](/vpc-service-controls/docs/dry-run-mode).\n- Learn about [ingress and egress rules](/vpc-service-controls/docs/ingress-egress-rules) that enable communication between service perimeters."]]
