WiFi认证系统上线后，很多人会关注能不能连上网、认证快不快、页面好不好看，但很少有人认真考虑过日志保存。直到有一天监管部门来检查，或者安全团队需要溯源某个异常流量，才发现日志要么没保存，要么字段不全，要么查询慢得离谱。认证日志是网络安全的黑匣子，平时不起眼，出事时价值巨大。

一、日志要保存哪些字段

很多人觉得认证日志就是“谁什么时候连了网”。但实际上，一个完整的认证日志至少应该包括：用户身份标识、终端MAC地址、终端IP地址、接入时间、下线时间、接入位置（AP或SSID）、认证方式、认证结果、失败原因、使用的终端类型、访问的流量摘要等。这些字段共同构成了事件溯源的基础。

如果日志里只有用户名和上线时间，安全团队发现一个账号被盗用时，根本无从判断是在哪个设备、哪个位置发生的异常。如果日志里没有失败原因，运维团队排查“用户连不上网”的问题时只能靠猜。字段缺失是后期审计无力的最大原因。

不同场景对字段要求也不同。校园网需要关联学号，企业网需要关联工号，酒店需要关联手机号或房间号，医院需要关联住院号或就诊号。认证日志的字段设计要结合业务系统，不能只用系统默认模板。

二、日志保存多久才够用

保存期限取决于合规要求和实际业务需求。网络安全法、等保2.0、公共场所无线上网安全管理条例等法规，通常要求上网日志至少保存6个月到1年以上。但很多企业为了省存储成本，只保留30天或90天，一旦遇到跨季度、跨年度的事件，根本查不到。

从安全运营角度，建议至少保存12个月以上的原始日志。对于高敏感场景，比如政务、金融、医疗、关键基础设施，建议保留18到24个月。日志保存不是一次性存储成本，而是安全投资和合规能力的一部分。

需要注意的是，保存期限不仅指原始日志文件，还包括索引和元数据。如果日志文件存了两年，但索引只保留三个月，查询两年前的记录仍然会非常慢，甚至查不到。日志系统要做全生命周期的管理规划。

三、日志完整性和防篡改同样重要

日志保存下来之后，如果可以被随意修改，那就失去了作为证据的价值。一些企业把认证日志存放在普通数据库或文件系统里，管理员有权限直接删改。这种做法在合规检查时会被质疑，安全事件发生时也无法作为可信证据。

建议对关键日志做哈希校验、只写存储或WORM机制。日志一旦写入，就不能被修改或删除，只能按策略归档。对于特别重要的场景，还可以考虑把日志同步到第三方审计平台或不可变存储中，形成多重保障。

另外，日志的时钟同步也很关键。如果认证服务器、AP、RADIUS、数据库的时钟不一致，日志时间戳就会出现偏差，溯源时无法准确还原事件顺序。整个认证链路必须统一部署NTP或PTP时间源。

四、日志查询和分析能力决定日志价值

存了日志不会用，等于白存。很多企业日志堆积如山，但查询一次要十几分钟，甚至要运维人员手写SQL。这样的日志系统在真正需要响应安全事件时，基本派不上用场。

好的日志系统应该支持多维度快速检索：按用户名、按MAC地址、按IP地址、按时间段、按AP位置、按认证结果等。对于大规模部署，还需要支持分布式日志存储和全文检索。安全团队通常需要在几分钟内定位一个账号在指定时间段的所有接入记录，响应速度直接影响处置效率。

除了检索，日志还应该具备基本的分析能力。比如统计失败认证次数、识别异常的MAC漂移、发现同一账号多地点同时登录、检测暴力破解行为等。这些分析可以通过规则引擎或SIEM平台实现，但前提是认证日志格式规范、字段完整、时间准确。

五、项目建议：把日志设计当成正式需求

在建设WiFi认证系统时，建议把日志保存和审计作为正式需求写进方案。不要等系统上线后再补日志模块。要明确要求：日志字段清单、保存期限、存储容量、查询响应时间、归档策略、防篡改机制、与SIEM或日志平台的对接方式。

上线后要定期做日志审计演练。模拟一个安全事件，从发现异常到查清楚源IP、账号、设备、位置，全过程需要多久。演练能暴露出日志系统真正的问题，而不是等到真实事件发生时才发现漏洞。

WiFi认证系统的日志不是运维副产品，而是安全体系和合规能力的重要组成部分。日志做好了，网络出了事才能查得清、说得明、拿得出证据。