校园安全平台过等保二级，开发阶段要注意什么

文章摘要：等保二级的测评项里，身份鉴别、安全审计、剩余信息保护这三块，事后补的成本最高。本文按开发者视角，把等保 2.0 的五个技术层面拆成可落地的开发动作：身份鉴别的三条、审计记录的四个字段、剩余信息保护的三个易漏点，并给出信创适配在 CPU、操作系统、数据库、中间件四层的具体坑位。

等保二级过不了，多数时候不是安全设备买少了，是代码里少了几行。

尤其是三块：身份鉴别、安全审计、剩余信息保护。这三块在测评表里占的篇幅不大，但都是"要么有、要么没有"的判定项，测评前一个月补文档补不出来。

先对齐：常说的五层和等保 2.0 不是一套说法

开发团队习惯按"物理、网络、主机、应用、数据"分层，这是等保 1.0 时代的讲法。现行标准 GB/T 22239-2019 的技术部分换了个切法，按安全层面划分：

安全计算环境那 23 项，按控制点拆开是：身份鉴别 3、访问控制 4、安全审计 3、入侵防范 5、恶意代码防范 1、可信验证 1、数据完整性 1、数据保密性 0、数据备份与恢复 2、剩余信息保护 1、个人信息保护 2。

这里有个容易被忽略的数字：数据保密性在二级是 0 项。

意思是二级不强制要求存储加密。但《个人信息保护法》对敏感个人信息明确要求采取加密等保护措施，人脸、行踪轨迹都在其列。所以校园安全平台不能只盯等保——等保是底线，个保法是另一条线，两条都要过。

安全物理环境：开发团队管不到，但会被问到

这 15 项主要落在机房：物理位置选择、门禁、防盗防破坏、防雷、防火、防水防潮、防静电、温湿度、电力供应、电磁防护。

开发团队通常不负责机房，但有两件事必须提前确认：

一是部署形态。本地部署的，要拿到机房的等保测评报告或至少满足项清单；云上部署的，要拿到云服务商的等级测评证明和责任共担说明。测评时这两份材料是必查项，缺了会被直接记为不适用或不符合。

二是交付文档。部署架构图、网络拓扑图、设备清单，这三份东西在开发阶段就该产出来，不要等到测评前现画。

安全通信网络与区域边界：三条最低要求

通信传输加密。重要数据传输要用密码技术保证完整性，传输过程要保证保密性。落到开发上是：全站 HTTPS，禁用 TLS 1.0/1.1，内部服务间调用也不要裸 HTTP。有信创要求的项目，国密改造要提前规划 SM2/SM3/SM4 的支持。

网络架构分区。校园场景里至少有四张网要分开：视频专网、办公网、互联网、运维网。视频专网不能直接暴露在公网，GB/T 28181 的联网对接要过安全网关，不要为了调试方便开个公网端口就一直开着。

边界访问控制。默认拒绝、按需放行。这条在开发阶段对应的动作是：把服务端口清单列出来，逐个确认"为什么开"，说不清的就关掉。

安全计算环境：开发者真正的主战场

身份鉴别：二级只要求三条，但三条都要有

a) 登录用户有唯一身份标识，鉴别信息有复杂度要求并定期更换；

b) 有登录失败处理功能，配置并启用结束会话、限制非法登录次数、登录连接超时自动退出；

c) 远程管理时，采取必要措施防止鉴别信息在网络传输过程中被窃听。

四条开发动作：

用户唯一标识别用手机号。手机号会变更、会复用，用自增 ID 或 UUID 做唯一键，手机号只作为可修改的联系方式字段。

口令策略要在服务端校验。前端校验只是体验优化，抓包绕过前端是基本功。长度、字符类型、有效期、历史口令不重复，这四项在服务端各写一遍。

失败锁定要写审计。连续 N 次失败锁定 M 分钟，锁定和解锁事件都要进审计日志——测评时这一条会被要求出示记录，不只是功能演示。

会话超时要服务端可控。前端倒计时可以伪造，令牌失效必须由服务端判定。闲置超时和绝对超时两个都要有。

二级不强制双因素认证，三级才要求"两种或两种以上组合的鉴别技术"。但校园平台的运维账号、管理员账号，建议直接上双因素——这类账号一旦失守，影响面是整个学校的人脸库。

访问控制：最小权限是四件事，不是一句口号

默认账户要处理：改名或禁用，默认口令必须改。

多余账户要清理：离职人员的账号、测试账号、临时开通的账号。

授权粒度要够细：按角色授权，角色与岗位绑定，不要给某个人单独开权限。

权限要最小：普通业务账号不能有数据库管理权限，运维账号不能有业务数据导出权限。

开发上有两个常见反模式：一是权限判断散落在各个接口里，写成一堆if (user.isAdmin)；二是只在前端隐藏按钮，接口不做鉴权。前者改权限要改几十处，后者是典型的越权漏洞。

正确做法是把鉴权收在拦截器或网关层，权限模型用 RBAC，数据级权限（班主任只能看本班、宿管只能看本楼）单独做一层。

安全审计：四个字段不能少

审计记录必须包含：日期和时间、用户、事件类型、事件是否成功。

这四个字段是测评时的硬要求，缺一个就是不符合。很多系统记了"谁在什么时候做了什么"，但没记"成功还是失败"——失败记录恰恰是排查越权尝试的关键。

审计记录还要保护：不能被删除、修改、覆盖。落到实现上，审计库要和业务库分离，业务管理员无权删审计数据，审计员和系统管理员分设。

留存期：网络安全法第二十一条要求网络日志留存不少于六个月。这条比等保的表述更明确，直接按六个月做。

必审的关键操作清单：登录与登出、权限变更、数据导出、数据删除、配置修改、视频调取、人脸库变更。校园平台里，"视频调取"和"人脸库变更"是两个最容易被漏掉、也最容易被追责的动作。

入侵防范：五条加一条

二级的入侵防范有 5 项：最小安装、关闭不需要的服务和端口、漏洞修补、入侵行为检测、数据有效性校验。

开发阶段能做的是后三条：

依赖组件版本管理。上线前扫一遍依赖，别把带已知漏洞的组件带上去。第三方 SDK 也要扫。

所有外部输入做校验。长度、类型、范围、白名单，四道过滤。文件上传限制类型和大小，存储目录不能给执行权限。

漏洞修复要有记录。测评时会问"上次发现漏洞是什么时候、多久修好的"，答不上来就是不符合。

数据完整性那 1 项，要求传输过程做完整性校验。HTTPS 本身提供了，但关键业务数据（比如考勤记录、报警记录）建议再做一个应用层摘要，防止中间环节被篡改。

剩余信息保护：最容易漏的一项

二级只有 1 项，但该项的判定很干脆：释放前是否完全清除鉴别信息和敏感数据。

三个真实项目里最常见的漏点：

删除学生照片，只删了数据库记录，文件还在磁盘上。数据库里那条记录没了，但对象存储或本地目录里的图片还在，通过 URL 依然能访问。正确做法是数据库标记删除 + 定期物理清理 + 清理日志。

导出临时文件不清。导出 Excel 之后临时文件留在 /tmp 或应用目录，里面是全校学生名单。正确做法是临时目录定时清理，应用退出时也清一次。

调试日志打了敏感字段。手机号、身份证号、人脸特征、甚至整段 base64 图片进了日志文件。正确做法是日志脱敏，敏感字段统一走脱敏器，上线前把 debug 级别关掉。

还有一条容易被忽略：内存里的敏感数据。Java 里用 String 存口令，GC 之前那块内存一直可读；用 char[] 并在使用后清零，是更稳妥的做法。

信创适配：开发阶段就要定的四件事

信创环境不是"换个操作系统重装一遍"那么简单，四层都有坑。

四条经验：

数据库方言要做适配层，别把 SQL 写死在业务代码里。分页、字符串拼接、时间函数这三类最容易出问题。

字符集统一 UTF-8。达梦默认可能是 GB18030，迁移时中文乱码多数出在这里。

时间类型要实测。Oracle 兼容模式下 DATE 和 TIMESTAMP 的行为不完全一致，跨库迁移前先跑一遍时间相关的用例。

性能基线要重测。x86 上的压测数据不能直接拿去投标，ARM 平台上的加解密、视频解码性能差异要看具体型号。

开发阶段检查表

等保考的是设计，不是补丁

等保二级的技术要求本身不算高，难的是它要求的东西分散在每一行代码里。

口令复杂度是一行，会话超时是一行，日志里少打一个身份证号也是一行。这些东西在开发阶段加进去，成本几乎为零；等到测评前再补，要动的是架构。

测评前一个月补文档，能过形式；补不了代码。

本文内容整理自校园安全大脑产品官网的《校园人脸识别怎么合规落地？六个环节与对应法条》，法条对照表与材料清单见原文：​校园人脸识别怎么合规落地？六步流程与逐条法律依据 - 校园安全大脑

本文作者：校园安全大脑（济南亚爱特软件有限公司）

说明：「校园安全大脑」是济南亚爱特软件有限公司自 2019 年起研发的校园安全管理平台产品名称，与部分厂商方案中作为通用功能概念使用的「校园安全大脑」表述不是同一对象。