WiFi认证有个绕不过去的合规问题：按照网络安全法的要求，提供公共上网服务的场所必须记录用户的上网日志，包括身份信息和访问记录，保存时间不少于六个月。这个要求各家酒店、商场、学校的管理方都知道，但真正能做到位的项目并不多。问题不是出在"要不要做"，而是出在"怎么做才能长期可靠地做下去"。日志看似简单——不就是把数据记下来存着吗？但实际上涉及数据格式定义、存储容量规划、查询性能、数据清理策略、备份恢复、和外部监管平台的对接，每一项都不算复杂，但组合在一起就是一个需要认真对待的系统工程。

日志要记什么，格式怎么定。

最基本的合规要求是记录用户身份信息和上网行为。身份信息包括认证时使用的手机号、微信号、身份证号或者会员账号，以及设备的MAC地址、IP地址、认证时间。上网行为包括访问的目标IP、目标端口、上网开始时间和结束时间。这个字段列表看着不多，实际上遗漏非常常见——很多WiFi认证系统只记录了认证成功的事件，没有记录认证失败的事件；只记录了上线时间，没有记录下线时间，导致无法还原用户完整的上网时间段；只记录了内网IP，没有记录经过NAT转换后的公网IP，在需要追溯具体用户时缺少关键信息。

字段定义的另一个问题是类型规范。MAC地址是用冒号分隔还是用横线分隔？IP地址是存字符串还是存整数？时间戳用的是系统本地时间还是UTC时间？这些看起来很小的差异，在需要跨系统关联数据或者向监管部门提供证据时会带来巨大的麻烦。建议在项目初期就定好日志字段的规范文档，每一种字段的长度、格式、示例值都写清楚，所有模块的日志输出必须遵守这个规范。

还有一点容易被忽略：日志的完整性校验。如果日志文件可以被任意修改，那么这条日志在合规审查中的证据效力就大打折扣。对于关键的安全审计日志，应该考虑加入数字签名或者至少写入一次性的只写介质（Write Once Read Many），确保日志在写入后不可篡改。

存储容量的规划和日志的轮转清理。

这是一个在项目初期经常被低估的问题。以一个300间客房的酒店为例，日均入住率70%，每个房间平均1.5人连WiFi，每人每天产生约500条上网行为记录。那么每天的日志量大约是：300 × 70% × 1.5 × 500 = 157500条记录。每条记录包括身份信息和行为信息，按每条约300字节计算，每天产生约45MB数据。保存6个月就是约8GB。这个量对于现代存储来说不算大，但如果再加上Apache/Nginx的访问日志、系统日志、应用日志，实际需要的存储空间至少是这个值的3-5倍。

存储容量规划完了，接下来的问题是日志的轮转清理策略。合规要求是把日志保存至少6个月，但不需要保存所有的日志——比如系统debug日志、访问统计日志不需要保存这么久，可以设置30天的保存期限。需要长期保存的是合规审计日志和认证记录。清理策略要做分层设计，不同类别的日志有不同的保留期限，设好后通过自动化脚本来执行清理，避免人工手动删文件。

另外，日志存储的介质也需要考虑。如果日志直接写在认证服务器的本地磁盘上，一旦磁盘坏了或者服务器宕机了，日志就丢了。关键日志应该有异地备份——定期把日志文件同步到NAS或者云存储上。对于有合规审查风险的项目，还可以考虑把日志实时推送到独立的日志服务器上，和业务服务器做物理隔离。

日志检索和合规审查时的导出能力。

日志存着不是目的，能在需要时快速查出来才是目的。监管部门来检查时，通常会要求你提供某个特定时间段内、特定用户的完整上网记录。如果你说"日志都在服务器上，但需要花两三天来查"，这个回复在合规审查中会被认为日志管理不达标。

日志的检索能力取决于存储方式。如果把日志全部存入Elasticsearch这类全文检索引擎，查询速度很快但存储成本高；如果存在关系型数据库里，查询需要建索引但检索灵活性不如搜索引擎；如果存在普通文本文件里，查询几乎只能靠grep，效率极低。在预算允许的情况下，把热数据（最近30天的日志）放入Elasticsearch供日常查询，把冷数据（30天到6个月的日志）压缩归档到文件存储或对象存储上，是一个比较成熟的分层存储方案。

导出的格式也需要提前约定。监管部门通常要求导出为Excel或者CSV格式，但不同地方的网安部门可能有不同的模板要求。在系统设计阶段就应该考虑日志导出功能的灵活性——支持按时间范围、按用户身份、按认证方式等维度筛选，导出格式可以选择CSV或Excel，且导出操作记录本身也应该记入操作日志以防止滥用。

对接外部监管平台的技术准备。

很多地区的网安部门要求公共场所的WiFi认证系统将认证日志实时或准实时地上报到指定的监管平台。对接方式通常是标准化的API接口或者Syslog推送。技术实现本身不复杂——就是在系统里加一个日志转发模块，把符合格式要求的日志定期打包发送到指定的服务器地址。

但实际落地中，这个对接往往会出现各种意料之外的问题。比如对接文档给的API地址可能因为网络限制无法从酒店内网直接访问，需要配置代理或者通过VPN隧道；传输协议可能是老旧的FTP，而不是更安全的SFTP或HTTPS；数据格式的字段顺序和命名规范和你系统里现有的日志格式不完全一致，需要做字段映射和格式转换。

处理这些问题最好的方式是在项目初期就和当地网安部门做一次对接测试，搞清楚实际的传输方式、网络要求、数据格式规范，把这些要求纳入系统设计的约束条件里。不要在系统上线之后才去对接，那个时候如果发现网络不通或者格式不兼容，改造成本要高得多。

日志系统的运维监控。

日志系统本身也需要监控。日志文件快要写满磁盘了、日志上报到监管平台的链路中断了、日志清理脚本执行失败了——这些问题如果没有人去关注，会给合规带来巨大风险。对日志系统的监控指标应该包括：日志存储空间使用率、日志写入速率是否异常（突然大幅增长或下降）、日志同步到备份位置的成功率、向外对接监管平台的发送成功率。

有些项目的做法是把日志告警接入现有的运维监控体系，和其他业务告警一起管理。这种做法是对的——日志系统的稳定性和业务系统的稳定性应该是一体的，不能把日志当成一个"反正平时也不怎么用"的附属功能来对待。当合规审查真的来临时，日志的完整性和可检索性就直接决定了你能不能顺利通过审查。