# SDM2.0 优势与取舍

> **文档定位：** 把 Dayu-SDM 相对「只做交换与分类」的标准多出来的那一层写清楚，供介绍、评审和对齐使用。不替代字段清单、DDL，也不替代分层兼容的架构决策稿。
>
> **一句话：** 交换与分类停在「把多厂商日志说成同一种话」；SDM 把这句话接进 SOC——同一套行为句式做调查，独立对象做告警运营，实体可归并可走时间线。
>
> **页面对照：** [pages/index.html#advantages](../pages/index.html#advantages)
>
> **日期：** 2026-08-31

---

## 一、分层位置

SDM2.0 与行业交换 schema 的交集是「多厂商安全数据标准化」，但不是同层次的替代关系：

```
行业交换 / 分类 schema  = 逻辑 Schema + 行业分类 + 数据交换契约
SDM2.0                 = 内部事件语义 + 物理服务模型 + 实体调查 + 告警运营
```

方向是**分层，而不是替代或封闭**：交换与行业分类走投影；事件调查、实体归并、物理查询与告警生命周期留在 SDM。不把外部 schema 当作内部唯一模型，也不把分析能力建在某一家平台的字段体系上。

详细对照见 [9.SDM2.0-与OCSF对比分析.md](9.SDM2.0-与OCSF对比分析.md)。

---

## 二、补上的一层

相对只做交换契约的标准，SDM 把调查、实体和告警当成一等模型。

### 1. 跨类型同一套行为句式

行业 schema 往往先选定事件类，字段布局才确定。认证、进程、网络、邮件各有一套对象路径，做「这个用户过去 24 小时所有行为」必须记住每类事件的字段地图。

SDM 用统一五角色先回答「谁通过什么对谁做了什么」：

```
source → carrier → target
observer / related 补充观察与关联
```

User、Host、Process、File、IP、Domain 等实体放进角色，而不是按事件类更换根对象。跨类型时间线、行为链、调查跳转可以走同一套查询，不必为每个 class 写一套遍历。

### 2. 事实、声明、检出、案件分开

设备告警日志、检测引擎 Finding、SOC 工单里的 alert 常被塞进同一张表。结果是：设备声称改写了观测事实，研判结论覆盖检测分数，案件和事件分不清。

SDM 拆成四层对象：

| 层 | 对象 | 回答 |
|---|---|---|
| 事实 | `sdm_event` | 发生了什么 |
| 声明 | `source_finding` | 设备自己声称检测到了什么 |
| 检出 | `sdm_alert` | 哪条检测认为值得看 |
| 工作对象 | `sdm_case` | 谁来处理这组告警；升级才是正式安全事件 |

`event_category='alert'` 或来源侧声称是告警，不等于平台 `sdm_alert`。来源判断保存在事件里；平台告警做聚合、去重、分派、研判。证据只存指针，不复制日志正文。

### 3. 实体可归并、可走时间线

交换 schema 提供对象字段和调查支点，通常不规定：同一设备跨厂商如何得到同一个 ID，实体时间线如何索引，一跳关系如何回表。IP、hostname、Agent ID 都会变，对象表达的是当前状态，分析师很难重建「某个时间窗口里这个设备是谁」。

SDM 把实体身份做成服务契约：稳定 `entity_id`、角色 posting、S4 倒排索引、主对端、水位、重建与查询回退。调查可以从账号跳到设备、从进程跳到域名，而不是只在单条事件的嵌套对象里翻。

### 4. 逻辑对象权威，物理只是投影

交换 schema 不规定哪些字段物化成列、如何分区、查询成本如何验收。平台私有模型则把规则和仪表盘锁进自家查询引擎。

SDM 把两层分开：逻辑对象是权威语义；物理层是查询友好的 hybrid 投影（标量列加速过滤与聚合，VARIANT 保存完整对象）。原文进独立 `raw_log`，与 `sdm_event` 经 `event_id` 1:1 回查。投影可以有损，对象不可。查询路径、实体索引和回表成本有 Benchmark 约束。

### 5. 私有字段受治理，不进垃圾桶

源遥测越丰富，越有字段在标准字典里没有家。常见做法是丢进结构不稳定的 catch-all；检测规则、狩猎和 AI 都不敢依赖它，分析师最后还是去挖未归一字段。

SDM 的 `extensions` 是五个语义层之外的兼容容器，不是第六个业务层。映射状态至少区分完整 / 部分 / 未映射 / 无效。标准路径给查询和关联，原文给回溯，避免「标准字段能查、真正有用的上下文不可用」。

### 6. 分析只追加，结论可回放

把 AI 或规则的结论覆盖写回告警主表，无法追责，也无法区分检测分数与正式结论。

SDM 里分析是一行记录，只追加、可重跑；引用逐条落 citation。规则写 `detection_confidence` / `detection_risk_score`；AI 写分析行；`verdict` 仅策略（带 `policy_id`）或人回写。事实不被分析改写，给人和模型同一套可复现的语义层。

---

## 三、对应的运营问题

| 常见困境 | SDM 的收口 |
|---|---|
| 多厂商日志口径不一，检测规则写一份只能用一处 | 统一事件表；接新厂商只新增映射，不改下游 |
| 「设备说有攻击」被当成事实 | `source_finding` 独立成层，不改写 roles / facets |
| 告警大宽表：证据、实体、研判、工单混在一起 | 瘦主表 + 分层子表；列表扫主表，详情走聚合 |
| 交换标准能分类、能交换，但不规定实体归并、调查索引和告警生命周期 | 对外走交换投影，对内保留五角色、实体索引与告警对象 |

---

## 四、不假装解决的

标准救不了没记下来的字段，也换不来别人自动说这门话。下列边界写进模型，避免把 SDM 说成「更好的交换格式」。

| 代价 | 说明 |
|---|---|
| 对外仍靠投影 | 外部系统不原生理解五角色与内部枚举；对外交换优先走行业分类投影 |
| 映射劳动没有消失 | 接新厂商仍要写契约；一份源映射同时维护内部与交换两套投影，并做版本一致性测试 |
| carrier 必须可校验 | 父进程是 source 还是 carrier、附件是 carrier 还是 target，由事件类型注册表给出唯一规则，不能只靠文档约定 |
| 采集盲区救不了 | 没落盘的请求体、包内容、未覆盖资产，任何 schema 都看不见 |
| 分类覆盖不重复发明 | 行业事件分类作为交换投影，不绑进内部主查询契约 |
| extensions 必须持续治理 | 否则私有字段、富化与攻击技术标签会重新堆成坟场 |

---

## 五、相关文档

| 文档 | 用途 |
|---|---|
| [9.SDM2.0-与OCSF对比分析.md](9.SDM2.0-与OCSF对比分析.md) | 分层兼容的架构决策稿 |
| [10.SDM2.0-日志五层逻辑对象与字段投影设计.md](10.SDM2.0-日志五层逻辑对象与字段投影设计.md) | 逻辑对象权威位置与物理投影 |
| [4.SDM2.0-日志模型概念研究.md](4.SDM2.0-日志模型概念研究.md) | 事件、角色、实体关系 |
| [2.实体清单.md](2.实体清单.md) | 实体、值对象、行为切面注册 |
| [alert-model/docs/00-overview.md](../alert-model/docs/00-overview.md) | 告警域分层与对象边界 |
| [log-model/docs/main/05-sdm-event-logical-field-catalog.md](../log-model/docs/main/05-sdm-event-logical-field-catalog.md) | 事件逻辑字段清单（权威） |