 身份可信度评分——多源数据不一致时信哪个)
上一篇 (07) 数据可靠性我们把"数据流"做了一次体检——看板能告诉你数据从源到台账在哪一层坏了。但还有一个没解决的根本问题：
同一台设备，Wazuh 说"192.168.0.8 / bc:24:11:f0:1d:73 / dev-server"；TP-Link 说"192.168.0.8 / bc:24:11:f0:1d:73 / dev"。
两边都对一点点（IP+MAC 一致）、但主机名差 4 个字符。
这是同一台设备吗？AI-miniSOC 怎么知道信谁？
这就是身份可信度评分要回答的核心问题——也是资产主题的最后一篇。08 篇之后，资产/审计主题正式收官。
为什么这是个真问题？
想象三种现实场景：
- DHCP 漂移——公司给开发机固定 IP，但笔记本今天连 WiFi 拿的是 .8，明天插网线就可能变 .3。两台不同的笔记本在不同时间用过同一个 IP——它们是不同的资产，不是同一台。
- 重命名/重装系统——你的开发机从
dev-server改成了dev-server-01，但 MAC 没变。是同一台机器——但旧台账里的"主机名不一致"会变成 mismatch。 - 影子设备 + 真实设备——同事带自己的笔记本上班，MAC 跟前一台 dev-server 相同（刷了同款无线网卡）但 IP 是新的。可能是同一台、也可能不是——系统必须能分辨。
没"身份可信度"机制，整个资产台账都是不可信的：对账、报告、风险评分全都基于"我们知道这是哪台设备"，一旦身份判定错了，下游全错。
解决方案：5 因子加权 + 缺失重归一化 + 强仲裁
直接说设计——这套逻辑不是"拍脑袋调阈值"，是有三道关卡的判断流程：
第一关：5 因子加权
每个设备身份有 5 类身份信号（来自不同数据源），每个信号有"强度"：
| # | 因子 | 权重 | 为什么这个强度 |
|---|---|---|---|
| ① | IP 地址一致 | 0.25 | 弱信号——DHCP 漂移很容易让同一个 IP 被不同设备用 |
| ② | MAC 地址一致 | 0.30 | 强物理信号——网卡芯片全球唯一（除非刷过 MAC） |
| ③ | 主机名一致 | 0.15 | 弱信号——人会改名、系统重装也会变 |
| ④ | Wazuh agent id 一致 | 0.20 | 强管理信号——这是 Wazuh 服务端下发的 ID，可信 |
| ⑤ | 硬件指纹（序列号/主板）一致 | 0.10 | 强物理信号，但采集稀少，常缺失 |
两个观测越多的因子一致 → 越像同一台。
第二关：缺失重归一化（核心纪律）
数据缺失既不投赞成也不投反对。
这是个反直觉的纪律——很多人会写"如果观测 A 没报 MAC，观测 B 报 MAC，B 完胜"——这是错的。
正确做法：某个因子只有在"两条观测都有值"时才参与打分。然后在参与因子之间重新按权重归一化：
例：观测 A 报 [IP, MAC, hostname] 观测 B 报 [IP, MAC, hostname] → 三因子都参与 → 权重归一化（不变） → 置信度 = 一致率 例：观测 A 报 [IP, hostname] 观测 B 报 [IP, MAC] → MAC 不参与（A 没报）→ IP+hostname 归一化（占全部 100%） → hostname 不一致 → 扣掉 0.40 → 置信度 = 0.60这条纪律的反例：如果两台设备"都没报 MAC"，那 MAC 维度不算"不一致"——只是"无证据"。
第三关：强物理因子冲突仲裁
MAC 不一致 = 物理上不是同一台机器。IP 相同不算。
有时候会出现诡异现象：IP 相同 + 主机名相同 + MAC 不同——通常是因为换过网卡或 MAC 被刷过。强物理因子（MAC/硬件指纹）如果双方都有值且不一致，直接压到 needs_review，不管其他维度多么吻合。
这个设计防的是"误合并"——把两台真不同的设备误认成一台，比"该合并没合并"的危害大得多。
判定分档
| 置信度区间 | 判定 | 后续动作 |
|---|---|---|
| ≥ 0.80 | auto_merge（自动合并） | 写入台账，下次对账直接当"已纳管" |
| 0.40 - 0.80 | needs_review（待复核） | 进**「资产稽核 → 待处理」标签**（08 篇实战章节有实景），人工裁决 |
| < 0.40 | distinct（明显不同实体） | 不合并，各自保留为独立资产 |
单资产身份可信度：三维度评分
对单台设备，AI-miniSOC 用三个维度算它"这条身份记录有多可信"：
| 维度 | 含义 | 例子 |
|---|---|---|
| ① 覆盖度 | 5 因子里有几个被采集到了 | 只有 IP 和 hostname → 覆盖度低 |
| ② 多源佐证 | 这个 IP/身份被几个数据源确认 | Wazuh + TP-Link + Nmap 三方都有 → 强 |
| ③ 强锚 | MAC/硬件指纹 是否存在并一致 | 双向都有且匹配 → 强 |
三个维度都在 → 高可信度；只有覆盖度 → 中；只被单一源报 → 低。
🎯三维度分档的真实价值：单资产身份可信度低的资产，风险评分自动加权（身份本身存疑的设备，更可疑）。同时，F1.3 对账时身份可信度低的差异自动转 needs_review——不靠置信度的 auto_merge 是危险的。
实战：你已经看过这个页面
06 篇讲过"资产稽核"页，07 篇讲过它顶部的"X 条死信待处理"——08 篇讲的"needs_review 的人工裁决"和它们是同一个页面，只是身份融合层从 06 篇的"差异列表"升级到了"投票打分"。
人工裁决时的三件事——无论 UI 是在"待处理"标签里还是未来独立菜单里，逻辑都是这三条：
| 动作 | 什么时候用 | 后果 |
|---|---|---|
| 合并到候选资产 | 5 因子大部分对、只有 1-2 个浮动（典型 DHCP/重命名） | 观测归入候选，主键由候选继承 |
| 新建为不同资产 | 5 因子冲突太大（典型：换电脑但 IP 被 DHCP 分配到了） | 创建独立资产，两台都在台账里 |
| 忽略 | 噪声数据（探测器的反扫、测试痕迹） | 标记为"已知忽略"，永不重试 |
💡为什么要有人工裁决这一步？因为 0.40-0.80 是"看起来像但又不敢打包票"的灰区。auto_merge 风险太高（误合并会把两台设备当成一台），distinct 又太武断——人工看证据是最稳的。
常见问题
Q：阈值 0.80 / 0.40 是拍脑袋的吗？
A：是默认配置，但项目里支持热配置（无需重启）。调高 0.80 → 更保守，宁可人工裁决更多；调低 0.40 → 更激进，少一些裁决。建议起点用默认值，跑两周看裁决率再调。
Q：MAC 被刷过怎么办？
A：MAC 刷过（克隆/还原虚拟机）的场景下，MAC 一致是误判——这就是为什么有"强仲裁"：只有当 MAC双方都有值且不一致时，才会强压制到 needs_review。如果只一方有 MAC，强仲裁不触发，IP/主机名/agent id 仍然可以高置信度合并。
Q：资产稽核的’待处理’会越积越多吗？
A：会。正常节奏是每周清理一次，全量裁决后归零。建议：
- 处理顺序：先看 conflict 字段，只解决真正有冲突的；纯 IP 漂移的直接 merge；
- 长期堆积 > 100 条时，说明阈值太严了——考虑把 auto_merge 阈值降到 0.70。
Q：身份可信度 vs F1.3 资产对账什么关系？
A：F1.3 发现"差异"，身份可信度判断"是否该合并差异"。两者是上下游关系：
- F1.3 报"资产 X 不在台账"（shadow）
- → 身份可信度评分看：观测 A（来自 Wazuh）和台账的 dev-server 有多像？
- → 像（>0.80）→ auto_merge
- → 灰区 → needs_review → 进「资产稽核 → 待处理」
- → 不想像 → distinct → 真是一台新设备 → 一键纳管
收尾：08 在系列中的位置
到本篇为止，资产/审计主题正式收官——你的 SOC 拥有了"看清世界"的全套工具：
| 阶段 | 能力 | 来源 | 篇目 |
|---|---|---|---|
| 看得见 | 三路数据源拼接 | Wazuh + TP-Link + Nmap | 03 / 04 / 05 |
| 看得真 | 资产台账真实性稽核 | 资产对账（F1.3） | 06 |
| 不被骗 | 数据流健康自检 | 三层健康聚合 | 07 |
| 信得对 | 多源冲突时选哪边 | 身份可信度评分 + 「资产稽核」待处理标签 | 08（本篇） |
接下来进入 AI 副手四篇（09/10/11/12）——把"看清/看清/不被骗/信得对"的成果，交给 AI 自动写报告、自动查、自动派单。这是系列中"AI 灵魂"的部分，也是项目对读者最不可替代的差异化。
老李上周换了办公室，所有人手机换 SSID → 路由器把新 MAC 全报给采集器 → F1.3 报 30 多条 shadow。
看完 07 看板（源全绿），他知道数据没问题；
打开 08 的「资产稽核 → 待处理」标签，每条都是 0.95 以上 auto_merge——MAC 一致 + Wazuh agent id 一致 + IP 都在同一子网；
一键批量合并。5 分钟，不用判断哪条是真的哪条是攻击。没有 08 的话，他得一条条看"这是不是蹭网的"。
老李的周末又救回来了。你的呢？
【系列导航】《一个人的SOC》总目录（持续更新）
【上一篇】(07) 数据可靠性——源健康/同步死信/对账差异三层聚合
【系列开篇】(00) 中小企业为什么需要自己的安全运营中心
【项目地址】AI-miniSOC - GitHub · MIT 开源，欢迎 Star ⭐
【Gitee 镜像】https://gitee.com/xiejava/AI-miniSOC
【交流】「资产稽核 → 待处理」标签里积了 100 多条？把截图发 Issue，我帮你按"先看冲突因子 / IP 漂移直接合并 / 不一致的才逐条看"清理。
下一篇（预告）：(09) LLM大模型统一底座——9 个 AI 消费点如何接进安全运营（连载中，敬请关注）
作者博客：http://xiejava.ishareread.com/
