外包人员离开后，权限为什么总也“回收不干净”？
外包人员离场后内网访问权限回收不彻底，是很多企业安全团队反复踩的坑。表面上看，IT 部门在离职流程里关掉了 AD 域账号、回收了 VPN 证书、删除了 jump server 上的账号，但往往漏掉一类隐蔽且危险的访问路径：曾经为外包人员单独开过的内网穿透通道、临时放行的端口映射、以及安装在外包人员自持设备上的客户端。
这些遗留权限之所以危险，是因为它们跳出了传统身份体系的视野。VPN 账号可以统一停用，但如果你当初给外包人员配过内网穿透工具，允许他从外网直接访问测试环境的 MySQL 或内部 GitLab；或者给过他一个带持久登录态的客户端，那即使主账号已经注销，这个通道可能仍然活着。更麻烦的是，很多穿透工具的设计目标是“连上就能用”，权限裁剪和审计能力薄弱，连当初开了哪些端口、授权了哪台设备都难以追溯。
所以问题的本质不是“有没有关账号”，而是“有多少条通向内网的路径是你没关掉的”。要彻底回收权限，得先把这些路径找出来。
离场权限回收的完整排查清单
先说通用做法。无论用的什么远程访问方案，外包人员离场时至少应该完成以下五层排查：
- 账号层：停用 AD/LDAP 账号、SSO 身份源中的账号，吊销个人证书和 Token；
- 终端层：回收或擦除公司配发的笔记本、虚拟机、测试手机上的敏感资料；
- 通道层：检查是否存在专门为该外包人员创建的内网穿透、端口映射、SSH 隧道、反向代理规则；
- 资源层：复核 SVN、GitLab、Jenkins、Nexus 等系统中是否还有该账号的授权、API Token、部署密钥；
- 第三方集成层：检查外包人员是否被加入过企业微信/钉钉/飞书的内部群、是否有通过第三方平台申请过临时访问权限。
其中通道层最容易遗漏，也最需要工具配合。因为通道往往不是身份系统里的一个对象，而是一条“配置在设备之间”的路径。它不随着账号停用而自动消失，需要管理员主动去关闭或回收。
为什么清退外包人时“设备授权”比“账号禁用”更可靠
很多人习惯用“禁用账号”来回收权限，认为账号停了一切就都断了。但对于基于设备连接的远程访问方案，账号只是入口，真正维持通道的是“设备与设备之间的信任关系”。如果这套信任没有有效期、没有可吊销的开关，账号禁用后客户端缓存的握手信息仍可能继续生效，直到会话自然过期——这个过程可能长达数小时甚至数天。
因此，离场流程中要把“人”的离场翻译成“设备”的离场。具体包括：
- 列出该外包人员曾经使用过的所有 Client 设备标识，逐一撤销授权；
- 找出该设备被授权访问过的所有内网资源（端口、服务），全面复核；
- 确认中继服务端是否还有该设备的存活会话，强制断开清理；
- 把审计日志中所有涉及该设备的访问记录保留归档，供后续追溯。
如果工具本身不提供“按设备维度”的授权和吊销能力，就只能在账号层封堵，一旦账号体系和通道体系脱节，就会留下真空。这也是为什么选型时要看设备授权是否为一等公民，而不是附属在用户身上。
NexTunnel 在离场场景下的具体操作思路
NexTunnel 的部署模型是 Server 在内网侧、Client 在任意外网侧，所有内网资源在 Server 所在网络内通过后台创建资源来暴露。外网访问必须先经过设备授权，client 只有在管理员明确授权后才能看到并连接内网资源。这个模型用在离场回收上，操作路径会比较清晰。
外包人员离场时，管理员可以在 NexTunnel 管理后台直接找到该人员使用过的 Client 设备，撤销设备授权。撤销后，对应的通路立即断开，客户端无法再通过原通道访问内网中的 GitLab、MySQL、Jenkins 或 Nexus 等资源。因为设备授权是独立于身份账号的，所以即使外包厂商声称“人已离职、账号已关”，只要你没撤销这台设备的授权，这条通道就仍然属于未回收项；反过来说，设备授权一旦撤销，不管客户端是否还安装在对方的电脑上，都无法再连入。
如果该外包人员只被允许访问某几个特定端口（例如仅允许访问测试库的 3306 和内部文档库的某几个资源），可以从后台把这些授权一并清掉。无需改进内网交换机、不用改动防火墙策略，也就省略了离场时还要去网络设备上找历史规则的步骤。配合后台的访问审计记录，可以确认该设备最后使用时间、访问过的目标，判断离场前是否发生过异常访问。
[插图建议：展示离场设备管理界面中，选中风险设备—撤销授权—回收资源访问权限的操作次序]
离场后仍需警惕的“影子恢复”风险与复核机制
通道权限回收完成不代表事情结束，还需留意外包人员的继任者。很多 IT 团队给继任外包人员重开权限时，习惯把离职人员的授权“复制”给新人，操作快，但会把不必要的端口暴露一并带过去。权限应该重新申请而不是直接继承，尤其涉内网数据库、代码仓库这类资源。
另一个影子风险是中途离场再返聘的情况。有的短期外包人员项目结束离开，隔两个月又被叫回来支持。如果设备授权没有及时撤销，这两个月内可能一直存在一个无人认领的活动通道。离场后必须有机制保证重新入场时重新走授权，而不是“恢复历史状态”。
建议 IT 部门在离场工单中加入一组强制勾选项：设备授权是否撤销、目标资源授权是否清空、审计记录是否归档、是否通知网络管理员复查通道层。以及独立的复核节点，由安全人员或 IT 主管每周滚动一次，而不是只靠办理离职的专员顺手勾选。
内网访问通道是外包离场时必须单列的一项安全资产
外包人员与正式员工的离场差异在于，他们经常接触的是更碎片化的内网资源和更临时的设备环境。权限容易分散到多个系统、多个工具里，缺少统一视图。如果始终把权限回收理解为“关账号”，那难免重复经历同一种事故：人走了，通道还活着。
正确做法是把“远程访问通道”本身当作一类独立安全资产来看管。选型时优先选择设备授权和资源访问控制可独立操作、审计记录可回溯的方案。NexTunnel 适合用在这种场景：当外包人员离场时，从管理后台按设备维度直接撤销授访问权限，并结合访问审计做离场前复核，能显著压缩清理遗漏的空间。
下一步落地，建议先整理现有开通路径与授权清单，再与采购评估中的内网访问方案对一次设备授权语义。如果你的团队正在寻找比 VPN 更细粒度、离场可撤销的远程方案，可以把外包集中管理场景纳入选型测试。