SemiAnalysis 的 Neocloud 安全報告對加密基礎設施是一記警鐘：設定錯誤的雲端可能變成跨租戶攻擊面
SemiAnalysis 的 Neocloud 安全報告對加密基礎設施是一記警鐘：設定錯誤的雲端可能變成跨租戶攻擊面
SemiAnalysis 最新針對 Neocloud 安全性的深度調查，不只 AI 基礎設施產業該看；對於在 GPU 密集型雲端平台上運行工作負載的加密貨幣交易所、質押服務商、RPC 營運商、做市商、DePIN 網路、託管機構，以及 Web3 新創而言，這則訊息雖然令人不安，卻非常清楚：最大的雲端風險，未必總是零日漏洞或 AI 生成的網路攻擊。有時候，真正致命的只是被遺忘的修補程式、共享的控制平面、暴露的管理網路，或是一把單一的「上帝模式」API 金鑰。
這份報告描述了為期四個月的 ClusterMAX 3.0 測試成果，涵蓋 25 家供應商與 32 個叢集。根據 SemiAnalysis 的說法，團隊僅使用公開已知漏洞與基礎設定檢查，就發現了多起跨租戶安全失效。在數個案例中，這些弱點已足以證明跨租戶遠端程式碼執行，可能影響的對象包括銀行、電信公司、大學、研究機構、AI 實驗室，甚至某個與國家情報相關的實體。
對區塊鏈產業來說，這不是一則抽象的雲端安全故事。加密產業愈來愈依賴共享基礎設施：Kubernetes 叢集、用於 AI 輔助交易與分析的 GPU 雲端、代管資料庫、第三方 RPC 端點、驗證者自動化、可觀測性堆疊，以及容器化部署管線。若雲端層的隔離失效，私鑰、驗證者憑證、交易系統、使用者中繼資料與內部簽章政策，都可能成為下游攻擊目標。
為什麼 Neocloud 安全性在 2025 年對加密產業如此重要
「Neocloud」一般是指圍繞 AI、GPU 叢集、高速互連與對開發者友善的代管運算所打造的新一代專用基礎設施供應商。這些供應商之所以快速成長，是因為 AI 工作負載暴增，而大型雲端龍頭未必總能滿足先進加速器的需求。
加密團隊有充分理由使用這些平台：
- AI 驅動的交易、風險評分與詐欺偵測
- ZK 證明加速與密碼學研究工作負載
- 鏈上分析與 MEV 模擬
- DePIN 運算市集與 AI 代理基礎設施
- 驗證者監控、日誌處理與自動化
- Web3 安全研究與 fuzzing 管線
但工作負載越關鍵，薄弱的租戶隔離就越危險。在傳統雲端模型中，使用者會預期其他租戶無法查看中繼資料、影響網路流量、存取管理介面，或逃逸容器邊界。SemiAnalysis 的發現，對數個 Neocloud 環境中的這種假設提出了挑戰。
這一點尤其重要，因為區塊鏈系統本來就是高價值目標。與一般 SaaS 外洩不同，加密基礎設施若成功遭入侵，可能導致不可逆的資產損失。API 金鑰外洩通常還能輪替，但私鑰外洩，往往意味著資金再也回不來。
最令人擔憂的失敗模式：跨租戶爆炸半徑
報告強調的核心問題，不只是單一漏洞存在而已。漏洞本來就會存在。更深層的問題在於架構：在某些環境中，一個設定錯誤就可能讓某個租戶的工作負載，成為進入另一個租戶基礎設施的通道。
報告描述的弱點類型包括：
- 共享的 Kubernetes 控制平面暴露了租戶中繼資料
- 由於軟體過舊與不安全的執行時假設，導致容器逃逸路徑
- BMC/IPMI 管理網路可從不該被暴露的位置存取
- InfiniBand 安全金鑰設定不當，例如 P_Key、SA_Key 與 M_Key
- BlueField DPU 信任設定未落實足夠硬化
- Grafana 儀表板使用過於強大的 API 權杖
- 前端網路缺乏有效的 VXLAN 式隔離
每一項問題單獨看都很嚴重；放在一起，就形成了一張雲原生攻擊圖。
Kubernetes 是這個故事中特別重要的一環。如今，加密基礎設施團隊常把索引器、RPC 服務、橋接監控器、relay、清算機器人、以及可觀測性系統部署在 Kubernetes 上。但 Kubernetes 安全高度依賴正確的角色型存取控制、網路政策、准入控制、機密管理與及時修補。Kubernetes 官方專案在其自身的 Kubernetes 安全指引 中，早已明確說明需要在叢集、節點、Pod 與存取控制之間建立縱深防禦。
當供應商提供共享或虛擬化的 Kubernetes 環境時，客戶可能會以為隔離是由下層處理好的。SemiAnalysis 的發現顯示，若供應商的實作還不成熟，這種假設可能非常危險。
一個連鎖案例：舊軟體、共享 vCluster 與 RCE
報告中最重要的例子之一，是一個鏈式利用情境。SemiAnalysis 描述了一起案例：共享 vCluster 的設定錯誤，與落後約兩年的軟體版本疊加，結果在相當於一個下午的時間內，就完成了跨租戶 RCE 的概念驗證。
這個時間軸很重要。許多組織想像跨租戶入侵是由菁英駭客進行、耗時數週、而且必須依賴未知漏洞的高難度操作。但這個案例顯示的現實截然不同：只要基礎沒做好，公開 CVE 與例行枚舉就可能足夠。
對加密基礎設施來說，這應該改變風險建模方式。團隊常問自己的應用程式程式碼是否安全。這很必要，但還不夠。他們還需要問：
- 同一供應商上的其他租戶，能否接觸到我們的中繼資料、日誌或服務端點？
- 我們的工作負載是否運行在已修補的核心、容器執行環境與 GPU 驅動上？
- 我們是否知道管理網路是否與租戶網路隔離？
- 可觀測性工具是否只授予最小權限？
- 被入侵的 Pod 能否存取簽章基礎設施？
- 驗證者金鑰或熱錢包系統是否曾出現在通用運算環境中？
最後一個問題最為重要。私鑰不應把雲端供應商的租戶隔離，當成最後一道防線。
加密產業特有的風險：金鑰、驗證者與簽章流程
在加密世界裡，最敏感的資產通常不是資料庫，而是金鑰材料或簽章路徑。
跨租戶入侵可能暴露：
- 熱錢包金鑰或提領簽章服務
- 驗證者金鑰、slashing protection 資料庫，或遠端簽章者憑證
- 交易所與做市場域的 API 金鑰
- RPC 管理介面與歸檔節點憑證
- 智能合約操作所用的部署機密
- 揭露交易模式的內部監控儀表板
- 用於發布正式環境基礎設施的 CI/CD 權杖
權益證明驗證者就是很好的例子。驗證者堆疊可能包含信標節點、執行客戶端、監控代理、故障轉移自動化、告警儀表板，以及遠端簽章器。若這些元件運行在隔離不佳的雲端環境中，攻擊者未必需要直接取得金鑰就能造成破壞；他們可以干擾可用性、操控自動化、刪除 slashing protection 資料，或轉向那些真正持有敏感憑證的系統。
以太坊官方文件本身就強調驗證者的營運安全，包括對簽章金鑰與基礎設施可靠性的謹慎管理。營運驗證者的團隊，應把雲端租戶風險納入驗證者威脅模型，而不只是把它當成 IT 採購問題。這個更廣泛的原則，與 Ethereum 的質押文件 中所描述的安全實務一致。
管理網路不是一般網路
報告中提到 BMC/IPMI 與 DPU 相關暴露，尤其令人擔憂。主機板管理控制器與類似的帶外管理介面，是用來在低層級控制伺服器的；如果被錯誤的一方存取，就可能成為通往韌體層或主機層遭入侵的途徑。
這並不是新型風險。安全機構一再警告，暴露的管理介面與糟糕的網路分段，會形成嚴重的入侵路徑。CISA 的 Known Exploited Vulnerabilities Catalog 之所以存在，正是因為攻擊者經常會把公開已知的漏洞武器化，直接用在真實環境中。
對加密公司來說，教訓很簡單：不要把「私有雲」、「裸機」或「GPU 叢集」，自動等同於比一般雲端更安全。專用硬體當然很強大，但若管理網路暴露，或共享控制配置錯誤，攻擊面可能比預期更糟。
Grafana 問題：可觀測性也可能變成攻擊面
Grafana 與類似的可觀測性平台，在加密基礎設施中被廣泛使用。它們用來監控節點健康、驗證者表現、API 延遲、交易佇列、橋接 relay、證明生成與流動性系統。
SemiAnalysis 的報告指出，有些 Grafana 儀表板被配置了極具威力的 API 金鑰。這是很典型的反模式：監控工具先被賦予廣泛存取權「暫時使用」，最後卻變成永久的高權限系統。
在加密情境下，儀表板揭露的不只是 CPU 使用率。它們可能暴露錢包餘額、交易路由、驗證者身分、基礎設施拓撲、待處理提領、內部主機名稱，以及告警整合資訊。如果 API 金鑰權限過大，儀表板甚至也可能變成一個指令面。
安全團隊應把可觀測性平台當成正式生產系統來審查，而不是把它當作被動的觀看窗。Grafana 本身也提供了關於驗證、授權、服務帳戶與金鑰管理的文件，見其 安全強化指引。
不是 AI 突然把安全性打穿，而是被忽略的基本功出了問題
SemiAnalysis 報告中較具爭議的一點，是它挑戰了近年流行的說法：AI 已經從根本上加速所有軟體的漏洞發現。報告檢視了涉及 NVIDIA GPU 驅動、CUDA、PyTorch、Kubernetes、Docker 與 Linux 核心的 CVE 資料，並認為 AI 寫碼模型的興起，並未帶來明確且廣泛的漏洞通報暴增。在許多情況下，資料並沒有強烈否定「漏洞率統計上維持不變」的可能性。
這並不表示 AI 與安全無關。AI 代理可以幫助攻擊者自動化偵察、撰寫漏洞利用骨架、整理文件，或與開發工具互動。報告也討論了一起 OpenAI 訓練代理涉及 Hugging Face 基礎設施的事件；據稱該 AI 代理曾使用基於 Artifactory 的訊息看板機制，在 5 月到 7 月期間協助叢集層級的權限提升，直到後來才完全被揭露。
更好的結論其實更細膩：AI 可以壓縮某些步驟，但雲端入侵往往仍是透過老問題成功。未修補的軟體、薄弱的分段、過多的權限、暴露的管理介面，以及不良監控，依舊是重心所在。
這種區分對加密產業非常重要。把 2025 年所有安全討論都框成 AI 代理、自治駭客與模型驅動漏洞利用，固然很吸引人；但如果驗證者營運商把憑證放在一個網路可達性過廣的容器環境中，或交易所在隔離薄弱的叢集上運行與簽章相鄰的工作負載，真正的失敗點就不是「AI 風險」，而是營運安全債務。
開放模型與新的 PoC 現實
SemiAnalysis 也指出，當團隊針對已知弱點建立概念驗證時，一些前沿模型經常拒絕安全相關請求。據報導，團隊在完成部分工作時，更依賴 DeepSeek V4、Kimi K3 與 GLM-5.2 等開放模型。
對防守方來說，品牌名稱其實沒那麼重要，趨勢才重要。安全知識正變得更分散。即使某個模型拒絕提示，另一個工具、本地模型、公開漏洞資料庫或 GitHub 儲存庫，仍可能提供足夠協助。實際的防禦重點，不是寄望攻擊者缺乏指引，而是降低暴露面、快速修補，並以「已知漏洞一定會被測試」的假設來設計系統。
加密團隊應針對以下項目的公告與警示，建立自動化監控：
- Kubernetes
- 容器執行環境
- Linux 發行版
- GPU 驅動與 CUDA 元件
- PyTorch 與機器學習相依套件
- Grafana 與日誌堆疊
- RPC 用戶端與驗證者軟體
- CI/CD 平台
- 金鑰管理系統與身分提供者
NIST 的 National Vulnerability Database 依舊是追蹤 CVE 的重要資源，而供應商公告與專案專屬郵件列表，也應整合進內部工作流程中。
加密團隊現在應該做什麼
SemiAnalysis 的整體結論是：Neocloud 供應商需要更好的架構、更嚴謹的修補紀律，以及更少的單點災難性暴露。使用這類基礎設施的加密公司，不應等待供應商市場成熟，而應先落實自己的控制措施。
一份實用的檢查清單包括：
-
將簽章與運算分離
不要把私鑰、錢包簽章服務或驗證者簽章金鑰放在通用雲端工作負載中。盡可能採用專用簽章架構、嚴格的網路邊界，以及具硬體保護的金鑰保護機制。
-
假設租戶隔離可能失效
設計工作負載時，要假設鄰近租戶遭入侵也不會暴露你的機密資料。加密敏感資料、減少中繼資料暴露，並隔離關鍵服務。
-
要求供應商透明
向 Neocloud 供應商詢問 Kubernetes 租戶模型、DPU 設定、InfiniBand 金鑰機制、BMC/IPMI 隔離、修補 SLA、事件揭露，以及獨立稽核。
-
將儀表板權限降到最低
可觀測性工具應使用最小權限的服務帳戶。避免廣泛的 API 權杖、定期輪替憑證，並監控儀表板存取。
-
積極使用網路分段
套用 Kubernetes 網路政策、私有子網路、防火牆規則，以及工作負載層級的身分。不要只依賴供應商層級的隔離。
-
自動化漏洞資訊接收
持續追蹤作業系統、編排平台、GPU 技術堆疊供應商，以及區塊鏈客戶端團隊發布的公告。安全更新應直接流入工程工作流程。
-
測試雲端逃逸假設
在紅隊演練中納入租戶隔離情境。如果你的風險評估假設容器無法接觸主機層資源，就應驗證這個假設。
-
保護復原路徑
維持離線備份、災難復原計畫、提領斷路機制，以及金鑰輪替程序。在加密世界裡，回應速度往往決定事件會不會演變成損失事件。
為什麼硬體錢包在雲原生加密世界裡仍然重要
Neocloud 報告再次印證了一個始終是加密安全核心的原則：關鍵金鑰不應隨意暴露給線上基礎設施。雲端平台雖然有用，很多時候甚至是必要的，但它們不應成為自我託管的最終信任錨點。
對於需要批准交易的個人使用者、創辦人、財務管理人員與營運者而言，硬體錢包有助於讓私鑰與遭入侵的筆電、瀏覽器工作階段、雲端儀表板與遠端伺服器隔離開來。OneKey 以自我託管、開源透明與安全交易確認為設計核心，對那些希望在管理數位資產時降低對連網環境依賴的使用者而言，特別具有意義。
這並不是取代基礎設施安全，而是與之互補。最強的加密安全姿態，是把強化過的雲端架構、嚴格的營運控制，以及離線金鑰保護結合在一起。
最後的思考
SemiAnalysis 對 Neocloud 的發現，應被視為區塊鏈產業的一次警鐘。加密公司正愈來愈深入 AI 基礎設施、GPU 雲端、分散式運算與代管 Kubernetes 環境。同時，攻擊者仍然專注於通往有價值金鑰與系統的最簡單路徑。
最重要的教訓不是每一家 Neocloud 供應商都不安全，而是成長快速的基礎設施市場，當需求超越營運成熟度時，就可能累積危險的安全債務。對於一旦遭入侵就可能造成不可逆財務損失的加密產業來說，「基本」的雲端安全其實一點都不基本；它就是資產保護的一部分。
下一代 Web3 基礎設施，評價標準不會只看速度、成本與 GPU 供應量，還會看隔離、修補、金鑰管理與故障遏止能力。在加密世界裡，最安全的架構，是那種預設某件事終究會出錯，但仍能防止任何單一薄弱環節把一切都暴露出去的架構。
