本文档介绍了推荐的 VPC Service Controls 部署架构。本文档适用于在 Google Cloud 上运行和运营大型生产规模部署以及希望降低敏感数据丢失风险的网络管理员、安全架构师和云运维专业人员。
由于 VPC Service Controls 保护会影响云服务功能，因此我们建议您提前计划启用 VPC Service Controls，并考虑在架构设计期间使用 VPC Service Controls。请务必尽可能简化 VPC Service Controls 的设计。我们建议您避免在边界设计中使用多个网桥、边界网络项目（有时称为 DMZ 边界）以及复杂的访问权限级别。
使用通用的统一边界
单个大边界称为通用的统一边界，与使用多个细分边界相比，单个大边界可以最有效地防止数据渗漏。
通用的统一边界还可帮助负责边界创建和维护的团队降低管理开销。由于边界内的服务和网络资源可以与必要的 IAM 和网络控制权限自由通信，因此负责边界管理的团队将主要关注南北向的访问，即从互联网到边界内资源的访问。
当组织使用多个较小的边界时，除了来自组织外部的南北向流量之外，边界管理团队还必须投入资源来管理组织边界之间的东西向流量。根据组织的大小和边界数量，此开销可能相当大。我们建议您为边界添加额外的安全控制措施和最佳做法，例如确保 VPC 网络中的资源没有直接的互联网出站流量。
服务边界并非用于取代或减少对 IAM 控制措施的需求。定义访问权限控制时，我们建议您确保遵循最小权限原则并应用 IAM 最佳做法。
如需了解详情，请参阅创建服务边界。
在一个组织中使用多个边界
某些使用场景可能需要组织使用多个边界。例如，对于信任度较高的非混淆数据，处理医疗保健数据的组织可能需要对其使用一个边界，而对于较低层级的去标识化数据，还需要使用一个的单独边界，以便于与外部实体共享，同时仍然保护信任度较高的数据。
如果您的组织希望遵守 PCI DSS 等标准，最好对受监管的数据使用单独的边界。
如果数据共享是您所在的组织的主要使用场景，请考虑使用多个边界。如果您生成和共享较低层级的数据（例如去标识化的患者健康数据），则可以使用单独的边界促进与外部实体进行共享。如需了解详情，请参阅安全数据交换的参考模式。
此外，如果您使用 Google Cloud 组织托管独立的第三方租户（例如合作伙伴或客户），请考虑为每个租户定义边界。如果您认为数据从某个租户转移到另一个租户会泄露数据，我们建议您实施单独的边界。
边界设计
我们建议您在创建边界时启用所有受保护的服务，这有助于降低运营复杂性并最大限度地减少潜在的渗漏矢量。由于不受保护的 API 会增加可能的渗漏矢量，因此如果您的组织选择保护一个 API 而不保护另一个 API，则应提供审核和理由。
所有新项目都应完成以下部分中所述的审核和资格认证流程。在边界中包含符合资格条件的所有项目。
确保没有从边界内的任何 VPC 指向专用 VIP 地址的路径。如果您允许到 private.googleapis.com 的网络路由，则会使 VPC Service Controls 针对内部人员数据渗漏的保护失效。如果您必须允许访问不支持的服务，请尝试将不受支持的服务使用隔离到单独的项目中，或者将整个工作负载移出边界。
查看项目并对项目进行认证
典型企业拥有众多项目来代表工作负载和高层次构造，例如控制层面、数据湖、业务部门和生命周期阶段。除了将这些项目和组件整理到文件夹之外，我们还建议您将其限于 VPC Service Controls 边界内部或外部。要进行限定，请考虑以下问题：
是否有组件严重依赖 VPC Service Controls 不支持的服务？
VPC Service Controls 强制执行很明确，因此此类型的依赖可能无法在边界内正常工作。我们建议您修改工作负载，将不受支持的服务要求单独应用于单独的项目，或者将工作负载完全从边界中移除。
是否存在不含敏感数据且不使用来自其他项目的敏感数据的组件？
如果上述任何问题的答案都为“是”，我们建议您不要将项目放置在边界内。您可以按照许可名单设计主题中所述解决此问题。不过，我们建议您最大限度地降低边界的复杂性。