上个月有个客户给我打电话,语气很急:"网安明天来检查,说要看我们酒店WiFi的实名认证日志,你看看系统现在能不能导出他们要求的格式。"我远程登上去一看,日志倒是有,但分散在三个地方:认证网关存了一部分、本地服务器上有一批CSV文件、还有一部分因为磁盘满了被系统自动清理了。最后花了大半天时间手工拼凑,勉强凑出了一份能交差的报告,但数据完整性和格式规范性肯定是不达标的。这种事酒店行业每年都在发生,根源在于酒店WiFi实名认证系统上线的时候,合规审计需求没有作为硬性验收指标。
日志留存的法律依据和基本要求
酒店WiFi实名认证系统的日志留存不是可选项,是法律义务。根据《网络安全法》第二十一条和《互联网安全保护技术措施规定》的要求,提供公共互联网接入服务的单位必须记录并留存用户上网日志,留存时间不少于六个月。对于酒店来说,这个要求具体包括:用户身份信息(手机号、证件号等实名认证信息)、上网时间起止、分配的内网IP地址和公网IP地址、以及访问的目标地址(至少要记录到域名级别)。日志必须保证真实性和完整性,不能被篡改。如果网安部门来调取数据,酒店必须在规定时间内提供,否则面临行政处罚。这些是底线,没有任何商量余地。
日志采集点的完整覆盖
酒店WiFi实名认证系统的日志采集最常见的问题是覆盖不全。一个典型的酒店网络流量路径是:客人终端→AP→接入交换机→核心交换机→认证网关→出口路由器→互联网。很多系统的日志只记录认证网关注册的那一瞬间的认证信息,但客人的上网行为日志是需要从整个会话过程中持续采集的。如果认证网关做了直路部署,那所有流量都经过网关,日志相对完整。但如果是旁路部署,流量不经过网关,就需要额外的流量镜像或者NetFlow采集方案。旁路部署在成本上确实更友好,但对日志采集能力的要求更高,这一点一定要在方案阶段就明确。
NAT日志和实名信息的关联是核心难点
酒店WiFi实名认证系统面临的一个技术难题是NAT地址转换后的溯源。酒店一般用一个或几个公网IP地址为所有客房提供上网服务,内网通过NAT转换。这就产生了一个问题:日志记录的是公网IP的访问行为,但同一个公网IP下面可能有几十个不同的用户在同时上网。当需要追溯到具体哪个用户在某个时间访问了某个网站的时候,必须能做NAT日志的反查——即从公网IP+端口+时间反推出内网IP,再从内网IP反推出具体用户的实名信息。这个过程依赖三个日志表的关联查询:NAT映射表、DHCP地址分配表、以及用户认证信息表。如果这三个表的时间戳不精确或者格式不一致,关联查询就会失败。我们的实践经验是:所有日志表的时间戳必须统一到毫秒级精度,并且所有网络设备必须做NTP时间同步,否则时间漂移会让日志关联变成灾难。
日志存储的容量规划和安全保护
酒店WiFi实名认证系统的日志量比大多数人想象的大。一个一百间房的酒店,日均生成NAT日志和上网行为日志大约5到10GB。六个月就是1TB左右。这还只是原始日志,如果再算上索引和归档备份,存储需求翻倍。很多酒店一开始用单块硬盘做日志存储,跑两三个月就满了,然后系统自动清理旧日志——这等于主动销毁合规证据。正确的做法是:至少保证八个月的日志存储容量(六个月留存加两个月缓冲)、做RAID磁盘冗余防止单盘故障导致日志丢失、定期做异地或者云端备份。同时日志文件必须加密存储、设置严格的读取权限、所有访问日志的操作都记录审计痕迹。
审计场景下的快速检索能力
网安来查的时候不会提前一个月通知,通常都是提前一天甚至当天电话。酒店WiFi实名认证系统如果不能在短时间内按指定条件检索出日志,就等于不合规。典型的查询条件是:某个手机号在某段时间内的所有上网记录、某个IP地址在某个时间段的访问行为、或者某个时段内所有在线的用户列表。这些查询场景要在系统设计时就规划好索引策略:时间索引、手机号索引、IP地址索引至少要覆盖这三种查询维度的组合。响应时间方面,对于一周以内的查询应该秒级返回,对于一个月以上的全量扫描可以接受分钟级,但绝不能出现"查不了"或者"数据没了"的情况。
日志导出格式的规范性
很多酒店WiFi实名认证系统出报告的时候倒在最后一公里:数据有,但导出的格式不对。网安部门要求的日志格式通常有明确的规定,字段顺序、分隔符、编码方式都有要求。如果系统导出来的是系统内部格式,需要手工转换成标准格式,转换过程可能引入错误甚至数据丢失。建议在系统设计时就内置标准格式导出功能,支持的格式至少包括CSV和Excel,字段映射关系固化在系统配置里而不是靠人工记忆。另外每次导出时必须生成导出记录的摘要文件,包括导出时间、导出人、数据范围、数据条数、文件哈希值,防止事后出现数据完整性的争议。
酒店WiFi实名认证系统的合规审计能力是产品的基础功能,不是增值功能。一个系统如果技术上能认证、体验上也过关,但审计的时候拿不出完整日志,那它在酒店场景下就是不合格的。合规问题没有"差不多",只有"行"和"不行"。