告警堆到 100 万条那天，我决定自己写一个“会用 AI“的安全运营中心

原创

xiejava
xiejava

fullbug

2026年10月23日 10:43
湖南

去阅读

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 解释给你听，大概一个下午。

作者：xiejava ·

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

【一个人的SOC】(00) 中小企业为什么需要自己的安全运营中心

【一个人的SOC】(01) 总体架构——8G 内存的小服务器如何装下一个 SOC

【一个人的SOC】(02) 从零部署——一小时跑起来的实战与踩坑

【一个人的SOC】(03) Wazuh 接入实战——把第一台主机纳管进你的 SOC

【一个人的SOC】(04) 用一台 TP-Link 路由器做内网资产发现与上网行为审计

【一个人的SOC】(05) Nmap攻击面扫描-影子资产和暴露面主动发现

【一个人的SOC】(06) 资产对账——影子/离线/不匹配三类差异稽核

【一个人的SOC】(07) 数据可靠性——源健康/同步死信/对账差异三层聚合

【一个人的SOC】(08) 身份可信度评分——多源数据不一致时信哪个

【一个人的SOC】(09) LLM 怎么当好你的安全运营副手——从查资产到写周报的 10 个 AI 场景

作者博客：http://xiejava.ishareread.com/