核心结论
ZTNA(Zero Trust Network Access,零信任网络访问)是基于"持续验证、最小授权"原则的网络访问方案,通过将访问控制从网络层下沉到身份+设备+应用层,实现对资源的细粒度按需授权。VPN 替换不是单一产品替换,而是涉及身份治理、设备信任评估、应用迁移策略、客户端覆盖、断网降级的系统工程。本文从选型、PoC、灰度切换到常见坑点梳理一条可执行的工程化路径,适用于远程办公、多分支互联、SaaS 访问三类典型场景。
- ZTNA 与 VPN 的本质区别:VPN 一次认证建立网络隧道;ZTNA 每次访问请求都基于身份/设备/上下文动态鉴权
- 选型核心维度:身份集成(SAML/OIDC)、设备态势评估、最小权限粒度、客户端覆盖、API/应用可见性
- 迁移路径:画像 → 选型 → PoC(2 个应用+1 个用户群体) → 灰度(按部门/应用分批) → 全量
- 常见坑点:客户端覆盖率、设备合规检查过严导致办公中断、断网时降级方案、运维可见性
- 产品组合:Cloudflare Access / Zscaler ZPA / Palo Alto Prisma Access / Cisco Duo + 国内深信服 aTrust / 奇安信零信任
内容维护:VISBAT维思贝特 · 数据来源:NIST SP 800-207、CISA Zero Trust Maturity Model v2.0、Forrester Wave 报告、Gartner Magic Quadrant · 最近更新:2026年8月10日
为什么企业开始用 ZTNA 替换 VPN
过去十年,VPN(尤其是 SSL VPN)是企业远程接入的事实标准。但 VPN 的架构缺陷在近三年被反复暴露:一次密码+OTP 认证后,客户端获得内网大段 IP 的访问权限,横向移动攻击面巨大;VPN 设备本身也频繁成为 0day 目标(FortiGate、Pulse Secure、Cisco AnyConnect 等都出现过被利用的远程代码执行漏洞)。Forrester 调研显示,多数大型企业正在或有计划用 ZTNA 替换 VPN。
ZTNA 的核心思路是把"信任"从"网络位置"转移到"身份+设备+上下文"。用户即使身处内网,访问应用前也要重新做身份和设备态势校验;反过来,远程用户也能像在内网一样被策略引擎精确控制。这一转变对应的是 NIST SP 800-207《Zero Trust Architecture》提出的核心原则:"never trust, always verify"(持续验证、永不信任)。
ZTNA 与 VPN 的本质区别
很多团队把 ZTNA 当作"下一代 VPN",但两者在架构上有根本差异。理解这些差异是后续选型和迁移的起点。
访问控制粒度
VPN 的控制单元是"网络":用户认证成功后获得一个 IP 段,可以访问该段内的任意主机和端口。ZTNA 的控制单元是"应用":用户每次请求一个具体应用(或 API),都需要重新鉴权。策略引擎基于用户身份 + 设备态势 + 上下文(位置/时间/风险评分) 动态判断是否放行这个具体请求。
这带来两个直接收益——一是横向移动被切断,攻击者拿下某台机器后无法通过隧道扫整个内网;二是每个应用的访问记录可独立审计,合规追溯更清晰。
认证模型
VPN 通常是"用户名+密码+OTP",认证一次建立会话;ZTNA 默认走 SAML 2.0 / OIDC 联邦认证,与企业 IdP(Okta、Azure AD/Entra、Google Workspace 等)集成,支持自适应 MFA(根据风险评分动态触发二次认证)。每个应用可设置独立的认证策略,离职、调岗人员的权限回收在 IdP 一处完成。
设备态势
VPN 一般只校验"账号是否合法",很少检查设备健康。ZTNA 通常内置 EDR 联动或 MDM 集成:macOS/Windows 设备的补丁状态、磁盘加密状态、是否安装 EDR、是否越狱/Jailbreak,都会作为授权决策的输入。这是抵御凭据泄露+终端失陷组合攻击的关键。
部署模式
VPN 客户端连到中心 VPN 网关,客户端产生的内网流量经网关绕行;ZTNA 主流方案有两种 —— SDP 模式(Software Defined Perimeter) 客户端先与 ZTNA 控制器握手,再按需建立到应用的单连接隧道,网关不转发无关流量;反向代理模式(如 Cloudflare Access)用户访问应用时经 ZTNA 边缘节点鉴权后再转发到源站。两种模式各有适用场景,下文会详细讨论。
ZTNA 选型的五个核心维度
ZTNA 厂商众多,功能宣传口径相似。选型时建议从以下五个维度评估,避免被"零信任全功能"这类营销话术带偏。
1. 身份与设备治理深度
这是 ZTNA 的根基,直接决定"持续验证"能不能落地。需要关注:
- 身份联邦能力:是否原生支持 SAML 2.0、OIDC、SCIM 自动开通/回收,与现有 IdP 的集成复杂度
- 设备态势来源:支持哪些 EDR/MDM(Jamf、Intune、Workspace ONE、 CrowdStrike、SentinelOne 等),是否支持自定义设备属性(资产标签、用户组归属)
- 风险评分模型:能否综合身份风险、设备风险、行为异常、地理位置动态计算信任值
- 会话生命周期:会话超时、强制重认证、设备变更后的实时吊销能力
2. 应用接入覆盖
ZTNA 的目标是"每一个应用都受控",不是"几个核心应用受控"。需要确认:
- 协议支持:HTTP/HTTPS、SSH、RDP、TCP/UDP 自定义端口、Kubernetes Service、DBA 数据库协议的覆盖度
- API 可见性:是否提供 API 级别的鉴权(尤其针对微服务、Serverless、GraphQL 等场景)
- 应用发现:能否自动扫描企业内未登记的应用(影子 IT),这是 ZTNA 项目中常被低估的高价值副产品
- 无客户端模式:对合作伙伴、外包人员等不需要安装客户端的场景,是否提供浏览器反向代理方案
3. 客户端覆盖与稳定性
客户端是用户感知最直接的环节,稳定性问题会让项目早早失血。关注点:
- 平台覆盖:Windows、macOS、Linux、iOS、Android、ChromeOS 是否全部覆盖
- 静默升级:客户端能否在后台自动升级,避免老版本导致连接异常
- 资源占用:常驻进程内存/CPU 占用,长时间运行稳定性
- 断网降级:客户端断网时是否能给出明确提示,而不是默默卡死
- 多因子兼容性:与企业已采购的 MFA 方案是否兼容,避免重复采购
4. 性能与全球接入
ZTNA 普遍采用云原生 PoP 节点,如果用户分布在全球,节点覆盖密度直接决定体验:
- PoP 节点分布:中国大陆、海外是否都有节点,延迟在主流城市是否在 50ms 以内
- 带宽与并发上限:单租户支持的最大并发会话数,突发流量弹性
- 协议优化:智能选路、TCP/UDP 加速、Brotli 压缩等是否启用
5. 运维与合规可见性
ZTNA 部署后的日常运维成本容易被低估。关注:
- 日志与审计:是否提供完整的访问日志、设备态势日志、策略决策日志,能否对接 SIEM
- 策略可视化:策略生效范围、被拒请求原因的可视化,避免运维盲盒
- 合规报告:是否能一键导出等保、行业合规所需访问审计报告
- 支持与 SLA:厂商技术支持响应时长、生产事故 SLA 条款
部署模式:三种架构与适用场景
ZTNA 的部署模式不是"选一个就好",而是根据应用类型、用户分布、合规要求选择组合。
模式 A:客户端 + ZTNA 网关(SDP 模式)
用户在终端安装 ZTNA Agent,Agent 与 ZTNA 控制器握手后,按需与目标应用建立加密隧道,网关不做全局流量转发。这是传统企业内网应用(OA、ERP、自建 Jenkins、堡垒机等)的典型部署模式。
优点:对老旧 TCP/UDP 应用兼容性好,内部网络完全不可见;缺点:需要客户端安装,设备合规检查会让 BYOD 或合作伙伴终端遇到障碍。
模式 B:反向代理(SSE / 浏览器代理)
应用前部署反向代理或 SaaS 边缘节点,用户通过浏览器访问应用,反向代理先校验身份和上下文,再转发到源站。Cloudflare Access、Zscaler ZIA/ZPA、Akamai 都是这一模式的代表。
优点:无需客户端,适合 SaaS 应用、合作伙伴接入、外包开发;缺点:仅适合 HTTP/HTTPS 协议,对 SSH/RDP 需要额外客户端或 SSH bastion 配合。
模式 C:微分段 + 身份感知网络
在数据中心内部署微分段交换机或软件代理,基于身份和工作负载标签做东西向流量控制。这是数据中心内部(数据库、应用服务器之间)做零信任的延伸。
优点:防止横向移动;缺点:与 SDP/SSE 是互补关系,不替代,部署复杂度高。
迁移路径:从 PoC 到全量的五阶段
ZTNA 项目最容易失败的不是技术,而是迁移节奏。以下是经过验证的五阶段工程化路径。
阶段 1:画像(2-4 周)
- 梳理现有 VPN 用户数、并发峰值、应用接入清单(可以从 VPN 网关日志提取)
- 区分"必须 VPN"的内部应用与可以走反向代理的 SaaS/公网应用
- 识别特殊人群(运维、研发、外包、合作伙伴)对客户端安装的限制
- 评估现有 IdP 能力和目录数据质量(用户组、OU、设备属性)
阶段 2:选型(2-4 周)
基于画像结果筛选 2-3 家厂商做技术评估,核心是看 PoC 数据。建议优先做以下三方面的对比:
- 与企业 IdP 集成的"开箱即用"程度(避免大量定制开发)
- 客户端兼容覆盖(尤其是 macOS/Linux/老 Windows 客户端)
- 对核心 3-5 个应用的实际访问体验(延迟、并发稳定性)
阶段 3:PoC(4-6 周)
PoC 不是"装上能用",而是验证"用得稳、查得清、退得回"。建议:
- 范围:选 2 个应用 + 1 个用户群体(50-100 人),覆盖典型场景
- 关键验证:设备合规检查触发后的拒绝逻辑、异常登录的强制 MFA、断网时客户端提示、运维审计日志完整性
- 退出机制:PoC 用户能随时切回 VPN,避免业务受影响
- 文档:把策略配置、客户端部署、用户引导 SOP 写完整
阶段 4:灰度切换(8-12 周)
PoC 通过后,按"应用切换+用户切换"双维度灰度,避免一刀切:
- 应用维度:从非关键应用(内部知识库、研发 Wiki)开始,逐步到核心业务(ERP、CRM),最后是运维类堡垒机
- 用户维度:从接受度高的团队(研发、产品)开始,再到行政部门,最后到对客户端敏感的高层/外部人员
- VPN 双轨:ZTNA 与 VPN 同步运行 4-8 周,用户能自主选择,逐步引导至 ZTNA
- 运维观察:实时监控拒绝率、客户端崩溃率、用户投诉,设定"暂停切换"的回滚阈值
阶段 5:全量与持续运营
- VPN 保留只读模式 1-3 个月(应急备用),最终下线
- 建立 ZTNA 运营团队(2-3 人专职),负责策略调整、应用接入、用户问题
- 季度性策略评审,清理僵尸账号、过度授权
- 与 SIEM/SOC 流程对接,纳入安全运营日常
常见坑点与缓解
坑 1:客户端覆盖率不足
症状:部分用户(BYOD、临时工、合作伙伴)无法装客户端,导致关键应用访问中断。
缓解:
- 对合作伙伴、外包优先用反向代理模式(浏览器即可访问)
- 客户端做企业应用商店托管,自动静默升级
- 对极端拒绝安装的场景,保留有限的 VPN fallback 但配合网络分段限制访问范围
坑 2:设备合规检查过严
症状:策略要求"必须开启磁盘加密+安装 EDR+补丁全部更新",结果 30% 员工无法通过,业务大面积中断。
缓解:
- 合规策略分级:核心应用(财务、生产)严苛,一般应用宽松
- 提供"自助修复"入口,引导用户完成合规步骤(自动跳转到补丁更新页面)
- 对无法立即合规的设备,允许"限时访问+管理员审批"模式
坑 3:断网降级缺失
症状:ZTNA 服务或 PoP 节点故障时,用户完全无法访问应用,业务停摆。
缓解:
- 多 PoP 厂商备份(主备两家 ZTNA 厂商,流量按比例切)
- 关键应用保留本地反向代理作为 fallback
- 客户端故障时给出明确"降级使用 VPN"的指引
- 运维监控 ZTNA 服务可用性,30 秒内告警
坑 4:策略过度复杂
症状:策略数量爆炸,半年后没人能解释某条策略为什么存在。
缓解:
- 策略模板化:按"角色 × 应用 × 设备态势"建立模板,避免一条一条手写
- 季度清理:删除长期未触发的策略
- 变更审计:每条策略的创建人、变更时间、业务说明必须有记录
坑 5:运维可见性盲盒
症状:用户报告"访问失败",但 ZTNA 控制台没有清晰原因,运维无法定位是策略、设备、网络还是应用问题。
缓解:
- 选择提供"决策日志"的厂商:每条请求的策略路径、被拒原因可追溯
- 客户端日志本地留存 7-30 天,问题排查时能直接拿
- 与 SIEM 集成,把 ZTNA 日志纳入 SOC 监控
典型产品组合与选型参考
不同场景下,产品组合差异较大。下表汇总了主流方案的特点,具体选型建议结合企业实际环境评估。
| 产品/方案 | 部署模式 | 强项场景 | 参考要点 |
|---|---|---|---|
| Cloudflare Access | SSE/边缘代理 | SaaS 访问、合作伙伴接入、跨国分布式团队 | 与 Cloudflare 生态(WAF、Workers)集成度高,客户端要求低 |
| Zscaler ZPA / ZIA | SSE 全栈 | 大型企业全球远程办公、混合云访问 | PoP 节点覆盖广,适合跨国分布式团队,License 按用户计费 |
| Palo Alto Prisma Access | SASE/SD-WAN 一体 | 已有 Palo Alto 防火墙或 Prisma Cloud 的企业 | 与现有 PAN-OS / Cortex 生态联动,适合已有 Palo Alto 资产的企业 |
| Cisco Duo + Secure Access | MFA + SDP | 已有 Cisco 网络/协作资产的企业 | MFA 与零信任入口一体化,Duo 单独可作 MFA 增强 |
| Microsoft Entra Private Access | 身份驱动 + SDP | 深度使用 Microsoft 365 / Entra ID 的企业 | 与 Entra ID 条件访问策略天然集成,无需额外 IdP |
| 深信服 aTrust | 客户端 + SDP | 国内中大型企业、央国企合规场景 | 国内合规适配较好,等保支持完整,客户端覆盖主流国产化操作系统 |
| 奇安信零信任 | 身份 + SDP | 国内政府、金融、能源行业 | 国内合规体系完整,支持国密算法,与国产化栈适配 |
产品参数来源:各厂商官方文档、NIST SP 800-207、CISA Zero Trust Maturity Model v2.0;具体兼容性、性能和价格以正式采购时厂商当前发布的版本文档为准。
常见问题(FAQ)
ZTNA 和 VPN 能否并存?
可以并存,这也是推荐的迁移路径。ZTNA 项目初期建议 ZTNA 与 VPN 双轨运行 1-3 个月,用户逐步迁移;关键应用保留 VPN 备份,降低迁移风险。最终目标是下线 VPN,但保留有限 VPN 通道(比如机房运维专用)用于 ZTNA 服务故障时的应急。
ZTNA 是否会显著增加远程访问延迟?
取决于厂商 PoP 节点分布和协议优化。ZTNA 服务的访问延迟会受 PoP 覆盖和网络路径影响,通常与 VPN 直连相当或更优;如果走就近 PoP 节点,体验通常也更稳定。具体延迟建议在 PoC 阶段实测核心用户的访问体验后再下结论。
没有 IdP 或身份治理薄弱的企业能做 ZTNA 吗?
技术上可以,但收益会大打折扣。ZTNA 的核心是"持续验证",而验证的基础是身份数据(用户组、组织、角色)。如果企业连统一的 IdP 都没有,建议先做身份治理(LDAP 整理、统一账号、SCIM 自动化),再上 ZTNA,否则策略无法落地为细粒度。
ZTNA 替换 VPN 后,运维堡垒机怎么办?
堡垒机是 ZTNA 迁移中的"硬骨头"。常见做法:堡垒机本身作为"应用"接入 ZTNA,运维通过 ZTNA 访问堡垒机,再从堡垒机跳到目标服务器。也可选择支持 SSH/RDP 协议的 ZTNA 方案直接收敛,但需要确认对堡垒机会话录像、命令审计功能的影响。建议分两步:先 ZTNA 接入堡垒机,再考虑直连收敛。
ZTNA 是否能完全替代 VPN?
在大多数远程办公、SaaS 访问、分支互联场景下,ZTNA 可以完全替代 VPN;但在少数特殊场景仍需保留 VPN:对客户端安装有限制的工业控制现场、传统 OT 网络、运营商级 MPLS 备份链路等。建议在 ZTNA 全量上线后,保留有限 VPN 通道用于应急和特殊场景。
ZTNA 项目通常需要多长时间?
中型企业(500-2000 人)从 PoC 到全量切换典型周期 6-9 个月;大型企业(2000+ 人、多地域、多业务线)通常需要 9-18 个月。时间消耗主要在应用接入梳理(每个应用的访问关系、协议、依赖)和用户引导培训,而不是技术本身。建议预留充足的应用梳理时间和分阶段的运维培训。
总结:ZTNA 是工程,不是产品
把 ZTNA 当作"买一个产品就能用"的认知是项目失败的主要原因。ZTNA 的成功依赖身份治理、设备态势、应用可见性、客户端覆盖四个支柱,任何一个不到位,体验都会打折扣。把这四个支柱的现状摸清,再选型、再 PoC、再灰度,迁移路径才能走通。
VISBAT 维思贝特在企业零信任项目上有 PoC 设计、选型对比、灰度迁移的完整方法论,可为企业开展零信任建设提供技术支持。正式采购和部署时,请以厂商当时发布的最新兼容性及版本文档为准。
需要网络安全方案评估或落地支持？
我们的网络与安全团队可帮助企业梳理现状，规划零信任、SASE、等保合规与终端安全等落地路径，提供从评估、选型到部署的一体化服务。