设计访问权限级别

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

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

如需了解详情,请参阅结合使用入站流量规则的情境感知访问权限

基于来源 IP 授予访问权限

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

VPC Service Controls 网络和服务边界可防止访问不受信任的网络上的有效身份。

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

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

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

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

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

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

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

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

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

    启用了“经过验证的 Chrome 操作系统”选项的操作系统政策。

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

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

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

如需查看根据上文列表中所述条件授予受控访问权限的示例跟踪器,请参阅 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

后续步骤