委任啟動流程指南
中級4 分鐘閱讀更新於 2026-03-15
啟動 AI 紅隊委任的逐步指南:客戶初次會議、範圍界定、交戰規則、法律協議、環境設置與工具選擇。
啟動階段為後續一切奠定基礎。略過或趕工啟動會導致範圍蔓延、法律曝險、錯失攻擊面,以及無法回應客戶真正關切之報告。徹底的啟動通常需一到三天,產出三份關鍵文件:範圍界定、交戰規則,以及環境存取計畫。
步驟 1:初次會議
會議議程
將第一次客戶會議圍繞下列主題組織:
- 系統概觀(30 分鐘)—— AI 系統做什麼?誰使用?處理何種資料?
- 架構審視(30 分鐘)—— 涉及哪些模型、API、框架與基礎設施元件?
- 安全關切(20 分鐘)—— 何事使客戶徹夜難眠?是否曾有事件?
- 合規需求(15 分鐘)—— 適用哪些法規或標準?(EU AI Act、NIST AI RMF、產業特定規則)
- 委任後勤(15 分鐘)—— 時程、聯絡人、存取、溝通管道
要問的關鍵問題
關於系統:
- 部署了哪些模型?(供應商、版本、微調或基礎?)
- 系統提示是靜態或動態產生?
- 系統是否具工具呼叫、函式呼叫或代理能力?
- 連接了哪些外部資料來源(RAG、資料庫、API)?
- 目前有哪些 guardrail 或安全層?
關於威脅模型:
- 預期使用者為誰?(員工、客戶、公眾?)
- 何者構成嚴重安全事件?
- 客戶最擔憂的特定攻擊情境是否有?
- 系統先前是否經測試?結果為何?
關於限制:
- 是否有不得觸及之模型、端點或環境?
- 是否有不得測試之時段?(生產時段、維護視窗)
- 可接受的測試流量速率為何?
- 測試期間若發現關鍵漏洞,應通知誰?
步驟 2:範圍界定
範圍文件
建立清晰之範圍文件,回答:測試什麼、不測試什麼、成功長什麼樣子。
# AI 紅隊委任範圍
## 客戶:[客戶名稱]
## 日期:[日期]
## 紅隊負責人:[姓名]
## 範圍內目標
1. chat.example.com 上面向客戶之聊天機器人
- 模型:經 Azure OpenAI 之 GPT-4o
- 系統提示:由客戶提供(見附錄 A)
- 連接工具:訂單查詢 API、FAQ 檢索(RAG)
2. knowledge.internal.example.com 上之內部知識助理
- 模型:經 Anthropic API 之 Claude Sonnet
- 系統提示:依使用者角色動態產生
- 連接工具:Confluence 搜尋、Jira 工單建立
## 範圍外
- 訓練資料與微調管線
- 基礎設施(雲端帳號、網路、伺服器)
- 原始碼審查(除非具體影響提示邏輯)
- 第三方模型供應商基礎設施(OpenAI、Anthropic)
- 對客戶員工之社交工程
## 測試類別
- [ ] 提示注入(直接與間接)
- [ ] Jailbreak 與內容政策繞過
- [ ] 系統提示擷取
- [ ] 經由模型之資料外洩
- [ ] 工具/函式呼叫濫用
- [ ] RAG 投毒(若可寫入之知識庫在範圍內)
- [ ] 驗證與授權繞過
- [ ] 速率限制與濫用潛力
## 成功標準
- 所有範圍內類別皆測試並有結果文件
- 發現依嚴重度評級(Critical、High、Medium、Low、Informational)
- 為每個發現提供補救建議
- 測試完成後 5 個工作日內遞交最終報告
## 時程
- 啟動:[日期]
- 測試視窗:[開始日期] 至 [結束日期]
- 報告草稿:[日期]
- 最終報告:[日期]常見範圍陷阱
| 陷阱 | 問題 | 解方 |
|---|---|---|
| 「全部測」 | 無界範圍導致無焦點測試 | 列出具體端點、模型與類別 |
| 遺漏 RAG 來源 | 經由知識庫內容之間接注入被漏掉 | 明確納入或排除 RAG 資料來源 |
| 忽略工具呼叫 | 函式呼叫濫用是關鍵攻擊向量 | 列出模型可呼叫之所有工具/函式 |
| 未記錄排除項 | 不清楚哪些不可測 | 務必具明確之範圍外章節 |
步驟 3:交戰規則(ROE)
ROE 文件
# 交戰規則
## 授權
本文件授權 [紅隊] 針對 [日期] 範圍文件所列目標
進行 AI 安全測試,並由 [獲授權客戶代表] 簽署。
## 測試邊界
1. 測試僅限範圍文件所列目標
2. 不得進行拒絕服務攻擊或蓄意服務中斷
3. 未經明確核准不得修改生產資料
4. 不得於同意時段之外進行測試:[視窗]
5. API 請求速率不得超過每分鐘 [X] 次
## 資料處理
1. 所有測試資料與發現皆為機密
2. 可收集螢幕截圖與回應日誌作為證據
3. 測試期間擷取之客戶資料,委任結束後不得保留
4. 證據將加密儲存並於 [保留期] 後銷毀
## 溝通
- 主要聯絡:[姓名、email、電話]
- 緊急聯絡:[姓名、email、電話]
- 狀態更新:每日經 [管道]
- 關鍵發現:經 [管道] 立即通知
## 關鍵發現流程
若發現關鍵漏洞:
1. 確認漏洞後立即停止利用
2. 以最小再現證據記錄該發現
3. 1 小時內通知客戶緊急聯絡
4. 不進一步利用該關鍵發現
5. 繼續測試其他範圍內目標
## 法律
- 本委任受 [主服務合約/SOW] 規範
- 測試僅於所指定期間與範圍內獲授權
- 紅隊不會蓄意存取、修改或外洩超過展示漏洞所需之真實使用者資料ROE 協商提示
客戶有時會對 ROE 某些面向提出異議。常見協商點:
「我們希望你測試生產」 —— 若 ROE 含速率限制、時段與中止條款則可接受。對破壞性測試堅持採預備環境。
「可否在週末測試?」 —— 確保客戶端有人可回應關鍵發現。
「我們不想你測試 [類別]」 —— 明確記錄排除項。於最終報告註明該類別未評估。
步驟 4:環境設置
存取檢查清單
測試開始前,確認你已取得:
- 所有範圍內端點之 API 金鑰或憑證
- 系統提示文件或擷取管道
- 有效請求與預期回應範例
- 測試期間值班支援之聯絡資訊
- 若測試內部系統則需 VPN 存取
- 預備/沙箱環境存取(若可用)
- 任何監控儀表板之存取(以觀察你的測試流量)
測試環境組態
# 建立專屬專案目錄
mkdir -p engagement-[client-name]/
cd engagement-[client-name]/
# 設定環境變數
cat > .env << 'EOF'
# 客戶 API 憑證
TARGET_API_KEY=provided-by-client
TARGET_BASE_URL=https://api.example.com
# 攻擊者模型憑證(給 PyRIT 等)
OPENAI_API_KEY=your-openai-key
# 委任 metadata
ENGAGEMENT_ID=ENG-2026-001
CLIENT_NAME=Example Corp
EOF
# 建立目錄結構
mkdir -p evidence/ reports/ configs/ logs/ payloads/
# 初始化工具
# (假設依工具流程指南所述,每個工具使用虛擬環境)步驟 5:工具選擇
依委任範圍配對工具:
| 委任類型 | 主要工具 | 次要工具 |
|---|---|---|
| 提示層評估 | Promptfoo、Garak | Ollama(本地測試) |
| 全棧 AI 評估 | PyRIT、Burp Suite、Promptfoo | Garak、客製 Python |
| 代理系統評估 | PyRIT、客製 Python | Burp Suite、Promptfoo |
| 合規評估 | Inspect AI、Promptfoo | Garak |
| 持續紅隊 | Promptfoo(CI/CD)、Garak | 客製自動化 |
委任前工具驗證
測試視窗開啟前,驗證所有工具皆可觸及目標:
# 測試 API 連通性
curl -s https://api.example.com/health -H "Authorization: Bearer $TARGET_API_KEY"
# 以 garak 測試
garak --model_type rest --model_name target --probes test.Blank
# 以 promptfoo 測試
promptfoo eval --config configs/connectivity-test.yaml
# 測試本地環境
ollama run llama3.1:8b "Connection test"步驟 6:啟動交付清單
於進入偵察階段前,確認所有啟動交付已完成:
- 雙方簽署範圍文件
- 獲授權客戶代表簽署交戰規則
- 已取得並驗證 API 憑證
- 測試環境已組態並驗證連通性
- 工具已安裝、組態,並對目標測試
- 溝通管道已建立
- 緊急聯絡資訊已記錄
- 時程已議定並已發送行事曆邀約
- NDA 或保密協議已就位
相關主題
Knowledge Check
於開始任何 AI 紅隊測試前,最重要的待簽署文件為何?