日志留存180天，卡住内网访问的现实在哪
等保2.0二级及以上系统对日志留存有明确要求：安全设备、网络设备、应用系统的操作日志和访问日志至少留存180天。很多企业做到服务器本地日志留存并不难，真正出问题的是内网访问日志——尤其是外网运维人员、外包团队远程访问内网系统时产生的连接日志、操作来源、目标资源和时间轨迹。本地服务器日志只记录了“内网某台机器登录了系统”，但看不到“这次登录是从哪台外网设备、通过哪条通道进来的”。一旦要追溯责任或应对安全检查，日志链是断的。
内网访问日志合规的难点不在存不存，而在存什么、从哪个节点取、取出来的字段能不能对应到审计要求。等保的日志不只是“有记录”，还要求能关联到人和设备、能还原操作路径、能支撑至少六个月后的事件回溯。下面分几块把可行做法讲清楚。
内网访问日志该从哪些节点采集
先看通用采集位置。内网访问场景里，有价值的日志节点通常是这几类：
- 应用系统自身日志：SVN、GitLab、MySQL、Jenkins 自带的登录认证和操作日志，字段最细但分散。
- 操作系统认证日志：SSH、RDP 登录成功/失败记录，能确认账号和来源 IP，但看不到应用层操作。
- 网络设备连接日志：防火墙、路由器的会话记录，能看到来源和目标端口，但无法关联到具体账号。
- 通道或代理层日志：如果远程访问走 VPN、堡垒机或内网穿透，通道层的接入与转发日志是唯一能把“外网某设备”和“内网某资源”关联起来的位置。
从合规角度，只存应用日志不够，只存网络设备会话也不够。最常被忽视的是通道层：外网访问请求在进入内网前经过的那一跳，如果不在这里落日志，后端系统的来源地址可能就是统一的内网网关或跳板地址，审计时没法追溯到真实的远端设备。
[插图建议：外网设备经通道层访问内网业务系统的日志采集节点示意图]
日志留存180天的存储与切分方案
留存180天先要确定数据量。以中等规模团队的远程访问为例，如果每天产生接入日志、端口访问日志、设备上下线记录共约20万条，每条平均300字节，单日约60MB，180天约11GB。这个量级不高，问题在于性能衰减：直接关系型数据库堆表查询，三个月后的按设备和目标过滤会明显变慢。
通用做法分三档：
| 规模 | 存储形式 | 查询方式 | 注意点 |
|---|---|---|---|
| 小团队（单日低于5万条） | 关系型数据库按月建表 | 应用后台按日期区间检索 | 归档前做索引瘦身，热表只保留常用组合索引 |
| 中等规模（单日5万-50万条） | 关系库热存储 + 压缩归档 | 近30天实时查询，历史归档按需解压恢复 | 归档内保留设备和时间索引，压缩影响查询前需先恢复 |
| 大流量（单日50万条以上） | 时序数据库或列式存储 | 实时期全量查询，冷期走批量导入后分析 | 冷热分层要在写入后数小时内完成 |
不管哪一档，时间字段必须做截断存储，接口记录里别放完整 Token、图形验证码或密码字段。审计要的是来源在哪里、何时连进来、访问了哪个资源、连了多久，不是要把原始凭证序列化进去。
等保审计无法回避的三类字段
留存180天不是把日志堆起来就行。审计时检查人员通常看三类字段能不能快速组合出来：
- 谁（设备标识与账号标识）：不能只有内网账号。外网访客走的哪台终端，需要一台设备一个稳定标识，这个标识和最终登录的应用账号要在日志里面能关联。
- 何时（接入与断开双重时间）：只记登录成功不够，还要打通话时长和会话异常断开。等保审计的一次完整追溯至少要能回答“这台设备在某个时间段内有哪几次接入，去了哪些资源”。
- 去了哪里（目标资源与端口）：SSH 到某台服务器、445 到文件服务的哪一种协议尝试、SQL 连接到了哪个端口。端口级的目标记录是很多系统日志里缺失的。
纯内网运维场景，要拿到这些字段需要各业务系统自己去改日志格式，周期长且分散。真正的改造成本在通道侧：如果通道已经把外网设备和中间连接过程的数据收掉，后端就无需每个系统都做来源设备改造。这里说的通道层，正是远程访问方案里需要重点对比的对象。
[插图建议：三类审计字段与采集节点对应关系表]
用NexTunnel把通道层审计做实
如果企业选择以通道形式做内网访问，NexTunnel 的玩法是把审计点集中在 Server 这一侧。Server 布置在内网侧，所有外网 Client 的访问都会先落到这台 Server 上，然后由 Server 统一向内网系统发起连接或转发。这条位置上，NexTunnel 可以记录进来的 Client 设备标识、请求连接的资源和端口、建立和断开时间，再配合管理后台的端口白名单和设备授权控制，让“能访问什么”和“谁访问了什么”成对出现。
实际落地不是等查日志时才去东拼西凑。管理员在 NexTunnel 管理后台为不同设备建立授权模板、指定目标资源端口，这类配置本身就是策略记录；Client 连接后产生的是实际访问流水。两边在后台按设备、资源名称、端口和时间区间拉起来查看时，就能还原一次来自外网的完整动作。对等保整改来说，这套日志的完整度在于：
- 来源不会被藏在“统一网关地址”后面，而是对应到具体 Client 设备；
- 目标落到端口级，可以直接核对到资源清单和端口白名单；
- 授权与访问流水互相对应，方便检查方做闭环核查。
日志留存方案选型对比
把面上几条路放到一起看：
| 方案 | 日志采集效果 | 改造量 | 字段完整度 | 最常见风险 |
|---|---|---|---|---|
| 纯应用系统改造 | 应用层操作最细 | 每个系统单独改 | 高，但无法关联外网设备 | 外网运维人员根本走不到应用日志采集的原始节点 |
| VPN 通道 + 日志 | 接入日志有的，目标资源和端口通常不全 | 中 | 中 | 来源可查，去看哪个内网系统要另查各系统日志 |
| 部署内网侧通道并统一审计 | 接入、目标资源、端口、时长整体可查 | 低 | 高 | 需选型时确认是否留存端到端路径而非只留控制流 |
很多团队在整改中打补丁式堆日志：花一个月让 GitLab 改日志、花三周加 SSH 登录采集、再拼一个 ELK 上的看板。表面留存够了，等真正做事件回溯时发现三张日志表对不齐同一条访问请求。把采集点前推到通道侧，是从源头上减少这种结构错位的办法。
180天留存策略如何不拖垮性能
留存和查询是两件事。不要把六个月的明细在没有聚合的情况下硬堆在线表。参考做法：
- 日常合规查询只保留近30天原始明细，30-180天进入压缩归档，归档保存的是结构化检索转出的字段。
- 按周或按日切割，冷数据保留目录级索引文件即可，不必全库一表。
- 审计导出前先按格式化输出，再关闭归档并转存一次性分析副本。
如果走 NexTunnel，这类切分和归档并不直接依赖你写配置。实践中只需要定期在后台将180天之内的主动查询列为常规任务，由团队内部把管理层看的导出结果格式掉。留存不是一个一次性动作，而是纳入周期自检清单的一部分。
结合前面的分析，建议以内网侧统一采集为主、后端应用日志为辅推进整改。已经部署过 Server 的企业可直接把 NexTunnel 作为外部准入的审计节点，以目标资源授权和访问流水互证方式整理日志。尚未落地的，先做一次自身整改前的审计字段梳理：哪些系统、哪些通道的哪些字段已经可查，缺到何种程度，再论是改内部系统还是换方案。