本文档介绍了推荐的 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 强制执行很明确,因此此类型的依赖可能无法在边界内正常工作。我们建议您修改工作负载,将不受支持的服务要求单独应用于单独的项目,或者将工作负载完全从边界中移除。
是否存在不含敏感数据且不使用来自其他项目的敏感数据的组件?
如果上述任何问题的答案都为“是”,我们建议您不要将项目放置在边界内。您可以按照许可名单设计主题中所述解决此问题。不过,我们建议您最大限度地降低边界的复杂性。