网络安全等级保护2.0标准自2019年正式实施以来，高校信息系统的合规建设进入了一个新阶段。校园网作为全校师生每天依赖的基础设施，通常被定级为二级或三级系统。认证系统作为网络接入的第一道关口，在等保测评中承载着大量合规条款的落地责任。如果认证系统本身的设计存在缺陷，后续的整改成本会成倍放大，甚至影响整个校园网的定级通过。

等保2.0对于身份鉴别提出了明确而且具体的要求。首先，用户的身份标识必须唯一，系统要能够确保人与号之间的对应关系，禁止共用账号。校园网场景下每个学生和教职工都应使用独立的学号或工号进行认证，不能出现一个寝室共用一个账号的情况。现实中部分学校的临时工和外包人员使用共享账号，这是测评中的扣分项。其次，系统需要具备登录失败处理能力。当同一账号在短时间内连续认证失败达到一定次数后，系统应自动锁定该账号一段时间，防止暴力破解。锁定阈值和时长的设置需要平衡安全和体验——阈值设得太低用户输错密码就被锁，投诉量会上来；设得太高又形同虚设。实践中比较成熟的做法是五次失败锁定五分钟，并结合图形验证码机制对异常尝试进行二次确认。另外系统还要支持登录超时退出功能，用户认证通过后如果长时间无操作，系统应主动断开连接，强制用户重新认证。这个机制对于图书馆公共电脑、机房共用终端等场景尤其重要，少了它测评大概率过不了。

访问控制是另一个等保重点。等保2.0要求实现最小权限原则，不同角色的用户只能访问被授权的资源。校园网认证系统需要具备细粒度的访问控制能力，不能简单粗暴地要么全部放行要么全部拒绝。成熟的实践是通过动态VLAN下发来实现角色隔离。学生认证通过后被划入学生VLAN，只能访问教学资源池和外网；教职工进入教职工VLAN，可以额外访问财务系统和OA系统；访客被限制在访客VLAN，只有最基本的外网访问权限，且有时间窗口限制，超过两小时自动断线。更进一步，某些特殊场景需要更细的粒度——比如实验室网络内的设备需要访问特定的科研服务器集群，同时又不能访问外网。这就要求认证系统支持基于用户组的ACL下发，在认证通过时动态注入不同的访问控制策略。实现层面通常利用RADIUS的Filter-Id或厂商私有属性来传递策略标识，接入交换机根据标识匹配预定义的ACL规则集。

安全审计是等保2.0中篇幅最长、要求最细的部分，没有之一。认证系统产生的审计记录必须覆盖到每一个用户、每一次操作。具体来说，审计日志需要包含以下字段：事件发生的时间，精确到秒；用户身份标识，即学号或工号；事件类型，包括登录成功、登录失败、注销、账号锁定等；事件结果，成功或失败；源IP地址和MAC地址的关联关系。根据网络安全法规定，网络日志的留存时间不少于六个月。对于万人规模的高校，每天产生的认证日志量在几十万条级别，六个月累计下来是数千万甚至上亿条记录。这就要求审计系统具备高效的存储和检索能力。目前比较常见的做法是将原始日志压缩后存储到NAS或对象存储中做长期留存，同时把最近一个月以内的热数据保留在Elasticsearch集群里供快速检索。日志的完整性保护也是合规要求之一——审计记录不能被随意修改或删除，需要设置严格的权限控制和防篡改机制。技术上可以通过文件系统的只读挂载、WORM存储或者哈希链签名来实现。

数据安全方面，用户密码在传输和存储过程中必须受到保护，这一点没有商量余地。传输层面，认证协议应优先使用CHAP而非PAP。PAP以明文方式在网络上传输密码，在共享的局域网环境下等同于裸奔。CHAP采用挑战应答机制，服务端生成随机挑战码发给客户端，客户端用密码哈希后和挑战码一起计算响应值，密码本身不出现在网络报文中。存储层面，后台数据库中的用户密码必须经过加盐哈希后存储，严禁明文保存。盐值应为每个用户独立随机生成，防止用彩虹表批量还原。即使数据库被拖库，攻击者也需要逐个用户暴力破解，时间和算力成本大幅上升。另外建议定期强制用户修改密码，但这个策略在校园网里推行难度不小——学生普遍反感频繁改密码。折中方案是把密码强度要求提高，让初始密码足够复杂，降低被暴力破解的概率，同时保留异常登录检测作为兜底。

终端准入控制是等保2.0新增的安全要求，在旧版等保里没有明确规定。系统需要在用户认证之前检查终端设备的安全状态——操作系统补丁是否打到最新、杀毒软件是否安装并处于运行状态、是否开启了系统防火墙。不符合安全基线的设备应被放到隔离区，只能访问补丁服务器和安全策略指引页面，强制修复完成后才能接入正常网络。这个要求在教学办公区的802.1X部署中比较常见，配合第三方网络准入控制产品来实现。学生宿舍区由于设备类型过于繁杂，全量终端检查的实施难度较大，可以先从教职工终端入手，分批推进。同时要注意入学季新生电脑的初始状态五花八门，隔离区容量要在那段时间做弹性预留，否则会出现大量新生堵在修复页面上不去的情况。

合规不是一次性工程。等保测评每两年一次，但系统的安全状态每天都在变化。认证系统需要持续监控、持续优化，把合规要求内化成日常运维的一部分，而不是测评前两个月突击整改。突击整改过的系统在测评结束后往往很快回退到整改前的状态，下一次测评又是从头来过。把日志留存、访问控制审计、密码策略这些要求固化为系统的默认配置而非临时补丁，才是合规建设的正确姿势。

（约1920字）