高校等保实施清单与整改要点-等保测评网

高校信息系统多、责任分散、数据类型复杂：教务系统关注选课与成绩，科研系统涉及项目资料，一卡通连接消费与门禁，统一身份认证还为多个业务提供公共能力。边界划得过大或过细，都会增加整改和测评难度。高校等保应先理清业务、数据、技术和责任，再进入定级、备案、整改与测评。

先做系统清册，不要急着确定等级

第一步不是采购设备，而是确认“哪些系统由谁运营、承载什么业务、依赖哪些基础设施”。建议以系统为单位建立清册，至少记录：

划分定级对象要同时看业务独立性、责任主体、技术边界和数据交换关系。共用统一认证的教务与科研系统不一定需要合并；同一业务的前端、接口和数据库，也不能因部署位置不同就机械拆分。可参考等保定级流程，先形成边界草案再组织评审。

高校信息系统不能只按用户数量或“是否联网”判断等级。定级分析应围绕系统遭到破坏后，可能影响的对象以及影响程度展开。实践中可重点回答三个问题：

展示类网站与承载学籍、成绩、选课的系统，业务重要性和数据敏感性通常不同；统一身份认证、一卡通还要评估故障后的连锁影响。高校不宜套用“某类系统一律定三级”，应依据实际业务和破坏后果完成初步定级、专家评审、主管部门审核，再按要求办理等级保护备案。

完成边界与等级确认后，应依据对应级别的安全要求开展差距分析。高校场景中，以下五类问题通常应优先核查：

一是账号与权限。 学生毕业、教师调岗、外包人员撤场后，账号是否及时停用；管理员是否使用独立账号；统一认证与业务系统的权限回收是否同步。

二是敏感数据保护。 招生、学籍、成绩、科研、财务数据是否分级管理，导出、共享、备份和销毁是否有审批与记录，测试环境是否使用真实数据。

三是业务连续性。 选课、缴费、迎新、考试高峰期是否有容量评估与恢复预案；备份是否真正做过恢复验证。

四是网络与终端边界。 办公网、学生网、实验室、物联网设备和服务器区域是否隔离；暴露端口、远程运维入口和弱口令是否持续治理。

五是云服务与外包运维。 上云不等于责任转移。学校仍要明确数据归属、日志获取、漏洞处置、人员权限、服务退出和事件响应责任。

整改时建议按“高风险暴露面—关键身份权限—数据与日志—备份恢复—制度证据”的顺序推进，先消除可被直接利用的问题，再补齐持续运行能力。具体可结合等保整改要点制定责任到人的问题清单。

正式测评前，高校可先做一次内部预检查。技术侧核对资产、策略、补丁、基线、日志和备份；管理侧核对制度是否对应到岗位、流程和记录。建议提前整理以下材料：

材料要证明安全措施持续有效，而不是临时拼齐文件。制度与实际操作不一致时，应先修正流程并形成真实记录。正式阶段前，可按等级测评流程核对访谈、配置和证据准备。

高校项目周期受定级对象数量、现有基础、采购流程、整改复杂度和测评排期影响。单个边界清晰、基础较好的系统，差距分析可能需要约1—2周，整改与证据补齐约2—8周，正式测评及报告环节约3—6周；多个系统共用基础设施时，还要预留协调和联动整改时间，具体以属地要求为准。

预算也不宜只看测评服务本身。应把咨询梳理、技术整改、安全产品、云资源调整、测评服务和持续运营分别核算，并识别统一身份认证、日志平台、备份平台等可由多个系统共用的能力，避免重复建设。涉及具体费用时，应结合系统等级、规模、差距和当地执行口径评估，以属地要求为准。

高校可按以下顺序启动工作：

高校等保不是一次性的材料项目，而是持续治理机制。先把系统边界和责任讲清，再按风险排序整改，教务、科研、一卡通等系统才能有序推进，减少返工。