结论先行：远程接入长期被当作一条信任边界：能拨进来说明身份验过了，进来之后按内网对待。这个前提在认证机制自身出问题的那一刻就失效。2026 年被勒索团伙稳定使用的一个远程接入组件缺陷（CVE-2026-0257，CVSS 7.8）就是这种结构：攻击者不需要有效凭据，就能建立一条被系统认作合法的会话，流量从隧道内部发出，在流量侧与正常远程办公没有区别。从公开披露到成为稳定入口，大约五个月。要补的不是一道更强的认证，而是「进来之后再判一次」。

本文只谈隧道内流量该依据什么再判一次、以及管理面的隔离承接；不谈网关本身怎么加固、不谈微隔离策略的匹配对象怎么写，也不谈账号与口令策略。

一条绕过认证的会话，和正常远程办公长得一样

公开分析里有一句话最值得抄下来：攻击流量源自隧道内部，因此在防守方看来就像一次合法的远程接入。这意味着常规的健康检查、连接数统计、来源地址审计，都不会报警——所有指标都正常，不对劲的地方只剩一处：对面那个人从来没过身份验证。

这类事件的时间线也很能说明问题：缺陷在 2026 年 5 月中旬公开，5 月下旬被列入已知被利用目录，情报侧的跟踪从 6 月一直持续到 11 月，攻击面还在扩大。一个已修复五个月的缺陷仍然能被用来打进网络，说明问题不在补丁发布得慢，而在补丁之外的假设没变。

为什么「内网」这个前提已经不可靠

把一条远程接入会话当成本地身份，会连带出三个默认结论，而这三个结论在这类事件里全部不成立。

  • 「能从里面发起连接，说明是自己人」。绕过认证之后，发起连接的人与任何一个正常远程办公的员工无法区分。
  • 「横向移动会被挡住」。公开案例里的路径是从会话直接摸到虚拟化管理组件，关掉宿主机上的安全控制，再用离线方式从磁盘取凭据——服务器内部运行的安全软件在这个过程中没有参与。
  • 「管理面藏在内网所以安全」。虚拟化管理、备份管理、堡垒机、集中纳管平台这些组件，恰恰是拿到一个立足点之后先被访问的对象，因为它们才是通往全部资产的门。

三层承接：再判一次、圈住管理面、留下证据

其一，隧道内按业务关系再判一次。判据从「你在哪个网段」换成「哪个工作负载可以访问哪个工作负载的哪个端口」。这件事与远端是谁无关：即使对面是合法员工，他能碰到的对象也应当由业务关系确定，而不是由「已经进来了」确定。

其二，把管理面单独圈出来。虚拟化管理、宿主机管理、备份管理、集中纳管平台这几类组件，访问来源应当是固定的运维跳板与固定的时段，而不是任意一条远程会话。管理面一条规则的价值，高于业务面十条规则，因为它决定了失守之后是「一台机器」还是「一片」。

其三，留一份能按会话检索的记录。要能回答：这条会话从哪来、用哪个账号、碰过哪些资产、执行了什么。这类记录有个前提——不能和它保护的对象放在同一套权限里，也不能只存在被访问的那台机器上。

验收时可以核的三件事

要核的点可接受的答案常见的空答案
远程接入流量有没有再判一次能说清隧道来源在当前策略里对应哪几组工作负载、哪些端口「进来就是内网，按业务网段放通」
管理面是否单独管控管理组件只接受来自固定跳板、固定时段的访问，且有例外审批「管理口已经在内网了，外面进不来」
会话记录能否反向查给一个账号或时间点，能拉出该会话触及的资产与操作「防火墙有日志，要查的时候导一下」

三行里第三行最容易被低估。事件处置时最先被问到的不是「他们怎么进来的」，而是「他们进来之后碰了什么」。前一个问题当天可能查不清，后一个必须有答案。

边界与前提

三点说明。其一，文中漏洞编号与评分取自公开通告，本文不涉及任何利用细节；对具体产品的加固方式以其官方指引为准。其二，「再判一次」不是把远程接入整体收紧——收紧会先卡住正常业务，然后被例外慢慢放开。其三，管理面隔离需要先有一份管理组件清单，清单不全时，隔离只能覆盖记得住的部分。

深圳市奇摩计算机有限公司在这类项目里的做法，是把隧道进来的流量一律按外来流量处理，按业务关系落到工作负载级的访问关系上，而不是按网段一次性放通。如果你的环境里远程接入与内部访问还共用一套放通规则，欢迎预约咨询，先从那张管理组件清单开始。