策略

Cloudflare Access 通过应用您配置的 Access 策略来确定谁可以访问您的应用程序。

每个 Access 策略都有四个构建块：

• Actions（操作）：当用户匹配策略时会发生什么（Allow、Block、Bypass 或 Service Auth）
• Rule types（规则类型）：如何组合条件进行评估（Include、Require 或 Exclude）
• Selectors（选择器）：正在检查的属性（例如，电子邮件域、国家/地区或设备姿态）
• Values（值）：要匹配的特定值（例如 @example.com）

操作允许您向特定用户或用户组授予或拒绝权限。每个策略只能设置一个操作。

Cloudflare Access 中的 Allow（允许）操作允许满足特定条件的用户访问 Access 后面的应用程序。

下表显示了一个 Cloudflare Access Allow 策略示例，该策略允许拥有 @example.com 电子邮件地址（已通过 IdP 验证）的任何用户访问该应用程序：

您可以在同一策略操作中添加一个 Require 规则以强制执行其他检查。最后，如果策略包含 Exclude 规则，则满足该定义的用户将无法访问应用程序。

例如，下表显示了具有 Require 和 Exclude 规则的 Allow 策略。此配置允许来自葡萄牙（Portugal）且拥有 @team.com 电子邮件地址（已通过 IdP 验证）的任何用户访问应用程序，但 user-1 和 user-2 除外：

Cloudflare Access 中的 Block（阻止）操作会阻止满足特定条件的用户访问应用程序。例如，下表显示了一个 Block 策略，该策略会阻止来自俄罗斯源 IP（且不在您的批准 IP 列表中）的请求。

Block 策略最好与 Allow 策略结合使用，以此来排除 Allow 策略中的例外情况。由于 Access 默认是拒绝的，不匹配 Block 策略的用户仍然会被拒绝访问，除非他们明确匹配了 Allow 策略。

Cloudflare Access 中的 Bypass（绕过）操作会针对特定流量禁用 Access 强制执行。

Bypass 操作会对满足所定义规则条件的流量禁用任何 Access 强制执行。Bypass 通常用于允许需要公开特定端点的应用程序。

例如，某些应用程序在 /admin 路由下有一个必须可公开路由的端点。在这种情况下，您可以为域 test.example.com/admin/<your-url> 创建一个 Access 应用程序，并添加下表所示的 Bypass 策略：

作为实施 Zero Trust 安全模型的一部分，Cloudflare 不建议使用 Bypass 来授予对内部应用程序的直接永久访问权限。为了使网络内员工能够进行无缝且安全的访问，请使用 Cloudflare Tunnel 连接您的专有网络，并让用户通过 Cloudflare One Client 进行连接。

包含设备姿态检查规则的 Bypass 策略在以下情况下将不起作用：

• 为受 Access 保护的区域启用了 Zaraz
• Worker 拦截了该请求

为了绕过这些限制并绕过 Access，我们建议将策略操作更改为 Service Auth。

Cloudflare Access 中的 Service Auth（服务身份验证）规则强制执行不需要身份提供商（IdP）登录的身份验证流程，例如服务令牌和双向 TLS（mTLS）。

下表显示了一个 Cloudflare Access Service Auth 策略配置示例：

规则类型的工作方式类似于逻辑运算符，用于确定如何组合您的条件以对用户进行评估。所有 Access 策略必须包含至少一个 Include 规则。此 Include 规则定义了可以访问应用程序的符合条件用户的初始池。然后，您可以添加 Exclude 和 Require 规则来缩小范围。

Cloudflare Access 中的 Include 规则类似于 OR 逻辑运算符。如果指定了多个 Include 规则，用户只需满足其中一个条件即可。

Cloudflare Access 中的 Exclude 规则的工作方式类似于 NOT 逻辑运算符。满足任何排除条件的用户将不被允许访问该应用程序。

Cloudflare Access 中的 Require 规则的工作方式类似于 AND 逻辑运算符。用户必须满足所有指定的 Require 规则才能被允许访问。

默认情况下，添加到 Require 规则中的任何值都通过 AND 运算符进行串联。例如，假设您想向全职员工和承包商授予应用程序的访问权限，并且仅限位于特定国家/地区（例如葡萄牙和美国）的员工和承包商。如果您使用以下配置设置规则：

此策略要求用户同时在美国和葡萄牙，并且拥有的电子邮件同时以 @cloudflare.com 和 @contractors.com 结尾。因此，任何人都无法访问该应用程序。

解决方案：使用规则组将 Require 规则中的 AND 逻辑转换为 OR 逻辑。

1. 创建一个名为 Country requirements 的规则组，其中包括位于葡萄牙或美国的用户：

   规则类型	选择器	值
   Include（包含）	Country（国家/地区）	United States, Portugal

2. 创建一个要求该规则组的策略，该策略还包含电子邮件以 @cloudflare.com 或 @contractors.com 结尾的用户：

   操作	规则类型	选择器	值
   Allow（允许）	Require（要求）	规则组	Country requirements
   	Include（包含）	Emails ending in（电子邮件结尾为）	@cloudflare.com, @contractors.com

当您向 Cloudflare Access 策略添加规则时，系统会要求您指定希望用户满足的条件或属性。这些属性适用于所有 Access 应用程序类型，包括 SaaS、自托管 和 非 HTTP 应用程序。

非身份属性会被持续轮询，这意味着在用户会话期间，会对每个新的 HTTP 请求进行评估以检查其变化。如果您配置了 SCIM 配置（provisioning），那么每当您在 IdP 中撤销用户或更新其 IdP 组群关系时，您都可以强制用户重新向 Access 验证所有属性。

¹ 对于 SaaS 应用程序，Access 仅能在初始登录以及重新签发 SaaS 会话时强制执行策略。一旦用户通过了 SaaS 应用程序的身份验证，会话管理就完全属于该 SaaS 应用程序的范畴了。

连接上下文设置允许您控制在向用户授予访问权限后，他们如何与应用程序进行交互。虽然选择器决定了谁可以访问应用程序，但连接上下文设置决定了用户在会话期间可以采取什么操作。可用的连接上下文设置取决于应用程序类型。

连接上下文是按策略配置的，允许您向不同的用户组授予不同的权限。例如，您可以允许全职员工从远程 RDP 会话复制数据，同时限制承包商仅具有只读访问权限。

Cloudflare Access 策略根据其操作类型和您设置的顺序进行评估。Bypass（绕过） 和 Service Auth（服务身份验证） 策略首先进行评估（如 UI 中所示，自上而下）。然后，根据 Block（阻止） 和 Allow（允许） 策略自上而下的顺序对其进行评估。

例如，如果您安排了如下策略：

• Allow A
• Block B
• Service Auth C
• Bypass D
• Allow E

这些策略将按以下顺序执行：Service Auth C > Bypass D > Allow A > Block B > Allow E。一旦用户匹配了 Allow 或 Block 策略，评估就会停止，后续政策无法覆盖该决定。

如果您将以下任何规则添加到 Allow（允许） 策略中，任何人都可以访问您的应用程序。

下表显示了一个包含所有人的 Cloudflare Access 策略：

下表显示了一个包含所有具有有效电子邮件登录方法的用户的 Cloudflare Access 策略：

API 和 Terraform 提供了以编程方式管理您的 Access 策略和配置的方法。