很多酒店在上WiFi认证系统的时候，容易把认证和日志审计拆开来看，觉得认证是必须做的，日志嘛先看情况。这个思路有问题——这两件事在合规层面是不能分开的，而且日志做得好不好，直接影响认证这件事有没有真正意义。

法规要求的核心是什么

《互联网安全保护技术措施规定》和《网络安全法》对酒店类公共上网场所的要求，概括起来有三条：

第一，禁止匿名接入。所有上网用户必须经过真实身份核验，不能直接接入、不能用假账号接入。

第二，日志留存不低于6个月。日志内容要包括终端MAC地址、IP地址、认证账号、上网起止时间、访问记录等核心字段。

第三，日志必须能上报给网监系统。不是留着自己看的，是要能按公安部要求格式导出或实时上报。

只做认证不做日志，等于酒店有实名认证流程，但没法证明这些数据真实存在、没被篡改、随时能调出来。被检查的时候，认证系统有，日志拿不出来，一样面临整改。

日志应该记录哪些内容

具体要采集的日志字段，标准做法包括：

终端识别信息——MAC地址是设备的唯一标识，IP地址记录这台设备在网络中的位置。这两个结合，能定位到具体是哪台设备在上网。

认证账号——住客是房间号，访客是手机号或身份证信息。这一项让日志跟真实的人关联起来。

时间字段——上网开始时间和结束时间，精确到分钟级别。

行为记录——访问的域名或IP，有的系统还会记录流量大小。

如果酒店有IP电话系统，通话记录也应该一并纳入日志。这在做整体合规审计时会用到。

存储方式也有要求

日志不是存在哪里都行。合规存储有几个基本要求：

第一是时效性，不低于6个月，有些敏感场所要求更长。第二是完整性，日志不能删改，需要有防篡改机制。第三是可用性，需要的时候能快速导出或对接查询，不能说"日志有，但导不出来"。

本地存储是一种方式，成本相对固定，但需要自己维护存储硬件，日志备份也要另外安排。另一种是云端存储，好处是容量弹性、省本地硬件，坏处是依赖网络，如果网络出问题，可能有日志中断的风险，需要有本地缓存机制作为保底。

对于连锁酒店，建议走云端集中存储，所有门店的日志统一汇到云端日志服务器，总部可以统一管理和查询，单门店不需要单独维护日志硬件。

网监对接怎么做

各省的网监系统对接方式不完全统一，但基本都有标准接口。一般分为两种模式：

一种是实时上报，认证事件发生后，日志系统自动向网监平台推送数据，实时性强，但对网络链路有依赖。

另一种是定期上报，按天或按周批量导出日志文件，手动或自动提交到网监系统。实时性弱一些，但对网络稳定性要求低。

不同地区、不同规模的酒店，网监部门要求的接入方式可能不一样。如果供应商声称系统支持网监上报，建议让他们出具过往的对接案例或者直接联系当地网监确认接口规范，不要只看宣传材料。

配套部署的实际场景

在酒店认证项目里，认证网关、认证系统、日志服务器这三个组件通常是配套部署的。认证网关负责拦截未认证流量、推送Portal页面；认证系统负责记录用户账号和认证状态；日志服务器负责采集和存储上网行为数据。

三者分工明确，任何一环缺失，整套合规体系就会出现漏洞。部分规模较小的酒店会选择轻量化方案，把认证和日志功能集中在一台审计网关上，成本低，但功能相对有限，适合50间房以内的小型酒店。

中大型酒店建议三套系统分开部署，日志服务器单独放，避免认证系统出问题时日志数据也跟着丢失。

一个容易被忽视的细节

做完认证和日志系统上线之后，有一件事很多酒店会忘掉：定期检查日志是否正常写入，确认日志服务器存储是否正常，确认网监上报接口是否在线。

这些检查不做，很可能出现认证系统在跑、但日志没有正常写入的情况。等到被检查或者出了网络安全事件，才发现日志丢了一段时间，那时候补救很麻烦。

建议在运维合同里明确这部分的定期巡检周期，至少每月确认一次日志完整性。