iT邦幫忙

2026 iThome 鐵人賽

DAY 24
0
AI 自動化

從漏洞告警到 AI 決策:Wazuh × RAG × n8n 實作自動化資安漏洞驗證與智慧通報系列 第 24 篇

Day 24 | 守護自動化的心臟 :實作 n8n 憑證與金鑰安全管理

  • 分享至 

  • xImage
  •  

大家好!歡迎來到鐵人賽第二十四天。

在過去的 23 天裡,我們成功打造了一套功能強大的 SOAR 系統。為了實現這些自動化,我們串接了各式各樣的外部服務與底層基礎設施,包括 LINE Messaging API、VirusTotal、Google Workspace、Gemini AI,以及直接連線到伺服器執行防禦的 SSH 節點。

這意味著,我們的工作流中包含了大量的 API Keys、Access Tokens、密碼與私鑰。如果在開發初期為了方便,我們將這些機密資訊直接「寫死(Hardcode)」在 HTTP Request 的欄位或 Code 節點的程式碼中,這將會產生極大的資安風險。一旦工作流(JSON 格式)被匯出、備份或不慎分享到 GitHub,所有的金鑰都會以明文形式直接外洩。

因此,今天我們要進行一次全面的「架構資安體檢」,實作 n8n 內建的 Credentials(憑證管理) 機制,將所有敏感資訊抽離畫布,進行加密集中儲存。


憑證管理 (Credential Management) 的核心概念

在 n8n 中,Credentials 是一個獨立於工作流(Workflow)之外的保險箱系統。當你在 n8n 中建立一筆憑證時,系統會在後端資料庫將其加密。
工作流在執行時,只會「參照(Reference)」這個憑證的 ID,而不會在畫布介面上顯示真實的金鑰內容。這樣一來,即使你將整個 n8n 畫布匯出成 JSON 檔交給其他同事,裡面的金鑰資訊也會被自動剝離,確保安全。


第一步:遷移 VirusTotal API Key 至獨立憑證

我們以 Day 19 實作的 VirusTotal 情資查詢為例。當時我們在 HTTP Request 節點的 Headers 中,直接輸入了 x-apikey 與真實的 API Key。現在我們要把這個做法改掉。

  1. 建立憑證:
  • 點擊 n8n 左側導覽列的 Credentials。
  • 點擊右上角的 Add Credential。
  • 在搜尋框輸入 Header Auth 並選擇它(因為 VirusTotal 是透過 Header 驗證)。
  • 將這個憑證命名為 VirusTotal API Key。
  • Name: 輸入 x-apikey
  • Value: 貼上你真實的 VirusTotal API Key。
  • 點擊 Save。
  1. 套用憑證至工作流:
  • 回到你的 SOAR 工作流,打開負責查詢 VirusTotal 的 HTTP Request 節點。
  • 將原本寫在 Headers 區塊的 x-apikey 參數整行刪除。
  • 往上拉找到 Authentication 欄位。
  • 將設定改為 Predefined Credential Type。
  • Credential Type 選擇 Header Auth。
  • Credential 下拉選單選擇你剛剛建立的 VirusTotal API Key。

設定完成後,這張卡片上再也看不到明文的 API Key,但執行時依然能順利取得 VirusTotal 的情資。


第二步:強化 SSH 連線的安全認證

在 Day 18 的聯防機制中,我們使用了 SSH 節點連線到 Web-01 與 DB-01 下達防火牆指令。伺服器的最高權限如果不妥善管理,將成為最大的災難。

實務上,強烈建議不要使用帳號密碼(Password)進行自動化 SSH 連線,而是改用 SSH 私鑰(Private Key)。

  1. 建立 SSH 憑證:
  • 進入左側的 Credentials ➡ Add Credential。
  • 搜尋並選擇 SSH / SFTP。
  • 命名為 SecOps_Ubuntu_SSH_Key。
  • Authentication Method:選擇 Private Key。
  • 依序填入登入使用者名稱(如 ubuntu)、主機位址。
  • 將你的 .pem 或 id_rsa 私鑰內容,完整貼到 Private Key 欄位中。如有設定 Passphrase 也一併填入,然後存檔。
  1. 套用至 SSH 節點:
  • 回到畫布打開 SSH 節點。
  • 將 Credential for SSH 指定為剛剛建立的 SecOps_Ubuntu_SSH_Key。
  • 這樣一來,私鑰將被妥善加密儲存於 n8n 資料庫,不會暴露在工作流的配置中。

第三步:集中管理 Google 與 LINE 授權

前幾天我們在串接 Google Sheets(建立工單)、Google Drive(日誌封存)、Gmail(釣魚信監控)時,都是使用 OAuth2 進行授權。

你可以回到 Credentials 介面,統一檢視這些授權狀態。

  • 如果某個服務的 Token 過期,或是負責管理 LINE 官方帳號的同事離職,你只需要在 Credentials 介面更新一次 LINE Channel Access Token,所有引用到該憑證的 HTTP Request 節點就會自動套用新金鑰,不需要到龐大的畫布中一個一個節點慢慢修改。這大幅降低了維運的成本與出錯率。

今天的成果

今天我們沒有增加新的自動化功能,而是為現有的 SOAR 系統打好了最堅實的資安地基。

我們成功將散落在畫布各處的 API Key、私鑰與 Token,全數轉移到 n8n 專屬的憑證管理中心進行加密儲存。這不僅符合資安最佳實踐(Best Practices),也讓未來的工作流轉移、備份與團隊協作變得更加安全可靠。

目前我們的系統已經非常聰明且安全,但如果連線過程中發生網路異常,或是外部 API 剛好維護中,整個流程就會卡死報錯。明天(Day 25),我們將邁入系統穩健度(Robustness)的優化,實作「錯誤處理機制(Error Handling)」與異常通報,讓你的 SOAR 系統不再因為小小的網路斷線而全面停擺!我們明天見。


上一篇
Day 23 | 降低維運疲勞 — 實作 SOAR 誤報過濾與動態白名單機制
系列文
從漏洞告警到 AI 決策:Wazuh × RAG × n8n 實作自動化資安漏洞驗證與智慧通報 共 24 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言