Google Cloud在2026年9月30日宣布，VPC Service Controls入站与出站规则正式支持把文件夹和组织作为资源引用。过去需要逐个维护大量项目编号的访问场景，现在可以直接按资源层级授权，降低大型云环境中的规则长度和维护成本。
层级引用会把规则覆盖到文件夹或组织下的资源，范围远大于单个项目。配置更简洁不代表权限更小，组织级资源一旦写入错误规则，可能同时影响大量现有与新增项目。
入站和出站规则都能使用资源层级
入站规则用于描述服务边界外部客户端访问边界内资源的条件，出站规则处理边界内客户端或资源与边界外资源相关的访问。新能力允许在相关资源字段中填写folders或organizations，而不再局限于projects。
规则使用文件夹编号或组织编号，而不是显示名称。管理平台生成配置时应保存稳定的资源标识，并在组织结构调整后重新检查规则覆盖范围。
方向判断依据请求而不是数据流向
VPC Service Controls对入站和出站的定义看的是API请求与服务边界之间的关系，不是业务数据最终向哪个方向移动。一个复制对象的操作可能同时涉及边界内外资源，即使数据流向直观，也不能只凭源和目标判断需要哪类规则。
设计规则时应从调用者、API方法和涉及资源三个维度分析。某些跨边界操作同时需要入站和出站规则，只补其中一侧仍会导致请求被拒绝。
层级引用可以减少项目清单膨胀
文件夹或组织作为资源后，其层级下的资源可以被同一条规则覆盖。这对包含大量项目的企业环境很有价值，也能绕开常见的资源数量限制，减少新增项目后反复修改规则的工作。
层级成员会随组织结构变化而变化，新建或迁入的项目可能自动进入规则覆盖范围。使用前应确认哪些团队具备移动项目的权限，避免组织结构调整在没有安全评审的情况下改变访问边界。
跨多个服务边界仍要逐个满足策略
当客户端和资源分属不同服务边界时，所有涉及边界的策略都必须允许该请求。例如两个边界内的Cloud Storage存储桶互相复制数据，需要在两侧配置对应的出站规则，并为外部客户端补齐必要的入站条件。
文件夹或组织引用不能绕过其他边界的限制，也不会代替身份、服务和方法约束。层级资源应与明确的身份及最小API范围组合使用，不能单独作为宽泛放行条件。
迁移现有规则要分阶段验证
可先把多条项目清单整理为文件夹结构，核对每个项目的父级关系，再用层级引用构建等价规则。新旧规则短期并行时，应关注访问日志和拒绝事件，确认没有遗漏跨边界任务或后台服务账号。
验证完成后再删除旧项目列表，并把组织与文件夹变更纳入安全审批。回滚方案应保留原有项目级规则，以便在层级范围与预期不一致时快速恢复。
