本文档介绍了推荐的 VPC Service Controls 部署架构。本文档适用于在 Google Cloud 上运行和运营大型生产规模部署以及希望降低敏感数据丢失风险的网络管理员、安全架构师和云运维专业人员。
由于 VPC Service Controls 保护会影响云服务功能，因此我们建议您提前计划启用 VPC Service Controls，并考虑在架构设计期间使用 VPC Service Controls。请务必尽可能简化 VPC Service Controls 的设计。我们建议您避免在边界设计中使用多个网桥、边界网络项目（有时称为 DMZ 边界）以及复杂的访问权限级别。
使用通用的统一边界
单个大边界称为通用的统一边界，与使用多个细分边界相比，单个大边界可以最有效地防止数据渗漏。
通用的统一边界还可帮助负责边界创建和维护的团队降低管理开销。由于边界内的服务和网络资源可以与必要的 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"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],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."]]
