金融行业等保2.0三级与数据安全管理办法双轨合规落地路径

一家城商行半年里收到两份整改：一份来自等保测评机构，说核心系统「数据保密性、备份恢复」不达标；另一份来自监管数据安全检查，说数据分类分级没落地、敏感数据测试环境裸奔。两家来查的口径不一样、术语不一样，整改单却长得惊人地像。信息科技部同事第一反应是问：等保三级和《银行保险机构数据安全管理办法》到底是不是一回事？能不能一套整改、两个都过？

答案是：两条轨、同一条路。等保2.0三级（GB/T 22239-2019）管的是「系统」安全，数据安全管理办法管的是「数据」安全，但金融监管文件写得很直白——数据安全义务是「在网络安全等级保护制度基础上」履行的，等保是底座，数安要求是往底座上叠的加层。真正让银行头疼的不是技术，是两套术语怎么对齐、一次改造怎么同时满足两家的检查。

这篇按对比式拆：先分清两条轨各管什么，再用一张对照表把两套要求逐项对上，最后给出「数据分级对齐 → 双目录盘点 → 全生命周期落点 → 双达标验收」的并轨路径。文中涉及加密、认证、密钥、备份的产品落点，按安当 TDE/KSP/ASP/HSM/RDM/DSI 六件套怎么当答案来写，每条技术都给「怎么验证做对了」。

全文结构：

• 一、先认清两条轨：一条管系统安全，一条管数据安全
• 二、双轨到底都查什么：一张对照表全对上
• 三、数据分级：把三套术语对齐（最常踩坑的一步）
• 四、双轨并轨：五步落地路径
• 五、数据防护怎么落地：加密、认证、密钥、备份四件事
• 六、双达标验收清单（两套检查单合一张表）

一、先认清两条轨：一条管系统安全，一条管数据安全

轨 A：等保 2.0 三级——以「系统」为对象的网络安全等级保护

等保 2.0 的正式名称是 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》。它的检查对象是等级保护对象——一个信息系统、一个平台、一个安全域，第三级要求（8.1.x 系列）分五个面：安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心。

对银行来说，核心系统、网银、支付系统基本都是三级，按规定每年至少一次等级测评。等保是「终身制」的：定级备案 → 建设整改 → 等级测评 → 持续运行，测评不通过就是高风险项在案。

等保三级在「数据」上真正直接说话的，是安全计算环境里的数据完整性与保密性、数据备份恢复：核心数据要加密存储、要有本地+异地两级备份、要能恢复演练。但等保基本不回答「数据长什么样、分几级、能不能出域」——那是轨 B 的地盘。

轨 B：数据安全管理——以「数据」为对象，金融监管 24 号文是总纲

银行的数据安全轨，由三层文件搭成，从抽象到具体：

关键在于金规〔2024〕24 号第五条：银行保险机构利用互联网等信息网络开展数据处理活动，应当在网络安全等级保护制度基础上，履行数据安全保护义务。 这句话就是「双轨并轨」的法律接口——等保不是可以甩掉的旧账，而是数据安全义务的承重墙。

一句话记住两条轨的区别

等保三级问的是「系统跑得安不安全」，数安办法问的是「数据本身被没被保护好」。 前者按系统编号逐台过，后者按数据目录逐类过。系统可以安全，但数据照样泄露——把敏感数据明文导出到测试库、外包开发环境随便查，等保测评未必抓你，数据安全检查一抓一个准。

二、双轨到底都查什么：一张对照表全对上

把两套要求摊开，同一个对象在两条轨下各有说法。真正干活时不用背两套条款，把「对象」当行、「两条轨」当列，差异自然浮出来：

这张表看下来，规律很清楚：

1. 约七成要求是重合的——身份、访问、传输、存储、审计、备份，一套技术建设两边检查单都能勾上；
2. 轨 B 净增的是「数据视角」的活：分类分级、脱敏、数据共享审批、出境评估、按数据类型的存储位置管理——这些是等保查不出来的「死角」；
3. 所以不要建两套技术体系，而是建一套体系 + 一份数据目录：技术底座按等保三级建，数据台账按 24 号文建，检查时各取所需。

插一段：银行实际是「三套检查」，别把密评漏了

真到迎检那一步，银行核心系统往往同时面对三张检查单，别只盯着等保和数安两条轨，把密评混进来分清楚，才不会改错方向：

三者的关系一句话：等保管系统、数安管数据、密评管密码。前两者管「做什么」，密评管「用什么工具做、做得对不对」——所以你后面做加密、认证、密钥管理时，落到密评眼里就是 SM2/SM3/SM4 用得对不对、密钥生命周期管没管、密码产品过没过认证。技术底座一次建好，三张检查单各自对号入座；其中密钥这一层是密评和数安都盯着的交集，第五节会专门讲怎么落。

三、数据分级：把三套术语对齐（最常踩坑的一步）

银行做双轨合规，第一道坎不是技术，是术语打架。管数据的要你分「核心/重要/一般」，管个人信息的要你分 C1/C2/C3，做密评的按 1-5 级走，做等保的又只看系统等级。四套说法对不上，台账就建不起来。

对齐关系其实很固定：

个人金融信息（JR/T 0171）        金融数据级别（JR/T 0197）       监管分级（24号文口径）
C3 用户鉴别信息/密码      →       4级（从高可到5级）        →       敏感数据及以上
C2 身份证/银行卡/住址     →       3级                     →       敏感数据
C1 开户时间/机构代码      →       2级                     →       一般数据（敏感）
非个人信息业务数据        →       1-2级（看影响）          →       一般数据
汇聚/整合后影响放大       →       升至5级/按重要数据        →       重要数据

踩坑点 1：个人金融信息要「从高定级」。 JR/T 0197 明确：涉及个人金融信息的数据，参照 JR/T 0171 定级并从高考虑。密码、CVN 这类 C3 鉴别信息直接冲 4 级；就算是一条孤立的身份证号（C2），也按 3 级管，别图省事压到 2 级。

踩坑点 2：脱敏是监管认可的「降级通道」。 同一份数据，原始态是 4 级敏感数据，但经过脱敏（掩码/替换/保留格式 FPE）之后，识别不到具体个人，安全级别可以降下来——这就是为什么监管强制「测试环境必须用脱敏数据」：测试库之所以能用低防护跑，前提是数据已经被脱过敏，而不是明文直接搬过去。

踩坑点 3：别把「核心数据」当成「核心系统」。 24 号文的「核心数据」指对国家安全、经济运行、社会稳定影响重大的数据，和银行口头上说的「核心系统（Core Banking）」完全是两码事。做台账时要把这两个词分开，否则给监管的分级表会写错。

落地到系统里，就是给每张业务表打上数据级标签。实践中可以按字段类型直接映射，比手工一列列定级快得多：

-- 以个人客户主数据表为例，按字段口径初判敏感级（示意，需结合本行定级细则复核）
SELECT
  column_name,
  CASE
    WHEN data_type LIKE '%password%' OR column_name LIKE '%pwd%' OR column_name LIKE '%cvn%' THEN 'C3/4级-敏感'
    WHEN column_name LIKE '%id_no%' OR column_name LIKE '%card_no%' OR column_name LIKE '%mobile%'
         OR column_name LIKE '%address%' THEN 'C2/3级-敏感'
    WHEN column_name LIKE '%open_date%' OR column_name LIKE '%branch%' THEN 'C1/2级-一般'
    ELSE '待人工复核'
  END AS sec_level
FROM information_schema.columns
WHERE table_schema = 'core' AND table_name = 'cust_main';

定完级之后，所有技术措施都按「这个级别配什么防护」来挂：4 级/敏感数据上全套组合（加密存储+字段级加密+脱敏出口管控+审计），1-2 级一般数据只做基础防护，避免全库无差别上重武器把性能拖垮。

四、双轨并轨：五步落地路径

把两套要求并成一条路，落地顺序建议这样走：

第 1 步：双目录盘点——既清系统，也清数据

• 系统目录（喂给等保）：全行系统清单、定级备案、网络拓扑、安全域划分；
• 数据目录（喂给 24 号文）：每个系统里有哪些数据、属于哪一类（客户/业务/经营/系统运行）、定到哪一级、存在哪个库哪张表、流向哪里。

双目录是后面所有工作的地基。数据目录尤其重要——监管现在查你，第一件事就是让出数据目录和分类分级结果，目录是空的，后面全是空谈。

第 2 步：数据分级打标（第三节的映射落地）

给数据目录逐项定级、给表字段打敏感级标签、建台账并动态维护（新增数据源、新增字段即时补录）。这一步产出的台账，就是双轨检查单的索引。

第 3 步：技术保护按「数据全生命周期 × 控制点」落位

对每一类敏感数据，从采集、存储、使用、加工、传输、提供、公开、删除走一遍，每一段挂上对应控制点：

数据生命周期         敏感数据的控制点                          对应产品落位
─────────────────────────────────────────────────────────────────────────────
采集/录入   → 传输加密(国密TLS)、访问强认证              ASP 认证 / HSM 密钥
存储       → 数据库透明加密、字段级加密、密钥分离         TDE + KSP
使用       → 最小权限访问、按角色授权、敏感查询审计       ASP+DBG(审计)
加工       → 汇聚分析后重新评估是否升级、脱敏复用         DSI 脱敏
测试/开发  → 必须先脱敏再落测试库(静态/保留格式脱敏)       DSI 脱敏
传输       → 链路加密(国密SM2/SM4)、API双向认证           HSM+TDE 网关
对外提供   → 授权审批、脱敏共享、水印追溯                 DSI + 审计
备份       → 备份数据同样加密、防勒索保护备份池            KSP+RDM
删除/销毁  → 剩余信息保护、销毁留痕                       KSP 审计

第 4 步：应急与外包管理补齐「数据视角」的洞

等保三级有应急预案和演练，但对象是「系统故障/网络攻击」。按 24 号文，你得把数据安全事件（泄露、破坏、非法利用）单独拉出来：数据泄露应急流程、敏感数据泄露的溯源手段（水印/审计日志倒查）、对第三方外包/外部数据供应商的安全管理。银行数据泄露的常见口子恰恰在外包和共享环节，这一块是数据安全检查的高频失分点。

第 5 步：测评迎检，一套证据两处复用

等保测评交：测评报告、系统拓扑、整改记录；数据安全检查交：数据目录、分级台账、脱敏记录、共享审批单、应急演练记录。把第 3 步每一条控制点的验证命令、截图、审计日志存成一个证据包，两家来查时按清单对号入座，不用二次翻库。

五、数据防护怎么落地：加密、认证、密钥、备份四件事

双轨要求的技术活，落到落地点上本质是四件事。每件按「做什么 → 用什么产品怎么落地 → 怎么验证」写，产品只当答案不展开品牌：

1. 数据加密：TDE（存储）+ 加密网关（传输）

• 核心数据库敏感字段落盘加密用 TDE 透明加密：对应用零改造，数据库写入读出自动加解密，性能损耗可控（典型个位数百分比），同时满足等保「重要数据加密存储」和 24 号文「敏感数据存放重点防护」；
• 只对个别高敏字段（密码、CVN、完整卡号）做更细的字段级加密时，配合加密网关或应用加密 SDK 按字段处理，避免全表 TDE 影响大范围查询；
• 链路侧做国密 TLS / 传输加密，保证「传输中」也过检查。

2. 身份与访问：ASP 统一认证 + UKEY

• 数据访问入口做双因素：运维、柜面、开发环境登录走 ASP 统一认证，核心敏感系统加 UKEY/动态口令，一套认证体系同时勾掉等保「身份鉴别」和 24 号文「数据访问访问控制」；
• 权限模型按最小够用授权，敏感数据的查询、导出、批量下载单独拉权限 + 双人复核。

3. 密钥与密评底座：KSP + HSM

• 加密方案最怕「密钥和数据放一起」。TDE/传输加密的密钥统一交给 KSP 密钥管理系统托管，KSP 的根密钥落在 HSM 国密密码机硬件内，形成「数据用 TDE 加密、密钥归 KSP 管、根密钥锁在 HSM 里」的三级链条；
• 密钥全生命周期（生成/存储/轮换/归档/销毁）留审计记录，既满足密评 GB/T 39786，也满足 24 号文「数据处理活动可审计」——密钥台账随手能出证。

4. 备份与防勒索：KSP 备份加密 + RDM 防勒索

• 备份数据本身是敏感数据的大集合，得加密备份，密钥继续走 KSP；
• 给备份池加 RDM 防勒索：对数据库文件、备份文件的异常批量读写实时拦截，防止勒索病毒连备份一起加密——否则等保的「异地备份」和 24 号文的「备份可恢复」都会被一锅端。

5. 脱敏：DSI 数据加密集成服务（静态/动态脱敏）

• 测试库、开发环境、外包接触环节用脱敏解决「既要数据可用、又不能见明文」：静态脱敏把生产全量搬到测试环境时替换成假数据，动态脱敏对查询出口实时掩码，均支持 FPE 保留格式——身份证、卡号脱敏后仍保持格式可用，业务逻辑不崩；
• 这一步是等保查不到、监管必查的「数据视角」死角，是双轨里最容易漏、也最容易被单独点名的一项。

端到端视图（示意）：

业务系统/柜面/网银
   │  (双因素认证)         ASP 统一认证
   ▼
核心数据库 ── TDE 透明加密（落盘密文）
   │                   密钥由 KSP 管理，根密钥在 HSM 内
   ├─ 字段级加密（DBG/应用SDK，按字段）
   ├─ 测试/开发环境 → DSI 脱敏（先脱敏再落地）
   ├─ 对外共享/接口 → DSI 脱敏 + 水印 + 审计
   └─ 备份池 ── 备份加密(KSP) + RDM 防勒索拦截异常读写

六、双达标验收清单（两套检查单合一张表）

对着一份数据目录，逐条自查「这条要求两轨都过没过」：

逐条对照完，把第 4、6、7、10、12 这几项单独圈出来——它们就是等保查不到、数据检查必查的「数据视角」增项，也是双轨整改里真正会拉分的部分。

等保 2.0 三级和《银行保险机构数据安全管理办法》不是两套要重复建设的体系：技术底座按等保三级建一套，数据台账按 24 号文建一份，用「系统+数据」双目录把两套检查单对到同一套落地上。多数工作量在重合区，一次改造两边都勾；真正要额外补的，是分类分级、测试脱敏、共享审批、数据泄露应急这些等保覆盖不到、但数据安全检查盯得最紧的环节。

你们行现在卡在哪一步——数据目录还没建、测试库还是明文、还是备份池裸奔？评论区说说卡点，一起拆怎么一次过双轨。

文章作者：安当加密技术负责人