为 Cloudflare Access 设计 ZTNA 访问策略

如今，组织越来越多地采用 零信任安全 (Zero Trust security) ↗ 态势来保护公司资产和基础架构，以应对不断演变的威胁环境。与传统网络设计相关的传统安全性假设在企业网络边界内是受信任的。相比之下，零信任的运作原则是“从不信任，始终验证”，并对所有用户、设备和应用程序实施持续 身份验证和严格的访问控制 ↗，无论它们的位置或网络如何。

通常有两种技术在零信任架构中发挥作用。首先，安全 Web 网关 (SWG) ↗ 过滤发往 Internet 的出站流量，并阻止用户访问高风险网站，例如参与网络钓鱼活动的网站。然后，为了实现用户对 SaaS 应用程序、内部托管应用程序和网络的远程访问，零信任网络访问 (ZTNA ↗) 服务用于创建安全隧道，并为远程用户提供进入私有应用程序的访问权限。

本指南适用于希望部署 Cloudflare 的 ZTNA 服务 (Access) 的客户，并提供了如何有效构建正确策略的最佳实践和指南。如果您还没有这样做，我们建议您也阅读 Cloudflare 的 SASE 参考架构，其中详细介绍了如何将 Cloudflare 作为零信任计划一部分的各个方面。

本文档面向评估或已采用 Cloudflare 以取代现有 VPN 服务或为内部资源提供新的远程访问权限的管理员。这可作为设计第一个 ZTNA 策略的起点和持续的参考。本指南涵盖三个主要部分：

• 技术先决条件 (Technical prerequisites)：在您可以保护对第一个应用程序的访问并定义访问策略之前，需要具备哪些条件。
• 构建策略 (Building policies)：访问策略的主要组件及其组合方式。
• 用例 (Use cases)：可用作您自己策略设计蓝图的常见用例和策略。

本设计指南假设您对 Cloudflare 的 ZTNA 解决方案 Cloudflare Access 有基本的了解。因此，本指南重点介绍如何设计有效的访问策略，并假设您已经配置了 DNS、身份 和 设备态势提供程序，以及已经 建立了对自托管应用程序和相关网络的连接。

在本指南结束时，您将具备在各种常见企业场景中实施执行零信任原则的细粒度访问策略的能力。

本节介绍了在设计细粒度访问策略之前需要了解的基本架构组件和概念。

Cloudflare 允许组织使用我们的 连接云 (connectivity cloud) ↗ 促进应用程序访问，该云可安全地连接用户、应用程序和数据，无论它们身在何处。平台的核心是 Cloudflare 的 广泛全球网络 ↗，它为全球用户提供低延迟连接。通过在每个数据中心运行每项服务，Cloudflare 在单通道中应用网络、性能和安全功能，消除了通过多个专用安全服务器路由流量的需求，从而减少了延迟并避免了性能瓶颈。

提供对私有应用程序和网络访问主要有两种方式：通过公共主机名（其中请求被代理到应用程序），或通过专用 IP（私有 IP，其中用户位于通过 Cloudflare 将他们连接到其私有公司网络的设备或网络上）。

要使用公共主机名，您需要在 Cloudflare 中拥有一个 活动域。大多数客户使用 Cloudflare 作为其主 DNS 服务，但也可以配置用于 Access 的域并 在其他地方维护 DNS 记录。

要使 Cloudflare 能够控制访问，它必须位于应用程序前面，并为已成功通过身份验证的用户提供安全可靠的网络路由。应用程序访问请求首先到达 Cloudflare，在其中应用策略，如果成功，则将用户请求路由到应用程序。

Cloudflare 支持访问以下类型的应用程序：

• 互联网上的 SaaS 应用程序
• 通过公共主机名访问的自托管应用程序
• 通过私有 IP 访问的自托管应用程序

对于 SaaS 和其他面向 Internet 的应用程序，来自 Cloudflare 的访问很简单——它已经在 Internet 上。但是对于自托管应用程序，您可以创建从 Cloudflare 到运行该应用程序的专用网络的隧道。执行此操作有两种方法：

• 我们的推荐方法是使用 软件代理，例如 cloudflared 或 Cloudflare Mesh。（请注意，目前只有 cloudflared 支持将公共主机名代理到私有应用程序。）
• 对于基于网络的连接，Cloudflare WAN（以前称为 Magic WAN）使用 IPsec 或 GRE 隧道将 Cloudflare 连接到连接至私有网络的现有网络设备，如果您在 Cloudflare 运营的数据中心的服务器上运行应用程序，Network Interconnect 可以创建直接连接。（若要从现有的传统 VPN 解决方案迁移到基于网络的隧道，您可能会发现 本指南 很有用。）

一旦建立了与您的应用程序的连接，就该促进用户访问了。根据您的策略要求（稍后将详细介绍），用户可以通过 Internet 连接到公共主机名来直接访问应用程序，或者 — 为了更高的安全性 — 我们建议使用我们的 设备代理（Cloudflare One Client），该客户端可以直接创建通向 Cloudflare 的隧道，并提供有关其设备的信息以供在访问策略中使用。

应用程序访问的一个关键部分是对用户进行身份验证。Cloudflare 具有基于电子邮件的 内置身份验证 方法。但我们强烈建议配置第三方身份提供商 (IdP)。我们支持消费者和企业 身份提供商，并且可以使用任何符合 SAML 或 OpenID 的服务。组（Group）成员身份是定义应用程序访问最常见的属性之一，可以手动定义或使用跨域身份管理系统 (SCIM) 导入。

构建真正有效的访问策略的最后一个先决条件是配置 设备态势 (device posture)。当使用 设备代理 时，Cloudflare 可以访问有关设备的 各种信息，然后可以将这些信息用于访问策略。当使用 无代理方法 访问应用程序时，只有用户身份信息可用。我们还支持使用来自 其他供应商（例如 Microsoft、Crowdstrike 和 Sentinel One）的设备态势信息。

简要总结一下目前描述的架构，Cloudflare 是：

• 在对应用程序的网络访问前面。
• 与您的身份提供商集成。
• 了解您的用户正在使用我们的设备代理或第三方供应商所反映出的设备态势细节。

当用户发出访问应用程序的请求时，他们必须首先进行身份验证，然后，在授予访问权限之前，应用程序中的策略会根据与请求用户关联的数据进行评估。策略和其他特定于应用程序的设置在一个 Access 应用程序中定义。

Cloudflare Access 支持四种主要类型的应用程序：

• Self-hosted（自托管）：指您的组织在本地或云中托管和管理的应用程序。Cloudflare 创建了一个公共主机名，它使用该主机名通过安全隧道将流量代理到应用程序。虽然如果您的服务器只是面向互联网也是支持通过公共主机名访问的，但我们建议您使用 cloudflared 创建从应用程序到 Cloudflare 边缘的只出不进（outbound-only）的安全连接。发生这种情况后，Cloudflare 会将目标应用程序/内容反向代理给您的用户。
• Private IP（私有 IP）：应用程序也是私有托管的，但缺乏完全限定的公共主机名。可以通过 cloudflared、Cloudflare Mesh、Cloudflare WAN 或 Cloudflare Network Interconnect 促进访问。未连接到已与 Cloudflare 连接的网络的远程用户将需要使用设备客户端，通过私有 IP 获取对应用程序的访问权限，并且为避免使用户与 IP 地址打交道，可使用 内部 DNS 服务 将私有主机名解析为私有 IP 地址。但是，通过使用我们无代理的 浏览器隔离服务，也可以在未向客户端部署任何软件的情况下提供访问。
• SaaS：应用程序通过公共互联网访问，因此不需要连接到 Cloudflare 的任何隧道。相反，Access 充当用户和 SaaS 应用程序之间的身份代理。当用户尝试访问 SaaS 应用程序时，他们首先由 Cloudflare 进行身份验证，然后重定向到您的主身份服务。然后通过 SAML 或 OAuth 将 SaaS 应用程序配置为信任 Cloudflare。这使得组织能够实施额外的安全层（如设备态势检查）并集中对其 SaaS 应用程序的访问控制，即使 SaaS 或身份提供商本身不支持这些功能也是如此。
• Infrastructure（基础设施）：应用程序使用户能够控制对私有网络中各个服务器、集群或数据库的访问。基础设施应用程序通过定义经 cloudflared 代理的“目标”来工作，但允许用户将多台机器分组在同一目标下 - 本质上，允许用户跨潜在的不同基础架构资源定义通用的访问策略。内置的访问和命令记录功能意味着组织可以维护用于合规性和安全调查目的的详细审计跟踪。

Access 应用程序通常直接映射到单个应用程序。但是，可以有一个 Access 应用程序，其关联的策略位于多个应用程序端点之前。这可能是与您希望在其中实施通用访问策略的多个 Windows RDP 服务器相关的一系列 IP。同样的想法也可以应用于公共主机名，在那里您可能有多个主机名指向您希望拥有相同策略的几个应用程序。例如，您可能拥有 wiki.domain.com 和 wiki.domain.co.uk — 不同的应用程序实例，但具有常见的访问策略要求。

接下来，我们将研究 ZTNA 保护的应用程序的主要元素，为了创建有效的访问策略必须了解这些元素，稍后在本文档中我们将研究应用这些特定元素的一些用例。

验证用户身份是任何零信任策略的关键组成部分。尝试登录应用程序时，用户将被重定向到已配置的身份提供商 (IdP)。如果用户未能通过身份提供商的身份验证，Cloudflare 将不接受其对该应用程序的请求。

如上所述，Cloudflare 可以与所有身份提供商集成，包括企业和消费者。然后在应用程序和策略级别，您可以选择允许哪些 IdP 进行身份验证。例如，您可能拥有一个只有少数员工可以访问的应用程序。因此，您将仅启用您的企业 IdP。对于另一个应用程序，您可能希望允许更广泛的非员工用户（如承包商或第三方合作伙伴）访问。您可以通过他们的 GitHub 或 LinkedIn 凭证对其中一些用户进行身份验证。

当用户尝试访问应用程序时，系统会向他们显示登录页面，他们可以在其中选择使用哪个 IdP 进行身份验证。对于只有一个 IdP 的应用程序，您可以将用户自动重定向到该 IdP。还可以配置应用程序以显示已配置的每个可能的 IdP，从而允许您将来添加新的提供商，而无需更新策略。

身份验证后，IdP 会将有关身份的信息发送回 Cloudflare。根据 IdP 的不同，此信息可能包括 身份验证方法参考 (Authentication Method Reference) ↗ (amr) 值、IdP 组、SAML 属性或 OIDC 声明，这些信息随后可用于策略中。

当使用我们的设备代理时，用户还必须进行身份验证，并且可以向其显示自定义的 IdP 列表。代理经过身份验证后，他们能够连接到 Cloudflare，并且可以配置应用程序跳过身份验证，转而信任与设备代理关联的现有身份验证会话。

现在我们来到本指南的主要重点：定义应用程序访问的策略。这是真正进行定义谁能访问以及如何访问的工作所在。在查看示例用例之前，以下是策略如何工作的一项细分解析。

每个应用程序可以包含多个策略，并按顺序进行评估。由于多个策略（每个策略具有多组规则）可能会变得非常复杂，因此有一个策略测试器，您在其中提供用户名，即可查看针对所有策略和规则如何评估该用户。策略由以下元素组成：

虽然这个字段的用途很明显，但我们强烈建议您制定一种命名策略的方法。这是因为您很可能会在多个应用程序中创建类似的策略，例如“允许所有全职员工”或“阻止高风险用户”。在所有应用程序中使用相同的命名方案，将极大地简化您日后查看应用程序访问权限以及了解完整策略列表的能力。

策略中的 Action 字段决定了当用户或服务匹配该策略的条件时会发生什么。有四种主要类型的操作：

• Allow（允许） 授予对应用程序的访问权限。初始访问请求时，将向用户呈现登录页面。
• Block（阻止） 拒绝访问应用程序。通常不需要这样做，因为默认情况下 Access 是拒绝的。用户实施阻止策略的唯一原因是用于测试特定策略条件或短路策略评估。如果一个阻止策略的优先级高于允许策略，并且用户匹配了阻止策略，所有其他策略评估将停止。
• Bypass（绕过） 允许用户或服务在访问应用程序之前禁用对流量的任何强制执行。例如，应用程序中的特定端点可能需要在 Internet 上广泛访问。
• Service Auth（服务身份验证） 允许您使用 mTLS 或 服务令牌 (service tokens) 验证来自其他服务或应用程序的请求。如果用户或服务满足此策略标准，则不会向其显示登录页面。这样设计是为了让非用户请求（例如来自其他应用程序的请求）能够访问受保护的资源。

会话持续时间指的是用户成功登录到应用程序后其身份验证保持有效的时间长度。通常，会话持续时间设置为 24 小时，但您也可以为敏感应用程序将持续时间设置为立即过期。这种方法符合“从不信任，始终验证”的核心零信任原则。即使最初用户呈现了适当的设备态势和身份上下文，持续验证也能确保在每次新请求时重新评估访问权限。这种方法显著减少了风险窗口期，因为它消除了初始身份验证和授权状态在较长一段时间内仍然有效的假设。

这些是策略的主要重点。规则定义了所有指示策略是否允许或拒绝访问或在隔离浏览器中渲染应用程序的属性。它们由选择器和值组成，本质上即您希望评估的属性以及您正在评估的数据。

每个规则都是一个过滤器，用于确定此策略将影响哪些用户。有几类规则：

• Include（包含） 规则定义谁或什么有资格访问。当用户匹配“Include”规则时，他们将成为访问候选人，须遵守策略中的其他规则类型。这些规则使用 OR 逻辑——满足任何一个就足够了。例如，您可能将一个应用程序向一个特定的组开放，但需要为某个电子邮件列表添加承包商，只要用户匹配其中之一（组成员身份或有效的电子邮件），他们就会被包含在规则中。每个策略必须至少有一个 Include 子句。

• Require（要求） 规则设定了必须满足才能获得访问权限的强制性条件。与 Include 规则不同，“Require”规则使用 AND 逻辑——必须满足每一项规则。这通常用于在 Include 规则定义的基本访问标准之上叠加安全性。例如，管理员可以要求任何试图访问应用程序的人都必须使用特定的 MFA 方法。

• Exclude（排除） 规则定义了访问的例外，推翻了其他规则类型。如果用户匹配“Exclude”规则，则无论其他策略条件如何，都将被拒绝访问。例如，用户可能满足登录期间使用 MFA 方法的要求，但如果其特定的 多因素身份验证 (MFA) 方法 是定义在 Exclude 规则中，那么他们将被该策略阻止。或者，如果用户与一个“高风险”IdP 组关联，即使他们满足所有其他态势要求，也可以因此将其排除。

一种有用的方式来想象这几种不同类型的规则是如何应用的方法是将它们想象成一个漏斗。Include 选择器定义用户、流量或设备的哪些属性会被包含进策略以得到 Allow、Block 等处理。Require 然后进一步从该列表中过滤出该用户必须具有的关联属性，而使用 Exclude 类型则过滤掉已经同时匹配了 Include 和 Require 的用户身份。

上图可视化了“使用安全设备的采用强 MFA 的所有员工和承包商”策略的一个示例。“所有员工”组或使用其公司域中的用户名进行过身份验证的任何承包商将符合本策略中的第一条。要求（Require）他们使用的设备具有最新操作系统，并正在使用加密存储。他们必须使用某一种 MFA 因素进行了身份验证，但不允许使用 SMS (Exclude)。此外，他们还被要求必须是通过 Cloudflare 安全 Web 网关（SWG）访问该应用程序。

选择器类型有多种不同类型。虽然此处未列出每一种可能的选择器，但以下列出了使用 Cloudflare Access 的组织在构建策略时通常期望达到的特定结果。这将有助于您了解如何实现特定的目的。

• 用户流量是通过 Cloudflare Gateway 来的吗？ 保证用户仅通过我们的 SWG（Cloudflare Gateway）访问应用程序，是防止由于网络钓鱼或凭证被盗而造成未经授权访问的绝佳方法。此外，您可以确保发往应用程序的所有流量都被 Cloudflare Gateway 记录和过滤。

  您可以通过启用“gateway”设备态势检查并在应用程序策略中要求“gateway”来配置此控制。相较于仅依靠设备代理，要求“gateway”更为灵活，因为用户也可以通过浏览器隔离 (Browser Isolation) 或 Cloudflare WAN 连接网站（两者都提供流量记录和过滤功能）接入。另外，当使用设备代理时，这让您可以保证用户来自符合要求且通过了一组设备态势检查的设备。

  要求使用网关（gateway）是针对 自托管应用程序 进行持续执行的。对于 SaaS 应用程序，仅在登录时实施该要求。不过，专用出口 IP 可以串联使用，从而强制流量始终通过 Cloudflare Gateway 传输。

• 该用户是否属于现有组，或者是否具有特定的身份属性？ 如果您的 IdP 支持 SCIM，则可以将组成员身份信息导入 Cloudflare，然后可在策略中使用该信息。组信息也可以来自作为身份验证一部分发送的 SAML 或 OAuth 数据。实际上，当使用 OIDC 或 SAML 并发送声明 (claims) 时，它们可以在策略中使用。因此，如果您的用户使用 SAML 向您的 IDP 进行身份验证，并且结果令牌包含他们的“角色 (role)”，您便可以在规则中查询该值。

• 使用了哪种身份服务进行身份验证？ 类似于 IdP 组和属性，这个“Login methods（登录方法）”选择器查询使用了哪种身份服务，并且像 IdP 组一样，这更适合用于一个 Access 组，而不是访问策略上的特定规则项。登录方法允许您向使用特定身份提供商进行身份验证的特定用户应用不同的策略。例如，如果身份验证方法包含基于硬件令牌的 MFA，您可能仅允许使用消费者身份（如 GitHub 或 LinkedIn）进行身份验证的用户获得访问权限。

  这是一种非典型情况，但如果您确实需要启用多个 IdP 以进行身份验证，那么您可以使用此选择器以确保用户正在使用特定服务进行身份验证。当处理多层安全策略，并需要根据登录方式定义不同级别的访问权限时，这种要求的作用将变得更加清晰。

• 个人或组织电子邮件 所有身份服务均提供一个电子邮件地址，多数情况下该地址与个人用户名相匹配。当希望允许某个域的所有用户进行访问时，但在策略中使用电子邮件可能很有用，因为他们可能会通过允许任意电子邮件的消费者 IdP 进行身份验证。例如，您可能仅允许通过 GitHub 使用其 @company.com 电子邮件地址进行过身份验证的用户访问。

  这个选择器的另一个好用法是，如果您正在管理一个 电子邮件列表，这些用户可能属于高风险或者已被阻止访问特定应用程序。您可以使用 Exclude 规则与您的列表结合，以确保这部分用户不能访问应用程序。

• 用户是如何进行身份验证的？ 当身份提供商对用户进行身份验证，然后将他们重定向回 Cloudflare 时，它包含有关使用了何种身份验证方法的信息。这通常作为 身份验证方法参考 (Authentication Method Reference) ↗ 数据发送。使用它您可以检查是否使用了 MFA 以及使用的类型是什么。

  这可用于为不同应用程序定义不同级别的凭证要求。例如，一个一般的公司应用程序可能只要求使用了 MFA 而不关心方式。但一个极其敏感的管理工具可能会要求基于 FIDO2 硬件的安全密钥，并且在身份验证过程中如果仅通过 SMS 使用了一次性密码 (OTP)，则会明确拒绝对其访问。

• 请求来自哪个国家？ 您可以根据对传入请求进行地理位置查找来设置规则。这对于限制对您不开展业务的某些国家/地区的访问权限可能很有用。

• 请求来自哪个 IP 范围？ 您可以根据传入请求的 IP 范围来设置规则。例如可以仅允许从企业网络 IP 范围进行访问。

• 是否可以从列表中验证设备或用户信息？ 有时，您可能希望基于无法简洁归入其他类别的特定设备或用户特征来授予或限制访问权限。这就是 列表 (lists) 派上用场的地方：您可以定义或导入承包商电子邮件列表，或是批准的设备序列号列表，并在 Access 策略中将这些列表作为条件。这些列表可以手动更新或通过我们的 API 更新，允许与其他设备或用户管理系统集成。

• 设备的安全性是否足够？ 这就是设备客户端为提出访问请求的本地设备提供遥测数据的地方。它通过执行设备级别的扫描来完成。设备的硬盘加密了吗？代理可以检查像 BitLocker 或 FileVault 等技术是否处于激活状态，另外还可以检查特定的卷标。如果您要保护一个敏感的应用程序或容纳了关键信息的东西，这是一个可以强制实施的有效要求。

• 请求是由另一个进程或应用程序发起的吗？ 试图访问应用程序的并不总是在设备上的真实的人。这使得利用 Cloudflare Access 以管理其他软件对 API 的通信变得很有用。请求可以包含服务令牌 (service tokens)、双向 TLS 证书 (mutual TLS certificates) 以及 SSH 证书，从而启用了自动化过程和机器对机器通信的登录。在 Cloudflare 内使用服务验证选项，同时还将这些令牌和证书的存储与生命周期管理集中化。

• 您的第三方工具如何评价您的设备？ 许多组织使用用于端点安全的其他专业工具（例如 Crowdstrike，SentinelOne，或 Microsoft Intune），提供关于发起应用程序请求设备的安全性评估的遥测数据。相比于要求用户去浏览多个用户界面，您可以将这些工具通过它们的 API 集成到 Cloudflare One 中，并将它们对于设备状态属性的见解应用于在应用程序登录时进行强制执行。

以下是一些有助于提高安全性的附加应用程序设置。

有时，您想管理信任度较低的第三方用户（如承包商或合作伙伴）对于自托管应用程序的访问。您可能希望允许他们阅读应用程序中的内容，但限制他们下载文件、复制粘贴数据以及打印页面的能力。Cloudflare Access 允许您在一个远程 浏览器中渲染该应用程序（使用 远程浏览器隔离，或称为 RBI），使得程序在位于我们网络上的无头浏览器中进行渲染，而不是将所有内容下载到用户浏览器。这使得 Cloudflare 得以实施一系列对用户如何能与内容进行交互的控制手段。

该设置处于策略级别，因此一个策略可以允许可信用户（如员工）正常访问应用程序，而另一个启用了浏览器隔离的策略则对承包商应用 RBI 服务。

此设置会强制在向终端用户交付之前将流量路由到一个隔离的浏览器，这意味着所有流量随即受 Cloudflare Gateway 检查和管理。要限制用户可执行的操作，您需要在 Gateway 中创建一个附带的策略，其也将识别这些同样的用户并施加您期望用来限制访问的 控制。请注意，非常重要的一点是将 Gateway 策略编写成仅对访问 Cloudflare Access 策略适用的应用程序的那同一组用户施加 RBI。否则，该策略默认将强制隔离所有用户的浏览器。

如果同一组用户试图使用不安全的设备访问该应用程序，实际上也有可能对其强制应用 RBI。在这种情况下，您将继续在 Cloudflare Access 中为员工定义策略。但随后，也在 Cloudflare Gateway 中创建一个策略，以在访问相同应用程序 URL 的用户未通过一项认为设备不受管或不安全的设备状态检查时，通过它来隔离此应用程序。例如，当设备没有安装公司的终端安全客户端（例如 Crowdstrike 或 SentinelOne）或是并未通过某个安全核查，就可以运用此方法。我们将在下文的示例中说明这点。

相反，隔离浏览器也保护了本地设备免受尝试通过攻击应用程序漏洞或向应用程序执行恶意代码的人的威胁。

您可能想要审计应用程序的每个身份验证事件并捕获证明理由细节。此设置将创建更加明确的用户访问审计跟踪日志，并让管理员可以审查、分析访问的模式及理由。启用时，用户会被要求提供一份简单解释，随后再行赋予访问权限。这在特别是对特定敏感的应用程序或者是于比如常规营业时间段之外的特定的时间进行操作方面尤为具有相当高的有效性。

通过要求用户在访问应用程序前从指定授权人处获取“临时身份验证 (temporary authentication)”批准，从而加上了额外的访问控制层。此选项一旦启用，进行访问请求的用户即将会触发对获得授权的核准审批负责人发出提示或通知。

定义 ZTNA 策略最重要的部分之一是利用 Access 组 (Access Groups) 等可重用元素。每个 Access 组使用我们刚刚描述的相同规则来定义用户、流量或设备。这些组随后可在许多策略中使用，以允许、拒绝、绕过或隔离对应用程序的访问。

例如，您可以将“员工”定义为一次 Access 组，然后在每个需要引用员工的应用程序策略中使用它。对此 Access 组的更新将反映在每个策略中。这也是包含嵌套逻辑的好方法（例如，使用 Linux 设备且启用了防病毒软件的用户）。

下图展示了一个名为“Secure Administrators（安全管理员）”的 Access 组，它使用一系列属性来定义安全管理员的特征。该图还显示在“Secure Administrators”中添加了两个其他 Access 组。这些组包括运行最新 Windows 或 macOS 的设备，以及要求设备必须启用 File（文件）相关检查的要求。

既然保护应用程序访问的基础架构和策略体系已经介绍完毕，下面来看一些常见用例。

许多公司会托管某种内部内容系统，其中存放机密的公司信息。Wiki 是常见的一类应用程序，便于员工协作。但由于这些信息是机密的，因此使用强凭据验证用户身份，并确保他们通过安全设备和安全连接进行访问非常重要。

然而，有时公司用户需要使用非公司设备访问 wiki。您可能希望设置一个允许此操作但限制用户行为的策略。例如，防止他们编辑数据，或将其复制粘贴到未受管理的设备。本用例说明如何设置 Cloudflare Access 应用程序，为员工定义安全访问：在安全设备上通过安全连接时授予完整功能访问，同时仍允许从不安全设备进行有限访问。

首先，使用以下参数创建一个 Access 应用程序：

在我们研究如何定义这两个策略之前，先观察一个示例，其中创建了一个 Access 组以识别员工以及已批准的运行最新操作系统的设备。

此 Access 组将用于这两个策略，其唯一目标是识别什么是“安全员工”。

这是一个非常简单的 Access 组，仅包含两个组选择器。请注意，因为我们正在根据特定目录的组检查成员身份，这也意味着用户必须已对该目录进行了身份验证。这意味着在未来，如果您转移到另一个身份提供商，或者更改了构成全职员工定义的组成员身份要求，您只需更改此 Access 组一次即可。

如您所见，它定义了“所有员工”是 Azure AD 组“全职员工 (Full-Time Employees)”中同时也属于“已完成安全培训 (Completed security training)”组的人员。第一个选择器定义了 Access 组的初始范围，第二个选择器则要求他们也必须在该特定组中。

此 Access 组要求为 操作系统版本 创建三个 设备态势检查。例如，态势检查“最新版本的 macOS”被定义为“macOS 版本大于或等于 15.1”，这反映了公司认为稳定且安全的最新版本（相对于绝对最新发布的操作系统版本）。一旦包含在访问策略中，这将实施我们在此处建立的逻辑 - 如果有任何用户想要以“安全员工”的身份登录，他们将需要满足这些要求。

现在我们定义应用程序中的第一个策略。首先，选择已经定义的 Access 组。然后，定义以下规则以确定用户如何进行身份验证以及他们如何连接到应用程序。

此策略确保用户仅在通过了以下要求的情况下才能获得对贵公司 wiki 的完全访问权限：

• 他们是全职员工，使用具有最新操作系统的设备。
• 用户已经使用 MFA 进行了身份验证。
• 用户正通过运行 Cloudflare 设备代理的设备访问该应用程序。

第二个策略应处理未使用安全设备的用户。请注意，此策略在应用程序中的策略列表中排第二，因此当用户不满足第一个策略的要求时，将对其进行评估。

虽然这个策略与第一个策略非常相似，但它删除了必须具有最新操作系统以及要求使用我们的设备代理的要求。用户仍被要求必须是已通过可靠的、基于 MFA 支持的凭证进行了身份验证的全职员工。

但请注意，我们现在启用了“隔离应用程序 (Isolate Application)”。这意味着什么？这迫使发往该应用程序的所有请求现在都在我们的 RBI 技术上渲染。RBI 将防止 wiki 用户体验直接加载到终端用户的浏览器中，而是将内容在我们全球云网络上一台服务器中运行的无头浏览器内进行渲染。然后，该渲染的结果被安全、高效地向下传达到终端用户的浏览器。正因如此，该请求也是通过我们的 SWG 服务发送的，这使得您可以编写控制用户能够如何与该 wiki 进行交互的策略。

Gateway HTTP 策略

在上述例子中，SWG 策略匹配发往贵公司 wiki 的任何流量，然后实施 RBI（以与 ZTNA 应用程序策略相匹配），随后禁用所有与 wiki 的交互。

它还添加了设备态势检查“WARP 检查 (Mac OS) (WARP Check (Mac OS))”来扫描用户的设备以确认是否存在我们的设备代理。如果用户的设备未安装并启用该代理，则无法进行设备态势检查，且他们将自动无法满足策略要求。如果用户确实启用了设备代理，则他们将通过该态势检查并被授予对 wiki 的完全访问权。请注意，“WARP”是 Cloudflare One Client 之前的名称，后者是 Cloudflare 的设备代理。

从本质上讲，使用不安全设备的员工被允许以“只读”模式查看 wiki，但受到进一步交互的限制，如不能上传/下载或复制/粘贴机密信息。

这种策略方法达到了几个目标：

1. 它强制使用受信任设备才能获取对 wiki 的完全访问权限，这符合您的零信任安全目标。
2. 它为使用个人设备的员工提供了回退选项，允许他们通过浏览器隔离以一种受限、安全的方式访问 wiki。
3. 它激励员工使用他们的公司设备和/或保持 Cloudflare One Client 启用状态，这对于组织的安全态势具有净正向作用。
4. 它展示了通过将 Cloudflare Access 策略与 Cloudflare Gateway HTTP 策略相结合以实现更为细粒度安全控制的强大与灵活。

这种方法不仅保护了您的 wiki，而且为保护其他应用程序确立了模型——使您的组织能够保持良好的网络健康状态，同时适应混合办公方案的实际情况。

第二个用例实施了一项也要求使用设备客户端的安全访问策略。然而，该实施比之前的 wiki 示例略微复杂。

在具体说明之前，您将了解通过 Cloudflare 保护对 SaaS 应用程序的访问的好处。毕竟，Salesforce 和其他主要 SaaS 提供商已经提供了强大的安全功能，包括它们自己的访问控制、MFA 和审计日志。那为什么有些组织仍然选择通过 Cloudflare 路由其 SaaS 流量呢？

这里的关键好处是在整个 IT 生态系统中集中化安全策略执行。通过将 Salesforce 访问通过 Cloudflare 路由，您不仅保护了 Salesforce – 您还将它集成到一个更为广泛的零信任战略中，该战略包含针对所有用户活动提供单一的可见性立足点，并减少了管理多个安全系统的复杂性。这也允许您为访问单一 SaaS 应用程序实施来自于不同 IdP 的访问控制。

在此用例中，保护 Salesforce 免遭滥用非常重要，因为它包含敏感客户数据；将访问权限限制为授权用户同样关键。我们将设计一项策略，同时满足这两项安全目标。

第一步，在 Cloudflare Gateway 下配置 出口 IP 策略。这允许您购买并分配专用 IP，并将用户流量通过 Gateway 过滤。然后在 Salesforce 中，您可以强制仅允许源 IP 与出口策略中配置的 IP 匹配的流量进行访问。这种组合确保通往 Salesforce 的唯一访问路径经过 Cloudflare。

这对于保护对 Salesforce 的访问不仅重要，同时在其使用期间进行妥善保护也同样意义重大。下一步将检视这个访问策略，它类似于我们刚为 wiki 创建的策略。不过，此项策略将访问限制在 Sales（销售）或 Executives（高管）组成员。我们还使用 Crowdstrike 集成以确保用户在公司受管的设备上。

第二项策略现在适用于全体员工，但在授予访问权限之前，我们还需要增加几个步骤。

我们要在第二个策略里加入临时身份验证 (temporary authentication)。这意味着如果 Cloudflare 确定传入的请求来自 Sales（销售）或 Executives（高管）部门之外的人员，那么一名管理员将必须明确授予他们临时访问权限。在这种上下文中，此策略可用于为销售部门以外的员工提供受保护的 Salesforce 访问权限，因为客户信息可能是敏感并需要保密的。

这种方法很重要，原因如下：

• 它允许对潜在的高风险访问尝试进行人工监管，降低通过不安全或受破坏设备造成未经授权访问的几率。
• 它为合法用户提供了灵活性——即使设备未达到最高安全标准，仍可访问应用程序。这鼓励用户在其设备上维持良好的安全实践。
• 此外，由于所有用户流量都通过 Cloudflare 路由，我们还可以通过 Web 流量策略强制执行额外安全措施（例如阻止下载敏感数据）。

此场景涵盖保护 PostgreSQL 数据库管理工具。由于它可以访问敏感数据，它是由私有方式托管的高价值目标，设计其安全访问需要格外谨慎。考虑到数据库工具的性质，此用例不会采用前面示例中的分层策略堆叠方式。

在这里，我们引入了相当数量的安全态势检查，从 MFA 开始。我们有两个关于 MFA 的表达式：第一条要求用户必须使用至少一种 MFA 方式进行身份验证。第二条是一个“排除 (excludes)”表达式，明确指出 SMS 不能视为合法的有效身份验证方法。之所以这样做，是因为 SMS 是攻击者较容易利用和攻破的方式之一，并因此 它被认为不如其他 MFA 方法安全 ↗。因此，只有当用户提供了更强大的凭据（例如硬件密钥或来自身份验证应用的一次性密码）后，才允许访问。执行这些更严格的 MFA 要求将极大地降低基于凭证的攻击风险，并使潜在攻击者更难未经授权访问这一关键数据库——即便他们已获得了用户密码。

其他态势要素还包括：

• 要求最新的 OS 系统。
• 用户的设备已加入 Microsoft Active Directory 域。
• 用户的设备明确是受公司管理的设备（通过参考受管理设备序列号列表来显示）。

这些组合态势检查进一步确保只有最新的、位于您受管理环境中的、受公司控制的设备才能访问该数据库，进一步减少攻击面以及从潜在受损或不受控端点发起访问的风险。

在附加设置下，我们还要求用户输入访问该数据库的目的和正当理由。这使您的安全团队能够分析访问模式并识别潜在可疑行为。这组安全控制还可以确保对您关键数据库的访问受到严格监管、记录和证明——显著降低未经授权访问或滥用的风险。

这种级别的保护和可见性，若使用分散的独立安全解决方案来实现，将变得极为复杂且耗费资源。通过 Cloudflare 集中执行安全策略，您可以简化如何对关键内部资源实施细粒度访问。

最后一个用例重点关注通过两种方式（自托管或私有 IP）保护对设备的 RDP 远程访问。这两种选项各具优势，但最终取决于您的优先事项：简化访问更重要，还是密切监控活动更重要？

先从自托管选项开始 — 通过隧道代理端口 3389，并将其映射到主机名。

定义策略：

在策略内部，我们已将此应用程序提供给 IT 管理员新设的访问组。在“要求 (Require)”下，我们强制使用 Cloudflare One 客户端（而不是仅要求使用 Cloudflare Gateway）。用户必须在受公司管理的设备上，运行活动的客户端，并且对公司的 Cloudflare 实例进行了身份验证，在登录期间必须使用 MFA，而在下面还有一个外部评估选项。

外部评估 (External evaluation) 意味着我们有一个 API 端点，其中包含某些类型的 访问逻辑 ↗ — 本例中是基于时间的访问控制。我们将调用该 API 端点，并定义 Cloudflare 用于验证响应来自该 API 的密钥。这在很多方面都有用：外部评估允许用户基于无法涵盖在默认态势检查范围内的标准去创建自定义检查，例如通过基于 Cloudflare Workers 的服务去验证当天的时间从而仅在工作时间允许访问 RDP，这缩短了潜在攻击者有机会下手的空窗期。

现在，作为私有 IP 应用安全 RDP 的配置：

由于私有 IP 应用依靠 Cloudflare 将 IP 范围代理到网络上，因此该应用自然需通过连接客户端通过客户端到隧道的连通来解析那些非本地的 RFC 1918 路由地址。

在此配置它很简单，因为填入了 IP，限制为 RDP 3389 端口。而此处的网络策略规则中不能直接选择外部评估和 MFA 等部分访问选项，因为这些选项可以在用户开启客户端向组织进行认证登录时就被统一要求满足。 强制会话在此有其作用：经过一定时间后用户须重验证。在零信任之下，即使证书被盗，持续不断的强验证也将使得攻击窗口被死死限流在重验证时间内。

结合精确粒度控制及活动审计，Cloudflare 将为该类资源的运用带来巨大防护提升。

成功的 ZTNA 实施不仅仅是技术配置——它需要仔细考虑您组织的特定需求、用户工作流和安全要求。Cloudflare 的灵活性允许您从基本的安全访问策略开始，然后随着组织需求的变化和安全要求的成熟而不断发展它们。遵循本指南中概述的原则和实践，您可以创建一个强大的安全态势，在透明地提供保护的同时实现精准防护。

相关资源：

• Cloudflare SASE 参考架构
• 在 Microsoft 中使用 Cloudflare SASE
• 如何部署 Cloudflare ZTNA