2026-11-13 10:51:51 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

转向ZTNA和零信任的五个理由

原创

Stan Kaminsky
Stan Kaminsky

网络与信息安全参考

2026年11月12日 08:45
山东

去阅读

SECURITY BRIEF2026.11.10

企业已经装不下 VPN · 五个理由

从边界防护到零信任网络访问：VPN 网关为何成了攻击的首选入口，以及迁移该怎么做

PERIMETER

近四分之三得手的勒索软件攻击，始于一台被攻陷的 VPN

ZTNAZERO TRUST

那套久经考验的企业网络防护配方，如今的效果已远不如从前。用防火墙守住边界、再通过 VPN 网关开放远程访问——这套做法既笨重又危险：日常运维里，用户与云服务之间的交互很难配置清楚；而一旦遭遇网络攻击，VPN 网关本身就是首要攻击目标。据保险公司 At-Bay 的数据，在其 2025 年的分析中，近四分之三得手的勒索软件攻击，都是从一台被攻陷的 VPN 开始的。

要同时提升网络安全与运营效率，企业必须重新思考远程访问模型本身。终极目标是让员工与工作资源之间建立一条安全连接——这绝不意味着员工（或伪装成员工的人）应当获得对企业网络的完整访问权。

一只铆接的金属方块，像是旧式边界防护的隐喻——看上去坚不可摧，代价是所有信任都押在了这层外壳上。图片来源：Kaspersky

PART

近年来的 VPN 攻击说明了什么

VPN ATTACKS

VPN 技术本身并没有走到穷途末路——只要你把它当作一种加密与隧道传输流量的手段。问题出在 VPN 最常见的部署方式：用户在入口处完成认证，随后就落进了公司网络，而从这一步开始，一切限制（如果真有限制的话）都要依赖网络分段、防火墙以及各系统自身的防护。在网络内部、VPN 网关之后，用户可以几乎不受限制地触达大量内部服务。而 VPN 网关本身往往是一台特权设备，一旦被成功攻陷，攻击者就获得了许多接管整个网络的手段。

例如在 10 月针对 Ivanti Connect Secure 网关的攻击中，APT 组织 UTA0576 串联三个零日漏洞，攻陷了一台已打齐补丁的设备。拿到 root 权限后，他们使用 VPN 自带的合法服务账号去查询域控制器，收集密码与 BitLocker 恢复密钥。

更早之前，Check Point 与 SonicWall 网关的漏洞也遭到类似利用，其中 SonicWall 的攻击由 Akira 勒索软件团伙实施。

PART

远程办公、VPN 与被窃数据

REMOTE WORK

如今，视国家不同，有 12% 到 30% 的员工全职或部分时间在家办公。这一转变大幅增加了需要从组织网络之外访问的 IT 系统数量——而且常常是通过个人设备访问。个人设备感染信息窃取木马的概率远高于公司设备。结果是，黑市上充斥着从这类电脑上窃取的企业凭证：在初始访问代理（IAB）出售的所有东西里，这类凭证占到 30%。

即便是走 VPN，严格分段的网络也只能授予极其有限的访问权限。但在实践中，例外会随着多年运行不断堆积：某个承包商需要访问整个子网，某位管理员“临时”拿到了“全部权限”，某个老旧应用需要多开几个端口。新冠疫情期间，这类例外堆积得尤其快。结果是，一个被窃取的账号往往打开的不是某一项服务的大门，而是整个基础设施的大门。

PART

VPN 的管理负担

ADMIN OVERHEAD

要让 VPN 访问既正常又安全，通常只配置 VPN 网关是不够的：你还得单独搭好多因素认证（MFA）、设备状态检查、网络分段和日志采集，然后再让这一整套东西协同工作。新来一名员工或上线一个应用，可能同时要在好几个系统里改配置。每个系统单看都运转正常，但规则会逐渐彼此偏离；等到要查清某个用户为什么没有访问权限，就变成了逛五套管理控制台。

PART

切换到零信任网络访问，改变了什么

THE SHIFT

首先，零信任网络访问（ZTNA）改变的是访问模型本身，以及访问的基本单位。它不再问“这个用户对这个子网拥有访问权限”，而是做出这样的判断：“这个用户，在这台设备上、位于这个位置、通过了这些层级的验证，可以访问这个特定应用”。

这样的判断会把策略所规定的一组因素（身份、设备等等）综合起来考虑。有权使用工单系统或客户数据库，不应自动意味着某人可以连接文件服务器或域控制器。

视策略而定，ZTNA 系统可以通过多种方式的组合，在幕后把访问权授予所需的资源：一条通往某台特定内部服务器的专用 VPN 隧道、一条来自私有云中企业应用的反向连接，等等。合法用户完全不需要知道这些，但攻击者在网络中横向移动、攻击新服务的能力将被严重限制。

ZTNA 只是一件具体的工具 它只是更宏大的零信任架构中的一环——买下一个产品，并不意味着这家公司已经落地了零信任。

PART

从传统 VPN 转向 ZTNA 的收益

BENEFITS

一套实施得当的 ZTNA 系统，首要作用是在部分基础设施或某人的凭证被攻陷时降低潜在损害（也就是影响半径）；与此同时，部署它也会明显压缩攻击者的活动空间。

降低网关被攻击的风险

VPN 网关通常会接受来自互联网的任何连接。在验证用户之前，网关要仔细分析进来的连接、加密报文，以及发往其管理与认证门户的请求。网关存在漏洞，就等于让攻击者能在这个阶段对系统做细致的侦察，甚至完全绕过身份验证。

某些 ZTNA 架构可以降低这种暴露面。内部连接器自行向云端代理（broker）建立出向连接，用户则单独连接到该代理，必要的检查通过之后，对应用的访问才被打开。在这样的系统里，完全不需要把自家网关暴露在远程访问链路上。

在采用自建代理（self-hosted broker）的 ZTNA 架构中，你无法把风险转嫁给 ZTNA 厂商。但不少 ZTNA 方案也能显著缩小自建代理的攻击面，例如采用单包授权（Single Packet Authorization）——代理在收到一个格式正确的加密数据包之前不处理任何请求，而客户端正是用这个数据包预先证明自己的真实性。

限制凭证与终端失陷的后果

ZTNA 可以把访问权限不只绑定到密码上，还绑定到设备状态上：设备是否由组织管理、证书是否有效、操作系统是否已更新、安全软件的数据库是否是最新的、是否存在任何失陷迹象。更进一步，ZTNA 可以针对不同任务对同一个用户采用不同的认证强度。用户只是想在内网门户上看看新闻，而且他登录所用的电脑是已知的？一个密码就够了。用户要登录软件仓库修改应用源代码，或者要打开预算规划系统？那就必须通过抗钓鱼认证，例如使用硬件密钥（比如 YubiKey）。如果连接类型或其他参数发生变化，用户甚至需要重新认证。

很容易看出，在这种情况下，一次假想的信息窃取攻击会变得多么困难。仅仅偷到一个密码或一个浏览器会话已经不够了；一旦试图在新设备上使用它们，连接就会被切断。

在这一点上，ZTNA 的部分功能与 EDR、MDM/EMM 代理在设备上所做的事情存在重叠。正因如此，一些厂商把这些能力打包进同一个代理程序。同时也要清楚：ZTNA 限制的是攻击的后果，它并不替代终端防护。如果攻击者用的是远程访问木马（RAT）而不是信息窃取木马，直接操控某位员工的设备，那么 ZTNA 代理可能无法区分攻击者的操作与员工本人的操作。

提升可观测性，更快发现异常

当员工通过 VPN 在家办公时，防火墙、Web 过滤器和 SIEM/XDR 往往只能看到浅层的网络遥测数据。正因如此，举例来说，Qilin 勒索软件团伙的操作者——他们利用了 Palo Alto GlobalProtect 的一个认证漏洞（CVE-2026-0257）——其行为很难与合法员工的活动区分开来。

ZTNA 让你可以把访问事件绑定到具体的身份上：用户、设备和应用。视具体实现而定，SOC 团队可以获得连接日志，并且对于受支持的协议，还能获得针对特定应用的逐条请求日志。

有了这种细度的日志，再加上配置得当的 SIEM 规则，异常很快就会引起 SOC 分析师的注意。

简化访问权限管理

“访客”与“临时”VPN 访问权限，是 IT 与信息安全团队年年头痛的老问题。承包商账号按临时权限创建，却一活跃就是好几年。2026 年，攻击者正是通过这类管控不力的访问权限，攻入了一家欧洲大型金融机构。ZTNA 让即时（JIT）访问成为可能：承包商的支持工程师只能访问他所需要的那一台服务器的 Web 界面，而且该权限会在设定时间（比如两小时或两天）之后自动关闭。