soctalk
登录试用沙盒

对比

自建 Wazuh SOC,还是部署一套已经建好的

如果你运营的 MSP 或 MSSP 拥有扎实的工程团队,在内部自建多租户 Wazuh SOC 是一条正当的路,也确实有不少服务商这样做了。SocTalk 就是这套构建的成品:一个控制平面之下运行按客户的 Wazuh 技术栈,AI 分诊配人工把关,全部采用 Apache 2.0。下文列出 DIY 路线涉及的工作,供你判断把工程时间花在自行组装上是否值得。

← 全部对比

你需要构建什么

原生 Wazuh 提供 manager、indexer 和 agent。在此之上的一切都是这个项目本身:按客户的 manager 和 indexer、用于开通它们的控制平面、数据库级租户隔离、网络策略、代理注册管道、分诊工作流和升级工具。每一块单独看都可行;把它们全部集成起来,并在客户不断到来时保持集成状态,才是以月计的工程投入所在。再加一层 AI 分诊,你还要负责提示词、面向 Wazuh 及你的富化数据源的工具编排、防止模型关闭不该关闭事项的护栏、令牌预算,以及围绕这一切的复核工作流。

SocTalk 把这些组件组装好交付:一个控制平面在相互隔离的 Kubernetes 命名空间中运行按客户的 Wazuh 技术栈,分诊流水线和复核队列都已内置。由去重、合并、关联组成的确定性漏斗在任何模型调用之前就解决掉许多告警,每次升级都经过人工复核,不存在自动批准模式,LLM 由你按租户选择,包括完全本地的 Ollama。所有代码都是 Apache 2.0,chart 面向原生 Kubernetes 1.30+,在已准备好的集群上,生产安装大约需要一小时。

租户隔离

多租户是需要尽早做对的设计决策,走 DIY 路线时,证明它的责任在你。这意味着在每个租户范围表上设置行级安全策略、把租户身份贯穿到每个查询和仪表板、按租户配置网络策略和资源配额,还要有一套能证明跨租户查询确实会失败的测试。你为第三个客户写的开通脚本,到第三十个客户时仍然要能用。

SocTalk 在每个租户范围的 Postgres 表上强制启用 FORCE ROW LEVEL SECURITY,并由七项在 CI 中必须通过的隔离测试保障。每个客户在自己的命名空间中获得专属的 Wazuh manager 和 indexer,配有 Cilium NetworkPolicy、ResourceQuota 和租户范围的代理注册密钥。该技术栈在 3 节点集群上测试至 ~50 个租户;每个常驻租户按大约 6 到 8 GB 内存和 1.5 vCPU 规划。

客户接入与升级

在自研技术栈里,每个新客户都是一份操作手册:搭建他们的 Wazuh 实例、接通 DNS 和注册密钥、构建他们的仪表板,再把这一切接回你自己编写的中央工具。升级也按同样的方式成倍增加。Wazuh 版本升级乘以客户数量,加上 schema 迁移、证书轮换和 Kubernetes 生命周期,累积成随每个租户增长的经常性工程时间。

SocTalk 从控制平面接入客户。开通过程按九个有序阶段执行,支持幂等重试,创建命名空间、配额、Wazuh 技术栈和注册端点,代理通过按主机名路由的 ingress 使用租户范围的密钥注册。V1 中按租户的 DNS 和负载均衡接线仍为手动,另有一个 'provided' 配置文件可接入你已在运行的 Wazuh。两个 chart 均通过 helm upgrade 升级,数据库迁移自动执行;不过目前面向整个租户群的升级还是一套有文档说明的、对租户命名空间逐一执行的手动循环,群级升级 API 在路线图上,尚未发布。

成本如何

两条路线的许可费用都是零。Wazuh 是开源的,SocTalk 采用 Apache 2.0,没有社区版/企业版之分,也没有功能门槛。差别在于钱花在哪里。DIY 自建要预先投入数月工程时间,之后还要持续投入以维持运行;如果平台正是你想让团队深耕的方向,这笔交换并不吃亏。使用 SocTalk 时,你支付的是自己的基础设施和 LLM 令牌,在低成本配置下、每天 30 条告警时约为每租户每天 $9 的量级,波动很大;使用本地 Ollama 时按令牌计的成本为零。

什么时候自建更合理

SocTalk 以 Wazuh 作为数据平面。今天 SocTalk 的数据平面仅支持 Wazuh;其他 SIEM 在其工具面上是可行的扩展方向,但目前都未提供。以 Splunk 或 Elastic 为中心的团队更适合做自己的集成工作。

如果 SOC 平台本身就是你的产品差异化所在,也应该自建。定制的关联逻辑、专有的分析师体验、竞争对手无法复制的工作流,这些都指向掌控每一层,预置平台在这种情况下多半会碍事。

如果确实拿不准,源码在 github.com/soctalk/soctalk,采用 Apache 2.0。先读一读 RLS 策略、网络模型和分诊流水线再做决定。最坏的结果也不过是带着一套可用的参考架构回去自建。

无论哪条路,你保留的东西

SocTalk 运行在你自己的 Kubernetes 上,从裸机到 EKS、AKS 或 GKE,需要时可完全气隙部署,LLM 按租户自选,包括完全本地的模型。自托管在两条路线上都是常量。你保留自己的基础设施和数据,客户关系也从不经过任何供应商。

它就是组装完毕的 DIY 技术栈,而许可证意味着上限与自建相同:仓库里的一切都是 Apache 2.0,没有被扣下的企业版;如果哪天你不认同项目的走向,可以直接 fork 并继续运营。

五分钟看到它跑起来

下载演示虚拟机或克隆代码仓库。完整平台采用 Apache 2.0 许可,没有功能门槛。

资料来源