本文介绍了情境感知访问权限的常见使用场景，并提供了在基本模式下开发的配置示例。
如需查看在高级模式下（使用 CEL 编辑器）开发的访问权限级别示例，请参阅情境感知访问权限示例（高级模式）。
仅向使用公司网络的合同工授予访问权限
许多公司都希望限制合同工访问公司资源。例如，一些公司会聘用合同工接听常规支持电话，或者让他们在帮助中心和呼叫中心工作。与全职员工类似，合同工必须拥有受支持的许可，才能纳入情境感知访问权限政策的适用范围内。
在此示例中，合同工仅能通过特定的公司 IP 地址范围来访问公司资源。
| 访问权限级别名称 | contractor_access |
| 合同工获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 | IP 子网（公共） 74.125.192.0/18 |
| 访问权限级别分配 | 合同工所在的组织部门 合同工使用的所有应用 |
禁止从已知的黑客 IP 地址进行访问
许多公司都会禁止用户从已知的高风险源访问公司资源，以防公司资源遭到破坏。
在此示例中，74.125.195.105 是被禁止的 IP 地址。如果用户会话源自任何其他 IP 地址，则用户可以访问公司资源。您可以指定多个 IP 地址和范围。
| 访问权限级别名称 | block_highrisk |
| 用户获得访问权限的前提 | 不满足属性 |
| 条件 1 的属性 | IP 子网（公共） 74.125.195.105 |
| 访问权限级别分配 | 顶级组织部门 所有应用 |
允许来自 Google Cloud 中特定专用网络的访问
许多公司通过虚拟私有云 (VPC) 将用户流量路由到 Google。VPC 是 Google Cloud 环境中安全隔离的网络。
请注意，通过 VPC 路由的流量可能会使用专用 IP 地址。这可能会导致公共 IP 或区域政策出现问题。
在此示例中，您可以允许来自这些特定 VPC 的流量。
| 访问权限级别名称 | vpc_access |
| 用户获得访问权限的前提... | 满足属性 |
| 条件 1 的属性 |
IP 子网（私密） 专用 IP 子网： //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC 子网：74.125.192.0/18 |
| 访问权限级别分配 |
所有用户的组织部门 合同工使用的所有应用 |
请务必记住以下重要事项：
- 仅限直接流量：此访问权限级别仅适用于从已列入许可名单的 VPC 直接到达 Google 服务器的流量。如果流量先通过其他网络或隧道，则不会授予访问权限。Google 只会识别向其服务器发送流量的最后一个 VPC。
- 管理员权限：如需查看 VPC 并配置此访问权限级别，管理员必须拥有相应的 Identity and Access Management (IAM) 角色（例如 compute.networks.list、compute.subnetworks.list 等）。
- 外部 VPC：您列入许可名单的 VPC 可以来自您当前的 Google Cloud 网域之外。管理员必须拥有查看权限才能添加外部 VPC。
允许或禁止从特定位置进行访问
如果您的员工经常前往遥远的公司或合作伙伴办公地点，那么您可以指定员工可以从哪些地理位置访问公司资源。
例如，如果销售团队定期前往澳大利亚和印度拜访客户，则您可以限定为仅允许销售团队在主要办公地点、澳大利亚和印度访问公司资源。如果销售团队在出差期间前往其他国家/地区度假，则无法在这些国家/地区访问公司资源。
在此示例中，销售团队仅能从美国（主要办公地点）、澳大利亚和印度访问公司资源。
| 访问权限级别名称 | sales_access |
| 销售人员获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 | 地理位置来源 美国、澳大利亚、印度 |
| 访问权限级别分配 | 销售人员团队 销售人员使用的所有应用 |
您还可以创建政策来禁止用户从特定国家/地区进行访问，方法就是指定用户在不符合条件的情况下可以获得访问权限，然后在条件中列出要禁止用户从哪些国家/地区进行访问。
在分配时使用嵌套访问权限级别，而不要选择多个访问权限级别
在某些情况下，当您尝试为特定组织部门/群组和某个应用（或一组应用）分配访问权限级别时，系统可能会显示错误消息，要求您减少应用或访问权限级别的数量。
为防止出现这种错误，您在分配时可以将多个访问权限级别嵌套为单个访问权限级别，从而减少数量。嵌套访问权限级别通过运算符“OR”（或）连接多个条件，其中每个条件都包含一个单独的访问权限级别。
在此示例中，USWest、USEast 和 USCentral 分别属于 3 个不同的访问权限级别。假设您希望用户在满足 USWest、USEast 或 USCentral 中任一访问权限级别的条件时获得应用访问权限，可以使用运算符“OR”创建名为“USRegions”的单个嵌套访问权限级别。在分配访问权限级别时，您只需为相应组织部门或群组将 USRegions 访问权限级别分配给应用即可。
|
访问权限级别名称 |
USRegions |
|
用户获得访问权限的前提 |
满足属性 |
|
条件 1 的属性 （每个条件中只有 1 个访问权限级别） |
访问权限级别 USWest |
|
连接条件 1 和条件 2 所使用的逻辑关系 |
或 |
|
用户获得访问权限的前提 |
满足属性 |
|
条件 2 的属性 |
访问权限级别 USEast |
|
连接条件 2 和条件 3 所使用的逻辑关系 |
或 |
|
用户获得访问权限的前提 |
满足属性 |
|
条件 3 的属性 |
访问权限级别 USCentral |
要求使用公司自有桌面设备，而不要求使用公司自有移动设备
公司可能会要求使用公司自有桌面设备，但不一定会要求使用公司自有移动设备。
首先，创建桌面设备访问权限级别：
|
访问权限级别名称 |
aldesktop_access |
|
用户获得访问权限的前提 |
满足属性 |
|
条件 1 的属性 |
设备政策
设备加密 = 不支持 设备操作系统 macOS = 0.0.0 Windows =0.0.0 Linux 操作系统 = 0.0.0 Chrome OS = 0.0.0 |
然后，创建移动设备访问权限级别：
|
访问权限级别名称 |
almobile_access |
|
用户获得访问权限的前提 |
满足属性 |
|
条件 1 的属性 |
设备操作系统 iOS = 0.0.0 Android = 0.0.0 |
要求达到基本的设备安全条件
如今，大多数企业和公司都规定，员工必须使用满足最低操作系统版本要求的已加密设备才能访问公司资源。有些企业和公司还要求员工使用公司自有设备。
您可以为所有组织部门配置相应的政策，也可以仅为处理敏感数据的人员（例如公司高管、财务或人力资源部门员工）进行配置。
您可以通过多种方式配置同时包含设备加密、最低操作系统版本、公司自有设备这三个属性的政策。每种方式都各有利弊。
以一项访问权限级别包含所有安全要求
在此示例中，设备加密、最低操作系统版本和公司自有设备这三个属性都包含在一项访问权限级别中。用户必须同时满足全部条件才能获得访问权限。
例如，如果用户的设备属于已加密的公司自有设备，但运行的操作系统版本不符合要求，那么该用户无法获得访问权限。
优点：易于设置。将此访问权限级别分配给某个应用后，只有满足所有要求的用户才能访问该应用。
缺点：如要想将这些安全要求分别分配给不同组织部门，您需要为每项安全要求创建单独的访问权限级别。
| 访问权限级别名称 | device_security |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 （您可以将所有属性都添加到同一个条件中，也可以 创建三个条件并使用 AND（和）逻辑关系将它们连接起来。） |
设备政策 设备操作系统 |
三项单独的访问权限级别
在此示例中，设备加密、最低操作系统版本、公司自有设备这三个属性分别包含在三项单独的访问权限级别中。用户只需满足其中一项访问权限级别中的条件，就能获得访问权限。各项访问权限级别之间的逻辑关系是 OR（或）。
例如，只要用户的设备已加密，即使该设备运行旧版操作系统并且属于个人设备，用户仍然能获得访问权限。
优点：可以细致地定义访问权限级别。您可以为不同组织部门单独分配访问权限级别。
缺点：用户只需要满足一项访问权限级别中的条件。
| 访问权限级别名称 | device_encryption |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 |
设备政策 |
| 访问权限级别名称 | corp_device |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 |
设备政策 |
| 访问权限级别名称 | min_os |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 |
设备政策 |
以一项访问权限级别包含嵌套访问权限级别
在此示例中，先以三项单独的访问权限级别分别包含设备加密、最低操作系统版本、公司自有设备这三项安全要求，然后将这三项访问权限级别嵌套在第四项访问权限级别中。
将第四项访问权限级别分配给应用后，用户必须同时满足嵌套在其中的三项访问权限级别的条件，才能获得访问权限。各项访问权限级别之间的逻辑关系是 AND（和）。
例如，如果用户的设备已加密，但运行的是旧版操作系统并且属于个人设备，则用户无法获得访问权限。
优点：您可以保留按访问权限级别 1、2 和 3 来划分安全要求的灵活性。通过使用访问权限级别 4，您还可以强制执行包含所有安全要求的政策。
缺点：审核日志仅会记录获取访问权限级别 4（而不是访问权限级别 1、2 和 3）失败的事件，这是因为访问权限级别 1、2 和 3 都没有直接分配给应用。
按照上文的“三项单独的访问权限级别”中的说明创建三项访问权限级别：“device_encryption”“corp_device”以及“min_os”。然后，创建第四项访问权限级别“device_security”，并在其中包含三个条件。每个条件都以一项访问权限级别作为其属性。（每个条件中只能添加一个访问权限级别属性。）
| 访问权限级别名称 | device_security |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 （每个条件仅包含一项访问权限级别） |
访问权限级别 device_encryption |
| 连接条件 1 和条件 2 所使用的逻辑关系 | 且 |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 | 访问权限级别 corp_device |
| 连接条件 2 和条件 3 所使用的逻辑关系 | 且 |
| 用户获得访问权限的前提 | 满足属性 |
| 条件 1 的属性 | 访问权限级别 min_os |