数安法数据分类分级：从「怎么分」到「台账怎么维护」的完整流程

数安法检查前临时手动整理台账是最大的误区——台账是动态的，数据结构变了台账就要跟着变，手工维护根本跟不上。这篇文章讲清楚三件事：分级标准怎么定、规则引擎怎么配、变更如何触发自动更新。适合正在做数安法合规的数据安全负责人和技术负责人。

为什么手工维护台账是个陷阱

我们见过很多单位在数安法检查前集中人力手动整理数据台账，通常是 IT 人员拿着 Excel 逐库逐表整理字段，打标签，写说明。这个方式有三个根本问题：

覆盖不全：大型政务系统可能有几十个数据库、上千张表、数万个字段，人工很难做到全覆盖，遗漏是必然的
无法持续：业务系统每次上线新功能就可能新增字段，手工台账上线后立即过时
检查前突击：检查官看的不只是台账本身，还会看台账的维护记录，突击整理的痕迹很明显

🚨

真实案例：某省级政务单位在数安法检查时提交了一份 Excel 台账，检查官要求展示最近一次数据结构变更后台账的同步更新记录，单位无法提供，该项直接判定不合格。

分级标准怎么定

数安法把数据分为「核心数据」「重要数据」「一般数据」三级，但条文没有给出具体的判定标准。各行业监管机构会有细化指引，政务行业参考《政务数据分类分级指南》（GB/T 38664），金融行业参考 JR/T 0197。

以政务行业为例，我们在项目中使用的判定框架：

级别	定义	典型字段示例	处理要求
核心数据 L3	影响国家安全、国民经济命脉	涉密人员名单、关键基础设施信息	最严格保护，访问留痕，出境禁止
重要数据 L2	影响国家利益、公共利益	身份证号、手机号、家庭住址、财产信息	加密存储，动态脱敏，访问授权
一般数据 L1	不属于前两类	部门名称、公开公告、统计汇总数据	基本访问控制，审计日志

💡

实操建议：遇到无法确定级别的字段，优先往高定（宁高勿低），并记录判定理由。检查时检查官对「保护过度」的容忍度高于「保护不足」。

规则引擎怎么配

规则引擎的作用是把分级判定自动化：扫描数据库字段，根据预设规则自动打标签。规则分三个维度：

字段名规则

这是最基础也最有效的规则。常见字段名模式和对应级别：

# 重要数据 L2 —— 字段名包含以下关键词
id_card, identity_no, id_number        # 身份证
phone, mobile, tel, telephone          # 手机/电话
address, addr, location                # 地址
bank_account, card_no, account_no      # 银行账号
salary, income, asset, property        # 财产信息
password, passwd, secret, token        # 认证凭证（另外单独处理）

# 核心数据 L3 —— 字段名包含以下关键词
classified, secret, confidential       # 涉密标记
military, defense, national_security   # 国防安全相关

内容抽样规则

字段名可能被开发人员命名得不规范（比如把手机号字段命名为 field_03），需要对字段值做抽样检测：

# 身份证号特征：18位，最后一位可以是X
^\d{{17}}[\dX]$

# 手机号特征：11位，1开头
^1[3-9]\d{{9}}$

# 银行卡号：16-19位数字
^\d{{16,19}}$

# 含有典型个人信息的字段样本
sample_rate: 5%   # 抽取5%行进行内容检测
min_match_ratio: 30%  # 30%以上匹配则认为该字段含有对应数据

上下文关联规则

某些字段单独看不敏感，但结合同表的其他字段就形成了高级别数据组合：

# 组合规则示例
IF table contains (name AND phone AND address)
THEN all_fields IN table >= L2

IF table contains (id_card AND health_record)
THEN sensitive_level = L3  # 涉及医疗信息的身份关联

变更如何触发自动更新

数据结构变更（DDL 变更）是台账过时的主要原因。自动更新机制需要在三个节点介入：

DDL 变更监听

监控数据库 DDL 日志（CREATE TABLE、ALTER TABLE、ADD COLUMN 等），发现结构变更时触发扫描任务。主流数据库（MySQL binlog、PostgreSQL WAL）均支持实时监听。

增量扫描 + 重新分级

只扫描变更的字段，不重新全库扫描。新增字段自动套用规则引擎，输出分级建议，同时发送人工审核通知（如果新字段级别判定为 L2/L3）。

台账自动更新 + 变更记录

审核通过后台账自动更新，变更时间、变更内容、审核人全部记录。检查时可以展示台账的完整变更历史，证明持续维护。

台账输出格式

数安法检查通常需要提供以下格式的台账：

字段	说明	来源
数据库名	物理库名称	自动采集
表名	数据表名称	自动采集
字段名	字段物理名称	自动采集
字段描述	业务含义说明	规则推断 + 人工补充
数据类型	存储数据的类型描述	规则分类
数据级别	L1/L2/L3	规则引擎 + 人工审核
保护措施	加密/脱敏/访问控制	系统配置
最后更新时间	台账最近一次更新时间	自动记录
更新原因	本次更新的触发原因	自动记录

三个常见踩坑点

只扫关系型数据库：数安法要求覆盖所有数据存储，包括 Redis 缓存（如果存储了个人信息）、Elasticsearch 索引、对象存储（OSS 中的文档）、日志系统。不要遗漏非关系型存储。

忽略数据流转：台账只记录「哪里存了什么数据」还不够，还需要说明数据从哪来、到哪去（数据流图）。跨部门、跨系统的数据传输是重点检查项。

级别只定不落地：台账说字段是 L2，但实际上没有加密、没有脱敏、访问没有控制。检查官会验证台账中的保护措施是否真实有效。

正确做法：数据安全平台的分类分级台账与实际的脱敏配置、加密配置直接挂钩，台账显示 L2 则系统自动对该字段应用对应保护措施，台账与现实完全一致。

总结

数安法合规的核心不是「做台账」，而是「建立数据安全管理能力」。台账是这种能力的文档化表现，如果数据安全措施真实落地了，台账自然是准确的、持续更新的。

如果你正处于数安法合规建设的早期，建议的优先级顺序是：先搭规则引擎做自动识别（解决覆盖问题），再配置脱敏和访问控制（解决保护落地问题），最后打通 DDL 监听实现自动更新（解决持续维护问题）。