本文档简要介绍了 Access Context Manager 服务及其功能。 Google Cloud 组织管理员可以使用 Access Context Manager 为 Google Cloud中的项目和资源定义基于属性的精细访问权限控制。作为管理员，您首先要定义访问权限政策，这是组织范围内的访问权限级别和服务边界容器。
访问权限级别说明请求被接受所需要满足的条件。示例如下：
- 设备类型和操作系统
- IP 地址
- 用户身份
服务边界定义资源的沙盒，即可以在相应边界内自由交换数据，但不允许向外部导出数据。Access Context Manager 不负责强制执行政策，而是，Access Context Manager 旨在定义特定规则或情境。政策在 VPC Service Controls 等各个点进行配置和强制执行。如需详细了解这些服务，请参阅各自的用户指南。
您可以在以下 Chrome Enterprise 进阶版解决方案组件中配置和强制执行 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 Functions 函数以访问受 VPC Service Controls 保护的数据。
您可以使用 gcloud 命令行工具创建和管理仅使用身份的访问权限级别，但不能使用 Google Cloud 控制台来创建和管理。
如需开始创建基本访问权限级别，请参阅为 Access Context Manager 创建访问权限级别。
如需了解如何创建根据请求上下文授予访问权限的访问权限级别，请参阅创建自定义访问权限级别。
合并条件
一个访问权限级别可以包含多个条件。您可以使用 AND 或 OR 运算符来评估条件，还可以在创建或更新访问权限级别时指定模式。
AND 运算符的限制较为严格，也是默认选项。只有满足所有条件时，此选项才会授予访问权限级别。例如，您可以规定请求来自于公司网络内部，并且来自于运行最新版操作系统的设备。
OR 的限制较为宽松。此选项只需求满足多个条件中的一个。在处理用户身份时，这有时很实用；例如，从常规要求中排除特定实体（如服务账号）。
嵌套条件
您可以设置嵌套条件，使一个条件依赖于另一个条件。 例如，倘若您有“中度”和“高度”信任级别等两个访问权限级别，可以将“高度”信任级别的要求设置为需要满足“中度”信任级别，外加其他一些条件。
嵌套条件让您可以更加便捷地管理访问权限级别。例如，假设您最宽松的访问权限级别包含最低操作系统版本要求，并且您将较为严格的级别设置为依赖于它。如果您将来更新最低版本，您只需更新单个条件，而不必更新政策中的所有访问权限级别。