Binance 事件揭示 Web3 基礎設施的授權安全缺口

6.3 Billion 美元 Binance 安全事件揭示了甚麼：錢包授權、特權存取、交易治理與 AI 驅動安全的未來。

區塊鏈原本旨在改變我們對信任的看法。

區塊鏈不再依賴中央機構驗證交易，而是引入密碼學驗證、分散式共識和透明的交易紀錄。這個概念十分有力：參與者可以互動，而無須信任單一中介機構維護系統的完整性。

但業界仍然要面對一個令人不安的問題。

如果區塊鏈完全按照設計運作，但控制存取權限的基礎設施遭到入侵，會發生甚麼事？

2026年10月的 Binance 安全事件令這個問題尤其重要。Binance 表示，其熱錢包基礎設施遭人未經授權提款後，約有 6.3 billion 美元資產受影響。交易所亦表示，鏈上約有 3 billion 美元受影響資產已被凍結，而調查已找出多個遭入侵環節。Binance 稱，未發現錢包私鑰外洩的證據。全面的技術調查仍在進行。

這項區別十分重要。

這宗事件並不證明區塊鏈密碼學失效，而是凸顯另一點：區塊鏈生態系統的安全性，取決於遠超其底層協定的因素。

交易所、錢包服務、簽署基礎設施、員工身份、API、雲端環境，以及交易審批流程，全部都納入安全邊界之內。

而真正的工程挑戰，就從這裏開始。

\n \n 1. 無需信任的幻象\n

「無需信任」一詞經常用來形容區塊鏈網絡，但人們很容易誤解它的真正含義。

無需信任的系統，並不代表應用程式的每個組件都不再涉及信任，而是指特定互動可以透過密碼學及協定層面的機制驗證，而毋須依賴中央權威機構。

以常見的區塊鏈交易為例。

用戶建立交易，使用私鑰簽署，再將交易廣播至網絡。節點會驗證簽名及其他協定條件，然後才接納交易。

從區塊鏈的角度來看，關鍵問題是交易是否符合協定規則。

網絡未必知道該交易是否反映帳戶持有人的真正意願。

如果攻擊者取得簽署機制的存取權，或入侵負責發起交易的系統，區塊鏈收到的交易仍可能完全有效。

網絡可以驗證簽名，也可以核實交易，並將交易納入區塊。

即使操作是透過遭入侵的應用程式或未經授權的工作流程發起，網絡仍可完成以上所有步驟，而不會察覺。

這帶來一個重要區別：

區塊鏈完整性決定帳本是否遵循協定。
密碼學安全性決定交易是否具有有效簽名。
基礎設施安全性決定與網絡互動的系統是否受到保護。
授權機制決定某個行為者或服務是否應獲準執行操作。
營運管治決定操作是否遵循組織的政策。

這些是彼此獨立的安全責任。

區塊鏈可以符合首兩項要求，但組織在其餘方面仍可能未能達標。

因此，如果只説區塊鏈本身安全，卻不討論其周邊基礎設施，就無法呈現完整情況。

2. 當基礎設施成為攻擊面

現代加密貨幣交易所是複雜的分散式系統。

一般交易所可能包含帳戶服務、API 閘道、身分識別提供者、交易引擎、提款服務、錢包管理系統、交易簽署基礎設施、雲端工作負載、監察平台，以及內部管理工具。

每個元件都涉及不同的安全責任。

簡化的提款流程可能如下：

用戶提出提款要求。
應用程式驗證用戶身分。
提款服務驗證要求。
風險控制措施評估交易。
授權服務判斷是否準許執行該操作。
簽署服務產生所需的密碼學簽章。
交易廣播至區塊鏈。
監察系統追蹤交易的執行及確認情況。

每個步驟都至關重要。

組織即使擁有出色的密碼學金鑰管理，仍可能因憑證遭入侵、服務權限過大、部署環境不安全，或授權控制不足，令提款流程暴露於風險之中。

因此，安全邊界不能止於錢包。

人員與基礎設施問題

試想一個假設情境。

一名工程師擁有部署環境的合法存取權。攻擊者入侵工程師的工作站，並取得內部服務的存取權。

攻擊者未必需要直接竊取私鑰。

相反，攻擊者可以嘗試濫用現有的應用程式流程、利用過大的服務權限，或操控能合法使用交易簽署功能的元件。

關鍵分別在於：竊取密碼學機密資料，與濫用獲授權使用該資料的系統，是兩回事。

後者同樣可能造成嚴重後果。

Binance 的初步事故通訊提及，一名 DevOps 工程師的手提電腦可能遭入侵，並有人透過服務基礎設施進行未經授權的提款活動。交易所其後表示，還有其他被入侵的環節。在技術事後分析報告公佈前，不應假定完整的攻擊鏈已經明確。

更廣泛的工程教訓很清楚：如果授予某個身分或服務的權限超出實際操作所需，合法存取權就可能成為攻擊途徑。

3. 錢包授權問題：簽署不代表獲準

Web3 安全中其中一項最重要的架構區分，是簽署交易與授權交易並不相同。

簽署是一項密碼學操作。

授權則是一項決定。

簽署服務可能會驗證要求是否來自獲批的應用程式，但單憑這點，並不能確定所要求的交易是否恰當。

例如，請看以下兩筆交易：

交易 A

目的地：先前已核准的地址
金額：0.5 ETH
發起方：獲授權的提款服務
風險級別：正常

交易 B

目的地：新加入的地址
金額：5,000 ETH
發起方：同一個獲授權的提款服務
風險級別：需要額外驗證

兩項請求可能來自同一個服務身份。

兩者可能都持有有效的應用程式憑證。

但兩者不一定應獲得相同的授權決定。

安全架構應評估交易本身，而不只是提交交易的身份。

這是交易感知授權的基礎。

交易政策應評估哪些事項？

授權層至少應考慮：

發起方身份及服務帳戶。
所要求的操作。
交易金額及資產。
目的地地址。
地址信譽及歷史記錄。
交易頻率。
目前的審批狀態。
裝置及工作階段情境。
監察系統提供的風險訊號。
適用的機構政策。

有效身份不應獲得不受限制的資產轉移權限。

權限應限制於特定操作、特定條件及特定期間內。

這對熱錢包尤其重要，因為運作可用性與安全要求必須兼顧。

4. 為何身份驗證並不足夠

身份驗證回答一個相對簡單的問題：

你是誰？

授權回答的是另一個問題：

你獲準做甚麼？

在傳統應用程式安全中，這些概念通常被視為不同的控制措施。在金融基礎設施中，將兩者分開至關重要。

試想像一名員工已成功使用多重因素驗證。

該員工的身份真實可信。工作階段有效。裝置甚至可能由機構管理。

但該身份是否應有權批核大額提款？

不一定。

身份驗證確立身份的可信度，但不能證明交易正當。

更好的做法是將以身份為基礎的權限，與情境及交易專屬政策結合。

例如：

安全條件	預期行動
已核准服務、低金額交易	在已設定的限額內允許
已核准服務、新目的地	要求額外驗證
大額交易	要求獨立審批
異常交易速率	暫緩處理並調查
服務身份已遭入侵	撤銷存取權限並阻止執行
審批互相矛盾或已過期	拒絕請求

授權決定應由提出交易請求的元件以外的獨立部分執行。

這可防止遭入侵的應用程式自行宣稱其請求正當。

超越靜態權限

傳統的角色型存取控制很有用，但未必足以應付高價值金融操作。

擁有提款權限的服務帳戶，從技術上來説可能獲準提交數以千計的交易。

但這不代表每一項交易都應獲接受。

更具情境感知能力的模型會結合：

角色型存取控制（RBAC）。
屬性型存取控制（ABAC）。
交易專屬政策。
有時限的權限。
以風險為基礎的限制。
獨立審批要求。

如此一來，系統便會根據實際操作評估權限，而不是授予廣泛且永久的能力。

5. 缺失的安全架構

現代 Web3 安全架構需要在應用程式服務與交易執行之間，設置專責的授權及管治層。

此層不應取代加密簽署或區塊鏈驗證，而應控制允許簽署的條件。

我將此稱為交易授權與治理層。

其目的很簡單：

任何敏感交易在通過獨立強制執行的授權政策前，都不應送達簽署基礎設施。

參考架構可以如下所示：

             User / AI Agent / Internal Service
                           |
                           v
                    API Gateway
                           |
                           v
                 Identity Verification
                           |
                           v
                Transaction Validation
                           |
                           v
              Risk and Anomaly Detection
                           |
                           v
             Policy-Based Authorization
                           |
                +----------+----------+
                |                     |
                v                     v
          Approved Request       Rejected Request
                |
                v
           Approval Engine
                |
          +-----+------+
          |            |
          v            v
       Approved     Additional
       by Policy    Verification
          |            |
          +------+-----+
                 |
                 v
          Signing Service
                 |
                 v
           Blockchain RPC
                 |
                 v
           Blockchain Network
                 |
                 v
        Execution Monitoring

此架構將多項不應合併至同一服務的職責分開處理。

第 1 層：身份及服務驗證

每個用戶、員工、服務及自動化 Agent 都應有可識別的安全主體。

在可行情況下使用短效憑證、工作負載身份、強式驗證，以及明確的服務間授權。

避免只依賴靜態 API 金鑰作為關鍵操作的安全邊界。

第 2 層：交易驗證

授權前，先驗證所請求的交易。

檢查：

支援的區塊鏈及資產。
目的地格式。
交易金額。
Nonce 及交易參數。
合約互動詳情。
Gas 上限及其他執行限制。

驗證可確立交易在結構上是否可接受，但不能確立交易是否應獲批准。

第 3 層：基於政策的授權

政策引擎會評估所請求的操作是否獲準。

例如：

def authorize_transaction(tx, identity, context):

    if not identity.is_authenticated:
        return "DENY"

    if identity.status != "ACTIVE":
        return "DENY"

    if not identity.can_withdraw:
        return "DENY"

    if tx. amount > identity.transaction_limit:
        return "REQUIRE_APPROVAL"

    if tx. destination not in identity.allowed_addresses:
        return "REQUIRE_VERIFICATION"

    if context.risk_score >= 80:
        return "HOLD_FOR_REVIEW"

    return "ALLOW"

這是示意性的虛擬碼，並非完整的生產環境授權引擎。

生產環境的實作還需要嚴格的輸入驗證、政策版本管理、明確的資產及區塊鏈處理、並行控制、審計紀錄，以及遇錯即拒絕的行為。

重要的架構原則是：請求交易的應用程式不得凌駕授權決定。

第 4 層：多方批准

高價值操作應要求多於一方的獨立批准。

閾值簽署、多重簽署錢包及多方計算都可在此發揮作用。

然而，加入多名簽署者並不會自動形成完善的治理。

如果所有簽署者共用同一個已遭入侵的身份提供者、管理環境或批准流程，表面上的分隔可能會造成誤導。

獨立性至關重要。

批准流程應分散至真正分離的安全主體及執行邊界。

第 5 層：簽署隔離

簽署服務應與一般應用程式工作負載隔離。

實用的設計包括：

在適當情況下使用硬件安全模組。
在適當情況下使用多方計算或閾值簽署基礎設施。
嚴格的工作負載身份。
針對個別交易的簽署權限。
速率限制及交易上限。
獨立的授權驗證。
防篡改審計紀錄。

簽署服務絕不應只因請求來自已驗證的內部服務，就盲目簽署任意資料。

它應驗證請求是否附有有效的授權決定，且該決定已綁定至確切的交易。

6. 批准問題：為何有效的批准仍可能不安全

交易授權還有另一個微妙的問題。

如果一項批准可以重複用於另一筆交易，便沒有意義。

想像管理員批准提取 25,000 個單位。

執行前，遭入侵的服務將請求修改為 75,000 個單位。

如果授權系統只檢查是否存在批核旗標，修改過的交易仍可能通過檢查。

這是「檢查時間與使用時間」問題的一個例子。

系統檢查的是一項操作，執行的卻是另一項。

因此，安全的批核應以密碼學方式或其他安全方式，綁定至其授權的交易。

交易批核紀錄應包含：

唯一交易識別碼。
鏈識別碼。
資產識別碼。
確切金額。
目的地地址。
發起者身份。
政策版本。
批核者身份。
批核時間戳。
到期時間。
交易負載雜湊值。

簽署服務必須獨立核實待簽署的交易是否與已批核的負載相符。

它亦必須強制執行批核只能使用一次的規則。

如果兩個工作程序可以同時使用同一項批核，單靠一個已使用旗標並不足夠。

因此，使用批核時需要原子狀態轉換及具備並行安全性的執行機制。

示例：防止重複使用批核

def execute_approved_transaction(tx, approval):

    if approval.expired():
        return "REJECTED"

    if approval.transaction_hash != tx.hash():
        return "REJECTED"

    if approval.chain_id != tx.chain_id:
        return "REJECTED"

    if approval.status != "APPROVED":
        return "REJECTED"

    # Atomically claim the approval.
    claimed = approval_store.claim_once(
        approval.id,
        expected_status="APPROVED"
    )

    if not claimed:
        return "REJECTED"

    return signing_service.sign(tx)

在實際系統中，交易雜湊值必須涵蓋所有與安全相關的欄位，批核聲明必須以原子方式提交，而執行失敗則必須透過持久化狀態機處理。

正是這類工程細節，區分了表面上看似安全的權限機制，以及能夠應對實際營運環境的機制。

7. AI Agent 如何介入其中

AI 為這個問題帶來了新的層面。

各個機構正日益建立能與 API、資料庫、金融服務、雲端基礎設施及營運工具互動的 Agent。

AI Agent 可能具備以下能力：

發起錢包交易。
調整投資組合配置。
執行智能合約操作。
在帳戶之間轉移資產。
管理流動資金。
啟動自動化結算流程。

這些能力很有用，但也帶來一個根本問題。

我們如何防止智能系統把錯誤決策轉化為不可逆轉的金融操作？

答案並非單純令 Agent 變得更聰明。

Agent 可能誤解指示、根據過時的上下文操作、選錯工具、誤讀回應，或根據遭操控的資訊採取行動。

即使 Agent 的決策在技術上正確，也可能違反機構的營運政策。

這表示 AI Agent 不應擁有不受限制的交易權限。

它們應透過受權限控制的執行環境運作。

將推理與執行分開

一個實用的架構會把 Agent 的職責分為兩部分。

推理層

Agent 會解析請求、收集資訊、選擇工具並提出操作建議。

執行授權層

另一個獨立的確定性系統會驗證建議的操作、評估權限、執行交易限額，並判斷是否準許執行。

例如：

AI Agent 收到指示，要向外部錢包轉帳 10 ETH。

它可以準備交易，並解釋轉帳的原因。

但它不能直接指示簽署服務執行轉帳。

相反，請求會先交由獨立的政策引擎處理。

該引擎會評估身份、金額、目的地、風險訊號、批核要求及目前的交易狀態。

只有在符合這些條件後，簽署服務才可以繼續執行。

Agent 可以建議採取某項行動。

政策引擎則決定該行動是否獲準。

簽署基礎架構只會執行已獲授權的操作。

隨着 Agent 從對話介面延伸至自主財務及企業工作流程，這種分隔變得愈來愈重要。

8. AI 驅動的交易異常偵測

確定性政策固然不可或缺，但無法預見每一種異常模式。

機器學習和行為分析正好可以在這方面發揮作用。

異常偵測系統可以為不同身分、錢包、服務及應用程式建立正常的交易行為基準。

例如，假設有一項內部提款服務，通常會處理：

每小時 10 至 20 宗交易。
轉帳至先前已核准的地址。
金額維持在可預測的範圍內。
交易只在既定的營運時段內進行。

突然間，同一項服務開始向不熟悉的目的地發起數百宗交易。

由於服務身分仍然有效，靜態權限系統可能會允許這些交易。

行為偵測系統則可以識別出，這些活動與既定基準有顯著差異。

潛在的偵測訊號包括：

交易頻率異常。
新的或不尋常的目的地地址。
交易金額突然增加。
不尋常的地理位置或裝置情境。
服務帳戶行為改變。
異常的 API 請求序列。
意料之外的簽署請求。
多個基礎架構元件之間相互關聯的警示。

分層式偵測模型

實用的架構會結合多種技術：

技術	用途
規則式偵測	執行已知的安全限制
統計異常偵測	識別偏離正常活動的情況
圖分析	識別錢包與地址之間可疑的關聯
行為分析	偵測不尋常的身分及服務活動
序列分析	識別可疑的交易模式
AI 輔助調查	關聯證據並説明潛在威脅

機器學習不應成為允許或拒絕交易的唯一決策依據。

異常分數可能帶有雜訊。合法但不尋常的交易可能看似可疑，而經過周詳策劃的攻擊則可能與正常活動相似。

較佳的設計，是把異常偵測用作額外的風險訊號。

確定性授權引擎仍應負責執行最終安全政策。

例如：

def transaction_decision(tx, identity, anomaly_score):

    if not identity.is_authorized(tx):
        return "DENY"

    if tx. amount > identity.hard_limit:
        return "DENY"

    if anomaly_score >= 90:
        return "BLOCK_AND_INVESTIGATE"

    if anomaly_score >= 70:
        return "REQUIRE_MANUAL_APPROVAL"

    if not identity.destination_is_trusted(tx.destination):
        return "REQUIRE_VERIFICATION"

    return "ALLOW"

數值門檻僅供參考。實際門檻須根據交易量、業務要求、誤報率及漏掉攻擊的後果進行校準。

9. 不只着眼於防範，也要為失效做好設計

安全工程中一個最常被忽略的環節，是控制措施失效後會發生甚麼事。

沒有任何機構可以保證所有憑證、裝置、服務及應用程式都不會遭到入侵。

具韌性的系統會假設個別元件可能失效。

因此，架構應限制任何單一元件遭入侵時可能造成的損害。

可考慮以下控制措施：

交易限額

在錢包、身分、服務及營運層級分別設定限額。

地址允許清單

允許向新的目的地轉帳前，須進行額外驗證。

交易頻率控制

在指定時段內限制交易頻率及累計轉帳金額。

獨立審批

敏感操作須由多個安全主體共同參與。

憑證撤銷

確保可迅速停用已被入侵的身份及服務憑證。

緊急斷路機制

在偵測到重大異常時，提供可控機制以暫停交易執行。

持續監察

關聯身份事件、API 活動、簽署請求、區塊鏈交易及執行結果。

復原程序

測試事故應變、資產追回協調、備用簽署安排及業務持續運作。

目標不是建立一個攻擊不可能發生的系統。

目標是令攻擊更難執行、更容易偵測，並在攻擊發生時減輕其破壞。

10. 我們應建構的架構

新一代 Web3 安全不應依賴單一防護技術。

它應結合密碼學、身份、授權、交易治理、異常偵測及持續驗證。

我會以六項安全能力組織這套架構：

能力	職責
身份安全	建立可信任的用戶、服務及工作負載
交易治理	界定允許執行哪些操作
授權強制執行	驗證每項敏感操作
密碼學防護	保護金鑰及簽署操作
行為監察	偵測異常交易活動
事故協調	遏止威脅並協調復原

這些能力應互相配合，同時維持職責分離。

例如，AI 監察服務不應自動獲得轉移資產的權限。

發起提款的應用程式不應能批准自身的高價值操作。

簽署服務不應能更改授權政策。

政策引擎不應能繞過密碼簽署要求。

每個元件都應有明確界定的職責，以及範圍嚴格受限的權限。

這是零信任架構的實際應用：任何元件都不應僅因在組織的基礎設施內運作，便獲授不受限制的權限。

11. 超越 Binance：給每個自主系統的教訓

雖然這番討論從加密貨幣交易所開始，但相關的根本問題遠不止於 Web3。

同樣的架構弱點也可能出現在：

AI 金融應用程式。
企業支付系統。
自動化交易平台。
雲端基礎設施自動化。
智能合約管理系統。
自主採購工作流程。
由 Agent 驅動的營運平台。

只要軟件可以發起會帶來財務或營運後果的操作，僅有身份驗證便不足夠。

系統必須理解所要求的操作、評估背後的權限、核實操作可執行的條件，並保留獨立的決策紀錄。

隨着機構採用能與實際業務系統互動的 AI Agent，這一點變得更加重要。

我們正從主要處理資訊的軟件，邁向能夠採取行動的軟件。

這個轉變改變了安全要求。

聊天機械人提供錯誤答案，是一種失誤。

自主 Agent 執行未經授權的轉帳，則是另一種失誤。

架構必須考慮到兩者的差異。

結論：區塊鏈需要的不止是密碼學安全

區塊鏈從未承諾要消除所有形式的信任。

它提供了一種透過密碼學驗證和去中心化共識來確保交易完整性的方法。

但圍繞區塊鏈建立的系統，仍然依賴身分、權限、基礎設施及營運決策。

Binance 事件提醒我們，有效的交易未必是獲授權的交易。

這項區別值得在 Web3 工程中得到更多關注。

下一代區塊鏈安全不應只聚焦於保護私鑰，還應着重控制這些金鑰如何、何時、為何，以及在誰的授權下使用。

對於 AI 驅動的系統，這項原則更為重要。

Agent 可以進行推理、提出建議及啟動操作，但敏感操作的執行應繼續受獨立授權、確定性的政策執行機制及可審計的控制措施所規管。

Web3 安全的未來，不會單由密碼學決定，而取決於我們能否有效管治獲準使用密碼學技術的系統。

參考資料及延伸閲讀

免責聲明：本文提供獨立的資安架構分析。文中提出的控制措施及示例僅屬説明性工程建議，並非對 Binance 內部架構或已確認根本原因的陳述。Binance 對事件的調查仍在進行中。