Oxide这家做服务器机架的公司,最近放出一份内部技术文档,标题起得挺随性——《有人看到我的钥匙了吗?》。问题却一点不随性:如果攻击者真把机柜里的几块硬盘,甚至整台服务器搬走,数据还保得住吗?他们给出的答案是,机架本身就是安全边界——脱离机架,密钥凑不齐,硬盘里的东西就是一堆乱码。这个设计取舍,比"用什么加密算法"有意思得多。
这套方案的核心是Trust Quorum(信任法定人数)加上Shamir门限秘密共享。一个叫Rack Secret的根密钥被拆成N份,分发给机架里的N个节点,凑够K份才能重建,拿到K-1份也学不到任何信息。目前这些份额是明文存在每个节点的M.2硬盘上的,Oxide计划以后靠硬件级的root of trust给份额"加封",逼着攻击者不仅要偷够K台机器,还得让它们开机才能拿到密钥——这比顺手偷几块盘费劲得多。
机架当保险箱,一盘一把锁
从Rack Secret往下,每块U.2硬盘分配独立的ZFS加密密钥,单盘被偷不牵连全架数据。控制面数据、Crucible存储卷密钥、用户认证令牌、内部证书,统一靠ZFS的原生加密盖住。Oxide明确没走硬件全盘加密这条路,理由写得很直白:信不过厂商实现、密钥管理太复杂、供应商还不止一家。
每块盘一把钥匙是有意为之的隔离设计——就算被偷的那块盘密钥暴露,其它盘不受影响。这跟老式保险箱"一格一钥匙"的逻辑差不多。
机架成了保险箱,钥匙成了整架命门。
真正难啃的骨头,在换钥匙的那一刻
Trust Quorum成员一旦增删——新节点加入、旧节点退役、怀疑某个节点被攻破——Rack Secret必须换新。文档在这里态度很硬:哪怕只换份额、不换secret技术上完全可行,Oxide还是坚持每次重新配置都生成全新的Rack Secret。理由很直白:一个曾拿到过旧密钥的恶意节点,只要留着底,未来的新数据照样危险。换secret,至少能保证旧账归旧账,新账保得住。
麻烦在于,ZFS密钥的轮换不等于重新加密整块盘。ZFS手册原话是:密钥轮换由内核模块内部管理,更换用户密钥不需要重新加密整个数据集。这省了大量I/O,却也意味着旧新wrapper key必须同时被知道,才能完成切换。分布式系统里,"同时"是最难兑现的承诺:不是所有节点会在同一时刻得知新配置已提交,而且新配置在正式commit前,还可能经历多次false start——份额已经分发出去,配置最终却没被采纳。
Oxide的解法是给每次重新配置编上epoch号,走两阶段提交:dealer在prepare阶段就把加密后的旧Rack Secret随新份额一起发出去,但这份旧密钥要等新配置真正commit才能解密使用。绕是绕了点,本质是在"尽早分发"和"不过早暴露"之间找的一个折中点。
机架挡得住顺手牵羊,挡不住有备而来
把机架当成安全边界,这个思路我觉得站得住脚。硬件全盘加密这条路,Oxide想都没想就绕开了——不信厂商实现、密钥管理复杂、供应商太多,这个理由摆在明面上,比很多云厂商含糊其辞地说"我们支持加密"要诚实。
但方案里也留了没兜住的口子。贾谊说"众建诸侯而少其力",拆分权力是为了防患于未然;门限密钥的逻辑跟这一模一样,不让任何单一节点手握全部权力。可它防的是随手顺走几块盘的小偷,不是有组织、能凑齐门槛的对手——文档自己也承认,达到K份、拿到可启动的节点,数据照样能恢复。这不是一句"信任法定人数"就能一笔带过的安全上限,而是需要写进威胁模型里的现实。
- 风险.轮换期间新旧Rack Secret必须并存,叠加false start可能反复分发份额,窗口期的暴露面比稳态运行时更大,这部分至今没有一个干净的答案。
- 结论.K-of-N门限设计能挡住临时起意的物理盗窃,但挡不住能凑齐节点数量、还能让它们开机的有组织攻击。
再有一点得说清楚:这份文档里"TBD"和"未来计划"出现得不少——内部证书体系、密钥管理系统,都还在纸面上。这是一份设计方案,不是已经跑在生产环境里的成绩单。
方案讲清楚了钥匙该怎么拆,还没讲完钥匙丢了以后怎么办——这才是接下来真正值得盯着看的地方。