第2章：评估框架与方法论——成熟度模型（DSPM‑MM）
说实话，我第一次接触DSPM评估时，最大的困惑就是：“到底怎么才算搞得好？”
是发现了100个敏感数据源？还是合规报告没出过问题？后来我明白，单点指标都是骗人的。你真正需要的是一个标尺——能告诉你现在在哪，下一步该往哪走。
这就是成熟度模型的价值。说白了，它把“好”和“差”分解成了几个可测量的台阶。你每上一个台阶，就知道投入花在了刀刃上。
2.1 DSPM成熟度模型：从混乱到智能的五个台阶
我参考了Gartner的数据安全治理框架，结合自己参与过的十几个评估项目，整理了一套DSPM成熟度模型（DSPM‑MM）。它分五个等级：
核心观点：成熟度不是越高越好，而是跟你的业务风险、合规要求、预算匹配才最有效。我见过不少企业硬推到Level 4，结果运维成本暴涨，最后还是退回来了。
| 等级 | 名称 | 核心特征 | 典型状态 |
|---|---|---|---|
| Level 1 | 初始级 | 被动响应，无流程 | 全靠安全员手动查，出了事才补 |
| Level 2 | 重复级 | 有基本工具，但各自为政 | DLP、CASB、数据库审计各管各的 |
| Level 3 | 定义级 | 统一策略，集中管控 | 所有敏感数据走统一发现、分类、标记流程 |
| Level 4 | 量化级 | 数据驱动，可度量 | 用KPI监控覆盖率和误报率，持续改进 |
| Level 5 | 优化级 | 自适应，智能化 | 基于风险自动调整策略，零信任嵌入 |
每个等级的定义，是我在实践中反复打磨过的。举个例子，Level 1和Level 2最大的区别是：你有没有主动发现机制。我以前去过一家金融公司，他们自评Level 2，但我发现他们连数据源清单都是Excel手填的——这只能是Level 1。
下面这张图，概括了从Level 1到Level 5的演进路径：
2.2 评估生命周期：一步步走，别跳级
有了模型，下一步就是怎么用。我习惯把评估分成五个阶段，每个阶段都有明确的输入、活动和产出。你跳过一个阶段，后面准出问题。
- 规划阶段：确定评估范围（哪些业务系统、数据域），定义目标等级。我通常会问：老板想要什么？合规要求是什么？去年出了什么事故？
- 数据采集阶段：通过自动化工具扫描、人工访谈、文档审查，收集当前的DSPM状态。嗯，这里要注意——采集不是一次性事件。我在一个项目中，第一次扫描漏了一个重要RDS实例，后来不得不重来。
- 成熟度评定阶段：对照DSPM‑MM的五个维度（发现、分类、管控、审计、响应）逐项打分。每个维度满分5级，取最弱的一环作为整体等级——这就是“木桶原理”。
- 差距分析阶段：把当前等级和目标等级之间的差距拆解成具体行动项。比如从Level 2到Level 3，你可能需要部署统一敏感数据目录。
- 改进规划阶段：制定优先级、时间表、资源需求。我经常在这里加一个“速赢项”——比如先解决一个低风险但高可见度的问题，让管理层看到成果。
个人技巧：在评定阶段，我会给每个维度画一个成熟度雷达图。这样能一眼看出哪个维度是短板。比如“审计”维度经常只有Level 1，而“发现”维度可能已经到了Level 3——那你就知道该补哪了。
2.3 评估工具与数据源
你可能会问：用什么工具来做评估？其实，分级工具和日常运营工具是两码事。我常用的评估数据源包括：
| 数据源类型 | 关键信息 | 获取方式 |
|---|---|---|
| 云资源清单（AWS Config / Azure Resource Graph） | 所有存储服务、数据库实例 | API查询 |
| 数据分类结果输出 | 敏感数据类型、标签覆盖率 | 从DLP/分类工具导出 |
| 访问审计日志 | 谁、何时、从哪里访问了敏感数据 | 系统日志服务 |
| 安全策略文档 | 是否有统一的分类、脱敏、访问控制策略 | 人工审查 |
我曾经踩过的坑：有次评估一家电商公司，我完全依赖了他们提供的“数据源清单”Excel表格。结果发现里面有30%的数据库已经下线了，还有20%未注册。从那以后，我坚持用自动化工具重新扫描一遍，哪怕客户说自己有清单。相信我，你永远不知道Excel里面会有什么水份。
评估时，我一般会编写一个简单的脚本来自动拉取云资源清单。举个例子，在AWS上快速获取所有S3存储桶列表：
# 使用AWS CLI获取所有S3桶
aws s3api list-buckets --query "Buckets[*].Name" --output json
# 如果你只想看敏感数据分类的桶（假设标签为 Sensitivity=High）
aws s3api list-buckets | jq -r '.Buckets[].Name' | while read bucket; do
tags=$(aws s3api get-bucket-tagging --bucket "$bucket" 2>/dev/null | jq -r '.TagSet[] | select(.Key=="Sensitivity").Value')
if [ "$tags" = "High" ]; then
echo "$bucket"
fi
done这个输出你直接导入评估表就行。不用手动翻控制台，省下来的时间可以去喝杯咖啡。
2.4 如何输出一份可落地的评估报告
评估的最终产出不是一堆分数，而是行动路线图。我见过太多报告写了30页，老板看完只说了一句：“能不能告诉我下个月先干嘛？”
所以我通常把报告分成三块：
- 现状快照：一张雷达图+一句话总结（例如：“当前Level 2.3，主要短板在审计响应维度”）
- 关键差距：列表方式，每项都标注优先级（P1/P2/P3）和影响范围
- 改进行动项：每个行动项包含具体负责人、预计工期、验收标准
一个真实案例：去年我帮一家保险集团做评估，他们的“数据分类”维度得分很高（Level 4），但“访问控制”维度只有Level 1.5。原因很简单：所有数据都被标记了，但任何人都能访问。这说明单一维度的成熟度会骗人。最后我给的建议是：先把Level 4的分类能力降一点，来换取访问控制的快速提升——因为这才是真正堵漏洞。
好了，关于这个模型本身，就说这么多。你回去可以先对照着自评一下，看看自己企业在哪个Level。别急着上Level 5，从Level 2到Level 3的第一步往往最立竿见影。