设计访问权限级别

本文档介绍了访问权限级别实现方法，并提供了有关根据许可名单启动服务边界实施的建议。

完成工作负载的试运行时，您需要识别需要添加到许可名单的 IP 地址和身份列表。您还会发现某些工作负载需要基于设备的许可名单。如需授予受保护 Google Cloud 资源的受控访问权限，您可以使用 VPC Service Controls 访问权限级别。您可以实现访问权限级别所采用的实用方法基于 IP 地址、身份或设备。

如需了解详情，请参阅使用入站流量规则实现情境感知访问权限。

基于来源 IP 授予访问权限

在基于 IP 的许可名单中，访问权限级别仅支持使用公共 IP CIDR 范围。由于此方法允许来自此 IP 范围的所有受保护 API，因此这些 IP 后面的环境必须受信任且受到控制。该许可名单的典型使用场景是允许从本地网络访问边界。下图展示了基于 IP 地址的许可名单如何阻止和允许边界访问：

在上图中，有效身份将尝试访问边界。如果访问尝试来自任何互联网 IP 地址，访问就会遭到拒绝。但是，如果是来自公司的公共 IP 地址，则允许访问。

此场景的一种变体是，您允许从部署在其他项目或组织中的私有资源进行边界访问。在此用例中，源项目中必须有一个 Cloud NAT 网关。Cloud NAT 与专用 Google 访问通道集成，可自动在资源的子网上启用专用 Google 访问通道，并将流量保持在 Google APIs 和服务的内部网络中，而不是通过 Cloud NAT 网关的外部 IP 地址路由到互联网。由于流量在内部 Google 网络中路由，因此 AuditLog 对象的 RequestMetadata.caller_ip 字段会被隐去为 gce-internal-ip。在这种情况下，如需允许边界访问，应配置入站流量规则，依据项目或服务账号等属性进行访问控制，而不是基于外部源 IP 地址设置访问权限级别。

基于调用者身份授予访问权限

如需实现基于身份的许可名单，您可以将服务账号和组织超级用户添加到许可名单。边界向任何 IP 地址中的那些身份开放，因此您需要确保身份得到充分保护。您还需要确保避免为已添加到许可名单的服务账号创建密钥。将用户身份添加到边界上的许可名单并不常见（通常不能将群组添加到许可名单）。

边界内的资源可通过边界内的虚拟机、受信任的本地网络或从受信任的设备进行访问。我们建议使用 Cloud Workstations 访问边界内的资源，因为 VPC Service Controls 不支持 Cloud Shell。

注意：您只能通过 gcloud CLI 使用访问权限级别来实现基于身份的许可名单。您可以使用 Google Cloud 控制台来配置入站流量规则，以实现基于身份的访问权限级别。

基于调用者设备属性授予访问权限

设备信任（也称为“受信任端点”）需要有效的组织用户登录 Chrome 浏览器或 Chromebook。设备信任适用于操作系统登录会话。例如，已登录和运行 Chrome 会话的 Windows 用户（不需要打开浏览器）可以对受保护的边界 API 成功调用 gcloud CLI 命令。但是，同一机器上的其他 Windows 用户会话无法对受保护的边界 API 调用命令。

注意：仅当您使用 Chrome 企业进阶版时，调用方设备属性才可用。

以下设备条件有助于建立设备信任：

• 经过验证的 ChromeOS是一种高度安全、已经过加密验证的条件，指示有效的组织用户已登录安全引导的 Chromebook。这是推荐的第 1 层信任条件。

  

• 需要管理员批准才能访问设备允许 Cloud Identity 管理员先批准各个设备，然后再授予任何访问权限。默认情况下，如果设备上已登录有效的组织用户，则设备会自动获得批准。不过，我们建议您关闭自动批准选项。

• 需要使用公司自有设备需要 Chrome 代理从操作系统检索序列号，该号码通常来自 BIOS。此号码必须与您已输入 Cloud Identity 的现有序列号匹配。

  由于序列号在非 ChromeOS 设备中不是权威性的，因此具有提升管理员权限的用户也许能够仿冒序列号，因此我们建议您仅将此条件用作第 2 层检查。

注意：若要应用信任，用户和设备必须与 Google Cloud 资源位于同一组织中。

如需查看根据上文列表中所述条件授予受控访问权限的示例跟踪器，请参阅 VPC Service Controls 新手入门模板 - 许可名单 (PDF)。

开始强制执行

在设计许可名单并更新访问权限级别后，我们建议您再次执行工作负载，以确认没有任何违规行为。如果工作负载在运行时没有发生违规行为，您可以开始强制执行 VPC Service Controls，而不会影响应用。

规划强制执行时，请提供以下信息：

• 选择强制执行日期，并将该日期发送给所有相关团队。
• 确保安全运维和突发事件响应团队知道部署。此外，请确保具有相应权限的个人检查日志，并在必要时批准其他许可名单。
• 请确保如果出现任何问题，状况响应团队能够提交 Google Cloud支持请求。
• 使用 Terraform 等自动化工具创建或修改边界和访问权限级别。我们不建议您手动执行这些任务。

开始强制执行时，首先将与单个工作负载关联的项目从试运行边界移动到活跃边界。请务必留出时间，让应用在您观察违规日志时能够正常运行。对剩余的工作负载重复该过程（一次一个）。

如需显示已屏蔽的违规行为，请配置汇总日志记录接收器，以将边界内所有项目的审核日志发送到 BigQuery。然后，运行以下查询：

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter

后续步骤

• 了解如何允许从边界外访问受保护的资源。
• 了解如何列出、更新和删除服务边界。