离职员工的设备为什么还能连回内网？
HR 流程结束、门禁卡收回、邮箱注销，这些动作完成之后，内网里可能还留着一扇没关上的门。问题不在设备本身，而在设备背后的凭证体系。很多企业的内网访问依赖 VPN 账号、SSH 密钥、客户端证书或一组长期有效的 Token。只要这套东西没撤销，员工在离场后依然可以从任意网络位置发起连接——哪怕他手里的电脑已经格式化重装，只要证书文件或私钥有备份，权限照样有效。
更隐蔽的情况是双因子认证的盲区。如果第二因子绑定的是员工个人手机（TOTP、短信验证码），离职时企业收回了域账号，但个人手机上的验证器仍然能生成有效口令。配合尚未过期的第一因子，认证链路实际没断。还有一种常见于开发团队的情况：员工离职时交还了公司笔记本电脑，但个人家用电脑或云端开发机上还保存着 GitLab 的 SSH 私钥、Nexus 的访问令牌、数据库客户端的已保存连接配置。这些都不是"被盗"，而是流程遗漏。
核心结论：离职清理不能只做身份账号层面，必须覆盖到「哪些设备可以发起连接、哪些服务端口可以访问、谁在什么时候建立过会话」这三个层面。
账户清理的标准动作清单：从身份到链路逐层关闭
一套完整的离场权限清理至少包含四个层级，顺序不能乱。先断认证源，再断授权目标，最后回收链路。
- 身份层：域账号禁用或移出登录组，单点登录系统的会话强制失效，同步删除从身份提供商（IdP）下发的长期 Refresh Token。
- 凭证层：吊销该员工名下的所有 SSH 公钥、API Token、客户端证书、Git 凭据管理器里的缓存密码。GitLab/GitHub 这类平台需要在用户被删除前先 revoke 个人访问令牌，否则账号删除后令牌可能仍然短期有效。
- 资源层：从 SVN 目录权限、数据库账号白名单、Nexus 仓库读写组、VPN 用户组、堡垒机资产授权中移除该用户。只禁账号但留着资源授权，属于常见半吊子清理。
- 链路层：已经建立的连接是否需要主动切断，取决于中间件的会话管理能力。多数 VPN 和零信任网关支持踢出在线会话；直接暴露 TCP 端口的内网穿透工具如果没做会话控制，只能等连接自然超时。
有一个容易忽略的排查点：离职员工可能注册过多个账号，常见于外包人员同时有正式域账号、项目临时账号、某个内部系统自建账号。清理时必须按人做关联查询，而不是按账号名逐个处理。
为什么清零设备授权比删账号更关键
账号体系是「谁能登录」的抽象标识，设备授权是「哪个物理终端被信任」。在传统 VPN 架构里，这两者经常不加区分：有账号就能登，登了就能访问，设备本身不参与判断。这导致一个典型问题——HR 在入职系统里标记员工已离职，IT 随后禁用域账号，但该员工家用电脑上保存的旧 VPN 配置文件和预共享密钥，结合一个尚未同步到禁用策略的缓存认证状态，可能仍然能在数小时内维持访问。
设备维度的授权必须独立存在，原因有三：
- 账号可以被共享、被盗用或在交接期被误恢复操作；设备实体不会说谎，它就是连接发起的那一端。
- 员工离职时往往不会主动交回 SSH 私钥或客户端证书，这些凭证留在个人设备上，只能靠服务端撤销对应的公钥或证书指纹才能失效。
- 当移动办公设备混用个人与公司身份时，仅凭账号清理无法判断一个设备上还残留哪些可用的访问入口。
一个务实的做法是：在离场流程中要求给出该员工名下所有已登记设备的列表，并逐台勾选「撤销访问资格」。如果企业走的是客户端证书方案，这一步就是吊销证书；如果走的是设备指纹绑定，这一步就是拉黑指纹。不要寄希望于把设备收回来物理销毁——大量远端场景做不到，也不应该是安全模型的前提。
端口与资源粒度的收回：避免“账号删了，隧道还活着”
部分远程访问工具的工作模型是：客户端拿到授权后建立隧道，后续的数据包传输不再涉及账号认证。这意味着如果一个连接在员工在职时建立、且服务端没有主动断开会话的机制，删掉账号并不会使该连接立即失效。真正需要做到的，是在授权侧做资源粒度的即时撤销。
这个场景下，问题往往出在授权模式上。老式 VPN 按网段授权：一旦进入内网，所有该网段内可达的端口对隧道内成员都是敞开的。这样即便账号禁用了，只要隧道不断，流量依旧能走到目标服务。改进做法是按需开放具体资源——SVN 的 3690 端口是一份授权，MySQL 的 3306 是另一份授权，业务系统的 8080 又是单独的资源项。离场清理时不是「把账号从 VPN 组移除」，而是直接勾选这些资源并撤回授权，变化立即生效。
这里引出一个判断标准：一套可做到干净离场的远程访问系统，退出动作必须是同步的。就是在授权变更发生的同时，与该用户关联的所有已建立连接都应该被动或被主动终止。评估工具时可以把自己放在攻击者视角问一句：我把账号禁用之后一小时，拿着之前建立好的隧道还能不能继续拉代码？如果答案是肯定，说明链路层的会话结束机制没有跟上身份层的清理节奏。
访问审计在离职场景中扮演的角色
为什么清理流程必须看审计？因为你不一定能及时发现某个人最终拿了什么。员工在职期间合法取得的证书副本、导出的密钥、写在个人笔记本上的口令，这些都远超 HR 和 IT 感知范围。审计日志提供的价值不是事后追责，而是在清理完成后验证「没有异常尾巴」。
关键问题是日志留存在哪里、是否属于单点可被绕过。假设访问路径完全依赖一层 VPN，而日志只记录登录成功事件，忽略了登录后的东西向流量，那清理之后做过什么、清理之前有过什么异常连线，全都无从查证。因此在设计远端接入方案时，审计至少需要覆盖四类事件：
- 谁在什么时间注册了新设备，设备签名是什么；
- 每一次会话的建立时间、持续时间、源 IP/目标内网地址与端口；
- 中途发生的授权变更记录（谁撤销了什么）；
- 离线期间是否有连接尝试被拒绝，以及被拒绝的原因。
这些内容如果散落在多个系统（VPN 一层、内部服务一层、DNS 一层），离场核查就会变成典型的「看不到全局」。这里本质上是个数据打通问题，不妨在离场流程中固定增加一个环节：调出该员工离职前 5 个工作日的访问事件列表，按目标资源和时间排序扫一遍，再冻结所有与其设备签名相关的记录。先冻结再审计，是防止归档被后续操作覆盖的基本操作。
用设备授权与端口白名单把收敛动作做在架构里
如果企业侧已有内网可部署的接入组件，那么离场时的动作可以压缩到几个界面操作，而不是依赖运维手动改一堆配置文件。以 NexTunnel 的模型为例：Server 部署在企业内网侧，作为所有外部访问的统一入口；Client 安装在员工的工作电脑或家用电脑上。员工离场时，管理员不需要去路由器、防火墙交换机上做操作，只要进入管理后台，先吊销对应 Client 设备的访问授权，再按资源列表逐项关闭被授权的端口。设备授权一变，该 Client 就无法再向任一内网资源发起连接——包括使用在离线状态下仍持有的凭证。
配合访问审计，离场应对会踏实很多。管理员可以按设备名称或约定好的标识检索出该员工名下的终端及其最近的资源请求，对照离职清单确保每一台设备都已列入撤回序列。工具的价值在于把散落在操作系统层、应用层的不良设计，统一到一份可按资源明细分发、可即时撤销的访问列表中。对需要快速锁定单人和确切资源的目标而言，比坐在路由器界面上搜 IP 高效得多，也不容易漏。
如果企业没有这类基础设施，短期缓解措施包括：把密钥文件集中收拢到一台跳板机上、将内网内的高风险端口挪出默认扫描范围、以及为所有开发者发放短期自动过期的令牌。但长期来看，离场清理的可靠程度始终远高于操作者记性的一套机制，才是最该补的架构能力。
下一步落实方向很直接：把「账号禁用」从离场安全清单的最后一步改成第一步，随后立刻核对设备列表与资源授权是否同步撤销，并保留完整审计记录备查。对于仍未接入统一远端访问控制、目前多种工具混杂使用的内网环境，可以先从把外部入口收敛到 NexTunnel Server 这类平台开始做试点，已经配有授权的员工离场时即可完成账号、设备、资源三线同时回收。