零信任网络访问（ZTNA）和传统 VPN 有什么区别？
简化版
传统 VPN 通常先把用户接入企业网络，再靠网络边界和 ACL 控制访问；ZTNA 强调不默认信任任何网络位置，按身份、设备状态、应用、风险和上下文逐次授权，只暴露用户有权限访问的应用。VPN 偏“连上内网”，ZTNA 偏“只访问被允许的应用”，更适合云化、远程办公和最小权限场景。
详细版
对比：
| 维度 | 传统 VPN | ZTNA |
|---|---|---|
| 信任模型 | 连入内网后获得一定网络可达性 | 默认不信任，逐请求授权 |
| 访问粒度 | 网段、端口为主 | 应用、用户、设备、上下文 |
| 暴露面 | VPN 网关和部分内网可达 | 应用隐藏在代理后 |
| 适合场景 | 网络互通、传统内网 | SaaS、混合云、远程办公 |
| 核心能力 | 隧道、路由、加密 | 身份、设备、策略、审计 |
ZTNA 不是“更高级 VPN 客户端”，而是一套接入控制模型。它通常通过身份提供商、设备合规检查、应用代理、策略引擎和持续评估实现。面试回答要避免把零信任说成“不要 VPN”，更准确是“不要因为网络位置而默认信任”。
完整版教学
一、传统 VPN 的默认假设是什么
传统 VPN 诞生时，企业资源大多在内网，办公设备也在企业边界内。VPN 的任务是让外部用户“像在公司内网一样”访问资源。因此它常常建立三层隧道，给客户端分配内网地址，并下发路由。
远程用户 -> VPN 网关 -> 企业内网这种模型简单有效，但隐含一个问题：一旦接入成功，用户可能获得较大的网络可达范围。即使有 ACL，控制粒度也常以网段和端口为主，难以表达“某用户在合规设备上只能访问某应用的某功能”。
零信任的核心不是“不加密”，而是“不因为你在内网或连上 VPN 就默认可信”。
二、ZTNA 的访问单位从网络变成应用
ZTNA 更关注“谁在什么设备上，以什么风险状态，访问哪个应用”。用户不一定获得整个网段的可达性，而是通过代理或连接器访问授权应用。未授权应用对用户不可见，甚至不暴露真实内网地址。
User -> ZTNA Broker/Proxy -> Policy Check -> App Connector -> Internal App这样攻击面更小。攻击者即使拿到账号，也可能因为没有合规设备、位置异常、MFA 未通过而无法访问；即使访问成功，也只看到被授权的应用。
三、身份和设备状态是 ZTNA 的核心输入
传统 VPN 也可以做账号密码和 MFA，但 ZTNA 通常把身份和设备状态作为持续策略输入。设备是否加密磁盘、是否安装 EDR、系统是否打补丁、是否越狱、风险评分如何，都可以影响访问结果。
| 信号 | 可能策略 |
|---|---|
| 用户属于研发组 | 可访问代码平台 |
| 设备未安装 EDR | 禁止访问生产环境 |
| 异地异常登录 | 要求二次 MFA |
| 非托管设备 | 只允许浏览器访问低风险应用 |
这让远程接入从“网络层开门”变成“基于上下文的授权”。
四、最小权限如何落地
传统 VPN 里，最小权限常靠 ACL、路由和防火墙实现。例如只允许某地址池访问某网段的 443 端口。ZTNA 可以把粒度提升到应用，甚至路径和方法级别。比如只允许某组访问 https://deploy.company.com，不允许访问数据库网段。
传统 VPN: user_pool -> 10.20.0.0/16:443
ZTNA: user=dev && device=healthy -> deploy-app粒度越细，横向移动风险越低。攻击者不能简单扫描内网寻找其他服务，因为网络层未必可达。
五、ZTNA 对排障提出了新要求
传统 VPN 排障看路由、隧道、DNS、防火墙；ZTNA 还要看身份源、策略命中、设备姿态、应用连接器、代理日志。用户说“访问不了”，可能不是网络不通，而是策略拒绝或设备状态不合规。
访问失败:
身份认证失败?
MFA 未通过?
设备不合规?
策略未授权?
应用连接器离线?
后端服务异常?因此 ZTNA 的可观测性很重要，要能给出明确拒绝原因，否则用户体验会很差。
六、ZTNA 不是所有场景都替代 VPN
ZTNA 很适合 Web 应用、SSH/RDP 代理、数据库代理、SaaS 访问控制。但有些场景仍需要传统 VPN 或专线式网络互通，例如站点到站点连接、复杂三层协议、广播/组播、老旧客户端协议、大量非代理友好的系统。
| 场景 | 更合适方式 |
|---|---|
| 员工访问内部 Web 系统 | ZTNA |
| 分支机构和总部互通 | Site-to-Site VPN |
| 访问少量 SSH/RDP | ZTNA 代理 |
| 复杂内网三层调试 | VPN 可能更直接 |
面试里要避免绝对化。更好的说法是：ZTNA 减少传统远程接入 VPN 的暴露面，但不是所有网络互通场景的替代品。
七、从 VPN 迁移到 ZTNA 要分阶段
企业通常不会一夜之间关掉 VPN。更常见的是先把高价值 Web 应用接入 ZTNA，再逐步接入 SSH/RDP/数据库代理，最后保留少量 VPN 给网络运维和特殊场景。迁移过程中要梳理用户、应用、权限和设备。
资产发现 -> 用户分组 -> 应用接入 -> 策略试运行 -> 日志审计 -> 灰度替换 VPN如果没有资产清单和权限梳理，ZTNA 只是换了入口，权限混乱仍然存在。零信任落地是治理工程，不只是买一个产品。
八、常见误区与追问
- 误区：零信任就是不用 VPN。 零信任是不默认信任网络位置，具体实现可以包含隧道、代理和身份策略。
- 误区：ZTNA 一定比 VPN 性能更好。 它安全粒度更细，但代理、策略检查和连接器也有开销。
- 误区：有了 MFA 就是零信任。 MFA 只是身份验证的一部分，还需要设备、应用、最小权限和持续评估。
- 误区：ZTNA 可以直接替代所有 Site-to-Site VPN。 网络到网络互通、复杂协议和传统系统仍可能需要 VPN。
- 追问：ZTNA 如何降低横向移动风险？ 用户只获得授权应用访问，不暴露整个网段，未授权资源不可见或不可达。
- 追问：设备姿态检查有什么用？ 防止不合规或被攻陷设备直接访问敏感资源。
- 追问：ZTNA 排障看什么？ 看身份认证、MFA、设备合规、策略命中、代理/连接器状态和后端应用日志。
九、加强记忆
传统 VPN 记成“先连进网络，再靠网络策略限制”；ZTNA 记成“默认不信任，按身份、设备和应用逐次授权”。它的价值是缩小暴露面、细化权限、降低横向移动，但不是所有三层互通的替代品。答题时把信任模型、访问粒度、设备姿态、最小权限和迁移边界讲清楚。