ZTXGate vs Cloudflare Access
ZTXGate 和 Cloudflare Access 都可以为私有应用提供身份感知访问，但它们建立在非常不同的运行模式之上。
Cloudflare Access 属于一套广泛的云交付安全平台；ZTXGate 则是由客户或 MSP 运营的 ZTNA 平台，可以在无需强制 CoreZT 托管控制平面的情况下运行，包括完全隔离环境。
快速对比
| 领域 | ZTXGate | Cloudflare Access |
|---|---|---|
| 核心管理/控制 | 由客户或 MSP 运营的 ZTXGate 部署 | 由 Cloudflare 运营的 Zero Trust / SASE 平台 |
| 私有侧组件 | ZTXGate 网关/代理 | cloudflared Tunnel 及其他 Cloudflare 连接组件 |
| 受管终端访问 | 基于 WireGuard 的访问 | Cloudflare One Client / 私有网络访问机制 |
| 无客户端 Web 访问 | 许可式 HTTP/HTTPS 代理能力 | 通过 Access 和 Tunnel 从浏览器访问私有 Web 应用 |
| 更广泛的浏览器访问 | 聚焦 HTTP/HTTPS | 官方文档覆盖私有 Web 应用、无客户端 SSH 和浏览器内 RDP |
| 设备姿态 | Intune、Defender for Endpoint、SentinelOne、CrowdStrike、Jamf | 广泛的设备姿态与终端集成生态 |
| MFA | 许可式集成 ZTXBAS；联网时可使用受支持的外部选项 | 基于 IdP 的 MFA + Cloudflare Access 独立 MFA |
| 完全隔离运行 | 支持 | 在本次审阅的 Cloudflare 当前文档中，未找到永久断网的 Access 部署模式 |
| 可选供应商服务 | CoreZT 运营的 ZTXHub，用于集中许可/更新管理 | Cloudflare 服务是标准 Access 架构的内在组成部分 |
| 韧性模式 | 周期性备份并还原到新部署；无传统 HA 集群 | Cloudflare 运营的服务可用性 + 根据部署方式配置客户侧 Tunnel 冗余 |
这是架构对比，而不是功能打分。Cloudflare One 的平台范围远大于 ZTXGate，而 ZTXGate 更强调由客户/MSP 运营的 ZTNA 以及断网部署灵活性。
平台范围
Cloudflare Access 是 Cloudflare One 的一个组成部分。Cloudflare One 是更广泛的云交付安全平台，可包括安全 Web 网关、网络连接、浏览器隔离、数据控制和其他 SASE 能力。
ZTXGate 更聚焦于私有资源的零信任访问。它结合身份、设备上下文、策略执行、基于 WireGuard 的受管连接、许可式无客户端 HTTP/HTTPS 访问、审计可见性，以及可独立于 CoreZT 托管控制服务运行的部署模式。
希望获得广泛、由供应商运营的 SASE 平台的组织，与希望采用由客户或 MSP 运营 ZTNA 的组织，实际上是在评估不同的运行模式。
控制平面与私有连接
Cloudflare 官方文档中的私有 Web 应用模式，会在私有环境内部署 cloudflared。该连接器建立到 Cloudflare 的出站 Tunnel，而 Cloudflare Access 位于应用前方，对用户进行认证与授权。
ZTXGate 可以在由客户或 MSP 运营的基础设施中独立运行。策略与访问执行不要求强制依赖 CoreZT 托管的控制平面。
联网的 ZTXGate 部署可以选择使用由 CoreZT 拥有并运营的 ZTXHub，用于集中式软件更新与许可管理。ZTXHub 并不是 ZTXGate 核心访问运行的必需组件。
受管访问与无客户端访问
ZTXGate 有两条主要访问路径：
- 受管访问：使用基于 WireGuard 的连接，为需要网络访问的协议提供访问。
- 许可式无客户端 HTTP/HTTPS 访问：通过执行策略的 ZTXGate 代理访问受支持 Web 应用。
Cloudflare Access 在官方文档中提供更广泛的无客户端能力。目前第一方文档包括：
- 从浏览器访问私有 HTTP/HTTPS 应用
- 无客户端 SSH
- 浏览器内 RDP
这种覆盖广度是 Cloudflare 的优势。ZTXGate 不应被描述为对当前没有文档支持的协议提供等价的浏览器能力。
ZTXGate 的区别在于，它的 HTTP/HTTPS 无客户端能力可以作为由客户或 MSP 运营的 ZTXGate 部署的一部分运行，而不是依赖 Cloudflare 托管的 Access 服务。
身份与 MFA
Cloudflare Access 同时支持基于身份提供商的 MFA，以及由 Access 直接执行的独立 MFA。Cloudflare 当前文档列出的方法包括 TOTP、WebAuthn 安全密钥，以及 Touch ID、Face ID、Windows Hello 等平台生物识别方式。
ZTXGate 可以在联网环境中使用外部身份和认证服务。获得许可后，它还包含紧密集成的 ZTXBAS 抗钓鱼生物识别认证，无需单独部署 ZTXBAS 服务器。
真正有意义的比较，并不是双方是否支持 MFA——两者都支持。差异出现在访问环境必须有意与外部云服务断开时。
云不可达时的认证
有意义的对比应区分“临时中断容忍”与“有意设计的隔离运行模式”。
ZTXGate
独立的 ZTXGate 部署可以保持完全隔离。获得集成式 ZTXBAS 许可后，抗钓鱼生物识别认证仍可在隔离的 ZTXGate 部署内部使用。
这条 ZTXBAS 认证路径无需连接 CoreZT 或外部云 MFA 提供商。不使用 ZTXHub 时，许可管理和软件更新也可手动完成。
Cloudflare Access
Cloudflare Access 的独立 MFA 降低了第二因素对客户外部 IdP 的依赖，但该能力仍由 Cloudflare Access 服务实现。Cloudflare 文档中的私有应用工作流使用 Tunnel 把私有应用连接到 Cloudflare，并通过 Cloudflare 执行 Access 认证流程。
在本次审阅的 Cloudflare 当前文档中，我们没有找到一种永久断网的 Access 部署，使 Cloudflare 服务本身完全不处于认证路径中。
因此，区别不是“MFA vs 无 MFA”，而是：云服务 MFA，与能够在完全隔离 ZTXGate 部署内部继续运行的集成式抗钓鱼生物识别认证路径之间的差异。
设备信任与姿态
两种产品都可以把设备上下文纳入访问策略。
ZTXGate 支持以下姿态输入：
- Microsoft Intune
- Microsoft Defender for Endpoint
- SentinelOne Singularity
- CrowdStrike
- Jamf
Cloudflare 通过 Cloudflare One 及其集成提供广泛的设备姿态生态。
对两种产品而言，来自互联网托管 MDM 或 EDR 服务的姿态信号，都要求相应服务可访问。在隔离的 ZTXGate 环境中，策略应使用隔离边界内部实际可获得的身份、设备、姿态和安全信号。
断网与隔离运行
ZTXGate 支持永久断网运行模式：
- ZTXGate 仍由客户或 MSP 运营
- 不强制依赖 CoreZT 托管的控制基础设施
- 许可可以手动处理
- 软件更新可以手动处理
- 获得许可的集成式 ZTXBAS 仍可提供抗钓鱼生物识别认证
联网部署可以选择使用 CoreZT 运营的 ZTXHub，集中管理许可和更新。
Cloudflare Access 设计上属于 Cloudflare 云服务的一部分。这可以显著降低客户运营控制平面的负担，但它与“在没有供应商托管控制服务时仍可完整运行”的产品架构属于不同选择。
运营责任
以下情况 Cloudflare Access 可能更合适：
- 希望采用广泛的云交付安全平台
- 希望由供应商负责运行 ZTNA 控制平面
- 广泛的浏览器/无客户端访问选项很有价值
- Cloudflare 服务可以作为可接受的架构依赖
- 希望与更广泛的 Cloudflare One 平台集成
以下情况 ZTXGate 可能更合适：
- 访问平台应由客户或 MSP 运营
- 不希望强制依赖供应商托管控制平面
- 要求永久隔离运行
- 断网环境中仍必须提供抗钓鱼生物识别认证
- 同时需要基于 WireGuard 的受管访问和许可式无客户端 HTTP/HTTPS 访问
- 组织更偏好聚焦 ZTNA 的平台，而不是更广泛的 SASE 技术栈
这两组条件并不构成总体排名。更合适的选择取决于部署的运行模式和安全要求。
使用的官方资料
本页有关 Cloudflare 的信息根据当前第一方文档核验：