1. 背景
这两年, 因AI - Infra持续升温, 云上和云下的通算服务器建设节奏显著加快, 智算服务器建设节奏同样明显加快, 一方面, 服务器数量持续增多, 其作为核心基础设施, 承载了海量的训练任务, 承载了海量的推理任务, 承载了海量的Agents任务, 承载了海量的HPC任务, 另一方面, 围绕服务器引入的部件类型不断丰富, 有新的BMC芯片与固件解决方案, 有新的BIOS固件解决方案, 有新款GPU, 有新款RDMA网卡, 还有各类板卡控制器, 正是这样, 服务器固件安全问题愈发紧迫。
从业务视角看开云手机入口app下载开云app官方入口网站，服务器有三个突出的特点：
业务价值处于较高水平, 服务器所承担的训练任务, 以及推理任务, 还有Agents任务和HPC任务, 具备更高的业务价值, 要是出现固件层面的可用性问题, 或者完整性问题, 亦或是可信性问题, 常常会给业务连续性造成更大影响, 也会对运维管理产生更大影响, 还会对数据安全产生更大影响。
部件类型更为多样, 复杂度处于较高水平。伴随 AI-Infra 逐渐演变, 服务器部件的丰富程度差不多是以月为周期在提升。除了 Host CPU 之外, 还涵盖了 BMC、BIOS、GPU、RDMA NIC、UBB 以及各种各样的板卡微控制器, 整机的可信边界也跟着持续不断扩散。
后效风险因资源复用故而强, 此风险涉及多种设备, 对外售卖的裸金属实例是其一, 云上虚拟化实例是其一, 云下的物理机亦是其一, 这些设备皆会历经多次业务切换与租户复用, 倘若底层固件遭污染, 风险便有可能跨越实例生命周期, 进而持续影响后续租户或业务。
2. 整机威胁建模
2.1 整机视角风险分层
2.2 核心攻击路径
从固件安全视角看，服务器威胁场景可以划为三条路线：
主机操作系统, 经由BMC引导工具包, 进而对后续租户展开攻击。攻击者成功接管主机操作系统之后, 借助主机与管理主板控制通路、带内管理接口或者固件服务链路, 去植入恶意的管理主板控制固件, 以此达成持久化控制, 并且在机器回收再利用之后, 持续对后续租户产生影响。
主机操作系统被攻击者操作, 进而进入基本输入输出系统引导工具包状态, 然后去实施攻击接下来使用该系统的其他租户, 在此之后控制住主机操作系统, 接着进一步对基本输入输出系统或统一可扩展固件接口启动链造成污染, 再植入基本输入输出系统引导工具包, 如此恶意控制就能跨越重新安装以及实例回收这个动作而继续存在, 并且在后续其他租户使用的时候依旧能够发挥作用, 是这么一种情况。
如果宿主机或者虚拟机场景里, 若 GPU、RDMA 网卡等板卡或者模组存在固件签名是在启动的时候或者运行的时候被绕过, 那么就有可能会朝着 GPU、RDMA 网卡等高价值目标去植入恶意固件或者 Bootkit。Host/Guest OS 会朝着 Device即 GPU、RNIC 等去植入固件或者 Bootkit , 之后 Bootkit 会去攻击后续租户, 破坏整卡的完整性、机密性以及可用性, 进而影响后续任务、后续租户与业务。
2.3 威胁建模结论
围绕上述攻击路径，服务器的威胁建模至少应形成以下结论：
3. 火山引擎服务器安全最佳实践
3.1 服务器安全架构
3.1.1 签名与密钥管理：数字签名、HSM、PKI
服务器一般会同时承载多类固件, 具体有BIOS、BMC、GPU/DPU/NIC、SSD以及UEFI驱动等情况。只要其中存在任意一环的发布链路出现失守状况, 那么攻击者就有可能将合法升级过程转变为恶意固件投递通道的情形。所以, 固件安全的第一步是要建立起一套具备可追溯、可能够吊销、能够轮换的签名信任体系的步骤。
从工程落地看，这套体系至少包含四个关键层次：
HSM对根密钥和中间密钥施以保护, 根密钥得存于拥有物理防护以及权限审计能力的HSM里边, 于实际展开签名之际, 由HSM在受控边界范围之内达成私钥操作, 外部流程仅仅能够获取签名结果, 而无法导出私钥明文。
PKI对“证书链”以及“授权边界”做了定义，根证书下面, 能够顺着产品线、部件类型、环境以及发布职责进一步去派生中间证书和签名证书, 像主板BIOS、BMC固件、GPU卡固件还有驱动签名能够各自归属于不一样的证书域, 如此一来哪怕某一个子域密钥出现失陷, 也不会直接就扩大成整机范围的信任崩塌。
真实交付物被签名对象覆盖, 固件发布涵盖版本, 适配机型, 组件标识, 算法信息以及必要的manifest, PROT和IROT验签时, 验证的内容是符合当前机型的, 部件的在当前版本策略下允许状况的升级固件集合, 有标点符号。
证书的生命周期, 必然得具备可运营的特性。任何部件之中的固件, 都应当对密钥轮换、证书失效、吊销列表同步以及紧急禁用能力予以支持。不然的话, 一旦出现签名证书泄露的情况, 平台便会缺失能够迅速止血的手段。
最后, 用于解决固件发布可信问题的是数字签名、HSM 以及 PKI 共同作用的结果: 要使设备仅接纳来自授权发行链的固件, 而且当密钥泄露、供应链出现异常或者版本回退攻击发生时, 平台依旧能够通过统一策略来收紧信任边界。
3.1.2, 安全启动, PROT加上IROT达成整机链式验签。
关于安全启动需回答的核心问题, 是服务器处在从上电后直至业务启动的这个阶段, 自始至终是否仅仅是执行被授权过的代码。此一问题特别关键, 要是只有CPU以及BIOS在进行校验, 然而GPU 、DPU 、网卡或者存储控制器固件却处于启动链之外, 那么攻击者依旧有借助部件侧固件获取到持久化控制能力的可能性。
这里, PROT 是 Platform Root of Trust 其意思是整机级的可信根 , IROT 要指的是 Integrated Root of Trust 也就是部件内部的可信根。PROT 解决所涉及的问题是“谁有资格成为整机信任起点” , IROT 解决的相关问题是“关键组件可否能在自己的边界范围之内自证清白”。两者配合之后 , 整机链式验签一般是顺着下面要说的顺序展开:
先由 PROT 建立最初信任锚点, 在不可变的 Boot ROM、eFuse 或等效硬件机制里预置根公钥或其摘要, 设备上电后, PROT 先完成自身完整性检查, 而后校验最早期、权限最高的一跳固件, 像是 BMC 固件啦, 还有 BIOS 固件。
主扳启动链持续朝着上方延展, 于PROT达成主板关键固件校验之后, BIOS/UEFI接着去验证后续的DXE模块、Option ROM、Boot Loader、OS Kernel以及关键驱动。如此一来, 信任链便由“主板能够启动”延伸成“主板仅仅能依照授权路径启动”。
将信任拓展至部件, GPU、DPU、NIC、SSD 等等异类部件、若拥有 IROT/eROT（部分芯片会采用外置信任根）, 便能于本地达成部件固件验签, 如此行事的意义在于, 整机并非默认信任关键部件, 而是要求各个关键部件皆基于硬件可信根予以验证。
如果失败策略起到兜底作用。那么只要其中随便一个关键节点验签存在缺失或不实结果, 相关平台就必须能够实施阻断后续启动的操作, 将部件进行隔离, 并且进入到受到限制的恢复模式之中, 此外还要将该节点排除在资源池之外, 使其无法应对面向外部提供服务工作甚至是售卖行为。
对于服务器来讲, 链式验签的意义在于将主板、加速卡以及外设一同归进同一条受控制动流程里, 这样在接近实质的整机安全界限方面, 相较于单点Secure Boot更为贴近。
因此, PROT加上IROT, 是于异构硬件环境里, 将“平台可信”落实到整机, 在谁先启动、谁验证谁、失败后如何进行处理这些方面, 均有着明确的、能够执行的硬件约束。
3.1.3 可信度量：SPDM + TPM 构建信任底座
若讲安全启动所加以解决的部分是“能不能启动”, 那么可信度量所予以解决的部分便是“现在这台机器究竟处于何种安全状态”。于云上 ECS 的 AI - Infra 场景当中, 此情况直接关联到资源调度、密钥下发、租户隔离以及故障处置, 平台不光是要知晓某台服务器在理论层面支持安全启动, 还得能够证实它眼下的确是以预期配置来运行。
TPM 与 SPDM 分别承担两类能力：
在安全启动这个前提之上, 把SPDM与TPM相结合, 如此一来, 便能够针对服务器达成一套相对而言完整的可信管理逻辑。
可信管理平台作为控制面, 来开展统一比对以及决策。平台会对TPM事件日志、PCR摘要, 还有SPDM返回的部件测量值, 和既定基线予以比较, 判断这台机器可不可以加入资源池, 能不能允许承载高敏感训练任务, 可不可以领取工作负载密钥或者访问受限数据。
用来衡量的结果以反方向去推动业务方面平台所进行的动作, 针对AI-Infra来说, 能够被信任的度量会插入到资源调度之处 , 加入到远程证明之中 , 放置于机密下发之内 , 归入到异常隔离流程里 , 致使那些不符合既定最低标准要求的节点自动降低等级 , 进行阻断操作或者予以迁移。
“代码来自谁”这件事, 签名要告知平台, “是否按授权路径执行”, 安全启动得告诉平台, 而可信度量会更进一步, 回答“这台机器现在是否值得被信任”。
有关AI-Infra, SPDM加上TPM的意义在于, 将底层硬件里的信任传递至上层的控制面, 传递至调度系统, 传递至业务负载, 从而使得"可信计算节点"变为能够被识别的, 能够被证明的, 能依据策略来使用的基础资源。
3.2 服务器安全生命周期管理
3.2.1 安全需求
依据服务器资产状况, 以及相关风险和攻击路径情况进行分析, 再联系业界最佳实践, 从而制订服务器安全需求基线, 该基线涵盖服务器整机、部件以及固件, 并且把这个基线归入产品需求规格之中, 将其作为后续设计和开发的强制输入内容。
3.2.2 安全设计
服务器方案做设计的阶段, 针对具有高风险的安全特性去开展威胁建模, 要明确安全的边界在哪, 识别出关键资产是什么、数据流怎样以及潜在攻击路径有哪些, 对安全风险加以分析并且评估其产生的影响, 据此制定相应的威胁缓解措施, 由此去形成安全设计方案。这个安全设计方案经过技术评审被通过了之后, 才能够进入到开发阶段。
3.2.3 安全开发
需求开发阶段, 要在编码过程里贯穿安全控制措施, 在检视环节贯穿安全控制措施, 在测试全程贯穿安全控制措施, 以此确保设计阶段所定义的安全要求能够得到有效实现, 并且要及时发现实现过程当中的安全缺陷, 进一步及时修复这些安全缺陷。
3.2.4 安全测试
火山云平台安全保障团队, 联合字节跳动服务器团队, 以服务器为核心构建完整验证流程, 此流程覆盖安全测试平台以及安全渗透测试。不同于仅在版本发布前进行一次人工检查, 我们已把部分成熟的固件安全扫描能力纳入日常工程流程。该能力可同时服务于问题发现、版本验收以及风险复核。
在安全可信的测试平台之上, 构建了安全测试基线下的用例库, 还搭建了工具扫描平台。当中, 把好多不同类型的扫描能力, 都归入到了同一个入口处集中管理。针对服务器固件以及与之相关的软件所产生的各类产物, 借助特定工具进行扫描, 其涵盖的范围包括病毒扫描, 端口扫描, Web安全漏洞扫描, 主机系统漏洞扫描, 还有二进制文件漏洞扫描这些方面。
一项安全渗透测试工作, 在自动化扫描之外, 它要结合渗透测试来对服务器整机以及关键部件做进一步的验证, 渗透测试涵盖威胁及攻击路径分析, 还有管理面安全测试, 包括协议与接口测试, 以及凭据与敏感信息安全测试, 之后开展分析输出问题报告与典型案例, 就发现的问题进行风险评估, 再制定消减方案, 最终沉淀为后续版本验收以及案例复盘的输入。
3.2.5 安全部署
处于服务器部署阶段之时, 会开展安全检查, 此检查包含硬件检查, 固件检查以及配置检查, 其目的在于确认设备状态与出厂基线维持一致状态。另外, 在部署阶段还会依据最小化原则来实施安全配置加固工作, 其中涵盖修改出厂默认密码这一操作, 以及更换设备证书这一行为。
3.2.6 漏洞管理
在固件漏洞情报管理这块, 火山云平台安全保障团队跟字节跳动服务器团队一起, 建立了针对服务器产品 的持续感知机制, 之后把开源组件、第三方部件 , 还有供应商固件放进统一的漏洞业务视图里。围绕着服务器产品, 整理开源软件清单、第三方部件清单及相应的版本信息, 并且持续追踪公开漏洞库、开源社区公布的消息、供应商漏洞通报以及邮件等好多类输入来源。这样做所追求的目标, 并非仅仅局限于“察觉到存在漏洞”, 而是要达成一种状况, 在这种状况之下, 漏洞信息能够与特定的服务器产品, 以及部件的型号, 还有版本的状态构建起一种可以进行追踪的对应关系。
4. 案例分享：大规模修复固件漏洞的一次挑战
以公开披露的那个BMC固件任意读写漏洞（CVE - 2023 - 34335）作为例子, 这类问题比较典型的利用路径乃是: 攻击者首先获取到Host OS Ring0权限, 接着借助IPMI的Yafu接口去绕过常规升级的约束, 直接进行BMC Flash的读写操作。对于服务器来讲, 这类漏洞治理的难点并非在于理解单一漏洞的细节, 而是在于怎样在异构硬件以及租户复用还有连续服务约束的情况下, 以可控的方式达成大规模风险的收敛。
4.1 修复难点
源于该固件漏洞造成的影响, 致使风险边界常常会快速地由“单机组件缺陷”延展成为“整机可信性问题”。从修复实践加以观察, 主要难点聚焦于以下四个方面:
难以及时止住损失, 利用漏洞常常直接落在底层刷新以及管理接口这点上面然而传统主机侧监控能够提供线索, 但是很难在不影响正常运维与此同时还能实现可靠拦截存在漏洞的情况。
资产异构程度很高, 对于受影响面的识别极为复杂，服务器常常会在同一个时间覆盖多个不同的CPU平台, 涉及多个不同的供应商, 包含多种不同的固件方案以及多个不同的固件版本, 在短时间之内难以明确受到影响的机型, 也难以确定受到影响的业务。
在线修复时, 影响因素众多, 在升级那段时期里面, 带外管理、远程控制还有部分控制面能力会在不同阶段呈现不可用状态, 而且在这个期间, 有可能会出现个体出现异常这种状况, 需要人工介入去处理等情况, 这属于那种复杂性情形之中的高风险变更。
修补依赖跨角色共同协作, 固件版本核查、机型鉴别、升级开展、业务窗口沟通协调、失败处理以及上游供应商的支持一个都不能少, 整个修补流程需要全链条共同协作紧密配合。
4.2 修复流程
将那类漏洞的实战处置经验相联合, 一条愈发稳健些的修复路径通常涵盖了下面这五个步骤。
先要完成漏洞的定级, 并且确认好攻击链。重点对漏洞是否涉及 High权限针对 BMC/BIOS固件进行渗透, 还有跨租户持久化, 或者涉及管理网络扩展风险的情况展开评估, 只要这三者当中的任意一个成立, 便直接进入到由平台层面进行紧急修复的流程当中。
再去完成受到影响的资产盘点, 以及进行风险分层, 要按照服务器机型完成交叉识别, 通过具体的固件版本完成交叉识别, 依照特有业务形态完成交叉识别, 依据安全启动状态完成交叉识别, 根据资源池属性完成交叉识别。
依据工程可行性来挑选修复路径, 从理论层面来讲, 退役之后进行离线刷写, 以及替换部件, 包含在线升级这些都能够视作治理办法, 然而在云环境里, 修复工程需要于风险收敛速度, 还有业务连续性与实施条件之间达成平衡, 综合考量之后采用最为有利的路径, 要是在线升级属于可行路径, 那么就应当与此同时明确影响范围，以及升级窗口和观测要求。
逐一针对机型进行验证, 并且要提前去编写失败预案, 针对不同的机型, 在修复之前要针对差异展开针对性分析, 从而制定不同的修复失败处置预案, 在升级的时候一旦遇到需要立即执行预案。
按照基于灰度的节奏, 分批次逐步推进, 一直到实现收敛状态。首先开始于可控的环境之中, 接着分步慢慢地拓展到普通业务以及重点资源池范围里；每一个批次和其他批次之间, 都应当预留出用于观测的窗口, 并且把监控所得到的结果、失败的比率以及回退的条件当作下一批次能否进行放量推广的依据。
4.3 最终结果
在历经上述路径进行治理之后, 这类存在高风险的固件问题, 一般而言能够在不依靠整机进行大批量下线的前提条件之下, 达成大规模的在线收敛。以此次本案例所对应的处置实践当作代表, 最终形成了三种具备普遍参考价值的结果:
各类风险迅速地收敛起来, 借助分层识别以及分批升级的方式, 于多数据中心大规模服务器组成的集群之上, 完成了数万台设备的在线修复工作, 极大地缩短了高风险暴露的窗口, 这一切都是事实。
工程路径, 被进行了验证, 实践证实, 硬件外设类漏洞, 并非仅仅只能依靠停机返修, 或者等待自然退役；在充分验证, 且影响告知以及失败预案到位的前提之下, 在线升级同样能够成为可行且能够落地的治理路径。
流程能力得以沉淀, 修复过程不但解决了单次漏洞问题, 还沉淀出针对固件变更的定级机制、验证机制、灰度机制、观测机制及故障处置机制, 为后续同类事件给予了可复用的标准化框架。
4.4 短期演进
4.4.1 服务器BOM与资产监控
一次应急修复取得成功, 这并不表明治理工作就此终止。真正让后续响应速度得以提升的关键之处, 在于将临时盘点能力转化为长期资产能力。所以, 火山云平台安全保障团队当前也对服务器硬件BOM表以及资产表进行维护。
其中, 硬件BOM表描述的是, 这台服务器是由哪些其关键部件来构成的, 典型字段含有整机型号, 还有BMC固件版本, 以及BIOS固件版本, 另外有CPU微码版本, 包括关键外设型号以及对应固件版本；资产表又在于描述, 这台服务器当前所处的位置在哪里, 服务的是什么业务线, 处于什么样的状态之下, 将硬件信息与资源池关联起来, 和实例形态关联起来, 以及和地域关联起来, 还有和租户关联起来, 最后和运维状态关联起来。
这两类表协同起来之后, 我们将后续漏洞响应这个行为, 从原本的“人工搜集”这种工作方式, 提升到了“结构化查询”这样一种范畴:
4.4.2, BMC固件Nday扫描工具, 名为BoardSentinel。
至于BoardSentinel的价值, 那就是, TL;DR, 它并非是要去替代secure boot、可信根以及版本治理, 而是, 要使得固件管理方, 不再是依靠“上游说修了”这种方式, 去判断固件到底是不是真的安全。
基于怎样的缘由才会需要固件扫描工具呢? 火山云平台安全保障团队就此事开展了如下这般地调研:
拿CVE - 2023 - 34335来说, 针对10家服务器标准机厂商的80份BMC固件展开分析, 分析之后, 大约85%依旧处于未彻底修复的状态。有部分厂商将相关能力视作“便于带内升级的功能”, 仅仅是在云厂商定制的BMC固件当中进行额外处理。
负责原始设备制造商/原始设计制造商服务器的供应商, 忽略第三方组件漏洞。
即使云厂商会要求供应商将BMC漏洞进行修复, 然而由于在该行业里, 长久以来一直欠缺针对BMC固件内第三方组件漏洞的威胁评估以及检测能力, 所以很多三方组件漏洞会被无视。
对于服务器来讲就会有这样的情况: 不可以光是信赖厂商所宣称的“已经修过了”这个说法, 不能够单单凭借release note或者版本编号来判断, 不能仅仅依靠人工审计以及单点渗透测试这些方式, 而是需要具备这样一套扫描能力, 这套能力具备能够针对真实厂商固件产物展开分析的特性。
我们研发了BoardSentinel, 它的定位是针对服务器固件产物的分析框架, 所以, 从一套典型的固件扫描框架设计角度而言, 其流程大概能做如下概括:
把 firmware 拆解为 filesystems
遍历所有文件，识别类型并按路径规则筛选开云app官方最新下载地址，并给检测引擎分流
最终汇总 assessment results
从框架设计的角度去看, 能够将它理解成是一套体系, 这套体系是“多解析器 + 多引擎 + 插件化规则”这样的组合模式。
专利公开号：CN121808789A
这里可以用两个典型 CVE 做对比：
站在服务器安全建设角度开云真人app官网登录app,开云真人app在线登录，我们把它放在以下几个场景里：
新平台引进之前进行扫描, 针对上游供应商所给予的BMC固件开展基线扫描行动, 尽可能在传导之前察觉问题。
在版本升级之前进行验收, 新版固件在进入灰度这个阶段之前的时候, 要提前去做规则扫描以及差异分析, 还要交叉验证对应上游供应商的release note。
重大CVE响应, 在行业出现BMC、第三方组件漏洞被爆出之时, 迅速去评估受影响的范围, 避免进行人工逐个机型去翻产物的操作。
供应链治理, 把扫描得出的结果, 反过来用以对 OEM、ODM、标准机供应商进行约束, 促使其修复质量, 并减少那种“光口头声称修复, 实际上并未修复”的状况。
长期进行规则积累, 经过一次次漏洞响应, 将沉淀下来的特征转化成规则库, 逐步把经验转变为平台能力。
4.5 中长期演进
以长远视角来看, 本章节所探讨的修复实践依旧归属于“事件驱动治理”范畴；然而, 第3.1章节当中所阐述的数字签名、链式验签以及可信度量这些内容, 所表征的乃是“默认安全能力建设”。这两者并非呈现出相互割裂的态势, 前者致力于解决当下所面临的风险问题, 后者则起到判定同类问题是否能够从根源上降低重复发生概率的作用。
服务器固件安全的中长期目标, 不是停留在漏洞出现后尽快进行升级, 而是得逐渐演进到这样一种体系化架构, 在发布侧存在签名约束, 在启动侧具备硬件信任根, 在运行态拥有可信度量, 在运营侧有结构化资产视图, 就是要从救火状态转变为面向AI - Infra的默认安全能力。
5. 总结
AI-Infra迅速地发展着, 致使服务器固件安全它可不单单只是单个部件或者单次漏洞方面的问题了, 而是直接同云基础设施可信性挂钩的基础性问题。因BMC、BIOS、GPU、网卡、存储以及各类板卡控制器共同搭建起整机运行的底座, 所以安全建设也必然得从单点加固演变至整机可信视角: 既要留意固件源自何方、是不是被授权执行, 又要关注设备在运行进程里能不能持续证实自身处于可信状态。
所以, 服务器固件安全的长久方向, 不该停留在“察觉到漏洞便尽快去修复”, 而要渐渐构建起可验证、能运营的默认安全能力。借由签名体系、安全启动、可信度量、固件扫描、漏洞情报以及结构化资产视图的持续打造, 平台才能够从依靠上游供应商声明转变为基于证据的信任判断, 从事件驱动的应急治理迈向面向AI - Infra的长期安全底座。
以下这些句子由火山云平台那儿的跟负责安全保障相关事宜的团队, 以及字节跳动的负责服务器相关事务的团队, 一块儿给弄好的。
标签： AI服务器安全 固件安全 威胁建模 火山引擎 最佳实践
还木有评论哦，快来抢沙发吧~