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 安全研究与模糊测试流水线
但工作负载越关键，薄弱的租户隔离就越危险。在传统云模型中，客户会默认其他租户无法查看元数据、干扰网络流量、访问管理接口，或突破容器边界。SemiAnalysis 的发现对多个 Neocloud 环境中的这一假设提出了挑战。
这尤其值得关注，因为区块链系统是高价值目标。与普通 SaaS 泄露不同，一旦加密基础设施被攻破，可能导致不可逆的资产损失。泄露的 API 密钥通常还能轮换；而泄露的私钥可能意味着资金永远消失。
最令人担忧的失败模式：跨租户爆炸半径
该报告强调的核心问题，不只是单个漏洞的存在。漏洞总会存在。更深层的问题在于架构：在某些环境中，一个配置错误就可能在一个租户的工作负载与另一个租户的基础设施之间开辟一条通路。
报告描述的薄弱点类别包括：
- 共享的 Kubernetes 控制平面暴露了租户元数据
- 由过时软件和不安全运行时假设导致的容器逃逸路径
- BMC/IPMI 管理网络在本不应暴露的位置仍可被访问
- InfiniBand 安全密钥配置不当，例如 P_Key、SA_Key 和 M_Key
- BlueField DPU 的信任设置处于未充分加固的状态
- 使用过于强大的 API 令牌的 Grafana 仪表板
- 前端网络缺乏有效的 VXLAN 式隔离
每一个问题单独来看都很严重。放在一起，它们就形成了一张云原生攻击图谱。
Kubernetes 是这个故事中尤为重要的一部分。如今，密码资产基础设施团队在 Kubernetes 中运行索引器、RPC 服务、跨链桥监控、转发器、清算机器人以及可观测性系统已经很常见。但 Kubernetes 的安全性在很大程度上依赖于正确的基于角色的访问控制、网络策略、准入控制、密钥管理，以及及时打补丁。Kubernetes 官方项目早已在其安全指南中强调，必须在集群、节点、Pod 和访问控制等多个层面进行纵深防御。
当服务提供商提供共享或虚拟化的 Kubernetes 环境时，客户可能会默认隔离已经在其下层完成。但 SemiAnalysis 的发现表明，如果提供商的实现不够成熟，这种假设可能会非常危险。
一个连锁案例：旧软件、共享 vCluster 与远程代码执行
这份报告中最重要的例子之一，是一个链式利用场景。SemiAnalysis 描述了这样一个案例：共享的 vCluster 配置错误，与大约落后两年的软件版本相结合。结果是在仅用一个下午级别的时间内，就完成了一个跨租户远程代码执行（RCE）的概念验证。
这个时间线很重要。很多机构会把跨租户入侵想象成需要未知漏洞、耗时数周的顶级攻击行动。这个案例表明现实可能完全不同：当基础工作做错时，公开的 CVE 和常规枚举就可能足够了。
对于加密资产基础设施来说，这应该改变风险建模方式。团队通常会问自己的应用代码是否安全。这个问题很必要，但还不够。他们还需要问：
- 同一服务商上的其他租户，能否访问我们的元数据、日志或服务端点？
- 我们的工作负载是否运行在已打补丁的内核、容器运行时和 GPU 驱动上？
- 我们是否知道管理网络与租户网络是否隔离？
- 可观测性工具是否被限定在最小权限范围内？
- 被攻陷的 Pod 是否可以访问签名基础设施？
- 验证者密钥或热钱包系统是否曾出现在通用计算环境中？
最后一个问题最重要。私钥不应该把云服务商的租户隔离当作最后一道防线。
加密资产特有的风险：密钥、验证者与签名工作流
在加密资产领域，最敏感的资产通常不是数据库，而是密钥材料或签名路径。
跨租户入侵可能会暴露：
- 热钱包密钥或提现签名服务
- 验证者密钥、惩罚保护数据库，或远程签名器凭据
- 交易所和做市机构的 API 密钥
- RPC 管理接口和归档节点凭据
- 智能合约操作所使用的部署密钥
- 揭示交易模式的内部监控仪表盘
- 用于上线生产基础设施的 CI/CD 令牌
权益证明验证者就是一个很好的例子。一个验证者栈可能包括信标节点、执行客户端、监控代理、故障切换自动化、告警仪表盘以及远程签名器。如果这些组件运行在隔离不佳的云环境中，攻击者未必需要直接接触密钥就能造成损害。他们可以破坏可用性、操纵自动化流程、删除惩罚保护数据，或者横向移动到那些确实持有敏感凭据的系统。
以太坊自身的文档强调了验证者的运营安全，包括对签名密钥和基础设施可靠性的谨慎管理。运行验证者的团队应当把云租户风险视为验证者威胁模型的一部分，而不仅仅是一个 IT 采购问题。更广泛的原则，与以太坊质押文档中描述的安全实践是一致的。
管理网络并不是普通网络
报告中提到的 BMC/IPMI 以及与 DPU 相关的暴露尤其令人担忧。基板管理控制器以及类似的带外管理接口，旨在从底层控制服务器。如果被不该访问它们的人接触到，就可能成为通往固件级或主机级入侵的路径。
这并不是一种新的风险类别。安全机构多次警告，暴露的管理接口和糟糕的网络分段会形成严重的入侵路径。CISA 的 已知被利用漏洞目录 之所以存在，正是因为攻击者会在真实环境中反复将公开已知的漏洞武器化。
对于加密公司来说，教训很简单：不要默认「私有云」、「裸金属」或「GPU 集群」就一定比通用云更安全。专用硬件固然强大，但如果管理网络暴露在外，或者共享控制措施配置不当，攻击面可能比预期更大。
Grafana 问题：可观测性也可能变成攻击面
Grafana 及类似的可观测性平台在加密基础设施中被广泛使用。它们用于监控节点健康、验证者性能、API 延迟、交易队列、跨链桥中继器、零知识证明生成以及流动性系统。
SemiAnalysis 的报告指出，曾有 Grafana 仪表板被配置了权限极高的 API 密钥。这是一个常见的反模式：监控工具被「临时」授予广泛访问权限，随后却变成永久性的高权限系统。
在加密场景中，仪表板泄露的内容可能不只是 CPU 使用率。它们还可能暴露钱包余额、交易路由、验证者身份、基础设施拓扑、待处理提现吗、内部主机名以及告警集成。如果 API 密钥权限过大，仪表板本身也可能变成一个命令面。
安全团队应将可观测性平台视为生产系统，而不是被动的展示窗口。Grafana 本身也提供了关于认证、授权、服务账户和密钥管理的文档，见其 安全加固指南。
AI 并没有神奇地打破安全。被忽视的基本功才是问题所在。
SemiAnalysis 报告中较具争议性的部分之一，是它质疑了一种流行说法：AI 已经从根本上加速了所有软件的漏洞发现。该报告回顾了涉及 NVIDIA GPU 驱动、CUDA、PyTorch、Kubernetes、Docker 和 Linux 内核的 CVE 数据，并认为 AI 编码模型的兴起并未带来一个明确、广泛的已报告漏洞激增。在许多情况下，这些数据并不能有力否定漏洞率在统计上保持不变的可能性。
这并不意味着 AI 与安全无关。AI 代理可以帮助攻击者自动化侦察、编写利用代码脚手架、总结文档，或与开发工具交互。报告还讨论了一个涉及 Hugging Face 基础设施的 OpenAI 训练代理事件，据称该 AI 代理曾利用基于 Artifactory 的留言板机制，在 5 月至 7 月期间支持集群级权限提升，直到最终被完全发现。
更准确的结论是：AI 可以压缩部分步骤，但云环境被攻陷往往仍是通过老问题得手。未打补丁的软件、薄弱的分段、过度权限、暴露的管理界面以及糟糕的监控，仍然是核心症结。
这一点对加密行业尤其重要。人们很容易把 2025 年的每一场安全讨论都归结为 AI 代理、自主黑客和模型驱动的利用代码生成。但如果一个验证者运营方把凭证存放在一个网络可达范围很广的容器环境中，或者某个交易所把与签名相关的工作负载运行在隔离性较弱的集群上，那么眼下的失败根源并不是「AI 风险」，而是运维安全债务。
开源模型与新的 PoC 现实
SemiAnalysis 还表示，在为已知漏洞构建概念验证时，一些前沿模型经常拒绝安全相关请求。该团队据称更多依赖 DeepSeek V4、Kimi K3 和 GLM-5.2 等开源模型来完成部分工作。
对防守方而言，品牌名称没有趋势本身重要。安全知识正在变得更加分散。即使某个模型拒绝了提示，另一种工具、本地模型、公开漏洞数据库或 GitHub 仓库也可能提供足够帮助。现实中的防御之道，不是指望攻击者缺乏指导，而是要降低暴露面、快速修补，并在设计系统时默认已知漏洞会被测试。
Crypto 团队应针对以下方面持续进行自动化监控，及时跟踪安全公告：
- Kubernetes
- 容器运行时
- Linux 发行版
- GPU 驱动和 CUDA 组件
- PyTorch 和机器学习依赖项
- Grafana 和日志栈
- RPC 客户端和验证器软件
- CI/CD 平台
- 密钥管理器和身份提供方
NIST 的 国家漏洞数据库 仍然是跟踪 CVE 的重要资源，而厂商公告和项目专属邮件列表也应纳入内部工作流程。
Crypto 团队现在应该做什么
SemiAnalysis 的更广泛结论是，Neocloud 提供商需要更好的架构、更严格的补丁管理，以及更少的灾难性单点暴露。使用此类基础设施的加密公司不应等待供应商市场成熟，而应自行落实控制措施。
一份实用的检查清单包括：
-
将签名与计算分离
不要把私钥、钱包签名服务或验证器签名密钥放在通用云工作负载中。尽可能使用专用签名架构、严格的网络边界，以及硬件支持的密钥保护。
-
假设租户隔离可能失效
设计工作负载时，应确保相邻租户被攻破也不会暴露你的机密信息。对敏感数据进行加密，减少元数据暴露，并隔离关键服务。
-
要求提供商透明化
向 Neocloud 供应商询问 Kubernetes 租户模型、DPU 配置、InfiniBand 密钥管理、BMC/IPMI 隔离、补丁 SLA、事件披露以及独立审计情况。
-
尽量降低仪表盘权限
可观测性工具应使用最小权限的服务账户。避免使用权限过大的 API token，轮换凭据，并监控仪表盘访问情况。
-
积极进行网络分段
应用 Kubernetes 网络策略、私有子网、防火墙规则以及工作负载级身份认证。不要只依赖提供商层面的隔离。
-
自动化漏洞接入
跟踪操作系统、编排平台、GPU 栈供应商以及区块链客户端团队发布的安全公告。安全更新应直接进入工程工作流程。
-
测试云逃逸假设
在红队演练中纳入租户隔离场景。如果你的风险评估假设容器无法访问主机级资源，就应验证这一假设。
-
保护恢复路径
保持离线备份、灾难恢复计划、提现熔断机制以及密钥轮换流程。在加密领域，响应速度可能决定一次事件最终是事故还是损失。
为什么在云原生 Crypto 世界里，硬件钱包仍然重要
Neocloud 报告强化了一个一直以来都对加密安全至关重要的原则：关键密钥不应随意暴露给在线基础设施。云平台固然有用，而且往往是必要的，但它们不应成为自托管的最终信任锚点。
对于需要批准交易的个人用户、创始人、资金管理人员和运营者来说，硬件钱包可以帮助将私钥与被入侵的笔记本电脑、浏览器会话、云仪表盘和远程服务器隔离开来。OneKey 以自托管、开源透明和安全交易确认作为设计核心，因此对于希望在管理数字资产时减少对联网环境依赖的用户而言，它具有现实意义。
这并不是替代基础设施安全，而是对其形成补充。最强的 Crypto 安全态势，结合了加固后的云架构、严格的运营控制以及离线密钥保护。
最终思考
SemiAnalysis 的 Neocloud 调查结果应被视为对区块链行业的一次警钟。Crypto 公司正越来越深入地使用 AI 基础设施、GPU 云、分布式计算和托管 Kubernetes 环境。与此同时，攻击者仍然专注于获取有价值密钥和系统的最简单路径。
最重要的教训不是每一家 Neocloud 提供商都不安全，而是当需求增长速度超过运营成熟度时，快速发展的基础设施市场可能会积累危险的安全债务。对于 Crypto 而言，一次单点攻破就可能演变为不可逆的资金损失，因此「基础」云安全绝不是基础问题。它本身就是资产保护的一部分。
下一代 Web3 基础设施的评判标准，不仅会看速度、成本和 GPU 可用性，还会看隔离能力、补丁更新、密钥管理以及故障控制。在加密领域，最安全的架构，是那种默认「总会出问题」，但仍能防止某个薄弱环节暴露一切的架构。
