📚 课程目录第2章 DSPM核心组件

2、DSPM 核心组件：数据发现、权限分析、异常检测、风险评分

好，我们开始聊 DSPM 的四个核心组件。这四个组件构成了 DSPM 的整个工作流。说白了，就是从“找到数据在哪里”，到“谁在碰它”，再到“有没有奇怪的动作”，最后给出一个“风险有多高”的结论。

我在多个项目里把这四个组件拆开看过。但真正落地的时候，它们必须串起来。缺任何一个，整个安全视图就不完整。下面我一个一个拆开讲。

2.1 数据发现：你得先知道东西在哪

数据发现听起来最简单，做起来最头疼。为什么？因为数据太散了。

我记得有个项目，客户说他们的敏感数据就在那三个数据库里。结果扫描下去，发现在五个云存储桶、两个 SaaS 应用、还有十几个员工桌面的共享文件夹里都有。我跟你讲，这种情况一点也不少见。

DSPM 的数据发现组件，核心就干三件事：

扫描：连接所有数据源，无论是云上的 RDS、对象存储，还是本地的 NAS、Hadoop，或者 SaaS 里的 SharePoint、Salesforce。全量走一遍。
识别：用内置的敏感数据类型库去做匹配。比如身份证号、信用卡号、手机号、密钥等。我习惯叫它“指纹库”。
分类分级：发现敏感数据之后，给它打标签。“这是 PII”、“这是财务数据”、“这是内部公开的”。然后定级别，比如 L1 公开、L2 内部、L3 敏感、L4 绝密。

关键点：数据发现的频率很重要。我见过有的团队一个月跑一次，结果中间泄露了半个月都不知道。我个人建议至少每天跑一次全量，对于关键数据源要做实时监听。

下面是一个很典型的敏感数据发现配置示例，用于扫描某个对象存储桶：

{
  "data_source": "s3://company-data-backup",
  "scan_frequency": "daily",
  "sensitive_types": [
    "credit_card",      // 信用卡号
    "ssn",              // 美国社会安全号
    "phone_number",     // 手机号
    "access_key_id",    // 云服务密钥 ID
    "secret_access_key" // 云服务密钥
  ],
  "classification_output": "table: sensitive_data_inventory"
}

这个 JSON 配置看起来很简单，但实际跑起来会发现很多问题。比如匹配规则太宽松，会把正常的数字串误报成信用卡。所以团队需要花时间去调优规则，减少误报。这个过程急不来。

2.2 权限分析：谁在碰，谁不该碰

数据找到了，下一个问题就是：谁有权限？

权限分析模块会读取你所有数据源上的访问控制列表、策略、角色绑定等元数据。然后构建一张完整的权限关系图。

有效权限 vs 继承权限：很多平台权限是继承的。比如一个文件夹设了权限，里面的所有文件都继承。DSPM 要把这些摊开，算出每个用户对每个数据对象的真实有效权限。
权限滥用检测：比如一个普通开发人员，他对一个生产数据库的财务表竟然有“完全控制”权限。嗯，这里要注意，这通常就是个异常。
最小权限分析：工具可以告诉你，哪个用户的权限过大，应该收窄。我一直强调一个原则：权限应该像手术刀，而不是砍刀。

避坑指南：我曾经遇到一个项目，权限分析跑出来说某个离职员工的账号还在有效期内，而且有管理员权限。客户吓了一跳，说已经离职三个月了。你想想看，这个窗口期有多危险。所以权限分析不能只做一次，要持续做，并且要和 HR 系统的离职数据联动。

一个小技巧：我建议把权限分析的结果做成一个“权限热力图”。哪些账号权限最高、哪些数据对象被最多人访问，一眼就能看出来。用表格列出来更直观。

用户名	数据对象	有效权限	状态	建议操作
zhang.li	prod-db.finance.payments	读、写、删除	异常	降为只读
wang.fang	dev-bucket.*	读、写	正常	无需操作
li.chen	prod-db.*	完全控制	高危	立即降权
old.employee	hr-sftp.employee_pii	读	已离职	立即禁用账号

2.3 异常检测：揪出那些“不对劲”的行为

权限分析告诉你“谁应该有什么权限”，异常检测则告诉你“谁正在做什么不正常的事”。

这模块本质上是基于行为分析的。它会学习每个数据源和用户的基线行为，比如：

这个用户平时每天下载多少数据？10 条还是 10000 条？
正常访问时间是什么时候？上班时间还是凌晨三点？
访问的来源 IP 是公司内网还是境外某个节点？

一旦偏离基线，就会触发告警。我见过很多团队在异常检测上吃过亏，因为误报太多，导致运维人员直接关掉告警。为什么会这样？因为基线没有建好。

核心经验：把异常检测的阈值设得太敏感，满屏都是告警；设得太宽松，真出事了也发现不了。我个人的做法是：先默认跑两周的“学习模式”，不告警只记录。两周后手动调整基线，再开启告警。这个过渡期能筛掉至少 60% 的误报。

举个例子，一个正常的 BI 分析师，每天查询数据库生成报表，每次查询返回几千行数据。突然有一天，他执行了一个 SELECT * FROM customers，并且把结果导出到了他的个人笔记本。DSPM 的异常检测模块会立刻捕捉到这个行为，因为：

返回行数：从几千行飙升至几十万行。
目标：导出了所有客户的敏感信息。
目的地：个人设备，非公司资产。

2.4 风险评分：给每个问题打个分，排个序

好了，数据发现了，权限查了，异常也检测了。现在 DSPM 要告诉你一大堆可能的问题。但是，哪个最急？哪个可以排到下个月？

这就是风险评分模块要干的活。它会把前面三个环节的数据汇总，然后根据一个评分模型，计算出每个风险项的权重。常见的考虑因素包括：

数据敏感度：L4 绝密数据的问题分数更高。
暴露面：可公开访问的服务分数更高。
权限危险度：完全控制权限比只读权限更危险。
行为偏离度：从异常检测模块拿到的基线偏差数值。
合规要求：比如 GDPR 或《数据安全法》强制要求的某些控制点。

最后会输出一个类似这样的风险评分表：

风险项	数据敏感度	暴露面	权限风险	行为异常	综合评分	优先级
prod-db 财务表被外网访问	L4	高	高	低	95	P0
离职员工账号未禁用	L3	中	中	无	72	P1
开发人员对日志桶有写权限	L1	低	低	无	23	P3
BI 分析师凌晨大批量导出客户数据	L3	中	低	高	88	P1

给你的建议：我建议别盯着数字看，把精力放在 P0 和 P1 上。我自己在团队里就立了个规矩：P0 必须在 4 小时内响应，P1 必须在 24 小时内制定修复计划。这样才不会被海量低风险问题淹没。

这四个组件，你仔细看，其实是一个闭环。数据发现和权限分析告诉你“现状”，异常检测告诉你“正在发生什么”，风险评分告诉你“什么最重要”。缺少任何一个，你的 DSPM 都会瘸腿。