去年下半年开始，多地公安网安部门加大了对公共场所WiFi实名认证的检查力度。酒店作为重点检查对象之一，每年至少会迎来一到两次例行检查，遇到重大活动保障期间频率更高。很多酒店IT负责人反映，平时系统跑着没什么问题，但一遇到检查就紧张，因为不清楚检查组到底看什么、查到什么程度。

检查的核心关注点

认证记录完整性排第一。检查人员会随机抽取某一天的日志，看当天所有通过WiFi上网的用户是否都有对应的实名认证记录。这里的关键不是"有没有日志"，而是日志能不能跟实际使用情况对得上。有些系统的日志只记录了认证成功的事件，但没记录认证失败或者绕过认证直接上网的情况。如果检查人员用技术手段发现存在未认证设备在线而日志里没有对应记录，这就是硬伤。

然后是留存时长。按照《互联网安全保护技术措施规定》，公共场所WiFi的上网日志至少保留60天。但很多酒店的存储空间有限，尤其是小型酒店用的低端一体机设备，本地硬盘可能只有几百GB，开了全量日志之后两三个月就存满了。存满了之后是自动覆盖最早的记录还是停止写入？如果是自动覆盖，那留存时长实际上就不达标；如果停止写入，后续的日志就断了。这两种情况在检查中都是问题。

还有数据查询响应速度。检查人员现场可能会要求调取特定时间段、特定手机号或者特定房号的上网记录。如果系统查询一次要等好几分钟甚至更久，或者查出来的结果格式不标准（缺少必要的字段比如上下线时间、MAC地址、访问的URL），检查人员会认为系统运行不规范。这不是技术能力问题，而是合规展示的问题。

日志完整性是最容易被查出问题的环节

一家位于中部省会城市的四星级酒店去年底接受检查时就被指出了这个问题。他们的WiFi实名认证系统正常运行了快两年，日志也一直在存。但检查人员用专业工具扫描后发现，有少量设备的MAC地址在认证日志中从未出现过——也就是说这些设备连了WiFi但没有走认证流程。进一步排查后发现是部分老旧的客房AP没有正确配置强制 portal 跳转，导致某些设备可以直接绕过认证页面。

这个问题从2019年系统上线时就存在，但因为日常运维没人去逐个AP验证portal配置，一直没被发现。最后整改方案是把所有AP的强制认证策略统一推了一遍，并且每个月做一次抽样验证。听起来很简单，但如果不是被查出来，这个漏洞可能还会继续存在下去。

还有一类常见问题是账号和实名的对应关系不清

有些酒店允许住客用房号+姓氏来认证，比如"3012张"。这种方式操作简单，住客不用记手机号也不用收短信，体验确实好。但从合规角度看，房号加姓氏并不能唯一确定一个自然人身份。检查人员如果质疑"你怎么证明这个3012张就是身份证上叫张某的人"，酒店这边很难拿出有力证据。

手机号认证虽然也有瑕疵（虚拟号、多人共用一号），但目前来说是相对可追溯的方式。如果酒店想用房号认证作为补充方式，建议同时要求关联手机号或身份证信息，确保每一条认证记录都能追溯到具体的自然人身份。

准备工作的重点不在突击而在日常

每次检查通知下来之后才开始整理资料、补日志、测功能，这种做法风险很大。因为日志一旦丢失或覆盖是无法恢复的，功能缺陷也不是一两天能修好的。真正靠谱的做法是在日常运维中就把合规基线守住：日志定期备份到外部存储并校验完整性、每月做一次日志抽样审计确保无遗漏、每个季度做一次全链路测试确保认证流程没有被绕过的路径。

另外建议酒店IT部门提前准备好一份标准的"自查清单"，包含检查组通常会看的所有项目。这份清单不需要给外面的人看，但是内部要定期按清单过一遍。等到正式检查的时候，该有的东西都在，该能演示的功能都正常，应对起来就不会慌。

供应商的支持能力也很关键

检查过程中如果出现技术争议（比如对某个日志字段的解释双方不一致），酒店自己未必说得清楚，这时候需要供应商出面的配合就很必要。选型阶段就应该把这一点纳入考察：这家供应商在当地有没有技术服务团队？出了检查问题能不能派人到场支持？以前有没有配合客户通过检查的经验？这些软性指标在采购时容易被忽略，但到了关键时刻就会体现出来。

酒店WiFi实名认证系统是帮酒店满足监管要求的工具。但工具装上了不代表合规了——只有当它产生的数据完整、可用、可追溯，并且在检查中经得起验证的时候，才算真正发挥了价值。