网络计费系统:等保2.0对计费日志留存的具体要求有哪些
等保2.0测评是很多单位无法回避的合规检查。网络计费系统作为网络接入控制的核心环节,在等保测评中通常被列为重点检查对象。不少单位在测评前临时补日志、改配置,结果还是不通过。等保2.0对计费系统的日志要求不是含糊的"要留日志",而是有具体的技术指标。提前了解这些要求,在系统建设阶段就按规范落地,比事后补救有效得多。
一、日志留存期限:不少于六个月
等保2.0明确要求网络日志的留存期限不少于六个月。这个要求来自《网络安全法》第二十一条。对于计费系统来说,六个月意味着所有用户的认证记录、上下线记录、流量使用记录、计费扣减记录都要保存半年以上。
六个月的日志量不可小觑。一家有一万用户的单位,每天产生的认证记录可能有几十万条,计费记录可能上百万条。半年的日志量在几个TB级别。如果计费系统没有做好日志压缩和归档,磁盘空间很快就会不够用。有些单位在测评时被发现日志只保留了两个月,因为磁盘满了之后旧日志被自动覆盖了。解决方法是提前规划日志存储容量,按六个月的保留期倒推需要的磁盘空间,并留出百分之三十的余量。
二、日志内容的完整性要求
等保2.0要求日志能够"追溯"。对于计费系统来说,追溯意味着通过日志能够还原某个用户在某个时间段内的完整上网行为:什么时候认证、从哪个IP认证、分配了什么IP、用了多长时间、消耗了多少流量、什么时候下线。
具体到字段层面,认证日志至少要包含:认证时间、用户名、客户端MAC地址、客户端IP地址、NAS设备IP、认证结果(成功或失败)、失败原因。计费日志至少要包含:会话ID、开始时间、结束时间、输入流量(下行)、输出流量(上行)、会话时长、NAS设备IP。
很多计费系统的日志字段不全。最常见的缺失是客户端MAC地址和NAS设备IP。这两个字段对于追溯用户来源特别重要。没有MAC地址,无法确认是哪台设备在上网。没有NAS设备IP,无法确认用户是从哪个接入点上的网。测评时如果日志里缺少这些字段,会被判定为不合规。
还有一个容易忽视的字段是管理员操作日志。等保2.0要求记录管理员对系统的所有操作,包括登录、修改配置、查看用户数据、导出报表等。有些计费系统只记录业务日志,不记录管理日志,测评时会被扣分。
三、日志的防篡改要求
等保2.0要求日志具有防篡改能力。也就是说,日志一旦写入就不能被修改或删除,即使是系统管理员也不行。这个要求对计费系统的日志存储架构提出了挑战。
传统的日志存储方式是写文件或写数据库,管理员有权限直接修改文件或数据库记录。这种方式不满足防篡改要求。满足要求的方式有几种:一是把日志推送到独立的日志服务器,日志服务器只接受写入不接受修改和删除。二是使用WORM(Write Once Read Many)存储介质,数据写入后物理上无法修改。三是对日志做哈希校验,每条日志附带前一条日志的哈希值,形成哈希链,任何篡改都会导致链断裂。
实际项目中,最常见的方式是第一种:部署独立的日志服务器或日志平台,计费系统通过syslog或其他协议把日志实时推送过去。日志服务器由安全团队管理,运维团队无权修改。这种方式实现成本相对低,但要注意日志推送的实时性和完整性。如果计费系统到日志服务器的网络中断,日志会丢失。需要做好断线缓存和断线续传。
四、时间同步要求
等保2.0要求所有系统的日志时间必须一致。如果计费系统的服务器时间跟网络设备的时间差了几分钟,同一件事在不同设备上的日志时间对不上,追溯时就会产生混乱。比如用户在10:00:00认证成功,但如果认证服务器的时间比实际快了两分钟,日志里记录的就是10:02:00。而网络设备记录的用户上线时间是准确的10:00:00。两条日志关联不上,追溯就断了。
解决方案是所有设备都通过NTP协议同步到同一个时间源。时间源可以是单位内部的时间服务器,也可以是公网NTP服务器。关键是要确保计费系统的所有服务器、所有网络设备、所有日志服务器都指向同一个时间源,并且定期检查同步状态。NTP同步偏差超过一秒就应该告警。
五、日志审计和告警
等保2.0不仅要求留存日志,还要求对日志进行审计分析。对于计费系统来说,审计的重点是异常行为:短时间内大量认证失败、异常的流量突增、非工作时间的管理员操作、大批量数据导出等。这些行为可能意味着安全攻击或内部违规。
计费系统本身不一定具备日志审计能力,可以把日志推送到SIEM(安全信息和事件管理)平台做集中分析。SIEM平台可以设置规则,当检测到异常模式时自动告警。比如同一个账号在一分钟内认证失败超过十次,可能是密码暴力破解,SIEM告警后安全团队可以及时处置。
等保2.0对计费系统的日志要求不是额外负担,而是安全建设的基本功。一个日志完善的计费系统,在遇到安全事件时能够快速定位和追溯,在合规检查时能够从容应对。把日志建设当作计费系统的标配而不是选配,这个认知要贯穿从选型到部署到运维的全过程。


