本文档简要介绍了 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 访问权限级别。您可以在一个访问权限政策中指定多个访问权限级别。
!(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 会将以下 IP 范围视为专用范围：
10.0.0.0/8(RFC 1918)172.16.0.0/12(RFC 1918)192.168.0.0/16(RFC 1918)100.64.0.0/10（RFC 6598 共享地址空间）fc00::/7（IPv6 唯一本地地址 RFC 4193）
用户身份
在某些情况下，您可能需要向特定实体授予访问权限级别。在这些场景中，调用方的身份决定了是否满足条件。此场景通常与服务账号和 VPC Service Controls 搭配使用。
您可以使用 gcloud 命令行工具创建和管理仅限身份的访问权限级别，但不能使用 Google Cloud 控制台。
如需开始创建基本访问权限级别，请参阅为 Access Context Manager 创建访问权限级别。
合并条件
一个访问权限级别可以包含多个条件。您可以使用 AND 或 OR 运算符来评估条件，还可以在创建或更新访问权限级别时指定模式。
AND 选项是更严格的默认选项。只有在所有条件都满足时，此选项才会授予访问权限级别。例如，您可以要求请求来自公司网络内部，并且来自运行最新版本操作系统的设备。
OR 的限制较为宽松。此选项仅要求满足多个条件中的一个。在处理用户身份时，这有时很有价值，例如，从正常要求中排除特定实体（例如服务账号）。
嵌套条件
您可以设置嵌套条件，使一个条件依赖于另一个条件。 例如，如果您有“中”和“高”两个信任访问权限级别，则可以将“高”的要求设置为除了其他条件之外，还需要“中”。
嵌套条件让您可以更加便捷地管理访问权限级别。例如，假设您最宽松的访问权限级别包含最低操作系统版本要求，并且您将较为严格的级别设置为依赖于它。如果您日后更新最低版本，则只需更新一个条件，而无需更新政策中的每个访问权限级别。
嵌套访问权限级别时，请注意以下限制和约束：
无循环依赖项：不允许存在循环依赖项。访问权限级别不能在循环中相互引用，无论是直接引用（例如，
Level_A需要Level_B，Level_B需要Level_A，或者访问权限级别引用自身）还是传递引用（例如，Level_A需要Level_B，Level_B需要Level_C，Level_C需要Level_A）。如果您尝试创建或更新引入循环依赖项的访问权限级别，则调用会失败并显示INVALID_ARGUMENT错误。每个条件的最大依赖项数：在基本访问权限级别中，单个条件的
requiredAccessLevels列表最多可以引用 15 个其他访问权限级别。嵌套深度：由于 Access Context Manager 会按依赖项顺序评估嵌套访问权限级别，而不是以递归方式展开它们，因此嵌套访问权限级别链没有单独的最大深度限制，只有每个访问权限政策的访问权限级别数量限制。所有引用的访问权限级别都必须属于同一访问权限政策。