上一篇 (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_logsAI-miniSOC 内部的操作日志表——谁在什么时候做了什么可追溯。实战在你的 SOC 里看一次对账**资产对账F1.3**是定时任务 手动触发并行。第一次跑会暴露一堆历史欠账别慌——这是好事。点击资产管理-“资产稽核”就会看到资产稽核的概览——总体结论红/黄/绿 三类差异数字 近期趋势第一次看这个页面你大概会看到这样的数字shadow 可能有十几条路由器日志里有 IP但台账没有offline 可能有几十条老员工离职带走了设备、IT 把机器调拨到了别处、台账没改mismatch 通常是 IP 变了DHCP 重新分配、或者设备换了网段。这些数字本身就是资产台账真实性的体检报告。处置差异决策不是删不删第二件真实的事是看到差异后该怎么办资产对账F1.3的设计哲学是发现 vs 决策 分开——扫描器只负责发现05 篇的 Nmap 只能告诉你有什么要不要纳管是人的决定同理shadow/offline/mismatch 怎么处置也是人的决定不是自动删。未纳管的可以通过“纳管”操作进行“一键纳管”为什么不让系统自动清理因为你不知道离线是真的下线了还是网络抖动你不知道影子是新设备还是邻居蹭网这些判断需要业务知识。系统能做的是把差异推到你面前让你做决定。典型决策清单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→ 最终状态terminalresolved 已处理 / ignored 已知忽略 / failed 处置失败“推进最终状态后不可逆。这避免了一个常见事故运维 A 点了忽略”运维 B 不知道又点了纳管——一个资产被反复改来改去重复处理必须失败同一 shadow 行被两人同时处理后到的那个直接 409——这跟 02 篇讲过的严格保留 A-B-C 数据库纪律是一脉相承的。常见问题Q第一次跑出来几百条差异是不是系统坏了A不是。资产对账F1.3是历史欠账的一次性体检——你的台账从第一天起就有数据不准的问题只是以前没工具发现。这是好事以前这些差异是被忽视的风险资产现在它们浮现到台面上了。你做的是治理资产台账的卫生不是修系统的 bug。Q差异处理优先级怎么排A建议这样排shadow 优先——这是攻击者最爱藏的设备mismatch 中 IP 变的——影响所有按 IP 查询的能力06-18 篇所有功能都依赖 IPoffline 中超过 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 Nmap03 / 04 / 05看得真资产台账真实性稽核资产对账内部代号 F1.306本篇接下来 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/