学校WiFi网络计费系统作为校园网的重要组成部分，在等级保护测评（等保）中是一个必查项。很多学校网络部门在准备等保测评时，把注意力集中在防火墙、入侵检测这些显眼的防御设备上，对计费系统的等保要求了解不够。实际上，等保对审计、数据保护和访问控制的要求，和计费系统的功能设计密切相关，不是换个设备就能过关的。

一、身份鉴别与访问控制

等保测评首先查的是身份鉴别机制。学校WiFi网络计费系统的用户账号体系，必须能够确保"一人一号、一号一人"，即每个账号唯一对应一个真实用户。这听起来简单，但前面提到过，很多学校的账号共享问题严重，实际上一个账号背后可能是多个人在使用。等保测评会检查学校是否有有效的手段防止账号冒用和共享。

访问控制方面，等保要求系统支持基于角色的权限管理。计费系统的后台管理，不应该所有人都能操作所有功能。比如：普通运维人员只能查看用户信息和消费记录，但不能修改计费规则或删除账号；只有管理员才能修改系统配置和计费策略。等保测评会检查后台是否有权限分级，以及权限变更是否有审计记录。

很多学校的计费系统后台只有"管理员"和"用户"两个角色，所有运维人员共用管理员账号。这种做法在等保测评里会被扣分。即使学校只有几个人管网络，也应该为每个人建立独立账号，并分配最小必要权限。

等保还要求学生用户端有密码复杂度要求和登录失败处理机制。比如密码不能是纯数字、不能和学号相同；连续输错密码5次应该锁定账号一段时间。这些功能如果学校WiFi网络计费系统没有内置，需要额外配置或者二次开发。

二、安全审计

等保对安全审计的要求非常具体，不仅仅是"记录日志"，而是日志要覆盖哪些操作、保留多久、谁能查看、如何防止篡改。

计费系统的日志需要覆盖以下操作：用户登录（成功和失败）、账号创建/修改/删除、计费规则变更、余额充值/扣减/退费、套餐变更、设备绑定/解绑、管理员后台操作。每一条日志至少要包含：操作时间、操作人、操作内容、操作结果。如果缺少任何一项，等保测评都会指出问题。

日志保留时间也是一个硬指标。等保二级要求至少保留90天，等保三级要求至少保留180天。很多学校的计费系统日志只保留7天或30天，遇到等保测评时才发现不达标。延长日志保留时间不仅需要存储扩容，还需要考虑日志检索性能，如果保留了半年日志，但查询一条记录需要几分钟，实际运维中也无法使用。

日志防篡改是另一个重点。等保要求日志不能被随意修改或删除。如果计费系统的日志是明文存储在数据库里，管理员有权限直接修改，那就不符合要求。需要引入日志完整性校验机制，比如对每条日志做哈希签名，或者把日志同步到只读存储。部分学校采用的做法是把计费日志同时写入到独立的日志服务器，数据库里的日志只作为查询用，修改需要走特殊流程。

三、数据完整性和保密性

学校WiFi网络计费系统里存储了学生的个人信息（姓名、学号、手机号）和财务信息（余额、消费记录、充值记录）。等保要求对这些数据做保护。

数据完整性方面，等保会检查数据库是否有备份机制、备份是否定期执行、备份数据是否存储在异地。如果学校的数据库只存在本地服务器，没有备份，或者备份是手工操作不定期执行，这些都是不符合要求的。更严格的是，等保三级要求备份数据也要加密存储，防止备份介质丢失导致数据泄露。

数据保密性方面，等保要求敏感数据传输时使用加密通道。比如学生登录计费系统、查询余额、充值缴费，这些操作涉及账号密码和财务信息，必须通过HTTPS传输，不能走HTTP。后台管理界面同样要求HTTPS。很多学校早期部署的系统用的是HTTP，等保测评前需要升级。

数据存储方面，等保要求敏感数据在数据库中加密存储。学生的手机号、身份证号（如果采集了）应该加密，不能明文存放。余额和消费记录虽然不一定要求加密，但最好做脱敏处理。如果数据库被拖库，攻击者拿到的是加密数据，无法直接读取。

等保还会检查数据访问的最小化原则。计费系统的数据库，不应该所有应用都能直接连接。只有计费系统本身和必要的集成系统（如财务系统接口）有访问权限，其他应用（比如学工系统、教务系统）不应该能直接读取计费数据库。如果学校的数据库是全校共享的，没有做访问隔离，等保测评会扣分。

四、入侵防范和恶意代码防护

虽然学校WiFi网络计费系统本身不是安全设备，但它作为校园网的一部分，也需要有基本的安全防护。

等保要求系统有恶意代码防护能力。计费服务器应该安装杀毒软件或EDR，定期扫描。很多学校的计费服务器是Linux系统，管理员认为Linux不需要杀毒，但等保测评并不区分操作系统，只要有恶意代码防护机制就行。Linux上可以用ClamAV等开源方案，或者通过定期基线扫描来检查系统完整性。

入侵防范方面，等保要求系统能够检测到异常访问行为。比如计费系统后台有多次登录失败、某个IP短时间内大量请求充值接口、数据库出现非预期的查询模式。这些异常需要被记录，并且触发告警。如果计费系统本身没有这种能力，可以借助校园网的安全运营中心（SOC）或者日志分析平台来实现。

还有一个经常被忽视的问题是第三方组件的安全。很多计费系统基于开源框架（比如Spring、Django）或商业中间件（比如WebLogic、Tomcat）开发。等保测评会检查这些组件是否有已知漏洞，是否及时更新补丁。如果系统用了某个几年前的版本，存在公开的CVE漏洞，等保测评一定会指出。

学校WiFi网络计费系统通过等保测评，不是靠采购一套安全设备就能解决的。它需要从身份鉴别、访问控制、安全审计、数据保护、入侵防范等多个维度，对系统进行全面的检查和加固。很多学校在准备等保时，把主要精力放在网络和服务器层面，但忽略了计费系统本身的安全设计，结果测评时发现大量不符合项，临时整改时间很紧，效果也不好。提前了解等保对计费系统的具体要求，在建设阶段就把这些需求纳入设计，才是最有效的方式。