DLP基础：数据分类、敏感数据识别、保护策略
做 DLP 这件事，说白了就是回答三个问题：你有哪些数据？哪些最值钱？怎么守住它们？
我在集成 API 网关之前，先花了两周摸清公司内部的数据资产。嗯，那时候才发现——很多团队连自己存了什么都不知道。数据分类、敏感识别、保护策略，这仨步骤缺一环都不行。下面我把这些年踩过的坑和总结的方法一起聊透。
数据分类——先把家底摸清楚
数据分类是 DLP 的起点。千万别跳过这一步直接去写正则，你会后悔的。我个人习惯按三个维度划分：
- 业务属性：财务数据、客户信息、研发代码、运维日志。
- 数据价值：核心资产（用户密码、支付密钥）、重要资产（订单记录）、普通资产（公开文档）。
- 监管要求：GDPR 个人数据、PCI-DSS 信用卡信息、国内《数据安全法》重要数据。
举个例子，我在一家金融公司搭建 DLP 时，发现业务团队把“客户身份证号”和“客户姓名”存到同一个文本字段里。这俩属性分开来看都不算特别敏感，但拼在一起就成了敏感个人信息。所以分类一定要看数据关联。
| 等级 | 示例 | 保护要求 |
|---|---|---|
| L4 极敏感 | 密钥、个人密码 | 全链路加密 + 零信任 |
| L3 敏感 | 身份证号、银行卡号 | 脱敏后传输 + 审计 |
| L2 内部 | 项目排期、内部文档 | 身份验证 |
| L1 公开 | 官网文案、产品介绍 | 无限制 |
敏感数据识别——找出那些“不能丢”的东西
分类之后，得把真正的敏感数据从茫茫数据海里捞出来。我见过很多团队上来就写十几个正则，结果误报率奇高。为什么？因为没有结合元数据上下文。
我这里总结了三层识别方法，你配合起来用效果最好：
- 正则匹配：身份证号、手机号、邮箱、信用卡号。记得加校验位，不然会把“123456789012345678”也算作身份证号。
- 元数据标签：数据库字段名、API 接口参数名。比如字段名叫
id_card，直接把该字段定为敏感。 - 机器学习分类器：NLP 模型识别文本内容。适合非结构化数据，比如聊天记录、邮件正文。
我曾经在项目中只靠正则检测“身份证号”，结果把用户输入的“护照号”全漏了。后来加了元数据标签——凡是表结构里 column_name 包含
passport 的自动标记为敏感。误报率从 25% 降到了 3%。
你想想看，如果 API 网关收到的请求体里有 credit_card 字段，那至少得先判断这个字段值是否符合 Luhn 算法。只有通过格式校验的，才值得触发 DLP 策略。
保护策略——光知道还不够，得拦住
识别出来了，下一步就是决定怎么处理。保护策略不是一条规则，而是一整套动作。从 API 网关的角度，通常有四种处置方式：
- 阻断（Block）：直接拒绝请求，返回 403。适用于明文传输密码的场景。
- 脱敏（Mask）：对敏感字段替换成星号或哈希值。比如
310***5678。 - 加密（Encrypt）：数据出网关前用 AES 或 SM4 加密，下游解密使用。
- 审计（Audit）：只记录不放行。适合“只观察不拦截”的过渡期。
我习惯在网关侧做两层策略——第一层是内容检测，第二层是元数据检测。举个例子，某次请求带了 cardNumber 字段：
- 元数据检测：字段名命中“card”关键字，直接走脱敏规则。
- 内容检测：正则检查发现是 16 位数字且通过 Luhn 校验，确认是信用卡号，则执行阻断 + 告警。
下面是一个简易的 DLP 策略配置示例（以 YAML 表示）：
dlp_policies:
- name: "信用卡号阻断"
match:
field: "cardNumber"
pattern: "^(?:\d{4} ){3}\d{4}$"
luhn_check: true
action: block
alert: high
- name: "身份证号脱敏"
match:
field: "idNo"
pattern: "^\d{6}\d{8}[\dXx]$"
action: mask
mask_char: "*"
mask_range: [6,14]不要把 DLP 策略搞得太“硬”。建议留一个“仅审计”模式跑一周，等 false positive 收敛后再切换到阻断。我见过一家公司上线第一天就阻断了一百个正常业务请求，结果被投诉到 VP 那里。
说完这三个步骤，不妨看看它们之间的关系。下面的图帮你理清整体流程：
看到这张图，你应该能理解为什么我总是强调“分类在前，策略在后”。没有分类的 DLP 就像盲人摸象——你永远不知道真正要防的是什么。我自己每次做新项目，都会先拉上业务方一起画个类似的数据地图，把每类数据的流转路径标清楚，再往 API 网关里配规则。这样后期调整策略时，改动成本低很多。