合规是底线，不是可以商量的事

校园网出口的日志留存要求，这几年是越来越明确的。《网络安全法》规定网络日志留存不少于六个月，等保2.0对教育行业的校园网有更细化的要求，各地公安机关在执法力度上也有差异，但底线不能碰。

很多学校在选型阶段把日志审计当作"配一配就行"的附属功能，但上线以后才发现系统能力不够，要么字段不完整过不了检，要么查询响应太慢影响日常使用，要么留存周期管理不严谨，到期数据没有自动清理也没有人知道。这几类问题都是合规的隐患。

有几个细节在选型和部署阶段要逐项确认清楚。

日志字段完整不完整，决定能不能过检

监管部门查日志的时候，最关键要看的是"四个要素能不能关联起来"：账号、MAC地址、IP地址、上网时间。这四个字段如果记录不全，或者时间精度不够，回溯的时候就会卡住。

比如学生反映"有人用我的账号上网"，要证明不是自己用的，首先要有账号对应的上网记录，然后有当时的终端MAC和IP，再对应该时间段的上线记录。如果日志里只有账号和时间，缺少MAC和IP，追溯就无从下手。

日志字段的完整性要看这几项：账号信息（学号或者工号）、终端MAC地址、分配到的内网IP、上下线时间、访问的目标地址。这些字段在日志记录里一个都不能少。

查询响应速度，影响的是日常运维效率

日志审计系统不是只给监管检查用的，日常运维出问题时也要查日志。

一个典型的场景：学生投诉说某个时间段上不了网，运维人员要查这个账号当时的状态——是正常下线还是异常掉线，是账号问题还是网络问题。如果日志查询响应要等几十秒甚至几分钟，每天处理几十个投诉的时候，运维人员的体验会非常差。

有些供应商的日志系统查询响应慢，是因为底层存储用的是通用数据库而不是专门优化过的时序库或者全文检索引擎。大规模日志数据下，两种架构的查询速度差距很大。选型的时候要问清楚查询响应时间的承诺，并且把这个指标写进合同。

留存周期自动管理，数据过期了怎么处理

180天的留存周期，意味着系统要管理180天以前的数据。日志数据量随时间快速增长，如果系统没有自动清理机制，磁盘会持续膨胀，直到系统性能下降或者磁盘写满。

有些系统会设置自动归档策略：每天或者每周把超过留存期限的日志数据归档压缩，释放活跃存储空间。归档后的数据还能不能查，怎么查，这个机制要提前了解清楚。

如果系统没有自动清理机制，就要靠人工定期处理。这个事情一开始有人管，后面换人了就容易忘掉，积累下来的问题迟早爆发。

数据安全，不能只靠"系统安全"

日志里记录的是真实的用户上网数据，属于敏感信息。系统安全只是第一道防线，日志数据的访问控制、日志导出权限、查询记录审计这些细节同样重要。

比如系统管理员查询某个学生的上网记录，这个操作需不需要记录，谁来审核这个权限，查询记录保存多久。这些不是选型的硬指标，但在实际运维中如果缺乏这些管控，就会成为潜在风险点。

合规要求一般会提到日志存储要用国密算法加密，这个要求在选型阶段要确认清楚。如果供应商的产品不支持，要问清楚替代方案。

和计费系统、代拨网关的对接，接口稳不稳

日志审计系统不是独立运行的，它要从代拨网关、认证平台、计费系统收集各类数据。接口能不能稳定对接，数据格式能不能对齐，这几个问题在上线前要验证清楚。

常见的坑是：各子系统是不同供应商提供的，日志格式不统一，对接的时候要额外做数据转换开发，成本高工期长。或者对接以后数据有延迟，认证日志和上网日志时间戳对不上，追查问题的时候很麻烦。

如果是同一家供应商的一体化方案，对接风险相对小一些，但也要问清楚数据流向和接口标准。

说在最后

日志审计这件事，合规是底线，但它的价值不只是"过检"。一套好用的日志系统，在日常运维出问题时能快速定位，在安全事件发生时有数据可追溯，在学生投诉处理时能还原真相。选型的时候把这几个维度都考虑到，后续的运维和合规工作都会轻松很多。