3. 数据分类分级：敏感数据识别，分类标准与分级方法

数据分类分级这活儿，说白了就是给公司的数据资产发“身份证”。你得先搞清楚手里都有哪些数据，再按重要性贴标签。我在好几个项目里都见过，业务部门觉得“这表里没什么机密”，结果一查全是身份证号、银行卡明细……嗯，这种坑踩一次就够了。

3.1 敏感数据识别：先得知道“啥是敏感”

敏感数据识别是整个分级工作的起点。我个人习惯，先按业务场景扫一遍，而不是抱着理论框子硬套。你想想看，同样的手机号，在营销部门是客户联系方式，在风控部门就是反欺诈关键字段——场景决定敏感级别。

我建议按以下三层递进思路来识别：

1. 法规层面：先看《个人信息保护法》《数据安全法》里明确列举的“敏感个人信息”，比如金融账户、行踪轨迹、生物识别信息。这部分是底线，不能碰。
2. 业务层面：找业务方聊，问“这张表如果泄露了，公司最多能亏多少钱？”——我记得有一次，对方说“也就是挨个处分”，结果我们一算，涉及客户病历的泄露可能面临年收入5%的罚款。
3. 技术层面：用数据扫描工具跑一遍，正则匹配身份证、信用卡号、护照等模式。但要注意，光靠正则容易漏掉脱敏后的数据。

3.2 分类标准：把数据放到对的“抽屉”里

分类不是拍脑袋。我在一个金融项目里用过经典的“业务域-功能-实体”三层分类法，效果不错。你可以参考这个结构：

层级	说明	例子
业务域	最高层，按业务线划分	零售银行、对公业务、风险管理
功能模块	业务域下的子功能	客户管理、交易处理、产品定价
数据实体	具体的数据表或文件	客户信息表、交易流水表、利率配置表

分类粒度别太粗也别太细。我之前见过一家公司分了300多个类别，结果没人搞得清楚某个字段该归到哪个类里，最后全打了“其他”。我建议一个业务域下不要超过15个功能模块，每个功能模块下实体数量控制在50以内。

3.3 分级方法：按影响程度划等级

分级比分类更难落地。为什么？因为“重要”和“敏感”是主观的。我曾经在一次数据安全审计中，发现某部门把所有表都标成了“L4-最高机密”，结果真正高敏的数据反而淹没在假警报里。

我推荐用“影响力×可能性”矩阵来分级。这不是我发明的，但我在实际中做了简化：

• L1-公开：泄露后无影响或影响极小。比如公司官网公开的新闻稿、产品手册。
• L2-内部：泄露后对公司声誉有轻微影响，但无法律或财务后果。比如内部培训资料、非敏感项目文档。
• L3-敏感：泄露后可能造成中等经济损失或合规风险。比如客户联系方式、非金融交易记录。
• L4-高度敏感：泄露后会造成重大法律、财务或品牌灾难。比如身份证号、银行卡号、医疗健康记录、密码密钥。

分级方法的具体步骤，我习惯按这个流程走：

1. 先定分级标准（如上述L1-L4），逐条定义评判条件。
2. 由数据所有者（业务负责人）对每张表进行初评。
3. 安全团队抽检，重点抽查标注为L3/L4的表。
4. 如果发现初评偏差超过20%，退回重新评审。
5. 定稿后录入数据资产目录，同步给DLP、IAM等系统。

3.4 一张图看懂分类分级流程

下面这张SVG图，把从数据探查到分级落地的关键步骤串起来了。你看的时候重点关注“分类”和“分级”两条线是怎么在实践中交叉的：

3.5 常见避坑指南

另外几个我亲身踩过的雷，你务必注意：

• 别过度依赖自动化工具：正则匹配只能识别格式固定的敏感字段，像“病理诊断意见”这种自由文本，光靠工具根本识别不了。得加上人工抽样。
• 分级标准要可操作：别写“影响较大”这种模糊词。我建议每个级别对应一个具体的“如果不小心公开，公司会被罚款XX万元”或者“导致客户流失X%”。
• 定期重跑：业务变了、法规变了，分类分级也要跟着变。我一般在季度数据安全会议上做一次覆盖检查。

3.6 落地交付物清单

做完分类分级，最少要交付这些东西：

交付物	内容	用途
数据资产清单	所有数据表/文件的分类与分级标签	供DLP、IAM、审计系统消费
分级标准文档	L1~L4各自定义、判断方法、示例	供业务方自评时参考
分类目录树	业务域-功能模块-实体的层级关系	支撑数据地图和搜索
异常标记记录	初评与终评不一致的表，以及原因分析	用于过程改进和责任追溯

嗯，这章内容有点干货，但光看懂流程还不够。关键是在实际项目里动手做一遍——你会发现，最难的不是定规则，而是让业务部门配合你一次一次地确认。下次如果你遇到业务方说“这点小事不用管”，你可以笑着回一句：“要不咱们先按L3走，出了事我帮你扛？”——哈哈哈，开玩笑的，但道理是这么个道理。