自托管 ZTNA vs 云交付 ZTNA
“云 ZTNA”和“自托管 ZTNA”听起来像两个简单类别。实际上，市场中存在多种介于两者之间的架构模式。
最有价值的问题并不只是产品运行在哪里，而是：
谁运营控制平面？应用流量实际经过哪里？外部服务不可用时，哪些功能还能继续运行？
本指南对主要运行模式进行比较，并不假设其中某一种天然适合所有组织。
四种常见运行模式
1. 云交付 ZTNA
供应商以云平台方式运营管理、策略和访问服务。
这可以减少客户的基础设施工作，并提供由供应商管理的可用性和地域覆盖。
2. 供应商控制平面 + 客户 Connector
供应商运营中央协调与策略服务，客户在私有应用附近部署 connectors、gateways 或 service edges。
应用流量可能经过客户组件、供应商 service edge、直接 peer 路径，或根据产品采用这些方式的组合。
3. 自托管 ZTNA
客户或 MSP 运营产品的控制和执行基础设施。
这样可以获得更大的部署控制权，但运营方也承担更多维护、备份、可用性和监控责任。
4. 独立 / 断网 ZTNA
访问平台可以在没有强制供应商托管控制服务的情况下运行。
这才是永久隔离、高度受限或完全 air-gapped 环境真正关心的模式。
控制平面归属
控制平面通常负责配置、身份、资源定义、策略、授权和管理工作流。
在云交付服务中，这一层由供应商运营。
在自托管系统中，这一层由客户或 MSP 运营。
两者都不是天然更安全，它们只是形成不同的信任边界与运营责任。
值得询问的问题包括：
- 谁可以管理控制服务？
- 配置存储在哪里？
- 策略决策需要哪些外部服务？
- 互联网中断时，管理员还能继续工作吗？
- 哪些责任属于供应商，哪些属于客户或 MSP？
数据路径
控制平面运行在哪里，并不一定能说明应用流量经过哪里。
一个云管理的 ZTNA 产品仍可能让应用流量直接在客户控制的组件之间传输；另一个产品可能让流量经过供应商 service edge。自托管平台则可能通过客户自己运行的基础设施代理或转发流量。
评估产品时，应把下面两个问题分开：
- 策略决策在哪里协调？
- 应用流量实际经过哪里？
互联网依赖
联网服务可以提供很高可用性，同时仍然依赖供应商云来完成管理、新授权、认证协调或其他功能。
对于普通企业部署，这种依赖完全可能是可以接受的，甚至是更理想的。
断网环境则需要不同答案。
应询问以下情况发生时会怎样：
- 互联网连接消失几分钟或几小时
- 供应商控制服务不可达
- 外部身份提供商不可达
- MDM/EDR 服务不可达
- 网络被有意永久隔离
“能在临时中断期间继续工作”并不一定等同于“可以永久隔离运行”。
身份与认证
云交付 ZTNA 通常会与云身份提供商集成。自托管产品可能支持外部身份提供商、本地用户，或同时支持两者。
隔离架构必须使用断网环境内部能够访问的身份和认证方式。
同样的区别也适用于 MFA。若部署无法访问云推送服务，就无法完成依赖该服务的认证事务。
更新与许可
云交付产品通常由供应商承担大部分软件生命周期管理工作。
自托管产品则需要自己的更新模式，例如自动化软件仓库、托管更新服务或手动软件包。
如果更新和许可通常依赖外部连接，那么断网环境就必须提供可控的离线流程。
可用性与灾难恢复
云服务通常把供应商管理的冗余作为服务的一部分提供。
自托管会把更多责任转移给运营方。产品可能支持集群、主动/被动设计、分布式组件，或者采用备份与还原式恢复。
这些模式并不等价。
买家应询问具体实现，而不是把“高可用”或“韧性”当作泛化标签接受。
运营责任
| 领域 | 云交付 | 自托管 / 客户或 MSP 运营 |
|---|---|---|
| 控制平面基础设施 | 供应商 | 客户或 MSP |
| 平台补丁 | 主要由供应商负责 | 客户/MSP 按供应商流程处理 |
| 扩展 | 主要由供应商负责 | 客户/MSP |
| 备份 | 主要属于供应商服务责任 | 客户/MSP |
| 监控平台可用性 | 供应商 + 客户集成 | 客户/MSP |
| 互联网依赖 | 取决于产品，通常较明显 | 取决于产品；某些架构可避免 |
| 隔离网络适用性 | 取决于产品 | 如果架构支持则可行 |
自托管提供更多控制，也意味着更多责任。
合规与数据控制要求
有些组织偏好云交付，因为供应商可以运营标准化、全球可用的平台。
另一些组织则要求基础设施保留在明确的运行边界内，例如因为：
- 隔离网络
- 内部架构政策
- 受监管环境
- 客户合同要求
- 数据位置或依赖限制
正确选择取决于实际要求，而不是笼统地宣称云或自托管总是更优。
市场中的典型模式
当前 ZTNA 市场体现了多种可能性：
- 一些产品使用供应商托管 Controller + 客户 Connector
- 一些同时提供云托管和真正自托管版本
- 一些把控制平面作为 SaaS 管理，同时开源客户侧组件
- 一些提供本地连续性组件，但正常运行期间仍与云服务同步
正因为市场存在这种多样性，架构评估才很重要。
ZTXGate 的定位
ZTXGate 设计为运行在由客户或 MSP 运营的基础设施中。
核心访问运行不要求强制 CoreZT 托管云控制平面。
独立 ZTXGate
- 由客户或 MSP 运营
- 可以保持完全隔离
- 许可管理为手动方式
- 软件更新为手动方式
- 获得许可时，集成式 ZTXBAS 可以在断网 ZTXGate 环境内部运行
ZTXGate + 可选 ZTXHub
- ZTXGate 仍由客户或 MSP 运营
- ZTXHub 由 CoreZT 拥有并运营
- ZTXHub 提供集中式软件更新管理
- ZTXHub 提供集中式许可管理
- 该服务是可选项，而不是核心访问运行的必需组件
韧性模式
ZTXGate 当前不提供传统 HA 集群。管理员可以配置周期性备份，并在需要灾难恢复时把备份还原到新的部署。
这是备份与还原式灾难恢复，而不是自动故障转移。
向任何 ZTNA 供应商提出的问题
在选择架构前，建议询问：
- 谁运营控制平面？
- 流量经过哪里？
- 客户侧需要部署哪些组件？
- 供应商云不可用时会怎样？
- 系统能否永久断网运行？
- 哪些身份和姿态功能依赖外部服务？
- 更新如何交付？
- 断网环境中的许可如何处理？
- 实际可用性模型是什么？
- 谁负责备份和灾难恢复？
- 哪些功能要求终端软件？
- 哪些责任仍由客户或 MSP 承担？
这些答案通常比“ZTNA”这个标签本身更能揭示实际运行模式。