酒店作为互联网接入场所，在日志留存方面受到明确的法规约束。很多酒店管理者知道"要留存日志"这件事，但对具体要求是什么、执行起来会遇到哪些现实问题，了解得相当模糊。酒店网络审计网关是实现日志留存的核心手段，但仅仅部署了审计网关并不等于合规工作就完成了。

法规层面的基本要求

根据国内互联网安全管理的相关规定，提供公共上网服务的场所需要记录用户的上网日志，并留存不少于 180 天。日志内容应当包括用户访问的 IP 地址、访问时间、目标地址等信息，同时需要能够将网络行为与具体用户身份进行关联。这两个要求——留存时长和身份关联——是审计合规的两个核心指标，缺一不可。只有流量日志没有身份信息，或者有身份信息但日志只保留了 30 天，都不满足要求。

身份关联的实际难度

身份关联是实际执行中最难的部分。技术上，审计网关记录的是 IP 地址和流量行为，而不是"某某人"。要把 IP 和具体住客身份对应起来，需要在某个环节有一个身份绑定记录。这个记录通常来自 Portal 认证系统——住客登录 WiFi 时要输入手机号或房间号，系统在这个时点把手机号/房间号和分配到的 IP 做了绑定，留下了时间戳。只要审计网关的日志时间和认证系统的绑定记录能够对齐，查询时就能还原"这个 IP 在这个时段是哪位住客在使用"。

问题在于，很多酒店的认证系统和审计系统是两套独立的系统，两边的时钟可能存在偏差，IP 分配记录可能不够完整，或者认证系统的日志格式和审计网关的格式无法直接对应。这些细节问题在日常运行中看不出来，一旦需要提取某条具体的审计记录，就会发现两边的数据对不上。

DHCP 地址动态分配的干扰

住客的设备通常通过 DHCP 动态获取 IP 地址，同一个 IP 地址在不同时段可能分配给不同的住客。审计网关的日志里有大量的 IP 访问记录，但如果要溯源某条记录是哪位住客产生的，必须先查 DHCP 租约记录，确认这个 IP 在这个时间段是谁在用，再去认证系统里找到对应的身份信息，最后才能完成关联。这个查询链条比较长，中间任何一个环节的记录不完整，溯源就会断掉。很多酒店的 DHCP 服务器没有保留足够长时间的租约历史记录，导致事后查询时无从对应。

HTTPS 流量的审计局限

当前互联网流量中，HTTPS 占了绝大多数比例。加密流量对审计网关而言是一个现实约束：不解密就只能看到目标 IP 和域名，看不到具体的访问内容。这对大多数合规审计场景来说是可以接受的——合规要求的核心是记录访问行为，而不是还原访问内容——但对于部分特殊场景（比如需要识别违规内容），单纯的流量日志就不够用了。有些审计网关支持 SSL 解密，但解密功能涉及用户隐私，开启需要有明确的法律依据和技术隔离措施，不能随便启用。

日志存储容量的规划

180 天的日志留存听起来是个时间概念，实际上是一个存储容量问题。酒店网络在高峰期每天产生的流量日志可能达到数 GB，180 天累计下来对存储的要求相当可观。审计网关自带的存储空间通常有限，很多设备原厂配置的存储只够保留几十天，如果不扩容或者外接存储，到期后日志会被自动覆盖。日志被覆盖在系统正常运行时看不出任何问题，但一旦需要查询历史记录，就会发现想要的时段数据已经没了。

日志的完整性保护

合规审计的日志不仅要留存，还要保证完整性——也就是说，日志不能被随意修改或删除。有些审计网关支持日志哈希或数字签名，确保每条记录在存储后不会被篡改。这个功能在日常运营中用不到，但在需要提交审计日志作为证据的情况下，日志的完整性证明非常重要。如果日志没有完整性保护机制，提交的记录即使是真实的，也可能因为无法证明未被修改而失去效力。

日志查询效率的实际问题

审计日志的量很大，如果需要从中查询某个特定时间段、某个特定 IP 或者某个特定住客的记录，查询性能就变得关键。一些低端审计设备的日志存储用的是简单文本格式，全文检索速度很慢，查一条历史记录可能需要几分钟甚至更长时间。这在日常检查时影响不大，但在紧急情况下需要快速提取记录时，效率问题会非常突出。选型时应当关注审计系统的日志检索能力，而不仅仅是存储容量。

定期检查机制的必要性

审计网关上线后不是一次性的工作。时钟偏差可能积累，存储空间可能不足，认证系统的对接配置可能因为更新而失效。很多酒店把审计网关部署完就不再过问，等到检查时才发现系统已经出了问题。合理的做法是建立定期检查机制，每个月检查一次日志完整性、存储剩余空间、身份关联记录的完整度，发现问题及时处理，不要等到被动检查的时候再补救。

日志留存合规这件事，看起来是技术问题，本质上是管理问题。设备部署只是起点，能不能持续满足要求，取决于有没有人在日常运营中真正盯着这件事。