1. 安全運(yùn)營里的真實(shí)痛點(diǎn)告警太多、攻擊鏈看不清安全運(yùn)營中心SOC每天面對的現(xiàn)實(shí)是EDR、防火墻、郵件網(wǎng)關(guān)、身份系統(tǒng)各吐各的告警一個勒索軟件事件可能在 6 個索引里留下 40 條獨(dú)立告警但值班分析師看到的只是「PowerShell 編碼命令執(zhí)行」「LSASS 訪問」「卷影副本刪除」三條互不相干的記錄。Elastic Security 的 Attack Discovery 功能解決的正是這個問題——它把多條安全告警喂給 LLM讓模型自動識別跨告警的攻擊鏈輸出帶時間線和 MITRE 戰(zhàn)術(shù)映射的敘述性報告。但這里有個很多人踩過的坑Attack Discovery 不是裝好就自動跑的后臺服務(wù)。你在 Kibana 里配好了 AI Connector、測試返回 pong、許可證也正常索引.alerts-security.attack.discovery.alerts-default卻始終是 0 條文檔。原因很簡單——調(diào)度Schedule是獨(dú)立對象不顯式創(chuàng)建就永遠(yuǎn)不會觸發(fā) LLM 分析。這篇內(nèi)容面向做安全運(yùn)營、想把攻擊鏈分析流程自動化的工程師。我會用 Claude Code 配合 Elastic AI Agent Builder MCP把「創(chuàng)建調(diào)度 → 立即觸發(fā) → 查詢攻擊鏈 → 溯源原始告警」整條鏈路走通同時給出 TaoToken 統(tǒng)一 Key/API 通道的配置片段讓模型調(diào)用走同一個入口省去在多個 provider 之間來回切換的麻煩。適合誰手上已有 Elastic 9.x 集群、想讓 Claude Code 直接對話式操作 Elastic Security、又不想每次翻 API 文檔的人。整個流程的核心只有三步創(chuàng)建調(diào)度、手動觸發(fā)、用 ES|QL 查結(jié)果并關(guān)聯(lián)原始告警。下面按可跟做的順序展開。2. TaoToken 前置準(zhǔn)備統(tǒng)一 Key 與 API 通道在動手配 MCP 之前先把模型調(diào)用這一層理順。Claude Code 本身要調(diào)模型Elastic Attack Discovery 背后的 Connector 也要調(diào)模型如果兩邊各配一套 Key、各記一個 Base URL排障時很容易搞混是誰的憑證失效了。我的做法是統(tǒng)一走 TaoToken 的 API 通道一個 Key、一個 Base URLClaude Code 和 Elastic Connector 都指向它。官網(wǎng)入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端點(diǎn)是 https://taotoken.net/api 這個不加 UTM直接作為 Base URL 用。注冊后在控制臺的 API Keys 頁面生成一個 Key形如sk-開頭的一串字符復(fù)制下來先存到環(huán)境變量里別直接寫進(jìn)配置文件提交到倉庫。export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api這里要區(qū)分兩個概念很多人第一次配會混。Claude Code 用的 Base URL是給 Anthropic 兼容協(xié)議用的通常要在后面拼上版本路徑Elastic Connector 用的 Base URL是 OpenAI 兼容協(xié)議走/v1這一層。兩者指向同一個域名只是路徑不同。你可以在 TaoToken 的模型對話頁面先驗證 Key 是否可用再往下配。關(guān)于模型選擇Claude Code 側(cè)我一般用 claude-sonnet 系列做代碼和工具調(diào)用Elastic Attack Discovery 側(cè)的 Connector 可以用同一通道下的其他模型比如 qwen 系列或 gpt 系列因為 Attack Discovery 對模型的要求是「能讀懂多條告警并做歸納」不一定非要最強(qiáng)的編碼模型。統(tǒng)一通道的好處是賬單和限流在一個地方看出問題只查一處。注意Key 只存在服務(wù)端環(huán)境變量或密鑰管理里不要寫進(jìn) MCP 的 JSON 配置明文后提交 Git。下面示例里我用${TAOTOKEN_API_KEY}占位實(shí)際運(yùn)行時由 shell 展開。配好之后建議先做一次最小連通性測試確認(rèn) Key 和 Base URL 都對再進(jìn)入 MCP 配置環(huán)節(jié)。測試命令用 curl 打一個模型列表或最小對話請求即可返回 200 且結(jié)構(gòu)正常就說明通道沒問題。這一步花兩分鐘能省掉后面「到底是 MCP 配錯了還是 Key 失效了」的反復(fù)排查。3. 可復(fù)制配置MCP 服務(wù)端與 Claude Code 客戶端這一節(jié)是全文最需要照著抄的部分。Elastic AI Agent Builder MCP 的本質(zhì)是把 Elastic 的 API 能力包裝成 MCP 工具讓 Claude Code 能通過對話調(diào)用。配置分兩處MCP 服務(wù)端的啟動參數(shù)以及 Claude Code 客戶端的settings.json或 MCP 注冊配置。先看 MCP 服務(wù)端。Elastic 官方提供了 MCP server 的啟動方式核心是三個環(huán)境變量Elasticsearch 地址、認(rèn)證信息、以及是否跳過自簽名證書校驗本地或測試集群常見。如果你用的是 9.x 自建集群且證書是自簽的ELASTICSEARCH_INSECUREtrue必須開否則連接會直接失敗。# MCP 服務(wù)端啟動參數(shù)示例按你的集群地址替換 export ELASTICSEARCH_URLhttps://localhost:9200 export ELASTICSEARCH_USERNAMEelastic export ELASTICSEARCH_PASSWORD你的密碼 export ELASTICSEARCH_INSECUREtrue # 自簽名證書時開啟 export KIBANA_URLhttp://localhost:5601然后是 Claude Code 客戶端的 MCP 注冊配置。Claude Code 讀取的配置文件通常在用戶目錄下的.claude/settings.json或項目級.mcp.json具體路徑以你本地版本為準(zhǔn)。下面這段是可直接復(fù)制的 JSON 片段注意command和args要指向你實(shí)際安裝的 MCP server 入口env里把上面那些變量帶進(jìn)去同時把 TaoToken 的 Key 和 Base URL 也注入保證 MCP 內(nèi)部若需要調(diào)模型時走統(tǒng)一通道。{ mcpServers: { elastic-agent-builder: { command: npx, args: [-y, elastic/mcp-server-elasticsearch], env: { ELASTICSEARCH_URL: https://localhost:9200, ELASTICSEARCH_USERNAME: elastic, ELASTICSEARCH_PASSWORD: ${ELASTIC_PASSWORD}, ELASTICSEARCH_INSECURE: true, KIBANA_URL: http://localhost:5601, OPENAI_BASE_URL: https://taotoken.net/api/v1, OPENAI_API_KEY: ${TAOTOKEN_API_KEY} } } } }如果你用的是 Cline 或 CC Switch 這類客戶端來管理 MCP配置結(jié)構(gòu)大同小異關(guān)鍵是三件套齊全Base URL、Key、Model ID。Base URL 填https://taotoken.net/api/v1Key 填你的sk-憑證Model ID 填你在 TaoToken 控制臺看到的模型標(biāo)識比如claude-sonnet-4-6或qwen3.5-plus。三件套缺一個調(diào)用就會報 401 或 model not found。Elastic 側(cè)的 AI Connector 也要配一份因為 Attack Discovery 的調(diào)度參數(shù)里要引用connectorId。在 Kibana 里創(chuàng)建 Connector 時選 OpenAI 類型Base URL 同樣填 TaoToken 的/v1地址Key 填同一個模型填你選定的 Model ID。創(chuàng)建完記下返回的 connector id后面創(chuàng)建調(diào)度要用。# 驗證 Connector 是否可用把 ID 換成你的 curl -sk -u elastic:${ELASTIC_PASSWORD} \ -X POST http://localhost:5601/api/actions/connector/${CONNECTOR_ID}/_execute \ -H kbn-xsrf: true -H Content-Type: application/json \ -d {params:{subAction:invokeAI,subActionParams:{messages:[{role:user,content:ping}]}}}返回里帶status:ok和模型回復(fù)內(nèi)容說明 Connector 通了。這一步不通后面創(chuàng)建調(diào)度也是白搭因為 Attack Discovery 觸發(fā)時會用這個 Connector 去調(diào)模型。4. 驗證請求與成功結(jié)果從創(chuàng)建調(diào)度到攻擊鏈查詢配置通了之后進(jìn)入真正的攻擊鏈分析流程。我按實(shí)際操作順序走一遍每步都給命令和預(yù)期返回結(jié)構(gòu)。第一步確認(rèn) Attack Discovery 索引狀態(tài)。先看索引存不存在、有多少文檔。如果 count 為 0說明從未運(yùn)行過這是后面要創(chuàng)建調(diào)度的信號。curl -sk -u elastic:${ELASTIC_PASSWORD} \ https://localhost:9200/.alerts-security.attack.discovery.alerts-default/_count # 預(yù)期{count:0,_shards:{...}}第二步創(chuàng)建 Attack Discovery 調(diào)度。這是整個流程的關(guān)鍵不創(chuàng)建就永遠(yuǎn)不會有結(jié)果。參數(shù)里alerts_index_pattern指向原始告警索引api_config引用上一步的 Connectorsize控制喂給 LLM 的告警條數(shù)建議 100~200太大容易超 Token 限制start/end是分析時間窗。curl -sk -u elastic:${ELASTIC_PASSWORD} \ -X POST http://localhost:5601/api/attack_discovery/schedules \ -H kbn-xsrf: true -H Content-Type: application/json \ -d { name: 每日安全攻擊分析, enabled: true, params: { alerts_index_pattern: .alerts-security.alerts-default, api_config: { actionTypeId: .gen-ai, connectorId: ${CONNECTOR_ID}, model: qwen3.5-plus, provider: OpenAI }, size: 100, start: now-30d, end: now }, schedule: {interval: 24h}, actions: [] } # 預(yù)期返回含 id:schedule-id記下來第三步立即觸發(fā)一次。不想等 24 小時調(diào)度周期用_run_soon手動跑。注意這個接口需要x-elastic-internal-origin頭否則會被拒。curl -sk -u elastic:${ELASTIC_PASSWORD} \ -X POST http://localhost:5601/internal/alerting/rule/${SCHEDULE_ID}/_run_soon \ -H kbn-xsrf: true -H x-elastic-internal-origin: Kibana # 預(yù)期Rule is already running 或觸發(fā)成功提示第四步查詢攻擊鏈結(jié)果。分析完成后用 ES|QL 查 open 狀態(tài)的攻擊發(fā)現(xiàn)。返回結(jié)構(gòu)里重點(diǎn)看title、summary_markdown、details_markdown、mitre_attack_tactics四個字段。FROM .alerts-security.attack.discovery.alerts-default METADATA _id | WHERE timestamp NOW() - 24 hours AND kibana.alert.workflow_status open | KEEP _id, kibana.alert.attack_discovery.title, kibana.alert.attack_discovery.summary_markdown, kibana.alert.attack_discovery.details_markdown, kibana.alert.attack_discovery.mitre_attack_tactics | SORT timestamp DESC | LIMIT 20一次成功的返回會長這樣title是「Ransomware Attack Chain」這類歸納名details_markdown里是帶時間戳的攻擊步驟敘述比如「WINWORD.EXE 派生 powershell.exe 執(zhí)行編碼命令 → 建立 C2 連接 → rundll32 轉(zhuǎn)儲 LSASS 憑證 → vssadmin 刪除卷影副本 → 批量加密文件 → 投放勒索信」。mitre_attack_tactics會映射到 Execution、Credential Access、Impact 等戰(zhàn)術(shù)。第五步溯源原始告警。拿到攻擊發(fā)現(xiàn)后用_id關(guān)聯(lián)回原始告警索引還原完整時間線。這一步是把 LLM 的歸納落回可驗證的原始證據(jù)。FROM .alerts-security.alerts-default METADATA _id | WHERE _id IN (D11_kJ0Bb_T067uw3Wd2, Dl1_kJ0Bb_T067uw3Wd2) | KEEP _id, kibana.alert.original_time, kibana.alert.rule.name, host.name, user.name, process.name, process.command_line, process.parent.name | SORT kibana.alert.original_time ASC預(yù)期返回是按時間升序的告警序列process.parent.name能拼出進(jìn)程父子樹process.command_line里能看到編碼命令和 C2 地址。到這一步一條從「告警太多」到「攻擊鏈清晰」的閉環(huán)就走完了。5. 常見報錯排查401、local proxy failed、reading choices實(shí)操中卡住的地方基本集中在幾個固定報錯上我按出現(xiàn)頻率排一下每個都給定位思路。401 Unauthorized。兩種可能TaoToken 的 Key 失效或沒注入或者 Elastic 的認(rèn)證信息錯了。先分清是哪一層——如果 Claude Code 對話時直接報 401查OPENAI_API_KEY環(huán)境變量是否被 shell 正確展開${TAOTOKEN_API_KEY}在 JSON 里不會自動展開要確認(rèn)客戶端支持變量替換否則直接寫值但別提交。如果是創(chuàng)建調(diào)度時報 401查elastic用戶密碼和 Connector 的 Key。用前面那條_execute測試命令單獨(dú)驗證 Connector能快速定位。local proxy failed。這個報錯通常出現(xiàn)在 MCP 客戶端連不上 MCP server 時本質(zhì)是本地進(jìn)程沒起來或端口不通。檢查command和args指向的包是否已安裝npx -y首次運(yùn)行會下載網(wǎng)絡(luò)慢時會超時以及ELASTICSEARCH_URL是否可達(dá)。自建集群如果開了自簽名證書但沒設(shè)ELASTICSEARCH_INSECUREtrue連接會在 TLS 握手階段失敗表現(xiàn)也類似代理失敗。用curl -sk先手動打一下 ES 的根路徑確認(rèn)網(wǎng)絡(luò)層通。reading choices 相關(guān)報錯。這類錯誤一般來自模型返回結(jié)構(gòu)不符合預(yù)期常見于 Base URL 拼錯比如漏了/v1導(dǎo)致請求打到了非 OpenAI 兼容端點(diǎn)返回的是 HTML 或錯誤 JSON解析choices字段時就崩了。核對 Base URL 是否為https://taotoken.net/api/v1Model ID 是否在 TaoToken 控制臺存在。另外size設(shè)太大導(dǎo)致上下文超限時也可能在解析階段報錯把size降到 100 再試。OAuth 相關(guān)報錯。如果你用的客戶端默認(rèn)走 OAuth 流程而你的通道是 API Key 模式會提示授權(quán)失敗。在客戶端配置里顯式指定 API Key 認(rèn)證方式別讓它自動探測。CC Switch 這類工具里通常有「認(rèn)證方式」下拉選 API Key 并填三件套。調(diào)度創(chuàng)建成功但索引仍為 0。檢查調(diào)度是否enabled: true以及_run_soon是否真的觸發(fā)了。有時返回「Rule is already running」是因為上一次還在跑等幾分鐘再查。另外確認(rèn)alerts_index_pattern指向的索引里確實(shí)有數(shù)據(jù)空告警喂給 LLM 也不會有輸出。報錯最可能原因快速驗證401Key 未注入/失效單獨(dú)跑_execute測試local proxy failedMCP server 未啟動/證書curl -sk打 ES 根路徑reading choicesBase URL 缺/v1核對端點(diǎn)與 Model IDOAuth 失敗認(rèn)證方式選錯客戶端改 API Key 模式6. 把流程固化成日常調(diào)度參數(shù)與后續(xù)動作跑通一次之后真正有價值的是把它變成日常運(yùn)營的一部分。調(diào)度參數(shù)里schedule.interval建議按告警量設(shè)告警多的環(huán)境用1h或6h少的用24h足夠size控制在 100~200既能讓 LLM 看到足夠上下文又不至于超 Token。actions字段可以配置分析完成后的通知比如寫入 Elastic Cases 或推送到協(xié)作工具這樣分析師不用盯著索引等結(jié)果。我自己的習(xí)慣是保留一份調(diào)度管理 API 的速查方便隨時查狀態(tài)、改參數(shù)、臨時觸發(fā)。常用的就幾個GET /api/attack_discovery/schedules/_find列所有調(diào)度POST .../_run_soon手動觸發(fā)PUT改參數(shù)DELETE清理廢棄調(diào)度。配合 Claude Code 的對話能力這些操作可以直接用自然語言描述讓模型生成命令省去翻文檔。需要提醒的是Attack Discovery 的輸出是 LLM 歸納結(jié)果details_markdown里的時間線和進(jìn)程關(guān)系要回到原始告警用 ES|QL 驗證別直接當(dāng)結(jié)論用。把「LLM 歸納 原始證據(jù)溯源」當(dāng)成固定動作分析質(zhì)量才穩(wěn)得住。如果你想把模型調(diào)用和 MCP 配置再簡化可以從 API Keys 頁面統(tǒng)一管理憑證https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入細(xì)節(jié)看文檔https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。長期做編碼和 Agent 類任務(wù)的話Coding Plan 能把額度集中管理https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。先把調(diào)度建起來、觸發(fā)一次、查到第一條攻擊鏈?zhǔn)Ｏ碌木褪钦{(diào)參數(shù)和接通知了。