JeecgBoot AI专题研究 | 三级等保 2.0 应用安全要求逐条拆解，以及 JeecgBoot 低代码平台在身份鉴别、访问控制、安全审计、数据加密等环节的落地清单
做政企交付的同行都心里有数：客户合同里只要写了「三级等保」四个字，意味着后续半年要面对一份长长的整改单。要么团队自己一条一条对着标准改代码，要么客户找测评机构出报告时把锅甩回来——「这条不符合，请整改」。
更尴尬的是，研发同学经常被这几个问题问住：
- 等保 1.0 和 等保 2.0 到底差在哪？
- 我们这个系统该定二级还是三级？
- 三级等保的应用安全要求一共有几条？每一条具体要做什么？
- 低代码平台能直接覆盖多少？哪些必须额外开发？
这篇文章把三级等保基础概念和应用安全要求两条主线合在一起重新梳理，配合 JeecgBoot 低代码平台的实战经验，写一份对得起一线开发者的「等保速查手册」。
一、先把名字理清楚：等保 1.0 vs 等保 2.0
很多人嘴里说着「等保」，其实并不清楚自己面对的是哪一代标准。这两代的差距不是版本号那么简单，背后是行政法规升级到了国家法律。
| 维度 | 等保 1.0（2007） | 等保 2.0（2017 起） |
|---|---|---|
| 全称 | 信息安全等级保护 | 网络安全等级保护 |
| 顶层依据 | 《信息安全等级保护管理办法》 | 《网络安全法》 |
| 性质 | 行政管理办法 | 国家法律（违法要担责） |
| 覆盖范围 | 主要看软件应用系统 | 物理、网络、主机、应用、数据五大块全覆盖 |
| 测评对象 | 「软件系统」为主 | 云计算、移动互联、物联网、工业控制系统等都进来了 |
简单一句话：等保 1.0 是「行政指导」，等保 2.0 是「法律义务」。2017 年 6 月《网络安全法》正式生效后，「不做等保」就不再是「整改建议」，而是直接违法。这也是为什么 2017 年之后，再小的政企项目立项时，合同里都会冒出「等保备案」这一条。
二、五个等级，为什么我们重点谈三级？
等保把信息系统从「重要性 + 出事后果」两个维度切成五级：
- 一级 · 自主保护级：出事只损害一般公民、组织的合法权益，不影响国家安全和社会秩序。多数小型内部网站属于这一档。
- 二级 · 指导保护级：出事会对公民、组织合法权益造成严重损害，或对社会秩序、公共利益造成一般损害。一般的政务网站、企业 OA、HR 系统大多走二级。
- 三级 · 监督保护级：出事会对社会秩序、公共利益造成严重损害，甚至危害国家安全。这一档是大部分行业系统的「天花板」——医院 HIS、智慧政务、金融业务系统、能源调度、教育云平台几乎清一色三级。
- 四级 · 强制保护级：直接威胁国家安全，比如电网核心调度、央行核心交易系统。
- 五级 · 专控保护级：极特殊的国防、机要场景，民用基本接触不到。
为什么大家都在聊三级？
因为四级和五级是央企国家队的事，二级又太轻量、覆盖不够全面，三级是绝大多数政企交付能碰到的最高门槛，做完三级，意味着系统在制度、技术、管理三个层面都过了一遍硬指标。从生意角度看，能做三级的乙方在投标时也更有底气——这块资质几乎是政企赛道的入场券。
定级也不是项目经理拍脑袋决定，要走一整套流程：
确定定级对象 → 初步定级 → 专家评审 → 主管部门审核 → 公安机关备案 → 最终定级
三、定级的常见误区
「我们公司挺小的，定个二级吧。」
这是最常见的误判。等保定级看的不是公司体量，而是「系统受破坏后的影响范围」。
依据是 GB/T 22240-2020《网络安全等级保护定级指南》，里面给出了一个二维矩阵——一边是「受侵害的客体」（公民/组织合法权益、社会秩序和公共利益、国家安全），一边是「侵害程度」（一般、严重、特别严重）。两者交叉决定级别。
举几个真实场景：
- 一家区县级医院的电子病历系统：受众覆盖几十万居民，泄露/篡改会造成严重社会影响 → 三级起步。
- 一家民营公司的内部 OA：只影响员工，不涉及公共利益 → 二级即可。
- 一个开放给公众使用的政务服务平台：哪怕用户量不大，因为属于政府公共服务 → 必须三级。
按行业拍脑袋（「医院都是三级」）、按数据量定级（「我们才几千条数据，二级吧」）、按主观感觉（「我们安全做得挺好」）都是错的。该参照标准定多少级就是多少级，能不能通过测评是技术问题，定级标准本身不接受讨价还价。
四、三级等保应用安全要求逐条解读
等保 2.0 的技术要求分五个维度：物理安全、网络安全、主机安全、应用安全、数据安全。前三项更多是 IDC 和运维侧的责任，真正落在研发团队头上的，是应用安全和数据安全。下面把这两块的硬指标一条一条拆开。
4.1 身份鉴别：登录这一关怎么过
这是测评机构最先翻的一页，也是低代码平台最容易踩坑的地方——因为「能登录」和「登录方式符合等保」是两回事。
四条硬要求：
- 用户身份要唯一：不能两个账号共用一份凭据；管理员账号不能跟普通账号混用。
- 鉴别信息要有复杂度并定期更换：业界共识是 8 位以上，必须同时包含大小写字母、数字、特殊符号，3~6 个月强制改一次。
- 登录失败处理 + 会话超时：连续 5 次失败必须锁定账号（一般 20 分钟），30 分钟无操作自动登出。
- 远程管理传输加密：HTTPS 是底线，国密场景要 SM2/SM4/RSA，明文 HTTP 直接被判不合格。
- 双因子认证：必须采用两种或以上鉴别方式的组合，比如密码 + 短信验证码、密码 + USB-Key、密码 + 证书。
低代码平台要做什么？ JeecgBoot 默认提供密码强度策略、登录失败锁定、会话超时三大基础能力，开箱即可勾选启用。双因子部分需要二次集成：短信 OTP、企业微信扫码、CA 证书、人脸识别都能挂上去，但这步是研发实施时的「必做项」，不要把它当作选配。
4.2 访问控制：谁能看到什么
身份鉴别解决「你是谁」，访问控制解决「你能干什么」。三级等保对这一项的态度是「最小权限 + 三权分立」。
- 用户和权限要按需分配，不能「全员超管」。
- 默认账号必须被重命名或删除：admin / root / 123456 这类弱默认值是测评的红线。
- 默认口令必须修改，初次登录强制改密。
- 三权分立：系统管理员、安全管理员、审计管理员，三个角色的权限要互相独立、互相制衡。系统管理员不能查审计日志，安全管理员不能改系统配置——这一条很多自研系统都会栽。
低代码平台天然适合这个场景，因为权限模型本身就是平台核心能力。JeecgBoot 的菜单权限、按钮权限、数据权限、字段权限四级体系可以直接拆出三个角色；难点是测评时要拿出制度文档证明三权确实分离，不能只是技术上配了三个角色但实际同一个人在用。
4.3 安全审计：日志才是底气
这一条几乎是所有测评的「重灾区」，因为日志不是「记下来就行」。
- 审计要覆盖每一个用户：不能漏掉任何账号的关键操作。
- 审计内容要全：重要业务行为（增删改查）、安全事件（登录失败、权限变更）、系统异常都要落库。
- 审计记录不能被删/改：即便是管理员也不能直接清日志。
- 审计记录保存周期不少于六个月，且要定期备份到独立的介质。
低代码要做的是：
- 在 AOP / 拦截器层统一切入，给所有 Controller 自动织入操作日志。
- 日志库与业务库物理隔离，业务管理员没有日志库写权限。
- 提供「日志查询 + 归档导出」的独立模块，给审计管理员单独授权。
JeecgBoot 自带的「系统监控 → 系统日志」+「定时任务」就是为这条要求设计的。但要注意：默认日志只是登录日志和操作日志，业务侧的关键行为（比如审批、提现、改价）需要在代码里手工 @AutoLog 一遍，等保测评时审计员会专门翻这一块。
4.4 入侵防范：把口子收紧
- 数据有效性校验：所有用户输入要在服务端再校验一次，前端校验不算数。SQL 注入、XSS、CSRF 是三件套必查项。
- 上传文件限制：限制文件大小、扩展名白名单、MIME 类型校验、内容嗅探（防止改后缀名）。
- 定期漏洞扫描：发现高危漏洞 30 天内必须修补，中危 60 天内修补——这是文档要求，不是建议。
低代码平台在这里通常用统一的 XssFilter + 文件上传白名单两套组件解决。但有一个常见的低代码雷区：很多平台允许用户在线写 SQL（自定义报表、自定义查询），这一块如果没做 SQL 解析白名单，三级等保铁定过不了。JeecgBoot 在积木报表里加了 SQL 关键字黑名单 + 只读账号隔离，就是为了过这道关。
4.5 数据完整性：别被篡改
- 存储中的重要数据要用 SM3、SHA-512 等算法做哈希校验。
- 传输中的数据要保证完整性，常用 HMAC 或者签名机制。
低代码层面这一条往往落在「字段加密 + 摘要校验」上：身份证号、手机号入库前过一遍 SM3，并把摘要单独存一列用于校验。
4.6 数据保密性：别被偷看
- 存储敏感数据要用 SM2、SM4 加密。
- 数据展示时要做脱敏（手机号中间四位 *，身份证留头留尾）。
JeecgBoot 在字段级别提供了 @SensitiveInfo 注解，前端展示自动脱敏；数据库层面国产化场景接达梦、金仓时，配合数据库自带的透明加密一起用。
4.7 数据备份恢复：兜底方案
- 本地备份：每日全量 + 增量备份。
- 异地实时备份：同城 30 公里以上，异地 300 公里以上。
- 热冗余部署：集群 + 负载均衡 + 故障自动切换。
这一条主要靠基础设施和 DBA，不归应用研发管。但低代码平台要做的是业务数据的导出/导入工具——比如表单数据、流程定义、报表配置一键打包，方便客户在异地灾备时还原系统状态。
4.8 剩余信息保护：擦干净再走
容易被忽略但测评必查：
- 用户登出 / 会话过期后，Cookie、Session、本地缓存要立即清除。
- 临时文件用完就删，不要堆在服务器上。
- 内存中处理过的敏感数据（密码、token），用完置空——Java 里
String不可变这事不能装作没看见，敏感场景该用char[]就用char[]。
五、一张表看清低代码要补的功课
| 等保要求 | 低代码原生支持 | 仍需额外开发/配置 |
|---|---|---|
| 身份唯一 | ✅ 内置 | — |
| 密码复杂度 + 定期更换 | ✅ 内置（需开启策略） | — |
| 登录失败锁定 + 会话超时 | ✅ 内置 | — |
| 传输加密 | 需运维 HTTPS / 国密 | 国密改造需引入 SM2/SM4 SDK |
| 双因子认证 | ⚠️ 提供集成点 | 必须二次开发：短信/CA/扫码 |
| 三权分立 | ✅ 角色模型支持 | 制度文档 + 实际人员分离 |
| 操作审计 | ✅ 系统日志模块 | 业务关键操作要手工加 @AutoLog |
| 日志保存 6 个月 | 配置即可 | 独立日志库 / 异地归档 |
| XSS / SQL 注入防御 | ✅ 统一过滤器 | 自定义报表 SQL 要加白名单 |
| 文件上传限制 | ✅ 内置白名单 | 病毒扫描需对接第三方 |
| 数据加密存储 | ⚠️ 字段注解 | 必须二次开发：密钥管理、HSM 接入 |
| 数据脱敏展示 | ✅ 注解支持 | — |
| 备份与异地容灾 | — | 完全靠基础设施 |
| 剩余信息清除 | ✅ Spring Security 退出登录 | 自定义会话需自查 |
把这张表交给项目经理，能在投标阶段就把哪些是「平台送的」、哪些是「要单独报价的」分清楚。
六、给一线团队的三条实战建议
第一，先做差距分析，再动代码。等保测评公司通常会先来一轮预检，列出 30~80 条不符合项。不要等他们出报告才开始改，应该在合同签订前自己照着 GB/T 22239-2019 跑一遍 checklist，心里有数才好谈整改预算。
第二，双因子和加密这两块必须早决策。这是最容易被「我们后期再加」拖死的两个模块。短信通道选谁、证书 CA 选谁、国密 SDK 用哪家，一旦立项前没敲定，到测评期再补会让整个上线计划推迟一个月起步。
第三，审计日志「宁多勿少」。日志多了无非多花点存储钱，日志少了直接整改不过。所有写库操作、所有权限变更、所有敏感数据访问，全部加日志，等到测评员问起来，截图打开就完事。
低代码平台的价值在这里很明显：80% 的等保技术要求都能靠平台默认能力覆盖，研发只要把剩下的 20%（双因子、国密、业务侧审计、自定义报表 SQL 白名单）补上即可。和从零搭一套相比，时间从一年压到两三个月——这也是为什么近几年政企交付几乎清一色选低代码当底座。
总结
三级等保不是「装一套防火墙」那么简单，它是一份覆盖身份、权限、日志、加密、备份、清理六大块的系统级清单。等保 2.0 已经从「行政办法」升级为「国家法律」，做政企项目绕不开它。
对研发团队来说，把 GB/T 22239-2019 的应用安全部分读一遍，再对照低代码平台的能力列一张差距表，是项目立项前最有性价比的功课。JeecgBoot 这类低代码平台已经把通用能力打包好，剩下的就是把项目特性的那部分补齐——把通用基建省下来的时间，花在双因子、国密、业务审计这些必须定制的地方，才是把等保做扎实的正确节奏。
合规不是负担，是政企赛道的通行证。
本文为 JeecgBoot AI 专题研究系列文章。