2. DSPM 系统架构：核心组件、数据流、部署模式
各位同学，欢迎来到第二章。这一章我们聊聊架构。
做DSPM（数据安全态势管理）最怕什么？不是功能不够，是架构糊成一团。你想想看，所有敏感数据在系统里跑，哪个模块管什么、数据怎么流转、部署到什么地方，全得理清楚。
我习惯把DSPM系统看成一本“数据通行账”。谁在动数据？数据去了哪？风险高不高？这套账本怎么建，就是架构的事。
2.1 核心组件——四板斧
DSPM的架构，说白了就四个核心模块。我管它们叫“四板斧”：
| 模块 | 英文名 | 一句话功能 |
|---|---|---|
| 数据发现引擎 | Data Discovery Engine | 扫描源头上有哪些数据 |
| 分类分级引擎 | Classification Engine | 给数据贴上“敏感度标签” |
| 风险分析引擎 | Risk Analysis Engine | 检查谁在不该碰的地方碰数据 |
| 策略执行与告警 | Policy & Alert Engine | 按规则拦截或通知 |
这四个模块分得越清楚，后期对接越省心。我有一次出过事故——发现引擎和分级引擎耦合得太死，后期想单独升级分级规则库，把发现引擎也挂掉了。后来重构了，才缓过来。
2.1.1 数据发现引擎
这是DSPM的“侦察兵”。它要对接各种数据源：数据库、对象存储、大数据平台、SaaS应用。我建议你一开始就把它做成“插件式”架构，方便后面加新源。比如MySQL一个插件，AWS S3一个插件，Salesforce一个插件。每个插件只管怎么连、怎么读元数据，不参与后续判断。
2.1.2 分类分级引擎
这个模块是核心。它负责识别数据类型（身份证、信用卡号、病历）和敏感等级（L1-L4）。
很多DSPM厂商会把AI模型塞在这里。但你得注意：模型推理太慢会拉低整个流水线。我见过一个项目，分级引擎是单节点，每来一批数据就卡死。后来改成异步队列+多实例，才跑顺。
2.1.3 风险分析引擎
风险分析引擎做“场景化判断”。它会结合上下文：数据在哪个环境？谁在访问？访问行为正常吗？
比如：一个普通账号深夜批量下载包含大量L4级数据的Excel，这就是高风险。我能分享的经验是：把风险模型做“轻”一点，不要搞太复杂的图计算。初期用规则引擎就够了，跑得快。后期再上图谱分析。
2.1.4 策略执行与告警
策略引擎是“保安队长”。它负责把风险转成动作：告警、阻断、脱敏、封账号。
这个地方避个坑——我曾经把策略引擎和告警通道写死在代码里，结果换一个大屏系统时，要动核心逻辑。后来我改成“策略-动作-通知”三层解耦，换任何一端都不影响其他。
2.2 数据流——动静两张图
数据在DSPM里怎么跑？要分清楚“静流”和“动流”。
- 静流（批量扫描）： 发现引擎定期扫描数据源，拿到元数据和样例，送给分级引擎处理。结果存入资产清单库。
- 动流（实时流量）： 数据被访问时，网络流量镜像或API调用，被流量采集模块捕获，送风险分析引擎实时判。高风险直接触发告警。
我遇到过一个场景：客户既要全量扫描又要实时监控。如果只用一条管道，扫描流量会堵住实时流量。我建议两条管道分开跑，扫描走批处理队列，实时走消息队列。
下面我画了一张整体数据流框架图，帮你快速建立全局感：
这张图里，上半部分是“静流”：数据源 -> 发现引擎 -> 分类引擎 -> 资产清单库。下半部分是“动流”：实时流量采集 -> 风险分析 -> 策略与告警。两部分通过资产清单库同步元数据信息，但不共用执行管道。
2.3 部署模式——三种打法
部署模式怎么选？我碰到的客户，90%逃不出以下三种：
| 模式 | 适用场景 | 优点 | 我踩过的坑 |
|---|---|---|---|
| SaaS托管 | 轻量级、中小规模、云原生环境 | 无需自建，升级由厂商负责 | 数据出境的合规问题要提前确认 |
| 本地化部署 | 金融、政务、军工等涉密场景 | 数据不出域，完全自主可控 | 硬件资源预算最好上浮30% |
| 混合部署 | 大型企业，既有云也留本地 | 灵活，核心数据留本地、非核心上云 | 网络连通性和版本一致性要特别注意 |
2.3.1 关于部署的几点思考
- 网络规划： 千万别让发现引擎直接扫描生产库！给它建一个“只读影子库”或者使用卷快照。我曾经因为扫描压力打崩过生产MySQL，那是血的教训。
- 高可用： 核心引擎至少双节点。不解释。
- 扩展性： 数据源数量翻倍时，发现引擎要能水平扩展。接入层用负载均衡，后面挂无状态工作节点，这是标准做法。
好了，架构这块就说到这里。核心记住四组件两流程三模式。下一段我们开始进入实操——怎么搭一个能跑的DSPM环境。