VPC 服务控制（VPC-SC）是保护 Google 云 API 的一项极其重要的安全控制。过度简化。VPC-SC 允许你在组织内的项目周围定义安全边界，它可以阻止跨越边界的 API 调用，除非定义了入口规则等例外情况。

通常情况下，VPC-SC 不应被用于细粒度访问控制，这属于云 IAM 的范畴，但在本文中，我将介绍一个使用案例，它完美地打破了这一规则。

挑战：在 Bigquery 上隔离分析用例

Bigquery 允许对数据集进行细粒度访问，这使得数据所有者可以轻松地仅授予用户访问其业务用例所需数据集的权限。根据企业、Bigquery 数据湖中存储的数据类型以及访问监管策略的不同，一些客户可能希望防止用户将不同用例访问的数据集关联起来。

本图展示了一个非常基本的示例：

图片细节：

• 我们的分析师正在执行 2 个不同的分析，需要查询和关联多个数据集，而使用情况之间的重叠极少
• 查询 1，只查询已授权用于分析 1 的数据集，且应允许查询
• 查询 2，同样只查询已授权作为分析 2 一部分的数据集，应同样允许
• 查询 3：关联单独分析用例中的数据集，不应允许查询。

为什么要这样要求？企业限制相关性的原因有很多，例如：使用不同的聚合策略，将通过聚合数据进行匿名化处理的两个数据集关联起来，可能会提取出公司政策不允许的粒度信息。

为什么这是一个挑战？云资源的默认访问控制基于云 IAM 策略，这些策略授予委托人（例如：服务帐户、用户或组）某些资源（例如：项目）的某些权限（例如：bigquery.tables.create）。拥有多个资源权限的委托人可以同时使用这些资源，一个 bigquery 作业如果要查询两个表（A,B）的聚合数据，基本上需要以下权限：

因此，我们不能为查询中的其他内容在表 A 的 bigquery.tables.getData 中添加条件。

解决方案

该架构基于以下谷歌云平台组件：

• Bigquery、数据仓库和数据分析平台
• 数据交换，用于跨项目共享数据集的云数据中心功能
• 云工作站，在 GCP 上客户项目内运行的受管开发和分析环境
• VPC 服务控制，根据上下文控制 GCP API 访问的安全边界

该架构的目标是允许一个用户（user1@example.com）在两个独立的分析项目（项目 A 和项目 B）上工作，而无法直接关联两者之间的数据。用户可以从作为云工作站部署的分析环境中访问数据，云工作站在 GCP 项目数据分析项目 A&B 中运行。

数据视图项目 A&B 承载着数据交换和从订阅创建的链接数据集。数据交换和订阅以链接数据集的形式在 “数据视图 ”项目 A&B 中创建。实际上，Bigquery 用户将在 “数据视图项目 A ”中看到一个 bigquery 数据集，但该数据集直接链接到数据湖项目中的数据集，在这种情况下，使用数据交换是为了避免项目间的数据重复。user1@example.com 没有访问数据湖项目的权限。

链接数据集和数据交换的创建可作为分析环境设置的一部分来执行，user1@example.com 只需获得与项目数据视图项目中的订阅链接的 bigquery 数据集的 IAM 权限即可。

架构组件摘要：

包含数据的项目：

• 数据湖项目：包含已审核并批准用于外部消费的数据集的项目
• 数据视图项目 A：为启用分析项目 A 而创建的项目，其中包含通过订阅数据交换创建的链接数据集，这些数据集包含分析项目 A 所需的数据
• 数据视图项目 B：与项目 A 相同，用于项目 B

VPC-SC 周边： 它围绕着所有包含数据的项目，限制每个 API。

• 分析项目也可以在 VPC-SC 周边内，只要它是与此周边分开的周边即可

输入规则：

• 输入规则 A：它允许来自数据分析项目 A 的 user1@example.com 访问项目中的 bigquery API 资源： 数据视图项目 A
• 输入规则 B：它允许来自项目数据分析项目 A 的 user1@example.com 访问项目中的 bigquery API 资源： 数据视图项目 B

IAM 策略

• user1@example.com 具有访问项目中 bigquery 数据集的 IAM 角色：

         数据视图项目 A

         数据视图项目 B

         数据湖项目中没有任何数据集

工作流程：

user1@example.com 登录工作站 A

• 工作站执行的 API 调用将显示为来自数据分析项目 A
• user1@example.com 将能够查询数据视图项目 A 中的链接数据集
• 需要使用数据视图项目 A 作为 bigquery 的计费项目
• 但 user1@example.com 将无法查询数据视图项目 B 中的数据

user1@example.com 登录工作站 B

• 在这里，API 调用将显示为来自数据视图项目 A B
• user1@example.com 将能够查询数据视图项目 B 中的数据
• 需要使用数据视图项目 B 作为 bigquery 的计费项目
• 但 user1@example.com 将无法查询数据视图项目 A 中的数据

入口规则示例：

ingressPolicies:
  - ingressFrom:
      identities:
      - user:user1@example.com
      sources:
      - resource: projects/[# Data analysis project A]
    ingressTo:
      operations:
      - methodSelectors:
        - method: '*'
        serviceName: bigquery.googleapis.com
      - methodSelectors:
        - method: '*'
        serviceName: analyticshub.googleapis.com
      resources:
      - projects/[# Data view project A]

入口规则是 VPC_SC 边界默认行为的例外情况，该行为只允许从与被访问目标资源位于同一边界内的网络或资源调用 API。在本例中，只要符合以下条件，输入规则就允许从边界外调用 API：

1. 用户已验证为 user1@example.com
2. API 调用来自项目 “数据分析项目 A”，该项目托管云工作站所在的 VPC 网络
3. API 是 bigquery.googleapis.com 或 analyticshub.googleapis.com
4. 目标资源位于 “数据视图项目 A ”中

此架构的测试重点是安全要求，而不是数据架构的角度。要构建用于生产的解决方案，你需要检查分析集线器和其他数据组件架构，并使其与最佳实践保持一致。

本解决方案可满足托管敏感数据和个人数据的 GCP 组织的特定要求。这是一个复杂的架构，因为这是一个复杂的需求，仅使用云 IAM 策略无法解决。

在生产中使用该解决方案时，强烈建议使用自动化为新用例创建分析环境：云工作站项目、数据视图项目和入口规则。如果不使用自动化，我不建议使用此解决方案，因为出错的可能性太高。

目前（2024 年 9 月），VPC-SC 在预览版中提供了一项功能，允许将用户组作为入口/出口规则中的参数，而不是单个用户。一旦该功能投入生产，它将极大地简化该架构的入口/出口规则管理，因为现在需要将单个用户添加到策略中。