Access Context Manager 概览

本文档简要介绍了 Access Context Manager 服务及其功能。 Google Cloud 组织管理员可以使用 Access Context Manager 为 Google Cloud中的项目和资源定义基于属性的精细访问权限控制。作为管理员，您首先要定义访问权限政策，这是组织范围内的访问权限级别和服务边界容器。

访问权限级别说明了请求得以执行所需满足的要求。示例如下：

  • 设备类型和操作系统
  • IP 地址
  • 用户身份

服务边界定义资源的沙盒，即可以在相应边界内自由交换数据，但不允许向外部导出数据。Access Context Manager 不负责强制执行政策，相反，Access Context Manager 旨在定义特定规则或情境。政策在 VPC Service Controls 等各个点进行配置和强制执行。如需详细了解这些服务，请参阅各自的用户指南。

您可以针对以下 Chrome 企业进阶版解决方案组件配置和强制执行 Access Context Manager 政策：

优势

许多公司都依赖于防火墙等边界安全模型来保护内部资源。边界安全模型设有守卫森严的单一进出点。墙外的任何东西都被认为具有危险性。而墙内的一切都受到信任。

只要特定用户和服务有精确的边界，防火墙和边界安全模型就可以有效运行。但是，如果员工移动不定，当用户使用自带设备 (BYOD) 并利用基于云的服务，设备种类便会不断增加。在这种情况下，会出现不在边界模型考虑范围内的额外攻击向量。鉴于此，边界不再只是企业的物理位置，并且也不应将内部东西一律视为安全。

借助 Access Context Manager，您可以减小特权网络的大小，并移至端点不承载基于网络的环境权限的模型。您可以改为根据请求的上下文（例如设备类型、用户身份等）授予访问权限，同时在必要时仍检查公司网络访问权限。

Access Context Manager 是 Google 的 BeyondCorp 不可或缺的一部分。如需了解详情，请参阅 BeyondCorp。

访问权限政策

访问政策是所有 Access Context Manager 资源（例如访问权限级别和服务边界）的容器。

您可以在组织环境中创建访问权限政策，并可在组织中的任何位置使用组织级访问权限政策。如需委派访问权限政策的管理权限，您可以创建范围限定的访问权限政策，并在文件夹或项目级层设置政策的范围。范围限定的政策所分配到的委派管理员只能管理范围限定的访问权限政策，而不能管理组织级访问权限政策。

使用 etag 对访问政策进行版本控制。您可以使用 etag 将对访问政策的更改（例如对访问权限级别的修改）瞄准该政策的特定版本。如果多个来源更改您的访问政策，则对 gcloud 命令行工具和 API 调用使用 etag 字段有助于防止意外覆盖和冲突。

如需了解如何创建访问权限政策，请参阅创建访问权限政策。

访问权限级别

访问权限级别用于允许访问资源（根据与请求相关的上下文信息）。借助访问权限级别，您可以开始组织信任层。例如，您可以创建一个名为 High_Level 的访问权限级别，该级别将允许一小部分具有高度特权的用户发出请求。您也可以识别一个更通用的组来信任，例如您允许发出请求的 IP 范围。在这种情况下，您可以创建一个名为 Medium_Level 的访问权限级别以允许这些请求。

访问权限级别定义完毕之后，强制执行服务就可以使用它们来确定是否接受请求。例如，您可以指定Medium_Trust可以使用许多资源，但某些更敏感的资源需要High_Trust级别。这些检查将与标准的 IAM 政策一同应用。

访问权限级别可自定义；例如，High_Trust 和 Medium_Trust 访问权限级别。您可以在一个访问权限政策中指定多个访问权限级别。

Access Context Manager 提供两种定义访问权限级别的方法：

  • 基本访问权限级别包含用于测试请求的一系列条件。 条件是要测试的一组属性，例如设备类型、IP 地址或用户身份。这些属性会以 AND 运算（所有属性都必须为 true）或 NOR 运算（所有属性都不得为 true）的方式组合在一起，以确定是否满足条件。

  • 自定义访问权限级别使用通用表达式语言的子集创建。除了用于基本访问权限级别的请求上下文之外，您还可以使用自定义访问权限级别来允许基于来自第三方服务的数据的请求。如需了解详情，请参阅自定义访问权限级别。

在嵌套访问权限级别和组合所有逻辑时，请注意，如果布尔值运算符 AND (&&) 和 OR (||) 的任何操作数唯一确定了结果，则可能会评估或可能不会评估另一个操作数。此外，如果该评估产生运行时错误，则会被忽略。例如，在以下表达式中，origin.region_code 的评估失败，但 levels.ip_check 的评估成功。由于至少有一项检查成功，因此由 OR 组合而成的总体条件变为 true，并且访问权限为 GRANTED。 
!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED  // levels.regions_check

inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED  // levels.ip_check

!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED

levels.regions_check || levels.ip_check -> GRANTED

IP 地址

您可以根据发出请求的 IP 地址来授予访问权限级别。要允许的 IP 范围以无类别域间路由 (CIDR) 地址块的形式进行指定，以便对要允许的 IP 地址进行精细的控制。

一个访问权限级别可以包含多个 IP 范围。

如需了解如何创建仅将访问权限授予指定范围内 IP 地址（例如单个公司网络中的 IP 地址）的访问权限级别，请参阅为公司网络访问权限创建访问权限级别。

设备类型

Access Context Manager 使用端点验证来收集用户设备的相关信息，例如操作系统、设备类型或版本。您可以根据这些数据授予访问权限级别。例如，如果设备运行公司部署的主要操作系统的最新版本，可以为其授予较宽松的访问权限级别。

如需了解如何根据此类设备特性授予访问权限级别，请参阅按设备类型限制访问权限。

用户身份

在某些情况下，您可能希望为特定实体授予访问权限级别。 在这些场景中，调用者的身份将决定是否满足条件。此方案通常与服务账号和 VPC Service Controls 搭配使用。 例如，您可以使用此方案来启用 Cloud Function，以访问受 VPC Service Controls 保护的数据。

您可以使用 gcloud 命令行工具创建和管理仅使用身份的访问权限级别，但不能使用 Google Cloud 控制台。

如需开始创建基本访问权限级别，请参阅为 Access Context Manager 创建访问权限级别。

如需了解如何创建根据请求上下文允许访问的访问权限级别，请参阅创建自定义访问权限级别。

合并条件

一个访问权限级别可以包含多个条件。您可以使用 AND 或 OR 运算符来评估条件，还可以在创建或更新访问权限级别时指定模式。

AND 运算符的限制较为严格（且为默认选项）。只有满足所有条件时，此选项才会授予访问权限级别。例如，您可以规定请求来自于公司网络内部，并且来自于运行最新版操作系统的设备。

OR 的限制较为宽松。此选项只需求满足多个条件中的一个。在处理用户身份时，这有时很实用；例如，从常规要求中排除特定实体（如服务账号）。

嵌套条件

您可以设置嵌套条件，使一个条件依赖于另一个条件。 例如，如果您有“中度”和“高度”信任级别等两个访问权限级别，可以将“高度”信任级别的要求设置为需要满足“中度”信任级别，外加其他一些条件。

嵌套条件让您可以更加便捷地管理访问权限级别。例如，假设您最宽松的访问权限级别包含最低操作系统版本要求，并且您将较为严格的级别设置为依赖于它。如果您将来更新最低版本，您只需更新单个条件，而不必更新政策中的所有访问权限级别。

了解详情