上一篇 (05) Nmap 攻击面扫描我们把"三路数据源"拼齐了——Wazuh 看到装了 agent 的主机、TP-Link 看到 DHCP 设备、Nmap 看到影子和暴露面。但拼齐之后的下一步是什么？
是把数据丢在那里让它自己增长吗？不。下一个必然的问题是：
“我登记的资产台账，和这三路实际数据，对得上吗？”
这就是 资产对账 解决的问题。
05 篇结尾我留过一句话：“你的 SOC 现在看得见整个世界。剩下的，是把看见的变成可治理的。” —— 这句话现在就兑现。资产对账（项目内部代号 F1.3）是这道分水岭。
为什么要对账？
直说原因——资产对账（内部代号 F1.3） 解决的不是"锦上添花"的问题，是**“数据可信”**的问题。
没有对账，资产台账会"看起来很丰富"——80 条资产、按类型按业务系统分类清楚。 但真实性是未知的：
- 那台三年前登记的服务器，是不是真的还在？
- 上周采购的新笔记本，是不是真的接进了网络？
- 财务部的打印机，登记的 IP 还是不是它现在的 IP？
对账不解决的问题：让你知道"哪些数据是假的"。
听起来有点反直觉——一个"找出哪些数据是假的"的功能，怎么会放在 SOC 里？因为 SOC 的核心承诺是**“基于真实世界做决策”**。一旦台账失真，所有基于台账的分析（风险评分、攻击面、合规报告）都会失真。
资产主题开篇就讲资产对账（内部代号 F1.3），就是因为没有它，后面 (07) 数据可靠性、(08) 身份可信度、(17) 成本账本这些都站不住脚。
三类差异：资产对账输出什么？
资产对账的结果只有三种形态——别看代码里字段很多，最终交付给运维的就是这三类：
| 差异类型 | 一句话 | 该怎么处理 |
|---|---|---|
| 👻 shadow（影子） | 实际网络里有，但台账没记录 | 决定要不要纳管（05 篇的"一键纳管"按钮用在这） |
| 📴 offline（下线） | 台账有，但实际网络里已经不在了（agent 断开、IP 失效） | 决定是删除还是"已知异常忽略" |
| 🔀 mismatch（不一致） | 两边都有，但字段对不上（IP/主机名/OS） | 哪边为准就改哪边 |
关键不变量（这是资产对账设计里的硬约束，不是可选项）：
- 判定全部由规则完成，不走 LLM——AI 只负责把差异"讲成人话"。这跟 (11) 诚实降级是同源思想：安全决策不该依赖模型的随机性。
- 必须标注数据新鲜度——源不新鲜时（台账超 24h 未同步）禁止静默给出"无差异"结论。那比报错更危险。
- 处理动作走状态机**（一种"按步骤推进、不能回退"的流程控制）**——重复处理必须失败（不能引入锁——避免运维误操作）。
- 全部处置动作落
soc_audit_logs（AI-miniSOC 内部的"操作日志"表）——谁在什么时候做了什么，可追溯。
实战：在你的 SOC 里看一次对账
**资产对账（F1.3）**是定时任务 + 手动触发并行。第一次跑会暴露一堆历史欠账，别慌——这是好事。
点击"资产管理"-“资产稽核”，就会看到资产稽核的概览——总体结论（红/黄/绿）+ 三类差异数字 + 近期趋势：
第一次看这个页面，你大概会看到这样的数字：
- shadow 可能有十几条（路由器日志里有 IP，但台账没有）；
- offline 可能有几十条（老员工离职带走了设备、IT 把机器调拨到了别处、台账没改）；
- mismatch 通常是 IP 变了（DHCP 重新分配、或者设备换了网段）。
这些数字本身就是资产台账真实性的体检报告。
处置差异：决策不是"删不删"
第二件真实的事是：看到差异后该怎么办？
资产对账（F1.3）的设计哲学是" 发现 vs 决策" 分开——扫描器只负责"发现"（05 篇的 Nmap 只能告诉你有什么），要不要纳管是人的决定；同理，shadow/offline/mismatch 怎么处置也是人的决定，不是自动删。
未纳管的可以通过"纳管"操作进行"一键纳管”——确认后，影子设备进入资产台账（来源 = wazuh/tplink/scanner），下次 F1.3 跑就把它当成"已纳管"不再报：
不让系统自动"清理"？** 因为你不知道"离线"是真的下线了，还是网络抖动；你不知道"影子"是新设备，还是邻居蹭网；这些判断需要业务知识。系统能做的是把差异推到你面前，让你做决定。
典型决策清单：
- shadow + 来源是 TP-Link + 名称是"iPhone" → 纳管（员工私人手机办公网）
- shadow + 来源是 TP-Link + 名称是"unknown" → 看 MAC 决定，陌生设备就忽略
- offline + 设备名称是"研发-test-01" → 删除（确定已下线）
- offline + 设备名称是"财务-payroll" → 先打电话问（不能误删，可能只是临时断网）
- mismatch + IP 变了 → 看是 DHCP 重分配还是真换了位置；前者改台账，后者改 agent 上报
处置必留痕：审计 + 不可逆
处理 shadow 的时候你可能图快——点了"纳管"就走。但资产对账（F1.3）不允许这样：
- 每个处置动作都进
soc_audit_logs（操作日志表）：操作人、时间、动作类型、目标资产 ID、原因备注——合规审计需要这些（等保测评一定会问"你怎么处理资产差异的"）； - 状态机是单向的：每条差异按"待处理（pending）→ 已认领（acknowledged）→ 最终状态（terminal：resolved 已处理 / ignored 已知忽略 / failed 处置失败）“推进，最终状态后不可逆。这避免了一个常见事故：运维 A 点了"忽略”，运维 B 不知道又点了"纳管"——一个资产被反复改来改去；
- 重复处理必须失败：同一 shadow 行被两人同时处理，后到的那个直接 409——这跟 02 篇讲过的"严格保留 A-B-C 数据库纪律"是一脉相承的。
常见问题
Q：第一次跑出来几百条差异，是不是系统坏了？
A：不是。资产对账（F1.3）是"历史欠账"的一次性体检——你的台账从第一天起就有数据不准的问题，只是以前没工具发现。这是好事：以前这些差异是被忽视的"风险资产"，现在它们浮现到台面上了。你做的是治理资产台账的卫生，不是修系统的 bug。
Q：差异处理优先级怎么排？
A：建议这样排：
- shadow 优先——这是攻击者最爱藏的设备；
- mismatch 中 IP 变的——影响所有"按 IP 查询"的能力（06-18 篇所有功能都依赖 IP）；
- offline 中超过 30 天未恢复的——大概率是真下线了。
Q：资产对账（F1.3）多久跑一次？
A：项目默认每小时一次（AI-miniSOC 的定时任务框架自动跑，无需手动开 cron）。如果你对台账"健康度"特别敏感，可以改成每 15 分钟。不建议关闭——它是后面 07-08 篇所有功能的数据基础。
Q：资产对账（F1.3）和 05 篇的 Nmap “一键纳管"什么关系？
A：资产对账是”产生 shadow 差异"，Nmap 的"一键纳管"是"处置 shadow 差异"。两者闭环：Nmap 发现新设备 → 进入 AI-miniSOC 的"扫描发现"表 → 资产对账定期把它转为 shadow 差异 → 运维在资产对账页面一键纳管 → 设备进入台账 → 下次资产对账跑就把它当成"已纳管"不再报。
收尾：资产对账在整个系列中的位置
到本篇为止，你的 SOC 已经能"完整看清世界 + 不被自己骗"：
| 阶段 | 能力 | 来源 | 篇目 |
|---|---|---|---|
| 看得见 | 三路数据源拼接 | Wazuh + TP-Link + Nmap | 03 / 04 / 05 |
| 看得真 | 资产台账真实性稽核 | 资产对账（内部代号 F1.3） | 06（本篇） |
接下来 07-08 篇会进一步把"看见"推向"可治理"——
- (07) 数据可靠性——三路数据源"自己说的话能不能信"（同步死信、源健康、采集器心跳），资产对账的"24 小时没同步就不出结论"红线是从这里来的；
- (08) 身份可信度评分——多源数据不一致时，信哪个？（多因子融合评分、置信度门槛）；
- (09) AI 统一底座——开始用 AI 副手"自动生成对账报告"。
但本篇有它自己独立的价值：资产对账（内部代号 F1.3）是 SOC 的"质量检查"层。哪怕你后面什么都没接，先把资产对账功能跑一遍——你就已经知道自己的资产台账是真是假了。
老李的 SOC 已经跑通资产对账，清理掉 30 多条"看起来有但实际没有"的"幽灵资产"——他终于敢在月度报告里写"资产完整率 100%“了。你的呢？
【系列导航】《一个人的SOC》总目录（持续更新）
【上一篇】(05) Nmap 攻击面扫描——影子资产和暴露面主动发现
【系列开篇】(00) 中小企业为什么需要自己的安全运营中心
【项目地址】AI-miniSOC - GitHub · MIT 开源，欢迎 Star ⭐ **【Gitee 镜像】**https://gitee.com/xiejava/AI-miniSOC
【交流】 第一次跑出几百条差异不知道怎么处理？把数字 + 截图发 Issue，我帮你定优先级。
下一篇（预告）：(07) 数据可靠性——源健康/同步死信/对账差异三层聚合（连载中，敬请关注）
作者博客：http://xiejava.ishareread.com/
关注：微信公众号，一起学习成长！