用 n8n + RAG 构建 AI 驱动的安全事件响应

Viraj 曾在 n8n 担任客户成功负责人，帮助电信、政府、金融等行业的企业级客户采用 n8n 并成功部署到关键部门。他花了大量时间与网络安全领导合作，并在下文中分享了这些经验。

Dmitry 是安全自动化和检测工程师，具有检测工程、SecOps 自动化和云安全背景。他在蓝队工作了多年，从事云环境中的安全工具建设和审查，作为共同作者在此分享了这方面的经验。

事件响应团队面临的挑战

事件响应团队在处理一系列问题时往往没有预警。这些问题在后台积累，直到它们造成实际伤害才显现出来：

• 平均解决时间（MTTR）不断上升
• 本应在检测后数秒内制止的攻击造成的成本激增
• 分析师精疲力尽，纷纷离职——员工流失率高企

这篇文章介绍了一个为解决这些挑战而设计的自动化框架，同时为风险意识强的网络安全工程经理提供了一种在自动化工作流中安全利用 AI 的方法。根据我们的经验，许多经理在这方面确实采取了谨慎态度。

我们在走访的 SOC（安全运营中心）中反复遇到三个核心诉求，据此构建了这个框架：

三大核心目标

1. 减少捕获和重用过往解决方案的时间

目前，当事件得到解决时，修复背后的推理很少被以一种有助于下次事件处理的方式记录下来。事后分析报告会被写出来，但当几个月后发生类似事件时，几乎没人会翻出来读。加上 SOC 中 50% 的分析师流失率达 10–25%（1），人员离职时知识也就随之丧失了。该框架使用检索增强生成（RAG）管道自动捕获这些推理过程，并在分析师需要的那一刻呈现给他们，而不需要他们付出额外努力。

2. 让分析师重新专注于真正需要人类创意的工作

在实时事件中一边逐项核对行政清单是最不应该做的事。通过把常规工作从分析师的工作清单中移除——Slack 线程搜索、翻阅旧解决方案笔记——这个框架释放了只有人才能做出的判断所需的脑力。

3. 让 AI 在真实 SOC 工作流中安全可用

对 AI 的兴趣显而易见——调查报告持续显示 50–90% 的组织正在"探索"或"规划"在 SOC 中使用 AI（2）。困难的部分在于在实时事件中将其转化为团队信任的东西，这通常归结为几个担忧：

• 将真正的威胁误标记为误报会造成高成本错误
• 没有明确边界的 AI 会浪费时间或误导分析师
• 票证数据通常过于敏感，不能发送到第三方云服务

虽然这些不是纯粹的技术问题，但解决方案的一部分是。下面的库就是围绕此设计的：自动化重复性的、非创意工作，保持有用的上下文靠近分析师，让团队根据风险承受度和希望人工介入的位置来调节 AI 的使用程度。

工作流做什么

该工作流在 n8n 中创建的 webhook 地址接收 JSON 有效负载。这种格式是来自 SIEM（如 Elastic）或票证工具（如 Jira）的典型事件或工单格式。

有效负载被摄取并触发三个并行检索：最匹配的参考应急手册、来自历史记录的类似已解决事件，以及来自网络的最新威胁情报。

一个综合 agent 将所有三者整合，生成结构化的应急方案：立即行动、隔离步骤、IOC、明确阐述的假设、在确定性低的地方标注置信度。

原理是重用而非重新发明，每次都更快地解决重复事件。你是在让 LLM 组织你的团队已经知道的内容，而不是从通用训练数据中生成应对方案。

支撑这一切的是一个 RAG 管道，同样用 n8n 构建，它对你的应急手册和过往事件进行分块，存储在 Supabase 向量数据库中，为主要工作流做好准备。提供了说明以持续将新的已解决工单或应急手册集成到此向量数据库中。

架构深度讲解

让我们更仔细地看看每个检索通道：

应急手册检索。 参考应急手册被分块并存储在 Supabase 中。新事件针对应急手册库进行语义相似性搜索。检索最匹配的项。如果匹配质量低，会标记出来——agent 不会默默假设找到了强匹配继续进行。

威胁情报丰富。 出于演示目的，这是通过 Tavily 基于警报类型、相关 TTP、最近的公告进行网络搜索。在生产环境中，你会接入你的生产 TIP 或多个威胁情报工具的组合。

历史事件检索。 已解决的事件通过同一向量管道处理。同一数据库，不同的表。相似性搜索提取最相关的过往案例，包含完整上下文：发生了什么、如何进行的隔离、什么有效、什么花的时间更长。

来自所有三个通道的结果合并到单一综合 agent。综合 agent 获取该块加上原始事件数据，生成应急方案。

技术栈：

• Supabase：向量存储和关系存储。一个数据库同时处理两者。
• Gemini embeddings：摄取管道和检索。这可以通过 n8n 中的简单节点改动替换为你选择的嵌入模型。
• OpenRouter：LLM 路由。默认模型是 Claude Opus 4.5。
• Tavily：威胁情报通道的网络搜索。

LLM 是即插即用的。当更强大的模型发布时，你改动一个配置值，其余工作流保持不变。对于无法将事件数据发送到云 AI 供应商的团队——这在许多企业环境中是真实的限制——任何 OpenAI 兼容端点都可作为即插即用替代方案，包括 Ollama 或 vLLM 进行完全本地推理。工作流不关心模型在哪里。

摄取管道与运行时工作流分离。你运行一次摄取来填充向量表——应急手册、已解决事件、测试事件——仅当你想在将来向数据库添加新分块时运行。运行时工作流从不触及它。

工作流同时产生两个输出。如果你有特定的输出格式，可以删除其中一个以节省 LLM 输出 token 成本。

结构化 JSON——使用离散字段的经过验证的模式：事件摘要、立即行动、隔离指导、提取的 IOC、假设和置信度。每个字段在下游都是可寻址的。将其导入票证系统以预填充字段，将其送入 SIEM 规则，或触发下游 n8n 工作流，无需解析自由文本。

Markdown 应急方案——与格式化文档相同的内容。这是发布到 Slack 的内容，进入战情室文档的内容，人员在事件期间阅读的内容。源标签是内联的，所以无需打开 JSON 就能看到属性。

两者来自同一次综合运行。JSON 是权威输出；markdown 从中生成。如果你只需要人类可读版本，忽略 JSON。如果你在构建集成，解析结构化字段并忽略 markdown。

前置条件

在对真实数据运行工作流之前，三件事需要处于合理状态。

参考应急手册。 至少对你的组织面临的最高容量事件类型。它们不需要很长——覆盖检测标准、初始分类步骤、隔离选项和已知误报模式的应急手册就足够了。检索质量随着专一性而扩展。一份通用的"恶意软件响应"应急手册会返回通用指导。为你的 EDR 勒索软件检测编写的应急手册会返回可用的内容。

已解决事件历史。 历史检索通道需要在修复和经验教训字段中有实际内容的记录。模板化条目增加噪声。记录具体发生了什么、涉及哪些系统、实际解决了什么的记录是改进输出质量的关键。随着历史的增长，工作流变得更有用。

工单上的 MITRE ATT&CK 映射。 虽然不是严格要求，但摄取管道使用战术和技术字段进行检索丰富。已经有一个配套的 n8n MITRE Mapping 工作流可以为你做这个。

有些团队会先运行他们 SIEM 的 AI 分组——将相关警报合并为单一富集票证——然后传入该复合事件。这是一个受支持的模式，比原始单一警报输入产生更好的检索结果。

实施这个框架的一个理想副作用是，它将引导你提升组织的安全态势。

可追踪性和细节

综合器 prompt 强制明确的源属性。应急方案中的每条建议都带有标签：

• (Source: Playbook) ——来自匹配的参考应急手册
• (Source: Internal precedent — [incident ID]) ——来自特定的历史事件
• (Source: External intel) ——基于 Tavily 检索
• [General knowledge — not sourced from inputs] ——没有组织或外部来源

第四种可能需要解释。agent 被指示不压制让输出更有用的通用知识。它被指示诚实地标签。读者知道什么是组织先例，什么是模型补充的。

还有显式的无匹配处理。如果没有充分匹配的历史事件，应急方案会明确说出来。它不会从空白状态产生高置信度指导并隐瞒这个事实。

在数据库写入前，输出通过结构化 schema 验证。必需键必须存在且非空。Schema 验证失败→错误通知。不会无声地写入格式错误的应急方案。

如何测试

最简单的测试方法是使用我们构建的 UI：https://incident-response.deployed.engineer。这允许你向工作流发送 JSON 有效负载（我们在 n8n cloud 上托管）。每个请求都有 LLM 成本，所以我们要求你从 OpenRouter 获取密钥，用于 LLM 调用。每次运行成本约为一两美元。

该工作流在 n8n 上作为模板提供，用于在你自己的实例上设置。你需要四个凭证：Supabase、Google AI Studio（用于 Gemini embeddings）或类似的、OpenRouter 或类似的，以及可选的 Tavily。所有都有免费层级。详细文档可在 Github 上获取。

安装花费约 30 分钟，大部分时间是等待摄取。示例数据中包含 13 个测试事件，涵盖勒索软件、钓鱼、暴力破解、S3 配置错误和内部威胁。Test-ransomware_detection-001 是最好的起点——它有强的应急手册匹配、强的历史匹配，生成一份标签良好的应急方案供你端到端检查。

→ 导入工作流模板

未来演进方向

今天呈现的框架已被设计为使 SMB 和企业 SOC 能够快速解决他们最紧迫的自动化优先级。但我们相信这仅仅是开始。在像你这样的贡献者和真实世界测试的帮助下，我们相信框架将如下演进：

自主丰富。 agent 能运行的低风险丰富和通知工作流。例子包括当检测到可疑登录位置时向用户经理发送电子邮件或执行 VirusTotal 哈希查询。低风险丰富使用 n8n 的"From AI"函数自动运行。丰富工作流保持确定性性质，只有是否调用它们的决策和要传递给工作流的（锁定）参数由 agent 决定。

修复和通知工作流——人工或 AI 触发。 另一方面，任何有真实世界后果的事情都需要人工批准。离散的子工作流——隔离端点、在防火墙上阻止 IP——从应急方案"立即响应清单"中的 webhook 链接触发。分析师审查，如果同意则点击，n8n 执行。严格的人工边界，更快的修复配合确定性工作流。

立即开始

核心框架已准备好供你尝试：

• 快速演示请访问 UI
• Github 上有详细的实现说明供你在自己的环境中部署

我们欢迎使用 Github issues 的贡献、讨论和反馈。如需白手套级别的支持，如果你是网络安全分析师或经理，可以在这里联系我们。

参考资料： (1) https://www.msspalert.com/news/criticalstart-findings

(2) https://cyberfuturists.com/when-marketing-fails

n8n 的用户来自广泛的背景、经验水平和兴趣。我们一直在寻求在博客文章中突出不同的用户及其项目。如果你在使用 n8n，并想启发社区，请联系我们 💌