Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Access Context Manager 概览

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

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

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

服务边界定义资源的沙盒。边界内的资源可以自由交换数据，但不能向边界外导出数据。 Access Context Manager 不负责强制执行政策，而是 Access Context Manager 旨在定义特定规则或上下文。政策在 VPC Service Controls等各个点进行配置和强制执行。如需了解这些服务的更多信息，请阅读各自的用户指南。

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

Identity and Access Management (IAM) 条件

福利

许多公司都依赖于防火墙等边界安全模型来帮助保护内部资源。边界安全模型受到严密保护，并设有单一进出点。位于边界外的任何内容都被视为危险内容，而墙内的一切都受到信任。

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

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

访问权限政策

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

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

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

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

访问权限级别

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

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

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

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

!(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 命令行工具创建和管理仅使用身份的访问权限级别，但不能使用 Cloud de Confiance 控制台。

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

合并条件

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

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

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

嵌套条件

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

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

了解详情

了解与 Google Cloud 之间的 Access Context Manager 差异 Cloud de Confiance 。