司法数据中台的招标文件里,几乎都有一句「须满足等保三级要求」。但真到测评那天才发现:权限是事后加的、审计日志东缺西漏、数据加密只做了传输没做存储、外部数据导入没纳入分类分级——于是整改、返工、延期。等保三级从来不是验收前补的一摞材料,而是从架构第一层就要长出来的能力。这篇文章不重复讲中台怎么建(那篇在《数字法治政府:司法数据中台建设方案》),而是专门下钻到一件事:怎么把一套司法机关数据中台,设计成天生就能过等保三级。等保三级的五大技术要求怎么落到中台每一层、定级备案走哪几步、分类分级与最小权限怎么固化、审计怎么做到全程可溯、信创与数据不出域怎么兼顾,以及测评最常见的失分项和照着问供应商的清单。
一、先纠一个最贵的误区:合规内生 vs 事后加装
多数项目栽跟头,不是技术不够,而是把等保理解错了。等保的核心原则之一是「三同步」——安全建设与系统建设同步规划、同步建设、同步使用。这句话翻译成工程语言就是:安全不是一个并行的「安全分包」,而是中台架构本身的一部分。
对照两种做法:
| 做法 | 表现 | 结果 |
|---|---|---|
| 事后加装(错) | 中台先按功能建好,临到测评再采购防火墙、堡垒机、日志审计、数据库审计往上贴,权限和脱敏靠应用层临时打补丁 | 测评高概率整改:审计覆盖不全、权限粒度太粗、数据存储未加密、外部数据游离在治理体系外,返工动架构 |
| 合规内生(对) | 定级先行,五大安全要求在架构设计阶段就分解到每一层;权限、审计、加密、脱敏、边界隔离是数据治理层和服务层的原生能力 | 测评是验证既有能力,而不是临时凑;后续加应用、加数据源,安全能力自动复用 |
一句话判断供应商:问它「等保三级的能力是架构自带的,还是测评前另外加产品补的?能不能拿出一个把审计、权限、脱敏画进数据治理层的架构图?」。答不上来、只会报一堆安全设备清单的,大概率是事后加装思路,后面一定返工。
二、等保三级的五大技术要求,怎么落到中台每一层
等保 2.0 三级的安全通用要求,技术部分可归纳为五个层面。下面把每一层翻译成「司法数据中台该做什么」,这是整篇文章的骨架:
| 等保技术层面 | 在数据中台里对应做什么 |
|---|---|
| 安全物理环境 | 中台部署在政法专网内的机房,机房按三级要求做物理访问控制、防雷防火防水、电力与环境监控;通常落在已建的政务云/政法云,沿用其物理安全资质 |
| 安全通信网络 | 网络架构分区分域,核心数据区与一般区隔离;通信传输全程加密(国密算法优先);关键链路冗余;与外网物理隔离,外部数据只走离线导入 |
| 安全区域边界 | 各安全区域之间边界访问控制(防火墙/网闸),入侵防范、恶意代码防范、安全审计部署在边界;最小化开放端口与服务;跨部门数据交换走受控的共享交换区 |
| 安全计算环境 | 这是数据中台的主战场:身份鉴别(双因子)、访问控制(RBAC+最小权限)、数据完整性与保密性(存储与传输加密)、数据脱敏、剩余信息保护、个人信息保护、操作全程审计——全部落在治理层与服务层 |
| 安全管理中心 | 统一的系统管理、安全管理、审计管理「三员分立」;集中的日志审计平台汇聚全中台操作与安全事件,可关联分析、可追溯、日志留存不少于六个月 |
这五层里,物理环境和通信网络往往可以复用已建政务云/政法云的资质和能力,真正考验数据中台设计水平、也最容易失分的,是安全计算环境和安全管理中心这两块——它们直接对应中台「治理数据、提供服务、留痕审计」的核心职责。下面三节重点拆这两块。
三、安全计算环境之一:数据分类分级是一切的地基
等保三级对数据保密性、访问控制、个人信息保护的要求,落地的前提是先把数据分类分级做出来。没有分级,「最小权限」无从谈起——你都不知道哪些数据该严管。司法数据中台的分类分级要解决两个问题:
- 按敏感度分级:把汇入中台的数据(本地办案数据、统计数据、全国裁判文书底座、法规库等)按敏感程度划级,例如可公开/内部/敏感/核心几档。不同级别对应不同的加密、脱敏、访问与审计强度。
- 按字段分级而非按表分级:同一份判决里,案号、案由、裁判要点可较宽松,而当事人身份信息、未脱敏的个人信息必须按最高级别管控。分级要细到字段,权限和脱敏才能精准。
分类分级既是《数据安全法》《个人信息保护法》的明确要求,也是等保三级访问控制与个人信息保护条款的落地基础。务实的做法是:在数据治理层把分类分级做成一套可配置的规则与标签体系,数据一入中台就打上分级标签,后续的权限、脱敏、审计策略全部基于标签自动生效,而不是靠人对每个场景单独判断。一个有政法项目经验的供应商,应当带着一套成熟的司法数据分类分级模板进场,而不是把这项最费力的治理工作甩给信息中心从零摸索。
四、安全计算环境之二:身份、最小权限与脱敏
分级之上,是访问控制三件套。等保三级在这里的要求比一般系统严得多:
| 控制点 | 三级要求落到中台 |
|---|---|
| 身份鉴别 | 重要操作采用双因子认证(口令+令牌/证书/生物特征其一);登录失败处理、会话超时、口令复杂度策略到位;管理员与普通用户分离 |
| 访问控制(RBAC + 最小权限) | 按角色授权,角色只拿到完成职责所需的最小数据范围与字段;跨部门调数据只能看到被授权的字段与范围;授权变更留痕;默认拒绝,显式授权 |
| 数据脱敏 | 对外共享、研判分析、AI 训练/检索等非办案场景走脱敏视图,屏蔽个人敏感信息;在严格授权和安全审查前提下保留按规则回溯原文的能力,兼顾保护与办案需要 |
| 数据保密性与完整性 | 敏感数据存储加密(国密优先)、传输加密;关键数据完整性校验;剩余信息保护,确保删除/释放的数据不可被恢复利用 |
这里的工程要点是:权限和脱敏必须做在数据服务层,而不是各个应用各做一套。中台的价值就是「数据一次治理、多处复用」,如果每接一个应用就重新写一遍权限和脱敏逻辑,不仅工作量翻倍,更会出现口径不一、有的应用漏脱敏的安全漏洞——而这恰恰是测评和实际泄露事故里最高发的点。正确的做法是把权限校验、脱敏、审计封装在统一的数据服务网关里,所有应用调数据都从这道关过,策略集中管理、一处变更全局生效。
五、安全管理中心:审计要做到「谁、何时、对哪条数据、做了什么」
等保三级对安全审计的要求,是很多司法数据项目最容易栽的一关。三级要求覆盖到每个用户的每一次重要操作,且审计记录要能支撑事后追溯与责任认定。具体到数据中台:
- 审计范围全覆盖:不只是登录登出,而是数据访问、查询、导出、共享、授权变更、脱敏开关、管理操作全部留痕。尤其是「数据导出」和「跨部门共享调用」这两类高风险操作,必须逐条可查。
- 审计内容够细:每条日志要能回答「哪个身份、在什么时间、从哪个 IP、对哪一条(类)数据、做了什么操作、结果如何」。粒度粗到只记「某用户登录了系统」是过不了的。
- 审计独立与防篡改:审计日志由独立的审计管理员管理,系统管理员无权删改自己的操作记录(三员分立);日志集中汇聚、防篡改存储、留存不少于六个月。
- 可关联可告警:安全管理中心能对日志做关联分析,对异常行为(如非工作时间大批量导出敏感数据)告警。
为什么司法场景对审计格外较真:办案数据一旦不当外泄或被违规查询,后果是司法公信力问题,不是普通的数据事故。一套查不清「这条当事人信息到底是谁在什么时候导出去的」的中台,不仅过不了等保,更担不起司法机关的责任要求。把不可篡改的全程审计当成中台的原生能力,而不是附加功能,是这一层的底线。
六、信创适配与数据不出域:两条政法系统的硬约束
除了等保通用要求,政法系统还有两条几乎写死的约束,设计时要一并满足:
信创适配
基础软硬件要适配国产化:国产 CPU(鲲鹏/飞腾等)、国产操作系统、国产数据库与中间件,满足自主可控要求。这对数据中台意味着:存储引擎、检索引擎、向量库、加密模块都要选有信创适配能力的技术栈,国密算法(SM2/SM3/SM4)优先。选型时要确认供应商的中台是真的在信创环境里跑通过、出过测评,而不是只在 x86 上演示。
数据不出域
全套部署在政法专网/政务内网,数据处理与模型推理均在内网完成,无外网调用。这一条和「引入全国裁判文书法规底座」并不矛盾——外部数据靠离线加密数据包导入,不是让中台去连外网。导入后的外部数据同样纳入中台的分类分级、权限、审计体系统一管理,与等保要求一致。这正是文书查在司法数据中台里的接入方式:
- 结构化全国裁判文书 + 法规底座:覆盖刑事、民事、行政、执行、国家赔偿,1.5 亿+ 篇,已做要素抽取与结构化,可直接进中台治理层对齐口径、套用同一套分级与权限。
- 加密数据包离线导入:数据源自人民法院等公开渠道,合法可溯源;以加密结构化包离线导入政法专网,全程不需中台连外网,守住数据不出域。
- 加密增量包定期更新:既补齐全国底座、保持时效,又不破坏内网隔离与等保合规。
七、过等保三级的流程:把节点写进项目计划
知道了要建什么,还要知道按什么节奏过。等保三级通常走五步,建议在立项时就把时间节点排进项目计划,让安全建设与中台建设并行:
| 步骤 | 做什么 | 谁主导 |
|---|---|---|
| ① 定级 | 运营单位依据《网络安全等级保护定级指南》初步定级,组织专家评审确定等级(中台一般不低于其承载的最高等级业务系统) | 运营单位(信息中心) |
| ② 备案 | 到属地公安机关网安部门提交备案材料,取得等保备案证明 | 运营单位 + 公安网安 |
| ③ 安全建设整改 | 按三级要求完成技术(五大层面)+ 管理(制度、人员、运维)两方面建设,与中台建设同步推进 | 建设方 + 供应商 |
| ④ 等级测评 | 委托有资质的测评机构开展等级测评,出具测评报告,不达标项整改后复测 | 第三方测评机构 |
| ⑤ 监督检查 | 投入运行后,公安机关对定级对象开展日常监督检查,运营单位持续做安全运维 | 公安网安 + 运营单位 |
关键提醒:定级要先行。等级没定,安全建设的强度就没有标尺,很容易要么过度建设浪费预算,要么建得不够测评通不过。先把级定下来、备案走起来,安全建设按标尺来,才不返工。
八、等保测评最常见的失分项(对照自查)
把这些高发失分点放进设计评审和供应商答疑,能避开八成返工:
- 审计不全:只记了登录,数据导出/共享/授权变更没逐条留痕,或日志粒度粗、留存不足六个月、可被管理员删改。
- 权限粒度太粗:按部门一刀切授权,没做到字段级最小权限;跨部门调数据能看到不该看的字段。
- 数据存储未加密:只做了传输加密,敏感数据在库里是明文;或没用国密算法。
- 外部数据游离体系外:引入的裁判文书等底座没纳入统一的分类分级、权限和审计,成了管控盲区。
- 三员未分立:系统管理员一人通吃系统、安全、审计三权,审计无法独立。
- 合规事后补:安全设备临时加装,与中台架构两张皮,联动不起来,违背三同步。
- 信创未真适配:演示在 x86,实际信创环境跑不通或性能塌方。
九、采购清单(照着问供应商)
把这份清单放进技术交流和招标答疑,一轮就能问出谁真懂政法等保、谁只是嘴上说满足:
- 等保三级能力是架构内生还是事后加装?能否提供把审计、权限、脱敏画进数据治理层的架构图?
- 数据分类分级怎么做?有没有成熟的司法数据分级模板?能否细到字段级?
- 权限与脱敏是统一在数据服务层做、所有应用复用,还是各应用各做一套?
- 审计是否覆盖数据访问/导出/共享/授权变更全操作?日志能否回答「谁在何时对哪条数据做了什么」?是否三员分立、防篡改、留存≥6 个月?
- 是否在信创环境(国产 CPU/OS/数据库 + 国密)里真实跑通并出过测评?
- 外部裁判文书/法规底座如何离线导入、如何纳入统一分级与审计、如何离线增量更新而不破坏数据不出域?
- 能否配合完成定级、备案、等级测评全流程?有无政法系统过等保三级的落地案例?
十、常见问题
Q:我们已经有政务云了,中台还要单独过等保吗?
A:政务云提供的是物理环境和部分基础设施层的安全资质,中台作为运行在云上的信息系统,其计算环境、应用与数据安全仍需按自身等级单独建设和测评。可以复用云的物理与网络安全能力,但安全计算环境和安全管理中心这两块是中台自己的责任,跑不掉。
Q:数据中台过了等保三级,上面的 AI 应用还要再过吗?
A:要看应用的定级和承载数据。AI 类案推送、量刑参考等应用通常复用中台的数据、权限与审计体系,安全能力是继承下来的,这正是「合规内生」的好处——底座过了,上层应用的安全大头已经解决,应用层主要再补自身的功能安全。具体仍以应用的等级测评要求为准。
Q:引入全国裁判文书底座,会不会增加等保整改的工作量?
A:如果按合规方式接入,反而不增加额外负担:数据以加密包离线导入,纳入中台已有的分类分级、权限与审计统一管理,沿用同一套安全策略,不需要为它单开一套机制。真正会增加工作量的,是把外部数据随意堆进来、游离在治理体系外——那才是测评失分和安全隐患的来源。
为你的司法数据中台评估一套等保三级合规架构
提供建设范围(涉及部门、合规等级、信创要求),我们反馈把等保三级落到每一层的架构建议、全国案例法规底座的合规离线接入方案与 POC 邀请。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:数字法治政府:司法数据中台建设方案 · 地方法院信息中心 AI 系统采购清单 · 1.5 亿裁判文书私有库:本地化部署的数据架构 · 裁判文书 API / MCP 定价