校园WiFi计费系统的日志审计，看起来是一个安全合规问题，实际上更多是一个"日志能不能在需要的时候真的用上"的问题。很多学校的计费系统日志功能在功能列表里都有，但真要调日志的时候，往往会发现存的不全、查的不快、或者对不上账。这篇文章不从合规条款层面谈，而是从日志粒度、存储架构、检索效率三个角度，把"合规"的真实水位拆开说。

等保二级/三级对日志审计有明确要求：用户上网行为要可追溯，日志要保存至少六个月，并且不能被随意篡改。听起来是标准动作，但落到校园WiFi场景里，细节很多。比如：如果一个学生投诉"我没上过这个网站，为什么计费系统里有记录"，信息化老师能不能在半小时内拿出完整的行为日志？如果拿不出来，等保检查时就是扣分项。更复杂的情况是：公安网安部门协查，要求提供某个IP在特定时间段内的使用者信息，你的系统能不能在合理时间内给出准确结果？这些问题不是"有没有日志"能回答的，而是"日志好不好用"的问题。

日志的粒度也很关键。有的系统只记录了"谁、什么时间、访问了哪个IP"，但 IP 现在大量被 CDN 覆盖，光看 IP 根本判断不出用户到底干了什么。更好的做法是：记录域名，或者至少记录 HTTPS 会话的 SNI。但记录域名会带来新的问题：日志量会变大，存储和检索的压力都会上升。这就是典型的"合规成本"问题：要做到可追溯，就要多存数据；但存多了，系统复杂度和硬件成本都会涨。很多项目在方案阶段只算了"要不要做"，没算"要做到什么粒度"，等到等保检查前才发现日志不满足要求，再改就晚了。

还有一个容易被忽视的点：日志的完整性和防篡改。很多学校的计费系统日志是存在本地数据库的，如果信息化老师或者集成商工程师有数据库权限，理论上可以删改日志。等保要求日志"不可篡改"，但实际落地时，很多项目并没有做独立的日志服务器或者 WORM 存储。这个差距，在方案评审时很少被认真讨论。一个很现实的问题：如果信息化老师自己误删了日志（比如清理数据库时手滑），等保检查的时候怎么证明"不是我故意改的"？没有独立日志审计链的系统，在这点上很被动。

更现实的场景是：多运营商接入。很多校园WiFi计费系统后面会接多家运营商，学生可以选网。这种情况下，日志应该在哪个环节记？是在计费系统侧，还是在运营商侧，还是两边都要？如果两边记录的口径不一致，出了问题谁负责？这些不是纯技术问题，而是管理边界问题，但日志审计方案必须把它们考虑进去。否则等保检查的时候，检查人员问一句"你们多运营商场景下的日志怎么保证一致性"，现场就很容易卡住。

最后说一个容易被当成"过度设计"的点：日志的检索效率。等保检查时，检查人员可能会随机抽几个用户，要求你出示过去三个月的上网日志。如果你的系统查一个用户的三个月日志需要十分钟，那检查现场就很尴尬。日志审计不只是"有没有"的问题，还是"好不好用"的问题。能在项目前期想清楚这个，后期会省很多事。一个好的做法是：在方案阶段就要求厂商现场演示"随机查一个用户的三个月日志"，看他们能不能在合理时间内给出完整结果。演示得出来，说明日志架构是真的能撑住合规要求；演示不出来，说明"支持日志审计"只是一句销售话术。

补充一个很少有人提的点：日志的"可解释性"。很多时候，审计不只是"有记录"，而是"能解释"。比如：为什么这个学生在凌晨两点还在上网？日志里能看到时间戳和域名，但能不能快速生成一份"用户行为报告"，直接拿给辅导员或者家长看？如果只能导出原始日志，信息化老师还要手工整理，那日志的"可追溯"在管理层面就打了折扣。好的日志审计系统，不只是存数据，而是能让非技术人员也能看懂"发生了什么"。这个能力，在方案阶段很少被问到，但真到需要的时候，价值非常大。