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

本系列的前兩篇文章闡述了為何加密貨幣機構需要區塊鏈滲透測試（第 1 篇），以及這門學科究竟是什麼（第 2 篇）。本文接著說明機構級專案如何準備與安全執行：交戰規則（rules of engagement）、生產環境安全防護措施，以及把發現轉化為修復的修補與複測——即下所示的專案生命週期。

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 界線並不終止於授權；監控與安全通道把這些界線轉化為恢復、暫停、圍堵，或將已驗證的發現交付修補的決策。它出現在此處，是因為這些決策屬於即時協調的一環，而非先前的範圍界定或生產環境準備階段。

同一套模式也適用於重大發現：已證實可通往未經授權資金移動的路徑、簽章權限或生產控制平面的淪陷、高度敏感客戶資料的外洩，或對關鍵服務的重大風險。應變路徑應界定升級門檻、負責判定發現等級的人員、暫停相關活動的授權，以及圍堵、修補與驗證的流程。滲透測試團隊負責演示並報告問題；機構保留生產環境決策、客戶溝通與修補的權力。重大發現通知應優先使用受保護的安全通道，接著才以議定的書面紀錄補充，且不揭露不必要的攻擊細節。

一旦發現被圍堵並指派處理，專案的價值就取決於機構能否把該結果轉化為經驗證的控制改善。

修補、複測與恢復正常

修補與複測是收尾流程，將已證實的弱點轉化為經驗證的改善。恢復正常是同一流程的一部分：測試存取權、受控情境與所蒐集的證據，都不能成為新的長期風險。

這個最後階段決定了專案是真正降低了風險，或只是產出一份報告。一項發現若沒有負責人、修補路徑與驗證條件，就可能一直懸而未決，而同一條攻擊路徑仍在生產環境中持續存在。

在測試開始前，應先確認發現如何進入工程、雲端、錢包營運或業務控制流程；誰負責修補；以及哪些發現需要複測。收尾時，臨時測試身分、權限與受控情境都回復到其預定組態，服務負責人並確認相關健康指標維持在預期範圍內。最終紀錄會把每項發現連結到其證據、影響、負責人、修補計畫與複測條件。對於受控的交易相關情境，也會連結流程參照、測試身分、時間戳、審批紀錄與由此產生的帳本分錄；為該情境建立的任何臨時存取權、審批或測試組態都會被註銷。證據僅在議定期間內保存，之後安全銷毀或歸還。

最終成果不是一份漏洞清單，而是一套經過測試、修補與複測的控制措施，足以支持機構的下一個營運決策。