上半年陪一个客户做了次网络安全审计，WiFi认证系统日志留存这块差点没过。审计老师翻得特别细，连一个月前某个时间点的某条NAT日志都能被揪出来核对。那次经历让我意识到，日志留存这件事如果只是"功能上有"，而没认真想过"怎么经得起检查"，检查来的时候基本就是手忙脚乱。

日志存了但不完整是最常见的问题

很多WiFi认证系统在宣传材料里都会写"完整记录上网日志""支持溯源审计"，但等你实际操作的时候发现，它所谓的"完整"跟你理解的不太一样。

最典型的缺失是NAT日志。根据合规要求，WiFi认证系统需要能够追溯到"哪个账号、在什么时间、用了哪个公网IP和端口、访问了什么目标"，也就是俗称的五元组信息。Radius认证日志只记录了用户什么时候认证成功、分配了什么私网IP，这不够。你需要的是在出口NAT设备上记录的转换日志——私网IP和端口到公网IP和端口的映射关系。

但很多WiFi认证系统跟NAT设备之间是解耦的，认证系统不知道NAT的转换记录，NAT设备也不知道这个IP背后是谁。要打通这两者的关联，要么在NAT设备上配置Syslog推送到统一日志平台，要么在认证系统里做Radius Accounting报文的关联分析。但不管哪种方式，都需要在方案设计阶段就把这条链路考虑进去，而不是等到检查来了才想起来补。

日志保留时长到底够不够

不同场景对日志保留时长的要求不一样。如果只是内部办公WiFi，一般要求保留六个月；如果涉及互联网上网服务提供，比如酒店、咖啡厅这类经营场所，各地网安的要求会更严格，有的地方要求保留十二个月甚至更久。

这里面的坑在于存储成本。假设每天产生一百万条日志，每条日志平均五百字节，一天就是五百兆，一年就是一百八十G左右。听起来不多，但加上NAT日志、认证日志、计费日志、Portal访问日志、管理操作审计日志，实际产生的数据量可能是这个数字的三到五倍。如果你用的是云服务器，硬盘扩容的成本需要提前算进去。

更大的问题是日志查询的性能。合规检查的时候，审计老师可能要求你在五分钟内查出来"上个月十五号下午三点到四点之间，IP地址为某网段的用户都访问过哪些目标"。如果日志量大了又没有建好索引，这个查询可能跑十几分钟都出不来。有一次我们在检查现场就是被这个问题卡住了，后来紧急写了一个按时间分区的查询优化脚本才算蒙混过关。那之后我把日志查询性能也列入了系统验收标准。

日志防篡改的证明链条

光存了日志还不够，你还得证明日志没有被篡改过。审计检查时，如果你拿出来的日志数据和原始格式不一致、时间线对不上、或者在存储过程中有任何可疑的修改痕迹，审计结论可能直接判不合格。

我们的做法是在WiFi认证系统的日志写入环节加了一层哈希链。每条日志写入的时候，除了日志本身的内容，还会写入上一条日志的哈希值，形成一条防篡改链。同时定期——比如每天凌晨——对当天的所有日志文件做一次SHA256摘要计算，并把摘要值写到一个独立的只写不删的审计表里。这样如果有人试图修改某一天的日志，当天的文件哈希就会变化，和审计表里的记录对不上。

还有一个容易忽略的点是日志的时间同步。所有产生日志的设备——认证服务器、Radius服务器、NAT设备、Portal服务器——必须用NTP同步到同一个时间源。审计的时候如果发现不同设备上的同一事件时间戳差了十几秒甚至几分钟，审计老师就会质疑日志的完整性和可信度。

这些细节平时运维不会有人提，但检查来的时候，一条一条都是必答题。与其到时候手忙脚乱，不如在部署WiFi认证系统的时候就把日志体系当作一个独立模块来认真设计。 另外还有一个实际工作中经常碰到的问题：日志存储介质的选型。很多人默认把所有日志存到数据库里，但认证日志和NAT日志的写入量远大于读取量，存数据库对写入性能是很大的考验。我们后来把热数据——最近三个月的日志——存在Elasticsearch里方便快速查询，三个月以上的冷数据压缩后存在对象存储里，查询的时候再从冷存储恢复。这个冷热分层方案不仅降低了存储成本，也保证了日常查询的响应速度。还有一个容易被忽视的细节是日志格式的标准化。不同厂商的设备输出的日志格式千差万别，Syslog、SNMP Trap、NetFlow的字段定义都不一样，如果不做统一的格式解析和标准化入库，日志分析平台在面对跨设备审计的时候就只能人工逐条比对，效率极低。所以在WiFi认证系统的日志方案设计阶段，就应该定义好统一的日志字段规范，要求所有接入设备都按这个规范上报或通过中转脚本转换后再入库。