AI-miniSOC：把 100 万条告警变成“今日必处理”

Splunk 用不起，Wazuh 不够用，告警没人看——这是大多数小公司安全运营的真相。这篇文章讲讲我是实现 AI-miniSOC 把 100 万条告警变成“今日必处理”。

从一个熟悉的困境说起

先看一组大多数小公司都在经历的现实：

• 买不起商业 SOC。Splunk 按量计费动辄每年几十万，QRadar 的报价单能让 CFO 直接把会议结束。这不是产品的问题，是商业模式天然筛选掉了小客户。
• 养不起安全团队。一个最小规模的安全运营组（三班倒的监控 + 分析 + 响应）一年人力成本百万起步，而小公司的“安全负责人”往往是兼职的网管。
• 开源工具拼起来不是平台。Wazuh 很强，但它是 SIEM 不是 SOC——有检测、有告警，没有资产台账、没有事件工作流、没有合规报告。你把 Wazuh、Loki、Grafana、OpenSearch 各装一套，得到的是四个独立界面和一堆互不相通的账号，运维成本反而更高。

于是小公司的安全运营普遍退化为三种形态：没有（靠运气）、Excel（资产台账是一张没人更新的表格）、告警坟场（SIEM 装了，告警堆了一百万条，没人看）。

第三种形态最可惜，也最普遍。我在自己的环境里统计过：OpenSearch 里 Wazuh 告警文档超过一百万条。一百万条技术性极强的 JSON 告警，对一个兼职网管来说等于零——他既看不完，也看不懂。告警的价值不在于产生，而在于被理解和被处置。

图 1：SIEM 的告警生产曲线 vs 人的消化曲线——剪刀差就是“告警坟场”

而 2025 年之后，人人都在谈“用 AI 做安全”。但真敢把 LLM 接进安全运营链路的人很快会撞上三堵墙：

1. 幻觉墙——模型一本正经地编造一个不存在的 CVE，比没有 AI 更危险；
2. 注入墙——让 LLM 直接生成 SQL 查数据库？提示词注入一进来就是数据泄露事故；
3. 可用性墙——大模型服务总会抖，AI 挂了整个平台是不是跟着瘫？

这些困境就是 AI-miniSOC 的出发点。它的定位一句话可以说完：

一个面向中小企业和个人安全团队的轻量级、AI 增强的安全运营中心——一台 8GB 内存的小服务器就能跑起来。

开源地址：github.com/xiejava1018/AI-miniSOC

实拍：总览仪表板——风险概览与 AI 态势摘要

核心能力全景：八大能力域

平台没有走“先搭平台再找场景”的路线——每个能力域对应一个具体运营痛点。全景如下：

图 4：八大能力域，43 个路由 / 60+ 服务 / 52 张表的顶层视图

用一张能力矩阵看会更清楚：

一句话：开源零件负责把“贵”解决掉，AI-miniSOC 负责把“零件”变成“整车”——统一账号、统一契约、统一运营视角。

五个问题，五组答案

挑五个最核心的讲。

问题一：开源工具是零件，怎么拼成一台整车？

架构上，AI-miniSOC 没有重新发明任何轮子：Wazuh 继续做主机入侵检测和 SIEM，Loki 继续做日志聚合，Grafana 继续做可视化，OpenSearch 继续存结构化告警。项目自己写的是 Wazuh 们做不好的那一层——资产、事件、告警治理、合规、报告，以及贯穿所有环节的 AI 解读。

图 2：AI-miniSOC 分层架构总览——43 个路由模块、60+ 服务、52 张表、9 个 AI 消费点

所有 API 走统一契约：HTTP 恒 200，业务码在 body.code，前端一套 axios 拦截器管所有错误处理；后端 39 个 Alembic 迁移保证数据库可持续演进。这些“整车”级的工程细节，是拿零件拼凑的人最缺的。

问题二：内网环境复杂，采集器怎么部署？

这是我认为整个项目里最值得讲的架构决策。

传统监控是“服务端主动连 agent”。但现实内网里：设备在 NAT 后面、防火墙只许出不许进、路由器根本不能装 agent。所以 AI-miniSOC 的采集器全部是拉模型：只发出向请求（心跳 + 拉任务 + 推数据），天然穿透 NAT，不需要在任何设备上开洞。

图 3：传统模式 vs 拉模型——同一个 NAT 墙，方向反过来就通了

三类采集器各管一段：wazuh-collector 同步 Wazuh 的 agent、SCA 基线、SCAP 漏洞数据；tplink-collector 从路由器发现内网资产和上网行为日志——那些“装不了 agent 的设备”由此进入资产台账；scanner-collector 跑 Nmap 的攻击面扫描器，跑在任意内网主机上。

扫描器这里做了第二个关键决策：控制面与数据面分离。扫描器不自己决定扫什么，而是显式注册到平台（管理员分配 scanner_id + API Key），中央调度下发任务，扫描器执行后回推结果。任何一台内网机器装上它，就变成了平台的扫描探针——发现影子资产、测绘公网暴露面，都是这个模型的自然产出。

图 4：扫描器控制面/数据面分离——注册、心跳、拉任务、回推的完整闭环

实拍：扫描任务列表

实拍：扫描发现明细——29 台内网主机自动浮出，含 MAC 与关联资产 ID

问题三：资产是糊涂账，怎么变成活台账？

资产管理的死结在于：台账永远落后于现实。设备是别人接的、IP 是 DHCP 的、云主机是研发自己开的——等安全团队知道的时候，它已经裸奔了三个月。

AI-miniSOC 的解法是让台账自动追上现实：

• 多源融合：Wazuh agent、路由器发现、Nmap 扫描三个来源的数据汇入同一台账，每个资产带 data_source 溯源字段，端口层有专门的 soc_asset_port_sources 多源汇聚表；
• 对账稽核（三类差异）：shadow（台账没有但现实中存在——影子资产）、offline（台账有但现实中消失）、mismatch（属性不一致）。扫描器每次发现新东西自动入稽核队列，不需要人去比对；
• 公网暴露面视角：资产带公网 IP 属性，暴露面扫描直接以资产库为目标下发，扫出的端口与 CVE 映射（CISA KEV 库自动同步）挂接在发现明细上。

图 5：多源融合 + 对账引擎——shadow / offline / mismatch 三类差异自动入队

从“一张 Excel”到“自动对账的差异队列”，这是资产运营从手工业变成流水线的那一步。

实拍：资产台账——溯源字段与风险评分

实拍：资产稽核差异队列

实拍：资产探测发现清单

问题四：AI 到底敢怎么用？

这是项目最核心的差异点。AI-miniSOC 接入智谱 GLM 作为统一大模型底座，覆盖 9 个消费点：自然语言资产查询、风险摘要、AI 安全报告、变更影响分析、对账 AI 解读、合规 AI 解读、AI Chat、AI Agent。

图 6：9 个消费点共用一个底座，每个消费点都有“诚实降级”路径

但真正的设计工作量不在“接入”，而在驯服：

第一，LLM 永远不生成 SQL。自然语言资产查询分两级：L1 由模型把问题翻译成受控的查询参数；L2 处理复合问题时，模型只从预置模板库里选模板、填参数——参数要过类型、范围、枚举三层校验和维度白名单。模型犯错的爆炸半径被限制在“查询结果不对”，而不是“拖库”。配了一套 50 条用例的评测集（W0），基线准确率 98%，对抗样本 5 条全部正确拒绝——攻击者想通过自然语言注入套数据，路径是不通的。

图 7：L1/L2 受限查询链路——安全围栏之内，SQL 永远由代码生成

第二，诚实降级。每个 AI 消费点都有非 AI 的降级路径：模型挂了，风险摘要退回规则统计，AI 报告退回模板生成，并且明确告诉用户“这是降级输出”。安全场景里，“AI 一本正经地编”是最恶劣的故障模式，宁可诚实地说“我现在不行”。这套路径做过专门的降级演练。

第三，AI 是解释器不是决策者。告警治理（聚合、分级）是确定性代码；模型负责的是把“rule 504 触发”翻译成“这台机器正在被暴力破解”这样的人话，把对账差异写成一份运营者能看懂的报告。确定性的归确定性，生成式的归生成式。

实拍：AI 告警治理分析

实拍：AI 安全报告

问题五：数据链路静默失败了怎么办？

安全平台最阴险的故障不是报错，而是静默失败：采集器死了没人知道、同步假成功、数据断了三天图表还在“正常”画。一个基于错误数据做出的“一切安全”判断，比没有平台更危险。

所以项目把数据可靠性做成了独立的一层——数据健康（data-health）：

图 8：源健康 → 同步死信 → 对账差异，三层聚合 + 6 场景主动推送

• 源健康：每个数据源的最近心跳、延迟、错误率；
• 同步死信：同步失败的记录进死信队列，可查可重放，而不是悄悄丢掉；
• 对账差异：第三层兜底，用资产对账结果反向验证数据链路。

配套的还有主动推送：数据链路异常、风险评分突变、EOL 到期、影子资产发现、报告生成完成、扫描器离线——六个场景主动推邮件/钉钉/企业微信，加上 WebSocket 站内通知。平台的沉默本身被当成一个需要告警的事件。

实拍：数据健康三层聚合

什么人适合用它

• 5-50 人的小公司：一台旧服务器（8GB 内存、50GB 磁盘）加一台 Wazuh，就能拥有资产台账、告警治理、漏洞管理和周报自动化，替代“没有”或“Excel”；
• 个人安全研究员 / 独立顾问：家庭实验室的完整 SOC，多个客户环境可以用多个采集器实例接入同一平台；
• 想学习 SOC 工程化的开发者：FastAPI async + Vue3 的全栈参考，采集器拉模型、控制面/数据面分离、LLM 受限执行、诚实降级，这些模式可以直接搬到你自己的项目里；
• 已有 Wazuh 的团队：它就是给 Wazuh 补上 SOC 能力层的那块拼图。

结语

AI-miniSOC 想证明的命题其实很朴素：安全运营的门槛可以不靠预算堆，靠架构和 AI 降。

开源工具负责把“贵”的问题解决掉（Wazuh/Loki/Grafana 全免费），拉模型采集器把“部署难”解决掉（出向请求穿 NAT），受控的 LLM 把“看不懂”解决掉（告警变人话、台账变报告），数据健康把“不可信”解决掉（静默失败变主动告警）。四个问题叠在一起，就是“一台 8GB 服务器上的安全运营中心”。

如果这个方向和你面对的现实有交集，欢迎来 GitHub 看看——README 里有完整的部署路径，从 clone 到第一个告警被 AI 解释给你听，大概一个下午。

项目地址：github.com/xiejava1018/AI-miniSOC（MIT）

免责声明

1.一般免责声明：本文所提供的技术信息仅供参考，不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》，作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。

2. 适用性声明：文中技术内容可能不适用于所有情况或系统，在实际应用前请充分测试和评估。若因使用不当造成的任何问题，相关方不承担责任。

3. 更新声明：技术发展迅速，文章内容可能存在滞后性。读者需自行判断信息的时效性，因依据过时内容产生的后果，作者及发布平台不承担责任。

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）