機構區塊鏈滲透測試的交戰規則與生產安全

本系列的前兩篇文章闡述了加密機構為何需要區塊鏈滲透測試（第一部分）以及該學科的內容為何（第二部分）。本文將探討如何安全地準備和執行機構層級的測試工作：交戰規則、生產安全保障措施，以及將發現轉化為修復的補救與重測——如下方所示的測試生命週期。

Web3以特定方式提高了生產環境測試的風險：鏈上操作通常不可逆轉，測試活動通常在鏈上公開可見，而範圍內的系統可以移動真實資金。因此，以下保障措施相較於傳統測試工作，更著重於環境選擇、價值限額、金鑰管理和對帳核算。

作為運作權責依據的交戰規則（RoE）

根據美國國家標準與技術研究院（NIST）的定義，交戰規則（RoE）為安全測試設定準則與限制 [1]。對於機構層級的測試工作而言，它將測試決策轉化為經授權的任務：明確的目標、明確的範圍，以及具名的行動權責。

這項任務之所以重要，是因為測試團隊不能僅憑合約或資產清單來安全地推斷授權範圍。若缺乏對所評估風險、涉及系統以及負責人員的共同決策，測試團隊可能會測試錯誤的路徑、遺漏關鍵依賴項，或缺乏驗證重大發現所需的權限。

起點是測試旨在支援的業務決策。目標可能涉及上線前的公開曝險。也可能聚焦於客戶與應用程式介面（API）授權，或聚焦於特權雲端與營運系統的可觸及性。也可能測試簽章或提款工作流程，或評估第三方整合。該目標明確了重要的系統、需降低的風險，以及管理層做決策所需的結果。

該目標應轉化為符合營運模式的範圍。在加密機構中，這通常包括面向客戶的網頁、行動及應用程式介面（API）服務；雲端帳戶與身分及存取管理（IAM）；持續整合與持續交付（CI/CD）系統與機密資訊；營運控制台；錢包與核准工作流程；簽章系統；帳本與提款服務；以及連接這些系統的供應商。這些元件共同管理客戶及內部團隊如何發起、核准、簽署、發布及對帳與資金相關的操作。機構與測試團隊也應就相關視角達成一致：外部攻擊者、一般使用者、合作夥伴、低權限員工，或假設已遭入侵的身分。

範圍內的每個系統、帳戶、介面及活動都應有具名的負責人及明確的授權路徑。這同樣適用於第三方依賴項，包括託管服務提供商、錢包介面、遠端程序呼叫（RPC）供應商、軟體即服務（SaaS）平台、身分提供商、程式碼託管平台及託管服務。測試供應商所擁有的環境，需要該供應商的書面許可；機構的授權本身可能無法授權針對供應商系統的活動。

目標、範圍及授權路徑三者共同確立了團隊可評估的內容。下一步則記錄團隊執行該評估的方式。

運作限制

運作限制是在任務達成共識後，管理執行過程的書面約束條件。它們區分了範圍內的內容與允許的活動：生產環境的提款服務可能屬於授權路徑驗證的範圍，但真實客戶提款、私鑰擷取、持久化變更以及產生負載的攻擊仍屬禁止行為。

這種區分能防止不確定性演變為營運風險。在生產環境測試工作期間，機構與測試團隊需要事先了解允許使用哪些技術、活動何時必須停止、誰有權做出該決定，以及證據應如何處理。否則，即使是經授權的測試也可能造成本可避免的服務或客戶影響。

交戰規則（RoE）應在測試開始前記錄這些決策。此外，該文件應足夠精確，讓雙方無需在測試過程中重新討論根本性問題即可採取行動。

下表將上述所建立的測試任務轉化為實用的交戰規則（RoE）記錄。它將測試開始前須確定的決策分組列出：評估內容為何、誰獲得授權、適用哪些活動及限制、雙方如何協調，以及證據如何處理。這並非可原封不動照搬的通用檢查清單；所記錄的數值應反映機構的營運模式、測試視角及生產環境風險。

RoE 主題	測試前應記錄的決策
目標與範圍	業務決策、範圍內的系統與介面、負責人，以及待測試的攻擊者視角。
授權	書面授權、測試身分、經核准的存取路徑，以及第三方環境的供應商核准。
測試方法與完成條件	允許使用的技術，以及團隊必須停止的時點，例如已展示的存取權限、權限提升，或受控的工作流程模擬。
運作限制	測試時段、請求速率與並行限制、帳戶操作限制、資料存取邊界、變更凍結期，以及在經核准的情境中使用交易時，允許的網路、測試位址、交易類型、最高測試金額及Gas預算。
禁止活動	例如包括阻斷服務測試、社交工程、真實客戶資產轉移、私鑰匯出、持久化，或未經核准的生產環境變更。
敏感工作流程	指定的錢包與帳戶、白名單目的地、最高測試金額、核准參與者、預期的政策行為、對帳步驟，以及驗證可觸及交易控制鏈中的最遠節點。
溝通與暫停	常規通知模式、受保護的安全溝通管道、升級聯絡人、重大發現門檻、有權暫停或恢復測試的具名權責人，以及經核准的公開交易廣播所預期的可觀測性與警報處理方式。
證據處理	所需的最低限度證據、資料最小化與遮蔽處理、加密、經核准的收件人、保留期限、銷毀確認，以及與經核准測試交易的內部核准及帳本證據相關聯的交易雜湊值與網路元資料。

在執行邊界達成一致後，機構便可準備測試所涉及的已部署系統及運作條件。

運作環境與線上服務保護

運作環境是指已部署的系統及其周邊的業務活動：信任邊界、資金流向、服務依賴關係、營運工作流程，以及各元件的負責人員。這正是測試發現獲得其實際意義的背景脈絡。

這種背景脈絡之所以重要，是因為同樣的技術弱點可能產生截然不同的後果。API問題、雲端權限或核准工作流程弱點可能影響客戶資料、內部營運、簽章權限、餘額變動或提款。對於運行中的交易所、支付公司、託管機構或錢包服務提供商而言，測試工作還必須與交易、支付、存款、提款、結算及支援業務並存。

當前概況應涵蓋資產與服務清單、架構及整合節點、雲端與身分模型、營運工作流程，以及第三方依賴關係。規劃工作也應識別相關的業務時段、計劃中的發布、變更凍結期、高交易量時期、熱錢包活動及其他營運事件。測試期間觀察的服務健康度訊號應包括交易與API量、回應時間、錯誤率、佇列深度、簽章服務健康狀態，以及錢包服務可用性。運作環境包括用於發起及控制交易的生產服務、身分、營運工作流程及外部依賴關係。交戰規則（RoE）記錄了經核准的測試環境、測試身分、簽章或提款工作流程中允許的步驟，以及適用於任何受控驗證情境的保障措施。這些參數使評估能專注於機構的控制措施，同時保護正常的客戶及營運活動。

歐盟的《數位營運韌性法案》（DORA）提供了一個高監管標準的有用參考點。對於被選中進行威脅導向滲透測試的金融機構，第26條要求測試須涵蓋關鍵或重要功能，並須在支援這些功能的生產系統上執行，包括相關的外包資訊與通訊科技（ICT）服務 [2]。這並非對生產環境測試的一般性授權；每個機構仍需擁有自身的授權、保障措施以及適用的法律和合約核准。

這一生產環境基準使機構能夠對可直接影響資金或客戶存取的工作流程，應用更具體的保障措施。

敏感工作流程的邊界

敏感工作流程是指其正常運作可直接影響資金、客戶存取或記錄完整性的系統與操作。這些包括簽章與提款工作流程、特權生產環境存取、客戶資料處理，以及帳本操作。

這些工作流程需要更嚴格的邊界，因為若非如此，符合實際情況的測試可能會從驗證控制措施演變為改變客戶或財務結果。這種風險不僅止於技術層面的中斷：它可能包括未經授權的資金轉移、餘額錯誤、敏感資料曝露，或測試活動與實際事件之間的混淆。當控制失效可能影響資金時，逆轉可能十分困難甚至無法實現，因此這些邊界必須防止測試產生任何非預期或未經授權的資金轉移。

簽章與提款工作流程需要受控情境，以驗證機構如何驗證請求、套用政策、路由核准及對帳結果。交戰規則（RoE）明確指定測試帳戶、經授權的參與者、預期的政策行為、該情境的上限，以及驗證該工作流程所需的證據。接著記錄允許到達的最遠工作流程步驟：請求建立、政策決策、核准顯示、簽章請求、發布決策，或對帳。測試身分透過雙方同意的存取流程進行配置、使用及註銷。同樣的規範也適用於特權存取、客戶資料及帳本操作：存取模型、預期的系統行為及證據邊界均在測試開始前達成一致；客戶資料僅在必要時被存取，並在證據中進行最小化及遮蔽處理，且保存於經核准的證據儲存庫內。

這些控制措施使得在生產環境中測試敏感路徑成為可能，而無需將其視為一般應用程式功能來對待。它們也為營運團隊及測試團隊協調線上活動提供了共同的基礎。

測試與協調

測試與協調是測試工作進行期間的即時運作模式。它們將服務負責人、安全營運團隊、事件應變職能及測試主導人員串聯起來。

這一模式是必要的，因為預期的測試活動與真正的安全事件可能看起來相似。若監控、通知或暫停決策不明確，測試可能延誤事件應變，或造成是否需要採取生產環境行動的不確定性。

溝通模式明確了誰了解完整的測試計畫、誰接收時效性通知，以及誰有權暫停或恢復活動。這因目標而異：某些測試需要圍繞敏感系統進行密切的安全營運中心（SOC）協調，而有限披露的測試則評估監控是否能偵測到活動，以及升級通報是否能到達正確人員。當受控情境涉及交易相關工作流程時，計畫也涵蓋來自託管、錢包、交易篩查及監控供應商的相關通知及預期警報。獨立的安全聯絡人及具名的暫停權責人須始終保持可聯繫狀態。服務負責人及測試團隊就可衡量的停止標準達成一致，例如偏離錯誤預算、第95百分位（p95）回應時間或佇列深度的異常增加、可疑的帳戶或錢包活動、重大對帳差異，或非計劃內的安全警報。

這種準備工作也能強化營運韌性。香港證券及期貨事務監察委員會（SFC）要求虛擬資產交易平台營運者維持全天候（24/7）監控及書面升級程序，並與相關第三方進行緊急應變及業務持續性演練 [3]。這些監管參考僅供說明，並非法律建議；其適用性因司法管轄區而異，應諮詢法律顧問確認。

該圖展示了測試進行期間所適用的控制迴路。其核心要點是：交戰規則（RoE）的邊界並不止於授權階段——監控與安全溝通管道將這些邊界轉化為恢復、暫停、圍堵，或將已驗證的發現轉交進行補救的決策。此處呈現這一內容，是因為這些決策屬於即時協調的範疇，而非先前範圍界定或生產環境準備的範疇。

同樣的模式也適用於管理重大發現：已展示的未經授權資金轉移路徑、簽章權限或生產環境控制平面遭入侵、高度敏感客戶資料曝露，或對關鍵服務構成重大風險。應變路徑應明確升級門檻、負責分類發現的人員、暫停相關活動的權責人，以及圍堵、補救及驗證的流程。滲透測試團隊負責展示並回報問題；機構則保留對生產環境決策、客戶溝通及補救措施的決定權。重大發現的通知應優先使用受保護的安全溝通管道，隨後再提供不會揭露不必要漏洞細節的、經雙方同意的書面記錄。

一旦某項發現被圍堵並指派負責人，測試工作的價值便取決於機構能否將該結果轉化為經驗證的控制措施改進。

補救、重測與恢復正常

補救與重測是將已展示的弱點轉化為經驗證改進措施的結案流程。恢復正常也是同一流程的一部分：測試存取權限、受控情境及所收集的證據都不應演變成新的長期風險。

這最後一個階段決定了測試工作究竟是能降低風險，還是僅僅產出一份報告。若某項發現沒有負責人、補救路徑及驗證條件，則同樣的攻擊路徑可能在生產環境中持續存在，而該發現仍處於未結案狀態。

在測試開始前，應確定發現如何進入工程、雲端、錢包營運或業務控制工作流程；由誰負責補救；以及哪些發現需要重測。結案時，臨時測試身分、權限及受控情境應恢復至其預定配置，且服務負責人須確認相關健康指標仍維持在預期範圍內。最終記錄將每項發現與其證據、影響、負責人、補救計畫及重測條件相連結。對於受控的交易相關情境，還會連結工作流程參考、測試身分、時間戳記、核准記錄及最終產生的帳本條目；為該情境所建立的任何臨時存取權限、核准或測試配置均須註銷。證據僅在雙方同意的期限內保留，隨後將安全銷毀或歸還。

其結果並非一份漏洞清單，而是一組經測試、經補救且經重測的控制措施，能支援機構做出下一步的營運決策。