做酒店宾馆无线实名认证，很多人把关注点都放在"认证能不能通过"上，觉得只要让住客输入个手机号验证一下就行了。但认证通过只是第一步，整套系统能不能在合规检查的时候站得住，看的其实是日志留存那一块做得怎么样。

说个实际的情况：现在很多地方公安来检查宾馆上网合规的时候，已经不怎么看你有没有认证页面了，直接问"日志在不在？能查多长时间的？能不能按时间按房间按IP导出？"这三个问题答不上来，基本上就属于不合规。

法规要求日志留存多长时间

网络安全法第二十一条明确要求网络运营者留存网络日志不少于六个月。公安部第82号令对互联网上网服务营业场所也有日志留存的具体规范。宾馆虽然不属于网吧，但在提供公共上网服务这一点上，监管逻辑是一致的。

六个月是个底线。有些地方已经要求更长时间，比如一年。而且不仅是"有没有日志"的问题，还要求日志的格式要能跟公安的后台系统对接，至少要支持按标准格式导出。如果日志存在自己设备上，格式是私有的、只有自己工具能打开，公安检查的时候可能不会被认可。

日志要记什么内容

一份合法的实名认证日志至少要包含以下字段：用户的真实身份信息（姓名、证件类型、证件号码）、上网账号或手机号、接入时间、断开时间、使用的IP地址（公网IP和私网IP都要）、关联的设备MAC地址、接入的AP位置或房间号。

这里有一个容易漏掉的地方：NAT转换前后的IP对应关系。宾馆出口一般用的是NAT，所有用户共用几个公网IP出去。如果日志里只记了公网IP没有记私网IP和时间戳的对应关系，以后公安要溯源某个网络行为到具体某个人、某个房间的时候，就做不到。

换句话说，NAT映射关系和用户认证日志之间必须能做关联查询。这件事在设计日志结构的时候就要考虑进去，不要等到需要导出数据的时候才发现缺字段。

日志的存储和安全性

实名认证日志里存的是住客的真实身份信息，这个敏感程度比一般的网络日志高得多。日志存储的安全性至少要做到这样几个方面：第一，日志数据在传输过程中要加密，不能明文走公网；第二，存储设备要物理隔离或者至少逻辑隔离，不能跟其他业务系统共用存储空间而且没有访问控制；第三，日志查询要有权限管理和操作审计，谁在什么时间查了谁的日志要有记录。

在酒店的实际场景里，如果日志存储在门店本地设备上，那设备本身的安全性也是问题。门店机房的条件参差不齐，有的就是个杂物间，设备放在那里谁都能碰到。所以很多连锁酒店开始把日志实时同步到集团的数据中心或者云平台，减少本地存储的风险。

数据生命周期管理不能只存不删

日志留存也不是说越多越好，存到硬盘满了再加一块硬盘。个人信息保护法要求个人信息处理者应当在处理目的已实现、无法实现或者为实现处理目的不再必要时主动删除个人信息。换句话说，日志到了法定留存期限之后，应该有计划地做数据清理，不能无限期地留着。

这要求日志系统具备自动化的数据生命周期管理能力：设置一个保留期限，到期后自动清理或者至少标记为"待删除"，由管理员确认后执行。同时也要支持在保留期内的数据冻结——如果有正在进行中的公安调查，对应的日志需要被保护起来不被自动清理。

日志的可审计性和可追溯性

从审计角度看，日志系统本身也需要防止被篡改。这个要求对酒店来说技术上有点重，毕竟酒店不是金融机构。但至少要把日志写入做成只追加的模式，不允许修改或者删除已写入的日志记录。任何对日志的删除操作都应该有独立于日志系统之外的审计记录。

实际项目里有一个比较务实的做法：日志双写。主日志存在本地设备上，同时把一份副本以只读方式同步到集团平台或者云端。这样即使本地设备出了故障或者被人为操作了，也还有一份干净的副本可以用来做合规检查和审计。

酒店宾馆无线实名认证的合规，不是一个"装好设备就合规"的事情，而是一个持续运行的状态。日志留存就是这个状态里最容易被低估但检查时最容易出问题的一环。把日志的事想在前面、做好了，相当于给整个认证系统上了一道起码的安全锁。 在准备合规审计的时候，还有一个容易被忽略的准备动作：预先按公安常用的检查口径做好几个日志导出模板。比如按时间段导出某一周的所有认证记录、按房间号导出某一个房间一个月的上网日志、按身份证号导出某一个人的完整上网记录。这些模板在平时没什么用，但一旦公安来检查，要求"把最近半年某个房间的日志调出来"，没有模板的情况下可能要折腾好几个小时。有了预置模板，几分钟就能出结果，这个准备对通过合规检查的帮助非常大。