大家好!歡迎來到鐵人賽第二十四天。
在過去的 23 天裡,我們成功打造了一套功能強大的 SOAR 系統。為了實現這些自動化,我們串接了各式各樣的外部服務與底層基礎設施,包括 LINE Messaging API、VirusTotal、Google Workspace、Gemini AI,以及直接連線到伺服器執行防禦的 SSH 節點。
這意味著,我們的工作流中包含了大量的 API Keys、Access Tokens、密碼與私鑰。如果在開發初期為了方便,我們將這些機密資訊直接「寫死(Hardcode)」在 HTTP Request 的欄位或 Code 節點的程式碼中,這將會產生極大的資安風險。一旦工作流(JSON 格式)被匯出、備份或不慎分享到 GitHub,所有的金鑰都會以明文形式直接外洩。
因此,今天我們要進行一次全面的「架構資安體檢」,實作 n8n 內建的 Credentials(憑證管理) 機制,將所有敏感資訊抽離畫布,進行加密集中儲存。
在 n8n 中,Credentials 是一個獨立於工作流(Workflow)之外的保險箱系統。當你在 n8n 中建立一筆憑證時,系統會在後端資料庫將其加密。
工作流在執行時,只會「參照(Reference)」這個憑證的 ID,而不會在畫布介面上顯示真實的金鑰內容。這樣一來,即使你將整個 n8n 畫布匯出成 JSON 檔交給其他同事,裡面的金鑰資訊也會被自動剝離,確保安全。
我們以 Day 19 實作的 VirusTotal 情資查詢為例。當時我們在 HTTP Request 節點的 Headers 中,直接輸入了 x-apikey 與真實的 API Key。現在我們要把這個做法改掉。
Header Auth 並選擇它(因為 VirusTotal 是透過 Header 驗證)。VirusTotal API Key。x-apikey
HTTP Request 節點。x-apikey 參數整行刪除。Predefined Credential Type。Header Auth。VirusTotal API Key。設定完成後,這張卡片上再也看不到明文的 API Key,但執行時依然能順利取得 VirusTotal 的情資。
在 Day 18 的聯防機制中,我們使用了 SSH 節點連線到 Web-01 與 DB-01 下達防火牆指令。伺服器的最高權限如果不妥善管理,將成為最大的災難。
實務上,強烈建議不要使用帳號密碼(Password)進行自動化 SSH 連線,而是改用 SSH 私鑰(Private Key)。
SecOps_Ubuntu_SSH_Key。Private Key。ubuntu)、主機位址。.pem 或 id_rsa 私鑰內容,完整貼到 Private Key 欄位中。如有設定 Passphrase 也一併填入,然後存檔。SSH 節點。SecOps_Ubuntu_SSH_Key。前幾天我們在串接 Google Sheets(建立工單)、Google Drive(日誌封存)、Gmail(釣魚信監控)時,都是使用 OAuth2 進行授權。
你可以回到 Credentials 介面,統一檢視這些授權狀態。
LINE Channel Access Token,所有引用到該憑證的 HTTP Request 節點就會自動套用新金鑰,不需要到龐大的畫布中一個一個節點慢慢修改。這大幅降低了維運的成本與出錯率。今天我們沒有增加新的自動化功能,而是為現有的 SOAR 系統打好了最堅實的資安地基。
我們成功將散落在畫布各處的 API Key、私鑰與 Token,全數轉移到 n8n 專屬的憑證管理中心進行加密儲存。這不僅符合資安最佳實踐(Best Practices),也讓未來的工作流轉移、備份與團隊協作變得更加安全可靠。
目前我們的系統已經非常聰明且安全,但如果連線過程中發生網路異常,或是外部 API 剛好維護中,整個流程就會卡死報錯。明天(Day 25),我們將邁入系統穩健度(Robustness)的優化,實作「錯誤處理機制(Error Handling)」與異常通報,讓你的 SOAR 系統不再因為小小的網路斷線而全面停擺!我們明天見。