使用 Cloudflare 演进到 SASE 架构

下载此参考架构的 PDF 版本。

Cloudflare One 是一个安全访问服务边缘 (SASE) 平台，可保护企业应用程序、用户、设备和网络。通过逐步采用 Cloudflare One，组织可以摆脱零碎的硬件设备和其他单点解决方案，转而在一个统一的控制平面上整合安全和网络功能。这种网络和安全转型有助于解决现代企业面临的关键挑战，包括：

• 通过 Zero Trust 实践保护任何用户对任何资源的访问
• 防御网络威胁，包括多渠道钓鱼和勒索软件攻击
• 保护数据以满足合规要求并防止泄漏
• 简化办公室、数据中心和云环境之间的连接

Cloudflare One 构建于 Cloudflare 的连接云（connectivity cloud） ↗之上，这是一个由可编程云原生服务组成的统一、智能的平台，可实现所有网络（企业网络和互联网）、云环境、应用程序和用户之间的任意对任意连接。它是全球最大的网络之一 ↗，数据中心遍布全球数百个城市 ↗，并与 over 13,000 network peers 互联。与许多其他大型科技公司相比，它在核心互联网交换中心 ↗的参与度也更高。

因此，Cloudflare 的运营范围在世界约 95% 的互联网连接人口的约 50 毫秒以内。由于所有 Cloudflare 服务都设计为在每个网络位置运行，所有流量都在靠近源头的地方进行连接、检测和过滤，从而提供最佳性能和一致的用户体验。

本文档描述了致力于实现 SASE 架构的组织的参考架构，并展示了 Cloudflare One 如何实现这种安全和网络转型。

本参考架构专为对组织现有基础设施负有一定责任或有所了解的 IT 或安全专业人员设计。如果对确保混合工作安全的重要技术有一定经验，那将会非常有用，包括身份提供商 (IdP)、用户目录、单点登录 (SSO)、终端安全或管理 (EPP, XDR, UEM, MDM)、防火墙、路由器，以及诸如数据包或内容检测硬件、威胁防御和数据防泄漏技术等单点解决方案。

为了对 Cloudflare 建立更强大的基础性了解，我们建议参考以下资源：

• 什么是 Cloudflare？ | 网站 ↗（需 5 分钟阅读）或 视频 ↗（2 分钟）

• 解决方案简报：Cloudflare One ↗（3 分钟阅读）
• 白皮书：Overview of Internet-Native SASE Architecture ↗（10 分钟阅读）
• 博客：Zero Trust, SASE, and SSE: foundational concepts for your next-generation network ↗（14 分钟阅读）

阅读本参考架构的读者将了解到：

• Cloudflare One 如何保护组织的员工、设备、应用程序、数据和网络
• Cloudflare One 如何融入您现有的基础设施，以及如何进行向 SASE 架构的迁移
• 如何规划部署 Cloudflare One

虽然本文档从技术层面探讨了 Cloudflare One，但它并未提供平台中每种产品的详细信息。相反，它着眼于 Cloudflare One 中的所有服务如何使网络和网络安全整合在同一个架构上。访问开发者文档以获取特定于产品领域或用例的更多信息。

传统上，大多数员工在办公室工作，并通过以太网或 Wi-Fi 本地连接到公司网络。大多数业务系统（例如文件服务器、打印机、应用程序）都位于该内部网络上，并且只能从中访问。一旦连接，用户通常会对本地资源拥有广泛的访问权限。网络周围创建了一个安全边界，以抵御来自外部的威胁，其中大多数威胁来自公共互联网。大多数业务工作负载都托管在本地，并且只能在网络内部访问，互联网上几乎没有或完全没有公司数据或应用程序。

然而，三个重要趋势给这种 IT 安全的“城堡加护城河”方法带来了问题：

1. 员工的流动性更强。组织越来越多地接受远程/混合办公，并支持使用个人（即非公司所有）设备。
2. 云迁移加速。组织正在将应用程序、数据和基础设施从昂贵的本地数据中心迁移到公共或私有云环境，以提高灵活性、可扩展性和成本效益。
3. 网络威胁在演变。上述趋势扩大了组织的攻击面。例如，攻击活动变得更加复杂和持久，利用多个渠道渗透组织，并且随着“网络犯罪即服务”（cybercrime-as-a-service）黑市的流行，网络犯罪分子的准入门槛降低了。

传统的基于边界的安全很难适应这些变化。特别是，将“护城河”向外延伸给管理员带来了运营复杂性，给用户带来了糟糕的体验，并且在用户和应用程序之间应用安全控制的方式上产生了不一致。

上图显示了这种经过调整的基于边界的方法的示例，其中防火墙、WAN 路由器和 VPN 集中器与由 MPLS 电路和/或专线组成的专用 WAN 接入（on-ramps）混合连接。该图还展示了常见的问题领域。为了使策略集中化，组织有时会强制所有员工的互联网流量通过其 VPN 基础设施，这会导致浏览缓慢并引起用户抱怨。然后，员工会寻求解决方法——例如使用未经批准的设备——这增加了他们在家中或在公共 Wi-Fi 上工作时遭受来自互联网的攻击的风险。此外，由于网络基础设施的复杂性，IT 团队无法快速响应不断变化的业务需求。

这些挑战促使许多组织优先考虑以下目标：

• 通过支持具有安全任意对任意访问的远程/混合办公来加速业务敏捷性
• 通过简化策略管理和优化用户体验来提高生产力
• 通过保护所有渠道中的用户和数据免受网络钓鱼、勒索软件和其他威胁来降低网络风险
• 整合网络和安全方面的可见性与控制
• 通过替换昂贵的设备和基础设施（例如 VPN、硬件防火墙和 MPLS 连接）来降低成本

近年来，安全访问服务边缘 ↗（SASE）已成为帮助实现这些目标的一种理想架构。在 SASE 架构中，网络连接和安全统一在单个云平台和控制平面上，以便为从任何用户到任何应用程序的连接提供一致的可见性、控制和体验。

SASE 平台由网络和安全服务组成，并由底层的运营服务和策略引擎提供支持：

• 网络服务将来自各种网络的流量转发到单个全球公司网络中。这些服务提供防火墙、路由和负载均衡等功能。
• 安全服务应用于流经网络的流量，从而允许对某些类型的流量进行过滤，并控制谁可以访问什么内容。
• 运营服务提供平台范围的功能，如日志记录、API 访问，以及通过 Terraform 等提供程序提供的全面基础设施即代码支持。
• 策略引擎集成了所有服务，允许管理员定义策略，然后将其应用于所有连接的服务。

大多数组织都是逐步迈向 SASE 架构，而不是一蹴而就，他们会优先考虑关键的安全和连接使用案例，并采用像 Zero Trust 网络访问 (ZTNA) 或 安全 Web 网关 (SWG) 这样的服务。一些组织选择使用来自多个厂商的 SASE 服务。然而，对于大多数组织来说，他们的愿望是将安全巩固在单个厂商，以实现简化的管理、全面的可见性和一致的体验。

Cloudflare One ↗ 是一个单厂商的 SASE 平台，其中所有的服务都设计为在所有位置运行。所有的流量都在距离其源头最近的地方进行检测，从而在各地提供一致的速度和规模。由于采用了模块化且灵活的接入方式，流量可以从任何源头路由到任何目的地。

Cloudflare 的连接云还提供了许多其他可以提高应用程序性能和安全性的服务，例如 API Gateway ↗、Web Application Firewall ↗ (WAF)、Content Delivery ↗ (CDN) 或 DDoS mitigation ↗，所有这些都可以补充组织的 SASE 架构。例如，我们的内容分发网络（CDN）功能可用于提高自托管公司内部网的性能。Cloudflare 的全套服务如下图所示。

Cloudflare 的 SASE 平台受益于我们对 anycast ↗ 技术的使用。Anycast 允许 Cloudflare 从全球的每一个数据中心播发我们服务的 IP 地址，因此流量总是路由到离源头最近的 Cloudflare 数据中心。这意味着流量检测、身份验证和策略执行都在靠近最终用户的地方进行，从而带来持续的高质量体验。

使用 anycast 可以确保 Cloudflare 网络良好平衡。如果网络上的流量突然增加，负载可以分布到多个数据中心，这反过来有助于为用户维持一致且可靠的连接。此外，Cloudflare 庞大的网络容量 ↗以及 AI/ML-optimized smart routing ↗ 也有助于确保性能得到持续优化。

相比之下，许多其他 SASE 提供商使用单播（Unicast）路由，其中单个 IP 地址与单个服务器和/或数据中心相关联。在许多此类架构中，单个 IP 地址随后与特定应用程序相关联，这意味着访问该应用程序的请求可能会产生非常不同的网络路由体验，具体取决于该流量需要传输多远。例如，对于在靠近应用程序服务器的办公室工作的员工，性能可能会非常好，但对于远程员工或在海外工作的员工，性能可能会很差。单播还使扩展流量负载变得复杂——当负载增加时，该单个服务位置必须增加资源，而 anycast 网络可以在许多数据中心和地理区域共享流量。

要了解 SASE 如何融入组织的 IT 基础设施，请参阅下图，该图描绘了所述基础设施的所有常见组件。本指南的后续部分将对该图进行补充，展示 Cloudflare 的 SASE 平台的每个部分在其中的位置。

在图的上半部分，有各种互联网资源（例如 Facebook）、SaaS 应用程序（例如 ServiceNow）以及运行在基础设施即服务 (IaaS) ↗ 平台（例如 AWS）中的应用程序。作为 Zero Trust 计划的一部分，此示例组织已经部署了基于云的身份提供商 ↗ (IdP)、统一终端管理 ↗ (UEM) 和终端保护平台 (EPP)。

在下半部分，是各种用户、设备、网络和位置。用户在不同的位置工作：家中、总部和分支机构、机场等。他们使用的设备可能是由组织托管的，也可能是个人设备。除了云端之外，应用程序还运行在组织总部的数据中心以及数据中心运营商的托管设施（本例中为 Equinix ↗）中。

SASE 架构将定义、保护和简化图中的每个用户和设备与各种资源的连接方式。在接下来的章节中，本指南将展示将 Cloudflare One 集成到上述基础设施中的方法：

• 应用程序和服务：将对私有应用程序和服务的访问置于 Cloudflare 之后
• 网络：将整个网络连接到 Cloudflare
• 转发设备流量：方便从任何设备访问受 Cloudflare 保护的资源
• 验证用户和设备：识别访问请求来自哪些用户，以及这些用户拥有哪些设备

迈向 SASE 架构的这一旅程始于组织需要为非面向互联网的、仅内部的 Web 应用程序和服务（例如 SSH 或 RDP）提供远程访问。组织通常部署 VPN 设备来将用户连接到托管应用程序的公司网络。然而，现在许多应用程序都位于云端基础设施即服务平台中，传统的 VPN 解决方案在这些平台中很难配置。这往往导致用户在应用程序和连接性能上面临糟糕的体验。

Zero Trust 网络访问 (ZTNA) 是一种保护对自托管应用程序和服务访问的 SASE 服务。ZTNA 功能大致可以分为两类：1) 在 Cloudflare 的网络与运行应用程序的环境之间建立连接；2) 设置策略以定义用户如何访问这些应用程序。在本节中，我们首先探讨前者——如何将应用程序连接到 Cloudflare。

与自托管应用程序的连接是通过软件连接器 cloudflared 创建和维护的隧道来实现的。cloudflared 是安装在组织基础设施中的轻量级守护程序，它通过与 Cloudflare 全球网络的出站连接创建隧道。该连接器可以通过多种方式安装：

• 安装在裸机服务器上的操作系统中
• 运行在虚拟化环境中的操作系统中
• 运行在 Docker 或 Kubernetes 环境中的容器 ↗中

cloudflared 在 Windows、Linux 或 macOS 操作系统上运行，并使用 QUIC 创建加密隧道。QUIC 是一种使用 UDP（而非 TCP）的现代协议，可提供快速的隧道性能和现代加密标准。一般而言，用户在其环境中部署 cloudflared 有两种方法：

1. 在运行应用程序或服务的同一台服务器和操作系统上。这通常用于高风险或合规性部署，在这些部署中，组织要求每个应用程序都有独立的隧道。cloudflared 消耗少量的 CPU 和 RAM，因此对服务器性能的影响微乎其微。
2. 在运行应用程序的同一网络中的专用服务器上。这通常采用 Docker 或 Kubernetes 环境中多个容器的形式。

cloudflared 管理返回 Cloudflare 的多个出站连接，通常不需要更改网络防火墙。出于可靠性和故障转移的考虑，这些连接分布在多个 Cloudflare 数据中心的服务器上。去往隧道的流量会被转发到在地理位置上最靠近该请求的连接，如果某个 cloudflared 连接未响应，隧道将自动故障转移到下一个可用的连接。

为了更好地控制通过每个隧道连接路由的流量，用户可以与 Cloudflare 负载均衡（load balancing）服务进行集成。为确保可靠的本地连接，组织应该在其应用程序基础设施中部署多个 cloudflared 实例。例如，如果有十个运行在 Kubernetes 集群中的前端 Web 服务器，您可能会部署三个运行 cloudflared 副本的 Kubernetes 服务。

一旦建立了隧道，将用户流量转发到您的应用程序或服务有两种方法。下面的每种方法都受到 ZTNA 服务管理的策略的保护，该服务强制执行身份验证和访问（本文档后文将对此进行深入探讨）。

每个公共主机名都特定于与私有应用程序关联的地址、协议和端口，从而在同一主机上可能运行多个应用程序时，允许对特定服务的狭窄访问。

例如，组织可以定义一个公共主机名 (mywebapp.domain.com) 来提供对运行在 https://localhost:8080 上的 Web 服务器的访问，同时确保无法访问本地 Kubernetes 服务。

关键能力：

• 在公共 DNS 区域中创建一个主机名，所有对该主机名的请求首先会被路由到 Cloudflare 网络，根据配置的安全和访问策略进行检测，然后通过隧道路由到受保护的私有资源。
• 每个隧道可以定义多个主机名，每个主机名映射到一个应用程序（服务地址和端口）
• 支持 HTTP/HTTPS 协议
• 访问资源仅需要浏览器
• 当 Cloudflare 的设备客户端部署在用户设备上时，策略可以在执行过程中利用额外的上下文信号（例如，确定设备是否是托管的或运行最新的操作系统）
• 对于访问 SSH/VNC 服务，Cloudflare 在浏览器中使用 WebAssembly 渲染 SSH/VNC 终端

通过这种方式公开的应用程序可获得 Cloudflare 领先的 DNS、CDN 和 DDoS 服务以及我们的 Web 应用程序防火墙（WAF）、API 和机器人（Bot）服务的所有优势，且无需将应用程序服务器直接暴露于互联网。

在某些情况下，用户可能希望利用 ZTNA 策略来提供对整个私有网络上许多应用程序的访问。这使得客户端连接方式以及服务的公开方式具有更大的灵活性。它还允许通过 HTTP 以外的协议与资源进行通信。在这种情况下，用户需指定希望通过 Cloudflare 访问的私有网络子网。

关键能力：

• cloudflared 与 Cloudflare 设备代理结合使用，提供对私有网络的访问，允许任意 L4 TCP、UDP 或 ICMP 连接
• 可以使用 CIDR 表示法配置一个或多个网络（例如 172.21.0.16/28）
• 访问私有网络上的资源需要客户端上安装有 Cloudflare 设备代理，且连接网络上至少有一个 Cloudflare Tunnel 服务器

对于这两种方法，重要的是要注意 cloudflared 仅代理入站流量到私有应用程序或网络。对于它代理入站连接的网络，它不会成为返回 Cloudflare 的网关或“接入（on-ramp）”。这意味着，如果 Web 服务器启动其自身到另一个基于互联网的 API 的连接，该连接将不会通过 Cloudflare Tunnel 进行路由，而是将通过主机的默认网关和路由进行路由。

这在大多数网络拓扑中是理想的结果，但在某些情况下，网络服务需要直接与远程连接的用户或与其他细分网络上的服务进行通信。

如果用户要求将源自服务器或网络的连接通过 Cloudflare 进行路由，有多种接入方式可以实现这一点，这将在“连接网络”部分进行进一步说明。

SaaS 应用程序本质上总是连接到公共互联网并可通过其进行访问。因此，前述的隧道和应用连接器方法并不适用。相反，具有 SASE 架构的组织会通过用作云原生正向代理的安全 Web 网关 ↗（SWG）来检测流向互联网的 SaaS 流量并对其执行策略。

SWG 包含相关策略，用于检查出站流量请求和入站内容响应，以确定用户、设备或网络位置是否可以访问互联网上的资源。组织可以使用这些策略来控制对获批 SaaS 应用程序的访问，以及检测和阻止使用未获批的应用程序（也称为影子 IT ↗）。

一些 SaaS 应用程序允许组织配置 IP 地址允许列表，这会根据请求的源 IP 地址来限制对该应用程序的访问。通过 Cloudflare，组织可以获得专用的出口 IP（egress IP）地址，这些地址可用作离开其网络的所有流量的源地址。当与 SaaS 应用程序中的允许列表结合使用时，组织可以确保用户只有在首先连接到 Cloudflare 的情况下才能访问该应用程序。（关于该方法的更多细节在后面关于连接用户设备的部分中进行了概述。）

另一种保护对 SaaS 应用程序访问的方法是配置单点登录（SSO），使 Cloudflare 在身份验证和授权过程中充当身份代理——充当身份提供商（IdP）绑定。

关键能力：

• 在自托管和 SaaS 应用程序之间应用一致的访问策略
• 将设备安全姿态层融入身份验证过程（例如，用户可以确保只有运行最新操作系统并通过所有终端安全检查的托管设备才能访问 SaaS 应用程序）
• 确保使用特定的网络路由进行访问（例如，用户可以要求设备使用设备代理连接到 Cloudflare，这允许他们过滤到 SaaS 应用程序的流量并防止下载受保护的数据）
• 将 SSO 应用程序集中到 Cloudflare，并创建从 Cloudflare 到其 IdP 的单一 SSO 集成——使基础设施和访问策略与 SSO 无关（例如，用户可以允许仅在启用多因素身份验证 (MFA) 时才能访问关键应用程序，无论使用哪个 IdP 进行身份验证）

当 Cloudflare 充当应用程序的 SSO 服务时，用户身份验证仍由组织现有的身份提供商处理，但会通过 Cloudflare 进行代理，以便在 Cloudflare 中应用额外的访问限制。下图是一个典型请求流程的高级示例：

将 SaaS 应用程序连接到 Cloudflare 的 SASE 架构的最后一种方法是使用基于 API 的云访问安全代理 ↗ (CASB)。Cloudflare CASB 通过 API 与常见的 SaaS 套件（包括 Google Workspace、Microsoft 365、Salesforce 等）进行集成，并持续扫描这些应用程序，以查找配置错误、未授权的用户活动以及其他安全风险。

与 Cloudflare 数据防泄漏（DLP） ↗服务的原生集成使 CASB 能够扫描可能存储在权限不正确的文件中的敏感或受监管数据——从而进一步降低泄露或未经授权访问的风险。CASB 会报告调查结果，提醒 IT 团队注意以下事项：

• 未配置充分 MFA 的管理员账户
• 存储为公开访问权限的文件中包含公司敏感数据
• 缺失应用程序配置（例如，域名缺失 SPF/DMARC 记录）

整合 Cloudflare 服务后，典型组织的网络架构可能如下所示。请注意，Cloudflare 的设计旨在通过以下方式保护组织现有的应用程序和服务：

• 所有的自托管应用程序和服务只能通过 Cloudflare 访问，并受 Cloudflare ZTNA 定义的策略控制
• SaaS 应用程序流量通过 Cloudflare SWG 进行过滤和保护
• SaaS 服务通过 Cloudflare CASB 扫描，以检查静态数据的配置和权限

一旦集成了组织的应用程序和服务，就是时候将 Cloudflare 连接到其现有的网络了。区域办事处、公司总部、零售店、数据中心和云托管基础设施都需要将流量转发到新的公司 SASE 网络。

当所有流量流经 Cloudflare 时，SASE 服务将执行以下操作：

• 授予应用程序访问权限
• 过滤流向互联网的通用流量（例如，阻止访问托管恶意软件的网站）
• 隔离网站以保护用户免受零日（day-zero）或未知的有害互联网内容的侵害
• 过滤流量以识别 DLP 策略定义的数据——然后阻止将这些数据下载/上传到不安全的设备或应用程序
• 提供对使用未经批准的应用程序的可见性，并允许管理员阻止使用或针对这些应用的使用应用策略

将网络连接到 Cloudflare 有几种方法，这为组织提供受 SASE 保护的资源的访问方式提供了进一步的灵活性：

1. 使用软件代理创建从主机回源到 Cloudflare 的隧道。这通常是拥有自己服务器和应用程序的用户所青睐的方法。
2. 在网络路由器和防火墙上设置 IPsec 或 GRE 隧道，将其连接到 Cloudflare WAN 服务。这是网络管理员在需要转发进出整个网络的流量时所采用的方法。
3. 将网络直接连接到 Cloudflare。当组织的网络位于支持的数据中心（通常是与 Cloudflare 数据中心在同一托管位置的数据中心）时，此方法最有效。

这些方法将在下一节中进行进一步说明。

根据网络上当前存在的应用程序类型，有两种基于软件的将网络连接到 Cloudflare 的方法。

如前一节所述，cloudflared 代理到私有网络上的应用程序和服务的请求。它安装在私有网络的服务器中，并通过互联网创建与 Cloudflare 的安全隧道。出于可靠性考量，这些连接在多个 Cloudflare 数据中心之间进行平衡，并可以通过多个连接器进行建立，这有助于提高隧道的容量。

使用 cloudflared，Cloudflare Tunnel 支持通过隧道建立客户端到服务器的连接。在发起出站连接时，运行在隧道后面的任何服务或应用程序都将使用默认路由表。

这一模型适用于大多数场景，即外部用户需要访问私有网络内的资源，而无需发起双向发起的通信。

对于双向或网状（meshed）连接，组织应使用 Cloudflare Mesh。

Cloudflare Mesh（旧称 WARP Connector）是一个轻量级的解决方案，用于站点对站点、双向和网状网络连接，而无需更改底层网络路由基础设施。Cloudflare Mesh 安装在组织网络内的 Linux 服务器上，该服务器随后成为其他需要将流量接入 Cloudflare 的本地网络的网关。

这提供了一个轻量级的解决方案来支持微软的 System Center Configuration Manager (SCCM)、Active Directory 服务器更新、VOIP 和 SIP 流量，以及具有复杂 CI/CD 流水线交互的开发人员工作流。它既可以作为 cloudflared 和 Cloudflare WAN（旧称 Magic WAN）的补充运行，也可以作为连接到 Cloudflare 网络的独立远程访问和站点对站点连接器。

Cloudflare Mesh 既可以代理用户到网络和网络到网络的连接，也可以用于建立运营商级 NAT（CGNAT ↗）寻址端点的叠加网络，以便使用 CGNAT IP 范围提供与已建资源的物理或逻辑直接安全连接。这有助于解决重叠网络 IP 范围的挑战、单点解决方案访问问题，或者在不影响更大底层系统的情况下进行网络设计的转变。

注意：此图中的标签可能反映了旧的产品名称。

通过 cloudflared 建立的 Cloudflare Tunnel 是将用户连接到私有网络上应用程序和服务的主要方法，因为对于许多应用程序所有者而言，它是一种更简单、更细粒度且更敏捷的解决方案（与基于 IP 隧道的连接技术，如 IPsec ↗ 和 GRE ↗ 相比）。当组织不想更改底层网络路由或边缘基础设施时，Cloudflare Mesh 是用于网状网或其他软件定义网络（大部分需要双向连接）的首选方法。

在安装软件代理不理想或不可能的情况下，也可以使用现有的网络设备（如路由器和网络防火墙）将网络连接到 Cloudflare。为此，组织可以创建连接到 Cloudflare 的云原生 Cloudflare WAN ↗ 服务的 IPsec 或 GRE 隧道。通过 Cloudflare WAN，现有的网络硬件可以通过以下方式将流量从其各自的网络位置连接并路由到 Cloudflare：a) 通过互联网建立基于 IPsec 的安全隧道，或者 b) 跨 Cloudflare Network Interconnect ↗ (CNI)——连接现有网络位置到最近的 Cloudflare 数据中心的私有直接连接。

Cloudflare 的 WAN 服务使用“轻分支、重云（light-branch, heavy-cloud）”架构，这代表了软件定义 WAN（SD-WAN）连接的演变。通过 Cloudflare WAN（如下网络架构图所示），Cloudflare 全球网络作为一个集中管理的连接中心，在所有现有网络位置之间安全高效地路由流量：

如前所述，Cloudflare 使用称为 anycast ↗ 的路由技术在全球范围内播发 Cloudflare 网络上的所有服务和端点，包括 WAN IP 隧道的端点。

通过 anycast IPsec ↗ 或 anycast GRE 隧道，从组织的网络设备（例如边缘路由器、防火墙设备等）配置的每个隧道都连接到 数百个全球 Cloudflare 数据中心。源自组织网络位置的流量直接通过这些隧道发送，并始终路由到最近的活跃 Cloudflare 数据中心。如果最近的 Cloudflare 数据中心不可用，流量会自动重新路由到次近的数据中心。

为了进一步提高网络韧性，Cloudflare WAN 还支持 Cloudflare 网络与组织的网络位置之间的等价多路径路由（ECMP）。通过 ECMP，流量可以在多个 anycast IP 隧道之间进行负载均衡，这有助于提高吞吐量并使网络可靠性最大化。在一条或多条隧道发生网络路径故障时，流量可以自动故障转移到其余健康的隧道。

将现有网络位置接入 Cloudflare WAN 服务的最简单、最容易的方法是部署 Cloudflare One Appliance，这是一种轻量级设备，您可以将其安装在公司网络位置，以通过安全的 IPsec 隧道自动连接、引导和整形任何 IP 流量。当 WAN Connector 安装到网络中时，它将自动建立与 Cloudflare 网络的通信，下载并配置相关的设置，建立具有弹性的 IPsec 隧道，并将连接的站点网络流量路由到 Cloudflare。

WAN Connector 既可以部署为硬件设备，也可以部署为虚拟设备，从而使其适用于各种用户网络环境——本地、虚拟或公共云。WAN Connector 的管理、配置、可见性和软件更新可通过仪表板或 Cloudflare API 从 Cloudflare 进行集中管理。截至 2023 年，WAN Connector 目前最适合将中小型网络连接到 Cloudflare（例如小型办公室和零售店）。

在部署 Cloudflare One Appliance 不可行或不理想的情况下，组织可以通过配置其现有的具备 IPsec 功能的网络设备（包括 WAN 或 SD-WAN 路由器、防火墙和云 VPN 网关）的 IPsec 隧道，安全地将其站点网络连接到 Cloudflare。请参阅 Cloudflare 文档以获取经过验证的 IPsec 设备的最新示例。

也可能存在不需要网络层加密的情况——例如，当站点的去往 WAN 流量已经在应用层（通过 TLS）进行了加密，或者当 IPsec network 设备在加密和解密 IPsec 流量时提供的吞吐量性能非常有限时。在这种情况下，组织可以使用 GRE 隧道连接到 Cloudflare 网络。

组织还可以通过 Cloudflare Network Interconnect ↗ (CNI) 将其网络位置直接连接到 Cloudflare 网络。Cloudflare 支持多种选项来将您的网络连接到 Cloudflare：

• 用于 Cloudflare WAN 和 Magic Transit 的 Direct CNI
• 用于 Magic Transit 的 Classic CNI
• 用于 Cloudflare WAN 和 Magic Transit 的 Cloud CNI
• 通过互联网交换中心（IX）或私有网络互联（PNI）进行对等互联。

下表总结了将网络连接到 Cloudflare 的不同方法：

这些连接和路由流量的方法都可以从任何位置同时部署。下图突出了在单个架构中如何使用不同的连接方法。

注意以下流量走向：

• 通过 Cloudflare Mesh 节点或设备代理连接的所有流量都可以通过网状网络相互通信
  • 在家工作的开发人员可以与云端生产和暂存（staging）网络进行通信
  • 零售店的员工以及在家工作的开发人员可以在其笔记本电脑上接收 VOIP 呼叫
• AWS 中的 HPC 集群代表了一种无法安装第三方软件代理的专有解决方案；因此，它使用到 Cloudflare WAN 的 IPsec 连接
• 在零售店位置，Cloudflare One Appliance 通过 IPsec 隧道将所有流量路由到 Cloudflare
  • 运行设备代理的员工笔记本电脑创建了其自己与 Cloudflare 的安全连接，并通过该 IPsec 隧道进行路由
• 报告系统的应用程序所有者使用 cloudflared 维持与 Cloudflare 的连接，不需要任何网络方面的协助来向员工公开其应用程序

注意：此图中的标签可能反映了旧的产品名称。

一旦网络、应用程序和用户设备连接到 Cloudflare——无论使用何种连接方法和设备——所有流量都可以由 Cloudflare SASE 服务进行检测、身份验证和过滤，然后安全地路由到其预期目的地。此外，无论流量如何到达 Cloudflare，都可以在所有流量上应用一致的策略。

现在，这就是来自各处的公司网络流量都被转发到 Cloudflare 并由其处理的 SASE 架构。在该架构中，可以从任何远程位置、办公室位置或数据中心建立网络连接，并连接到位于 SaaS 基础设施、云托管基础设施或组织自己的本地数据中心中的应用程序和服务。

注意：此图中的标签可能反映了旧的产品名称。

前面的部分解释了使用 ZTNA 来保护对自托管应用程序的访问，以及使用 SWG 来检测和过滤去往互联网的流量。当用户在连接到 Cloudflare 连接云的任何公司网络中的设备上工作时，所有这些流量都会被检测，并且策略会在不中断用户工作流的情况下应用。然而，用户并不总是（或根本不）在办公室里；他们在家里、旅途中或其他公共网络中工作。您如何确保他们对您的内部应用程序拥有可靠的访问权限？您如何确保无论他们的工作地点如何，他们的互联网浏览都是安全的？

有几种方法可以确保未连接到现有受 Cloudflare 保护的网络的用户设备的流量也能通过 Cloudflare 转发并受到保护。

• 在设备上安装代理
• 修改浏览器代理配置
• 引导用户到远程浏览器实例
• 修改 DNS 配置

确保设备流量转发到 Cloudflare 的首选方法是安装设备代理（也称为 Cloudflare One Client）。该代理运行在 Windows、macOS、Linux、iOS 和 Android/ChromeOS 上，并创建到 Cloudflare 的安全连接，所有非本地流量都会发送至该连接。由于 Cloudflare 使用 anycast 网络，设备代理始终连接到最近的 Cloudflare 服务器，以确保为用户提供最佳性能。设备代理还会收集本地计算机和网络信息，这些信息会在请求中发送，以丰富 Cloudflare 中的策略。

为了使不同设备和用户的连接方式更具灵活性，我们提供了多种部署模式：

• 完整的 L4 流量代理
• L7 DNS 代理
• L7 HTTP 代理
• 仅收集设备姿态（posture）信息的能力

例如，组织可能有一个办公室继续使用现有的 DNS 过滤（DNS filtering） ↗服务，因此他们可以配置代理以仅代理网络和 HTTP 流量。

还可以配置具有灵活路由控制的代理，以允许将发往办公室打印机的流量不发送到 Cloudflare 网络，而是路由到本地网络。这些分流隧道配置（split tunnel configurations）可以特定于用户组、设备操作系统类型或网络，并且默认情况下，发往所有私有 IPv4 和 IPv6 范围 ↗的流量都会发送到设备的默认网关。如果用户试图访问的应用程序不在公共 DNS 中，您可以配置主机名和域名以使用本地 DNS 服务进行解析，以便设备代理不会尝试使用 Cloudflare DNS 解析这些域名。

该代理不仅仅是一个网络代理；它还能够检测设备的安全姿态，例如操作系统是否已完全更新或硬盘是否已加密。Cloudflare 与 CrowdStrike ↗、SentinelOne ↗ 以及其他第三方服务的集成也提供了有关设备安全姿态的额外数据。所有这些信息都与每个请求相关联，因此可用于公司策略——如“统一管理”部分所述。

可以手动或使用现有的终端管理（UEM）技术将代理部署到设备。使用该代理，用户可以通过集成的身份提供商向 Cloudflare 注册并验证其设备。身份信息与有关本地设备的信息结合使用，随后用于您的 SWG 和 ZTNA 策略（包括在这两个 Cloudflare 服务之间共享的内联 CASB 功能）。

当无法在设备上安装软件时，还有免代理的方法。

一种选择是通过在浏览器或操作系统中配置代理服务器详细信息，使浏览器将 HTTP 请求转发给 Cloudflare。虽然这可以手动完成，但组织更常见的是使用互联网托管的代理自动配置 (PAC) 文件来自动配置浏览器代理设置。浏览器通过几种方式识别 PAC 文件位置：

• MDM 软件在浏览器中配置该设置
• 在 Windows 域中，组策略对象 (GPO) 可以配置浏览器的 PAC 文件
• 浏览器可以使用Web 代理自动发现 ↗ (WPAD)

然后，配置浏览器将发送所有 HTTP 请求到的代理端点。如果使用此方法，请注意：

• 过滤 HTTPS 流量还需要在设备上安装并信任 Cloudflare 根证书。
• 代理端点将仅代理源自一组已知 IP 地址的流量，例如管理员必须指定的站点 NAT 网关使用的公共 IP 地址池。

确保将设备流量发送到 Cloudflare 的另一个选择是使用远程浏览器隔离 ↗ (RBI)。当远程用户尝试访问网站时，相应的请求和响应由在 Cloudflare 网络中运行的无头远程浏览器处理，该浏览器作为用户设备本地浏览器的“克隆”运行。这保护了用户的设备免受可能从其访问的网站下载的潜在有害内容和代码执行的危害。

RBI 在隔离且安全的云环境中渲染接收到的内容。用户设备不是在本地执行 Web 内容，而是通过所有操作系统上所有符合 HTML5 标准的浏览器均支持的高度优化协议接收如何“绘制”最终网页的命令。由于远程浏览器在 Cloudflare 的服务器上运行，SWG 策略会自动应用于所有浏览器请求。

确保对网站的访问受到 RBI 保护不需要在本地安装任何软件或重新配置用户的浏览器。以下是实现此目的的几种方式：

• 通常，远程浏览器会话是作为 SWG 策略的结果启动的——用户只需请求网站，而无需收到内容正在远程浏览器中加载的通知。
• 组织还可以为用户提供一个链接，以自动确保 RBI 始终处理每个请求。
• 组织也可以选择使用 ZTNA 服务，通过 RBI 实例重定向来自自托管应用程序的所有流量。

通过远程浏览器的所有请求都会通过 Cloudflare SWG；因此，策略可以强制执行某些网站访问限制。例如，可以建立浏览器隔离策略以：

• 禁用远程网页与用户本地计算机之间的复制/粘贴；这可以防止员工将专有代码粘贴到第三方聊天机器人中。
• 禁用远程 Web 内容的打印，以防止外包商打印机密信息
• 禁用文件上传/下载，以确保敏感的公司数据不会发送到特定网站或从特定网站下载。
• 禁用键盘输入（结合其他策略）以限制数据暴露，例如有人在网络钓鱼网站上输入密码。

隔离 Web 应用程序并对风险网站应用策略有助于组织限制因网络威胁或用户错误导致的数据丢失。并且，与许多 Cloudflare One 功能一样，RBI 可以在 SASE 架构的其他领域得到利用。例如，Cloudflare 的电子邮件安全 ↗服务可以自动重写并隔离电子邮件中的可疑链接。这种“电子邮件链接隔离”功能有助于保护用户免受潜在的恶意活动（如凭据窃取钓鱼）的侵害。

通过 Cloudflare 网络保护流量的另一个选择是配置设备将 DNS 流量转发给 Cloudflare，以进行检测和过滤。首先创建 DNS 位置，这允许根据不同的网络位置应用策略。它们可以根据请求的源 IP 地址来确定，或者您可以使用“DNS over TLS ↗”或“DNS over HTTPS ↗”。

当使用源 IP 地址时，要么需要告诉设备使用哪些 DNS 服务器，要么设备连接到的网络上的本地 DNS 服务器需要将所有 DNS 查询转发给 Cloudflare。对于 DNS over TLS 或 HTTPS 支持，设备需要进行配置，并且支持情况各不相同。我们的建议是使用具有更广泛操作系统支持的 DNS over HTTPS。

上述所有方法仅导致 DNS 请求——而非所有流量——发送给 Cloudflare。然后在此级别实施 SWG DNS 策略以管理对公司网络资源的访问。

下表总结了向 Cloudflare 转发流量的各种方法的 SWG 功能（截至 2023 年 10 月）：

注：

1. 在 DNS over HTTP 模式下运行设备代理除了提供与通过 DNS 连接相同的能力外，还提供用户身份信息。
2. 要过滤 HTTPS 流量，需要在每个设备上安装 Cloudflare 证书。这在使用设备代理时可以自动完成。
3. 如果配置了 DNS over HTTPS，可以将 服务令牌（service token） 注入到请求中，从而将查询与已验证的用户相关联。

通过连接整个网络或单个设备，组织现在可以将用户流量路由到 Cloudflare，以安全地访问私有托管的应用程序并确保安全的公共互联网访问。

一旦来自所有用户设备的流量都转发到 Cloudflare 网络，组织就可以重新审视其高级 SASE 架构：

注意：此图中的标签可能反映了旧的产品名称。

在实施 SASE 架构的这一点上，组织有能力对流量进行路由和保护，即从用户设备上的浏览器发出请求的那一刻起，一路穿过 Cloudflare 的网络，到达公司托管的私有应用程序/服务或公共互联网。

但是，在组织定义策略来管理该访问之前，他们需要知道是谁发起了请求并确定设备的安全姿态。

任何访问决策的第一步都是确定是谁发起了请求——即对用户进行身份验证。

Cloudflare 与身份提供商（IdP）集成，这些提供商为组织员工、外包商、合作伙伴和其他用户管理对资源的安全访问。这包括支持与任何符合 SAML 或 OpenID Connect (OIDC) 标准的服务的集成；Cloudflare One 还包括与 Okta、Microsoft Entra ID（前身为 Azure Active Directory）、Google Workspace，以及诸如 Facebook、GitHub 和 LinkedIn 等个人 IdP 的预构建集成。

可以集成多个 IdP，允许组织对广泛的内部和外部用户应用策略。当用户尝试访问受 Cloudflare 保护的应用程序或服务时，他们会被重定向以通过集成的 IdP 之一进行身份验证。使用设备代理时，用户也必须向其组织配置的 IdP 之一进行身份验证。

一旦用户通过身份验证，Cloudflare 就会收到该用户的信息，例如用户名、组内成员关系、身份验证方法（密码、是否涉及 MFA 以及何种类型）以及其他相关属性（即用户的角色、部门或办公室位置）。来自 IdP 的这些信息随后会提供给策略引擎。

除了用户身份外，大多数公司目录还包含这些身份所属的组。Cloudflare 支持导入组信息，然后将其用作策略的一部分。组内成员关系是汇总单个身份以使策略不那么复杂的关键部分。例如，设置一项允许销售部门的所有员工访问 Salesforce 的策略，要比识别销售部门中的每个用户要容易得多。

Cloudflare 还支持通常不与人类用户关联的设备的身份验证——例如监控工厂天气状况的 IoT 设备。对于这些安全连接，组织可以生成服务令牌（service tokens）或创建 Mutual TLS ↗ (mTLS) 证书，这些证书可以部署到此类设备或机器应用程序中。

不仅需要验证用户身份，还需要评估用户设备的安全姿态。设备代理能够提供一系列设备信息，Cloudflare 使用这些信息来构建全面的安全策略。

以下是可用的内置姿态检测：

• 应用检测：检测特定的应用程序进程是否正在运行
• 文件检测：检测文件是否存在
• 防火墙：检测防火墙是否正在运行
• 磁盘加密：检测磁盘是否已加密/有多少个磁盘已加密
• 加入域：检测设备是否已加入 Microsoft Active Directory 域
• 操作系统版本：检测正在运行的操作系统版本
• 唯一客户端 ID：在使用 MDM 时，组织也可以为移动、台式机或笔记本电脑设备分配可验证的 UUID
• 设备序列号：检测设备序列号是否与公司台式机/笔记本电脑的列表相匹配

Cloudflare One 还可以与任何已部署的终端安全解决方案集成，例如 Microsoft Endpoint Manager、Tanium、Carbon Black、CrowdStrike、SentinelOne 等。来自这些产品的任何数据都可以传递给 Cloudflare，以便在访问决策中使用。

上述所有设备信息，结合关于用户身份以及设备所在网络的数据，都可以在 Cloudflare 中使用，作为公司策略的一部分。例如，组织可以选择仅在满足以下所有条件时才允许管理员 SSH 到服务器：他们的设备无威胁、运行最新的操作系统并已加入公司域。

由于该信息对每个网络请求都是可用的，因此每当设备姿态发生变化时，其连接组织资源的能力就会立即受到影响。

电子邮件——许多组织的首要沟通工具，也是网络钓鱼攻击发生最频繁的渠道——是另一个应通过 SASE 架构进行保护的重要企业资源。网络钓鱼是导致财务损失和品牌损害的 90% 以上数据泄露的根本原因。

Cloudflare 的电子邮件安全服务在恶意内容或附件到达收件箱之前对其进行扫描，并主动在互联网上扫描攻击者基础设施和攻击交付机制，寻找用作计划攻击一部分来托管内容的编程创建域名。我们的服务利用所有这些数据来抵御商业和供应商电子邮件泄露（BEC ↗ / VEC ↗），这些攻击由于缺乏有效载荷并且能够看起来像合法的电子邮件流量而出了名地难以检测。

与其部署隧道来管理和控制流向电子邮件服务器的流量，不如使用 Cloudflare 提供的两种电子邮件安全配置方法：

• Inline：通过修改 MX 记录，在所有入站电子邮件流量到达用户收件箱之前将其重定向通过 Cloudflare
• API：将 Cloudflare 直接与 Microsoft 365 或 Gmail 等电子邮件提供商集成

修改 MX 记录（内联部署）会强制所有入站电子邮件流量通过我们的云电子邮件安全服务，在其中进行扫描，如果发现是恶意的，则会阻止其到达用户的收件箱。因为该服务在 MX 记录级别工作，所以它可以与任何符合 SMTP ↗ 标准的电子邮件服务配合使用。

组织也可以选择通过 API 直接将电子邮件安全与他们的电子邮件服务集成。请注意，此方法有两个缺点：Cloudflare 支持的集成较少，并且在电子邮件传送到服务与 Cloudflare 通过 API 检测到它之间总是存在短暂的延迟。

上述步骤提供了使用 Cloudflare One 演进到 SASE 架构的完整视图。如下文图所示，对所有私有应用程序、服务和网络的安全访问——以及确保用户通用互联网访问的安全——现在已应用于组织中的所有用户，无论是内部用户还是外部用户。

注意：此图中的标签可能反映了旧的产品名称。

为方便使用，整个 Cloudflare One 平台都可以通过 API 进行配置；通过 Cloudflare 的 Terraform 提供程序 ↗，组织可以使用他们用来使其余基础设施自动化的相同工具来管理 Cloudflare 全球网络。这使 IT 团队能够使用代码全面管理其 Cloudflare One 基础设施，包括下一节中详述的所有策略。截至 2023 年 10 月，还有 500 多个 GitHub ↗ 存储库，其中许多允许 IT 团队使用和构建工具来管理其 Cloudflare 部署。

现在所有用户、设备、应用程序、网络和其他组件都已无缝集成在 SASE 架构中，Cloudflare One 为全面管理提供了一个集中平台。由于 Cloudflare 在整个 IT 基础设施中拥有的可见性，Cloudflare 可以汇总来自各种源（包括设备、用户和网络）的信号。这些信号可以为创建管理组织资源访问权限的策略提供信息。

在我们详细介绍如何编写策略来管理对连接到 Cloudflare 的应用程序、服务和网络的访问之前，有必要看看 Cloudflare 的 SASE 平台中控制访问的两个主要执行点：SWG 和 ZTNA 服务。这些服务通过单个管理仪表板进行配置，从而简化了整个 SASE 部署中的策略管理。

下图说明了请求流经这些服务的过程，包括策略的应用以及这些策略的数据源。在下图中，根据所请求服务的类型，用户请求可以通过 SWG 或 ZTNA 进入。也可以结合使用这两种服务，例如实施一个 SWG HTTP 策略，该策略使用 DLP 服务来检测与 ZTNA Cloudflare Tunnel 后面的私有托管应用程序相关的流量。此配置使组织能够阻止从组织已授权外部访问的内部应用程序下载敏感数据。

在以下章节中，我们将介绍如何配置不同策略以满足特定使用案例的示例。虽然这些示例并非详尽无遗，但目的是展示配置 Cloudflare One 以解决组织在转型到 SASE 架构过程中遇到的挑战的常用方法。

将 IdP 连接到 Cloudflare 可以基于组内成员关系、身份验证方法或特定用户属性等因素做出访问决策。Cloudflare 的设备代理还为策略考虑提供了额外的信号，例如评估操作系统或对照公司托管设备验证设备的序列号。然而，还有一些功能允许用户将额外的数据引入部署中以构建强大的策略。

Cloudflare 庞大的智能网络持续监控数十亿个 Web 资产，并根据我们的威胁情报和对互联网内容的常规知识对它们进行分类。您可以使用我们的免费 Cloudflare Radar ↗ 服务来检查可能适用于任何特定域的分类。策略随后可以包括这些分类，以阻止公共互联网上的已知和潜在安全风险，以及特定类别的内容。

此外，Cloudflare 的 SWG 提供了创建和维护自定义数据列表的灵活性。这些列表可以通过 CSV 文件上传、手动维护，或者使用 Cloudflare API 与其他过程和应用程序集成。列表可以包含以下数据：

• URL
• 主机名
• 序列号 (macOS, Windows, Linux)
• 电子邮件
• IP 地址
• 设备 ID (iOS, Android)

例如，组织可以维护所有远程办公室位置的 IP 地址列表、短期外包商的电子邮件地址列表或受信任的公司域名列表。这些列表可用于策略中，如果外包商的流量来自已知的办公室 IP 地址，则允许他们访问特定应用程序。

Cloudflare 会分析请求的各个方面，包括源 IP、请求的域以及发起请求的已身份验证用户的身份。Cloudflare 还提供 DLP 服务，该服务能够根据敏感内容的存在来检测和阻止请求。该服务针对常见数据类型（如财务信息、个人身份信息 (PII) 和 API 密钥）内置了 DLP 配置（profiles）账户。

甚至还有针对源代码的配置，因此用户可以检测并阻止 C++ 或 Python 文件的传输。组织可以创建自定义的 DLP 配置并使用正则表达式来定义他们寻找的数据模式。对于难以定义模式的数据，可以使用匹配确切数据值的数据集。这些数据集允许批量上传要匹配的任何数据，例如客户账户 ID 列表或敏感项目名称。这些配置和数据集可以合并到策略中，以防止用户下载包含机密客户数据的大型文件。

为了降低误报风险，内部用户可以选择在配置中建立匹配次数。这意味着在触发该配置之前，数据中需要有特定数量的匹配项。这种方法可以防止由于类似于 PII 或信用卡号的随机字符串不必要地触发配置的情况。通过实施匹配次数，策略要求多个数据元素与配置相匹配，从而显著提高了其准确性。

组织还可以通过启用上下文分析来进一步提高 DLP 配置的准确性。此功能要求在匹配的大约 1000 个字符内存在某些邻近关键字。例如，字符串“123-45-6789”仅在靠近诸如“ssn”之类的关键字时才会被计为检测。这种上下文要求增强了检测过程的准确性。

DLP 服务与 Cloudflare 的 SWG 和 API 驱动的 CASB 服务无缝集成。在 API CASB 的情况下，会选择 DLP 配置来扫描与每个 SaaS 应用程序的每次集成。这种自定义允许根据您希望在每个应用程序中保护的数据类型来量身定制检测标准。

对于 SWG 服务，DLP 配置可以包含在任何策略中，以检测通过网关的任何请求中是否存在敏感数据。与该检测关联的最常见操作是阻止该请求，从而提供坚实的安全保护。

访问组是 ZTNA 服务中的一个强大工具，用于将用户或设备汇总为一个统一的实体，并在策略中引用该实体。在 Cloudflare 中，可以将多条信息合并到单个访问组中，从而在多个策略中高效地重用数据，同时将其维护在一个集中位置。

考虑一个旨在管理对关键服务器基础设施的访问的访问组。该访问组也可以用在设备代理策略中，以阻止管理员停用其与 Cloudflare 的连接。这种方法简化了策略管理，并确保了不同策略实现之间的一致性。

下图展示了一个名为“Secure Administrators”的访问组，该组使用一系列属性来定义安全管理员的特征。该图显示了在“Secure Administrators”中添加另外两个访问组。这些组包括运行最新 Windows 或 macOS 的设备，以及设备必须启用 File Vault 或 Bitlocker 的要求。

与 Cloudflare 强大的灵活性一致，访问组可以通过 Cloudflare API 或使用 Terraform 进行创建、更新并应用于策略。这允许与现有 IT 系统和流程无缝集成，从而确保采取凝聚性的方法来进行访问管理。

现在我们对所有可用组件有了可靠的了解，让我们放大视角，看看一些常见的使用案例以及它们是如何配置的。请记住，Cloudflare 的策略引擎非常强大且灵活，因此这些示例仅展示了 Cloudflare SASE 平台能力冰山一角。

转向 SASE 架构的一个常见驱动因素是用更灵活、更安全的解决方案来替代现有的 VPN 连接。Cloudflare One SASE 架构允许从世界任何地方高性能且安全地访问自托管应用程序。然而，下一步需要定义控制资源访问的策略。

在本例中，考虑两种服务：数据库管理应用程序（例如 pgadmin ↗）和运行在数据库服务器上的 SSH 守护程序。下图展示了流量的流向并突出了 ZTNA 服务。重要的是要注意，所有其他服务仍保留检测请求的能力。例如，在德国使用个人手机的外包商应该只能访问数据库管理工具，而在托管设备上的员工则可以访问数据库管理工具并 SSH 进入数据库服务器。

允许访问的策略依赖于两个访问组。

• 外包商
  • 通过 Okta 进行身份验证并且属于标为“Contractors”的 Okta 组的用户
  • 身份验证要求使用硬件令牌
• 数据库和 IT 管理员
  • 通过 Okta 进行身份验证并且属于 Okta 组“IT administrators”或“Database administrators”的用户
  • 身份验证要求使用硬件令牌
  • 用户所用设备序列号应存在于“Managed Devices”列表中

然后将这两个组用于两个不同的访问策略中。

• 数据库管理工具访问
  • 允许数据库和 IT 管理员访问
  • 允许“Contractor”访问组的成员访问，但每个经过身份验证的会话都要求用户填写理由请求
  • 该管理工具在 Cloudflare 边缘网络上的隔离浏览器中进行渲染，并且禁用了文件下载
• 数据库服务器 SSH 访问
  • 允许“Database and IT administrators”（数据库和 IT 管理员）组访问
  • 其设备必须通过至少 80 分的 CrowdStrike 风险评分
  • 访问必须来自运行了我们的设备代理并已连接到 Cloudflare 的设备

这些策略表明，外包商仅被允许访问数据库管理工具，对服务器没有 SSH 访问权限。IT 和数据库管理员只有在其设备通过设备代理安全地连接到 Cloudflare 时，才能访问 SSH 服务。对于每次登录，访问组和策略的每个元素都会进行评估，因此使用受损笔记本电脑的 IT 管理员或无法使用硬件令牌进行身份验证的外包商将被拒绝访问。

这两个用户组都将通过 Cloudflare 全球分布的网络中最近且最快的访问点连接到 Cloudflare，从而为所有用户带来高质量的体验，无论他们身在何处。

使用 SASE 解决方案的另一个原因是在组织中的所有用户（无论他们是员工还是外包商）之间一致地应用公司安全策略，无论他们在哪里工作。Cloudflare One SASE 架构显示，所有用户流量，无论是直接在设备上路由还是通过连接的网络路由，都将通过 Cloudflare。然后，Cloudflare 的 SWG 处理该流量的检测。根据连接方法，策略可以应用于 HTTP 或 DNS 请求。例如：

随后这可以在一个策略中应用于保护所有用户。Cloudflare 还可以编写另一项策略，允许访问社交媒体网站，同时将所有会话隔离在托管于 Cloudflare 网络的远程浏览器中。

通过此设置，对社交媒体网站的每次请求都能确保以下安全措施：

• 阻止社交媒体网站上包含的任何有害代码在本地设备上执行
• 限制外部用户从该网站下载可能感染了恶意软件或间谍软件的内容

由于 Cloudflare One 能够看清每一个网络请求，因此 Cloudflare 可以创建适用于请求中数据的策略。这意味着可以使用 DLP 服务来检测从应用程序下载的内容，并针对特定用户群体阻止该下载。让我们来看看以下策略。

该策略将阻止外包商下载包含客户账户信息的文件。此外，如果用户的设备不满足特定的安全姿态要求，Cloudflare 可以配置额外的策略来阻止同样的下载。这确保了一项共同规则的一致执行：不能将敏感的客户数据下载到不符合所需安全标准的设备上。

DLP 策略也可以应用于另一个方向，以确保公司的敏感文档不会被上传到未经批准的云存储或社交媒体。

在迈向 SASE 的旅程中的这一点上，用户已经重新构建了 IT 网络和安全基础设施，以充分利用 Cloudflare One SASE 平台的所有功能。长期部署中的一个关键要素是建立对组织的完整可见性，以及诊断和快速解决问题的能力。

为了进行快速分析，Cloudflare 提供了内置的仪表板和分析功能，可提供部署运行状态的每日概览。随着流量流经 Cloudflare，仪表板将向内部用户警示最常用的 SaaS 应用程序，从而在外部用户访问任何未经授权的应用程序时使管理员能够采取快速行动。此外，来自所有 Cloudflare One 服务的所有日志信息都可以从管理员仪表板进行访问和搜索。这使得过滤特定被阻止的请求变得高效，每条日志都包含有用的信息，例如用户的身份、设备信息以及触发阻止的具体规则。这在部署的早期阶段非常方便，因为那时规则通常需要进行微调。

然而，许多组织依赖现有的专用工具来对其实施基础设施的性能进行长期可见性管理。为了支持这一点，Cloudflare 允许将所有日志信息导出到这些工具中。Cloudflare One 的方方面面都会被记录并可以导出。Cloudflare 提供了内置集成，用于将小批量数据持续传输到各种平台，包括 AWS、Google Cloud Storage、SumoLogic、Azure、Splunk、Datadog 以及任何兼容 S3 的服务。这种灵活性允许组织有选择地挑选哪些字段，以控制并纳入现有工具的数据类型和数据量。

除了与流量和策略相关的日志之外，归根结底，Cloudflare 还会对管理活动进行审计。所有管理操作以及对 Cloudflare Tunnel 的更改都会被记录。这允许进行变更管理审计，并且与所有其他日志一样，可以将其导出到其他工具中，作为更广泛变更管理监控解决方案的一部分。

Cloudflare 对互联网以及连接的网络和设备的性能拥有深刻的见解 ↗。这些知识使 IT 管理员能够了解其最终用户每分钟的体验，从而能够迅速解决影响生产力的突发问题。

数字体验监控（DEM）服务使 IT 能够针对用户设备运行持续测试，以确定与公司资源连接的质量。这些测试的结果可在 Cloudflare One 仪表板上获得，从而使 IT 管理员能够在特定用户遇到访问应用程序的困难时审查并识别根本原因。这些问题可能源于用户的本地 ISP 或特定的性能不佳的 SaaS 服务提供商。这些数据对于帮助管理员诊断和解决糟糕的用户体验非常宝贵，从而可以更快地解决问题。

仪表板显示了整个设备群的综合摘要，展示了所有组织设备的实时和历史连接指标。IT 管理员随后可以深入了解特定设备以进行进一步分析。

在全面了解了 Cloudflare 的 SASE 平台之后，您现在已经做好了将其与现有基础设施集成的充分准备。该系统高效地保护了员工和外部用户对应用程序的访问，从设备上的初始请求开始，延伸到每个网络，直到抵达应用程序（无论其位于何处）。这一用于保护网络、应用程序、设备和用户的强大新模型构建在庞大的 Cloudflare 网络之上，并通过直观的管理界面进行管理。

值得注意的是，本文档中描述的许多功能都可以免费使用（最多支持 50 个用户），没有任何时间限制。注册 ↗一个账户，然后前往 Cloudflare One ↗ 区域仪表板。虽然本文档提供了该平台的整体概览，但对于那些有兴趣深入了解特定领域的读者，我们建议探索以下资源。

如果您想更详细地讨论您的 SASE 需求并与我们的架构师联系，请访问 https://www.cloudflare.com/cloudflare-one/ ↗ 并申请咨询。