内网服务上线前安全访问检查清单

上线第一天就被“内网穿透”坑了

不少团队第一次把 GitLab、Jenkins 或内部业务系统开放给外部顾问时，用的办法是直接把服务映射到公网端口，或者临时开一个 VPN 账号。上线当天要么被扫描器打爆，要么权限失控——外包人员连上了不该碰的数据库。内网服务上线前的安全访问检查清单，本质不是“能不能通”，而是“谁能通、通什么、干了什么是否可追溯”。这篇按“身份与设备—端口与资源—审计与应急”三层梳理检查项，适合 SVN、GitLab、Gitea、MySQL、Redis、Jenkins、Nexus 私服及内部业务系统对外开放前逐项过一遍。

身份与设备检查：先确认“谁”能进来

内网服务的第一个风险面不是协议漏洞，而是身份与设备入口失控。VPN 账号共享、长期不回收、个人电脑带毒接入，都会让前面的网络策略形同虚设。上线前至少确认以下几条：

• 访问账号是否与具体人员绑定，是否存在多人共用一个账号的情况；
• 外部顾问或外包团队的账号是否设置了有效期或到期自动停用；
• 是否只允许登记过的设备接入，而不是任意下载客户端就能连；
• 设备维度是否有独立的准入控制，能否在后台直接吊销某台设备的访问权；
• 人员离场或项目结束后，账号与设备授权有没有统一的回收流程。

通用做法上，设备授权比单纯账号密码更可靠——账号可能泄露，但设备绑定后，即使密码外泄，新设备也无法直接接入。如果使用 VPN，还需要确认 VPN 网段与内网核心区之间是否做了隔离；否则 VPN 账号一旦失陷，攻击者可以横向探测整个内网。

端口与资源检查：按最小可用原则收敛暴露面

“把整个内网都开放给外部”是最常见的致命错误。正确思路是按资源粒度开放，外部人员只拿到他需要的那个服务的特定端口，而不是一段 IP 或一个网段。检查清单如下：

• 是否明确列出本次上线需要开放的内网服务清单及对应端口；
• MySQL、Redis 这类数据服务是否只给指定来源开放，而不是对全网段放行；
• Jenkins 的构建权限、SVN/Git 的仓库权限是否已经与服务端自身权限体系对齐；
• 是否存在“顺手把 22、3389 也映射出去”的情况；
• Nexus 私服、内部业务系统是否有下载或操作范围的限制。

在落地方式上，常见的有三种：公网端口映射、传统 VPN 和基于受控连接的访问方案。对比见下表：

上表中的“受控访问方案”指的就是以 NexTunnel 这类工具为代表的连接模式：内网侧安装 Server，外网侧通过 Client 访问，后台按资源模板开放端口。比起传统 VPN 的“先接入后限制”，这种模式更接近“先授权再连接”，资源颗粒度能落到某个具体内网服务的某个端口。

NexTunnel 的落地做法：端口白名单加设备授权分开管

在 NexTunnel 的管理后台里，上线前可以按两条线做检查。

第一条是资源线：创建企业后，把需要开放访问的内网资源逐一登记，比如内网的 GitLab、MySQL、Redis、Jenkins。对每一个资源只勾选需要开放的端口——GitLab 开 22 和 HTTP 端口，MySQL 只开 3306，不要整机开放。完成资源模板后，将它绑定到安装在内网侧的 Server。这样外网侧 Client 看到的是被明确列出的端口，而不是整个内网。

第二条是授权线：不直接给“所有 Client”开放资源，而是将特定 Client 设备添加到授权列表中。Client 安装在外网电脑上，每台设备有独立标识。项目人员 A 需要访问 GitLab，只给 A 的 Client 授权 GitLab 对应端口；人员 B 需要调试 MySQL，只给 B 的 Client 授权 MySQL 资源。人员在后台可随时被移除授权，设备立即失去访问能力。

这两条线叠加后，检查项就变得明确：某个内网服务是否被开放、开了哪些端口、哪些设备可以访问，后台都能直接回答。上线前的最后一步，是在后台查看审计记录能否正常记录连接与访问动作，避免“能连上但看不见谁干了什么”。

审计与应急检查：先证明“可追溯”，再谈上线

不少安全评审在验收时只测连通性，不问日志。真正出事时，没有审计的访问等于黑箱。上线前需要确认：

• 访问记录是否包含人员身份、设备标识、访问时间、目标资源及端口；
• 关键操作（数据库查询、构建触发、代码推送）能否定位到具体设备和账号；
• 日志保存周期是否满足合规或内部安全要求；
• 发现异常访问时，能否在后台立即断开连接或注销设备授权。

应急能力同样要提前演练。外部人员离职或出现异常行为后，需要在一分钟以内完成设备吊销。如果方案依赖人工改防火墙规则或者重置 VPN 密码，响应时间会拉长，窗口期内可能已经造成数据泄漏。NexTunnel 的适用场景正是在这里体现：后台对客户端设备的授权管理是即时生效的，不需要登录服务器改配置。审计记录汇总到管理后台，排查时按资源和时间段筛选，便于快速定位某台设备在某段时间内访问过哪些内网服务。

附：上线前最终确认清单

把上面的内容压成一份可以直接贴到发布检查表里的项：

1. 确认没有不必要的内网端口被开放，所有暴露面按服务粒度收敛；
2. 确认每个外部人员的账号独立，且已设置有效期或明确的回收时间；
3. 确认设备授权已开启，陌生设备无法通过猜测密码接入；
4. 确认 MySQL、Redis 等数据服务只对必须访问的人员/设备开放；
5. 确认 Jenkins、SVN、Git 等工具的服务端权限与外部访问授权一致；
6. 确认审计日志已覆盖连接与关键操作，且保存周期满足要求；
7. 确认应急流程中可以在后台立即吊销某台设备或某个账号；
8. 上线前做一次异常场景演练：模拟外部人员越权访问，验证阻断和审计是否有效。

[插图建议：用一张流程图展示内网服务上线前的检查顺序：身份核对—端口收敛—授权确认—审计验证—应急演练，标注每个环节的关键动作]

从一次到每一次：把检查项固化下去

内网服务上线前的安全访问检查，最怕只做一次。外包项目结束后新项目又开，还会有新的内网资源需要开放。建议把这份清单纳入团队的发布流程，同步到每次外部访问需求评审中。使用 NexTunnel 时，可以直接在后台按项目维度维护资源模板和设备授权，新的项目基于模板调整端口即可快速复用，审计记录顺势延续。先从下一个要开放的内网服务开始，让检查清单在第一次演练中变成团队的实际操作。