Oxide、盗難ドライブからのデータ漏洩を防ぐラック単位の鍵階層を構想

# Oxide、盗難ドライブからのデータ漏洩を防ぐラック単位の鍵階層を構想

Oxideは、盗まれたハードウェアが攻撃者にとってはるかに役立ちにくくなるようにするラック単位のセキュリティ設計を提示している。最近の意見募集文書で同社は、複数の信頼済みマシンに分割された共有ラックシークレットを中心に構築され、ストレージと内部サービスを保護する鍵の導出に使われる鍵階層を説明している。目的は明快だ。誰かがラックの一部だけを持ち去っても、そこから意味のあるデータを復元できないようにすることである。

設計は信頼クォーラムから始まる。Oxideによると、単一のマスターシークレットを1カ所に保管するのではなく、ラックシークレットをシャミアの秘密分散法で複数のシェアに分割し、信頼済みスレッド上に置かれたブートストラップエージェントに分配する。各エージェントは、ハードウェアのルート・オブ・トラストに結び付けられたプラットフォームID情報を保持するため、シークレットのシェアを移動させる前に、通信相手が誰かをピア同士で検証できる。十分な数のメンバーがそろうと、sprocketsセッションを介して必要なシェアを交換し、ラックシークレットを再構成できる。

そのシークレットがストレージ鍵として直接使われるわけではない。代わりに、異なる用途向けの別々の鍵を導出する階層の根となる。ノートによると、ラックシークレットは、デバイスごとの暗号鍵、内部証明書、その他の保護用素材の導出またはラップに使用できる。これが重要なのは、同社が資産ごとに異なる障害モードを持たせたいと考えているからだ。盗まれたディスクからラックの残りの部分を解除できてはならず、末端証明書が侵害されてもストレージスタック全体が露出してはならない。

ノートはまた、Oxideがハードウェア支援型のフルディスク暗号化に依存しない理由も説明している。同社は、ベンダー管理のディスク暗号化に伴い得る信頼性と複雑性のトレードオフを避けたいとしており、代わりに各U.2ドライブ上のZFSプールのほぼ全体を、ディスクごとの鍵で暗号化する計画だ。鍵はディスク自体には保存されない。現在の設計では、データを復号する前に、攻撃者はラックシークレットを再構成できるだけの数の信頼済みマシンを侵害する必要がある。

この階層は、プラットフォームの他の部分とも連携することを意図している。Oxideによると、ラックシークレットは、内部サービス向けのルート証明書や相互TLS向けの末端証明書の導出に役立つほか、顧客データやコントロールプレーンデータに使われる鍵のラップにも利用できる。言い換えれば、同一の共有信頼基盤で、ストレージ保護とサービスIDの両方を支えることを意図している。ノートによると、将来版ではこれらのシークレットをルート・オブ・トラストで封印し、起動時にしか復号できないようにする可能性があり、攻撃者が盗み出して正常に電源を入れなければならないハードウェアの量が増える。

RFDは、この設計を最終回答ではなく、現時点で機能する回答として位置づけるよう注意を払っている。シークレットをどこでローカルに保持すべきか、移動したデータにどのような物理的または論理的制限を適用すべきか、どの鍵をどの親鍵から導出すべきかについて、未解決の問いを投げかけている。その率直さは有益だ。この文書はマーケティング文ではなく、システムが前提を内包したまま固定化される前に、それらを明記しようとする設計上の試みである。

顧客や運用担当者にとって、実務的なメッセージは、Oxideがラックのセキュリティを中央集権的ではなく集合的なものにしたいと考えていることだ。単一のドライブ、スレッド、サービスのいずれにも、システム全体のロックを解除するのに十分な権限を持たせるべきではない。同社は、信頼をクォーラム全体に分散し、暗号技術をハードウェアIDに結び付けることで、物理的な盗難や部分的な侵害の価値を大幅に下げられると見込んでいる。

イベント日：2026年9月7日