Intel SGXの段階的廃止により、Diamond Rapidsがエンクレーブ対応の最後のXeonに

IntelはIntel SGXを段階的に廃止する方針を確認し、2027年のDiamond Rapids Xeonプラットフォームが、このエンクレーブ技術を搭載する最後の世代になると明らかにした。

この決定は、Intelの機密コンピューティング戦略における大きな章の終わりを意味する。Software Guard Extensions、すなわちSGXは、エンクレーブと呼ばれるハードウェア保護メモリ領域内で、選択したアプリケーションコードとデータを隔離する。今後Intelは、代わりに仮想マシン全体を隔離するTrust Domain Extensions、すなわちTDXへ投資を振り向ける。

この変更は、単なる通常の機能廃止ではない。SGXは開発者に限定的なセキュリティ境界を提供する一方、専用のアプリケーション設計を求める。TDXはより大きな環境を保護しつつ、クラウドプロバイダーや企業インフラチームがすでに利用している仮想マシンモデルに適合する。

Intelによれば、既存のSGXプラットフォームは2030年代初頭までサポートとセキュリティ更新を受けられる。そのため顧客には移行経路を評価する時間がある。ただし、新たな機密コンピューティングプロジェクトは、TDXを中心に構築するか、SGXの限られた将来性を受け入れるか、あるいは別のハードウェアプラットフォームを検討するかという、より明確なアーキテクチャ上の選択に直面する。

Intel SGXの段階的廃止はDiamond Rapidsの後に始まる

Diamond Rapidsは最後のXeon世代としてSGXを維持するが、Intelの長期ロードマップは現在TDXに委ねられている。

Intelは2026年10月9日にこの決定を公表した。同社は、Diamond RapidsがSGXを搭載する最後のXeonプラットフォームになると述べた。Intelはこのプロセッサファミリーを2027年に投入する計画だ。

同社は既存のエンクレーブを直ちに無効化したり、現行のサポートを終了したりするわけではない。機密コンピューティングのロードマップでは、2030年代初頭までセキュリティ更新とプラットフォームサポートを提供するとしている。このスケジュールにより、規制の厳しい企業やインフラベンダーには数年間の計画期間が与えられる。

Intelは2017年に初めてSGXをデータセンター向けプロセッサに導入した。その後、Sapphire Rapidsで主力Xeonサーバープラットフォームにもこの技術を導入した。SGXは、アプリケーションがデータを実際に処理している間の保護に向けた、最も広く知られるアプローチの一つとなった。

従来の暗号化は、保存中の情報やネットワークを通じて転送中の情報を保護する。機密コンピューティングは、ハードウェアで強制される信頼実行環境内にワークロードを配置することで、使用中のデータに対応する。ホスト管理者、ハイパーバイザー、あるいは隣接するワークロードは、保護されたメモリへ直接アクセスできないことが想定される。

SGXはこの考え方をアプリケーションレベルで適用する。開発者は機密性の高い機能とデータを選び、それらをエンクレーブ内に配置する。オペレーティングシステムとハイパーバイザーは、信頼境界の外側に残る。

TDXは隔離の単位を変える。ホストや他の仮想マシンからハードウェアで隔離された仮想マシン、すなわちトラストドメインを作成する。その環境内のアプリケーションは、多くの場合、エンクレーブと非エンクレーブのコンポーネントに分割せずに動作できる。

この違いが、Intelの発表が重要である理由を説明している。同社は、SGXのより小さく専門的な境界よりも、導入しやすい広範な保護境界を選択している。

Intelはまた、市場が仮想マシンの隔離を中心に整合してきたと述べている。主要なパブリッククラウドはすでに、仮想マシン、イメージ、オーケストレーション層、確立された管理ツールを基盤に運用されている。TDXはアプリケーションエンクレーブよりも、こうしたシステムに直接適合する。

ロードマップの最終性は、直ちに計画面での影響をもたらす。組織は引き続きSGX対応システムを購入、導入、保守できる。しかし今後のXeon世代でも同じアプリケーションアーキテクチャが維持されると想定すべきではない。

Diamond Rapidsは現在、二つの役割を担う。Intelの次世代ハイエンドXeonプラットフォームであると同時に、依然としてSGXに依存する顧客にとって最後の橋渡しとなる。

この橋渡しは、ハードウェア更新サイクルが長い組織にとって価値がある。ただし、進む方向を変えるものではない。Intelは今後の機密コンピューティングの取り組みをTDXに割り当てることを公表している。

Intelが今SGXからTDXへ移行する理由

この移行は運用上の現実を反映している。仮想マシン全体を保護する方が、各アプリケーションをエンクレーブ中心に再設計するよりも導入しやすい。

SGXとTDXは重複する脅威から防御するが、求められる責任は異なる。SGXは、セキュリティのために信頼しなければならないコードとコンポーネント、すなわち小規模な信頼コンピューティングベースを構築できる。境界を小さくすれば、攻撃者にさらされるソフトウェアの量を減らせる可能性がある。

この利点にはエンジニアリングコストが伴う。開発者は機密ロジックを特定し、保護されたコードと保護されていないコードの間の遷移を管理し、エンクレーブメモリの制約を処理しなければならない。また、エンクレーブモデルを中心に、アテステーション、シークレットの配布、エラー処理、ソフトウェア更新を設計する必要がある。

こうした要件は、暗号サービス、IDシステム、金融処理、あるいは特に機密性の高いシークレットを扱うアプリケーションでは正当化できる。しかし、組織が何千もの通常のワークロードを保護したい場合には、正当化が難しくなる。

TDXは異なる取引を提示する。インフラチームは、オペレーティングシステム、アプリケーションスタック、補助サービスを機密仮想マシン内に配置できる。既存のワークロードでは、アプリケーション固有の変更が少なくて済む。

IntelはTDXを、より低い総運用コストで利用できる、よりスケーラブルで柔軟なアプローチとして説明している。SGX移行ガイダンスでは、移行の理由として、使いやすさと導入の柔軟性を具体的に挙げている。

クラウドの普及はこの主張を強める。Microsoft Azure、Google Cloud、IBM Cloud、Alibaba Cloud、Volcano Cloudは、Intel TDXに基づくサービスを提供してきた。Red Hat、Canonical、VMwareも、エンタープライズおよびプライベートクラウド環境向けのサポートに取り組んできた。

この周辺ソフトウェアは、プロセッサ機能と同じくらい重要である。機密コンピューティングは、イメージ作成、鍵管理、ポリシー適用、オーケストレーション、監視、リモートアテステーションと連携しなければならない。

アテステーションにより、リモート側はシークレットを開示する前に、保護された環境のIDと想定された状態を検証できる。既存の導入システムに適合できない技術は、専門的なセキュリティ機能にとどまるリスクがある。

データ主権も別の推進要因だ。規制や社内ポリシーでは、情報がどこに存在するかだけでなく、誰がアクセスできるのかがますます問われている。ハードウェア隔離は、クラウド管理者や侵害されたホストソフトウェアへの露出を限定できる。

IntelはTDXを、そのような導入のための技術的制御手段として位置付けている。機密仮想マシンは、基盤インフラが別組織の所有であっても、そのメモリを隔離された状態に保てる。

エージェント型AIは、より新たな需要源を加える。AIエージェントは、企業記録を読み取り、外部サービスを呼び出し、システムを更新し、他のエージェントと情報を交換できる。その実行環境には、認証情報、独自データ、機密性の高い中間結果が集まる可能性がある。

慎重に選定された一つの機能を保護するだけでは、こうしたワークロードに常に適合するとは限らない。AIエージェントは、ランタイム、モデルインターフェース、検索サービス、ツール統合、複数のソフトウェアライブラリに依存する可能性がある。環境全体を隔離する方が実用的な場合がある。

これは、あらゆるセキュリティ問題に対してTDXが本質的に優れていることを意味しない。TDXが、Intelが機密クラウドおよびエンタープライズコンピューティングで主流になると予想する導入モデルに適合していることを意味する。

Intel SGXの段階的廃止は、この賭けを正式なものにする。二つの異なる隔離モデルに無期限で投資する代わりに、Intelはより広範なインフラサポートを持つ一方へロードマップを集中させている。

Intel SGXとTDXは単純なアップグレードではなく、トレードオフである

TDXは信頼境界を拡大することで導入を簡素化する一方、SGXではその境界を小さく保つためにより多くのエンジニアリングが必要となる。

Intel SGXとTDXの最も重要な違いは粒度にある。SGXは選択したコードとデータを隔離する。TDXはゲストオペレーティングシステムとアプリケーション依存関係を含む、仮想マシン全体を隔離する。

この拡大された範囲により、TDXは使いやすくなる可能性がある。一方で、より多くのソフトウェアが信頼コンピューティングベース内に置かれることも意味する。保護されたゲスト内の脆弱性は、そのゲストが利用できるデータを依然として侵害し得る。

SGXは、何を信頼領域に入れるかについてセキュリティチームにより大きな制御を与える。エンクレーブは、オペレーティングシステム、大半のライブラリ、無関係なアプリケーションコンポーネントを除外できる。この構造は、開発者が正しく実装すれば、厳格なコンパートメント化を支援する。

エンジニアリングの負担は大きい。通常のオペレーティングシステム環境向けに書かれたアプリケーションは、システムコール、動的メモリ、ファイル、ネットワーク、大規模なソフトウェアフレームワークに依存している場合がある。機密コンポーネントだけをエンクレーブへ移すには、慎重な分離が求められる。

ライブラリOSは、エンクレーブの内部または周辺で使い慣れたオペレーティングシステム機能を提供することで、この負担を軽減できる。それでも、アーキテクチャ上の判断、互換性テスト、追加の信頼コンポーネントが必要となる。

TDXは問題のより多くをインフラ側へ移す。チームはアプリケーションを機密仮想マシンにパッケージ化し、使い慣れたクラウドツールで管理できる。これにより、既存ソフトウェアポートフォリオ全体での迅速な導入が支えられる。

したがって、セキュリティの比較はワークロードに依存する。

信頼境界

• SGX: エンクレーブ内で選択したアプリケーション機能とデータを保護する。

• TDX: ホスト環境から仮想マシン全体を保護する。

アプリケーションの変更

• SGX: 多くの場合、コードの分離、エンクレーブ対応の開発、または互換性のあるライブラリOSを必要とする。

• TDX: 限定的なアプリケーション変更で、多くの既存ワークロードを実行できる。

運用モデル

• SGX: 個々のエンクレーブを中心に保護とアテステーションを行う。

• TDX: 仮想マシンイメージ、クラウドプロビジョニング、インフラオーケストレーションに適合する。

セキュリティ責任

• SGX: より多くのホストソフトウェアを信頼境界の外に保つが、アプリケーション開発者に追加の設計責任を課す。

• TDX: ホストを信頼境界から除外するが、より多くのゲストソフトウェアを信頼する必要がある。

移行も、単一のプロセッサ設定を置き換えるほど単純ではない。Intelの移行ドキュメントは、SGXアプリケーションを異なるアーキテクチャパターンに分けている。各パターンは異なる移行先につながる可能性がある。

すでにライブラリOSを通じて稼働しているアプリケーションは、比較的少ない変更で機密コンテナまたはTDX仮想マシンへ移行できる場合がある。SGX開発キットを直接利用して構築されたソフトウェアでは、より深い再設計が必要になる可能性がある。

一部のアプリケーションは、何年にもわたってエンクレーブアーキテクチャを維持するかもしれない。また、機密機能を別個のサービスに分割する場合もある。チームは段階的な移行の間、既存のSGXワークロードをより広範な機密環境内に配置することもできる。

リモートアテステーションにも別の違いがある。SGXはエンクレーブコードのIDと測定値をアテステーションできる。TDXはトラストドメインとそのブート環境の状態をアテステーションする。組織は、いつ鍵を解放するか、あるいは保護された結果を受け入れるかを決めるポリシーを調整しなければならない。

チームは、これらの測定値が同じ意味を持つと想定すべきではない。検証サービス、参照値、証明書プロセス、更新ルールの見直しが必要となる。

これは単純なIntel TDX移行ボタンではない。アプリケーション所有者、プラットフォームエンジニア、セキュリティチーム、コンプライアンス専門家が関与するアーキテクチャ・プログラムである。

TDX ConnectはCPUとアクセラレータ間の弱点を狙う

機密AIではプロセッサ、GPU、その他のデバイス間で情報が移動するため、IntelのロードマップはCPUメモリの外にあるデータも保護しなければならない。

機密仮想マシンは、そのCPUメモリをホストから隔離できる。しかし、その保護がアクセラレータや周辺機器へのすべての転送を自動的に保護するわけではない。

このギャップはAIにとって重要である。保護されたワークロードは、プロンプト、モデルパラメータ、埋め込み、あるいは中間結果をCPU環境からGPUへ送る可能性がある。その転送中に、データは当初の信頼境界を離れる可能性がある。

Intelは、保護されたデバイス通信向けに設計された信頼できる入出力アーキテクチャであるTDX Connectを通じて、TDXを拡張する計画だ。その目的は、機密仮想マシンが割り当てられたハードウェアとやり取りする際にも隔離を維持することにある。

Intelはすでに、一部のCPUからデバイスへの転送について、ソフトウェアベースの暗号化バウンスバッファを説明している。バウンスバッファは、宛先側が復号する前に、ホストからアクセス可能なメモリを通じて暗号化データを移動させる。これは機能的な橋渡しとなるが、オーバーヘッドを招く場合がある。

TDX Connectは、より直接的なハードウェア支援パスをサポートすることを意図している。Intelによれば、今後の開発にはより強力なアテステーションと耐量子暗号も含まれる。同社は、すべての機能強化について正確な提供時期を発表していない。

このスケジュールの欠如は重要である。Intelの戦略的方向性は明確だが、顧客には依然として製品レベルの詳細が必要だ。各機能をどのプロセッサ、プラットフォーム、デバイス、ファームウェアバージョン、クラウドサービスがサポートするのかを知る必要がある。

IntelはNvidiaと協力し、CPUとGPUをまたぐ機密コンピューティングの連携を進めている。Nvidiaはすでに、暗号化メモリやアテステーションを含む、選定されたアクセラレータ向けの保護実行機能を提供している。統合モデルは、AIシステム全体にわたる連続した信頼の連鎖を構築することを目指している。

この連鎖は依然として技術的に難しい。CPU、アクセラレータ、ファームウェア、デバイス割り当てシステム、仮想マシンモニター、アテステーションサービスが、保護された環境について合意しなければならない。1つの層の弱点が、デプロイメント全体への信頼を低下させる可能性がある。

Appleは、より広範な方向性を示す目に見える例を提供している。そのPrivate Cloud Compute設計は、専用ハードウェア、検証可能なソフトウェア、外部監査の仕組みを用いてクラウド処理を保護する。Intelによれば、Google Cloudとの拡張ではXeonインフラストラクチャ上のTDX信頼ドメインが利用されている。

この例は、ハードウェアによる隔離だけでは不十分である理由を示している。顧客には、ソフトウェアのアイデンティティ、更新管理、ログ記録、鍵の解放、管理者アクセスに関する証拠も必要だ。

エージェント型システムは、こうした疑問をより緊急のものにする。自律サービスは、データベース、メールシステム、ソースリポジトリ、業務アプリケーションの認証情報を保持する可能性がある。ツールの認証情報を露出したままモデル呼び出しだけを保護しても、重大なギャップが残る。

機密仮想マシンは、エージェントランタイムとそのコネクタを1つの隔離環境内に配置できる。その後、信頼できるI/Oがアクセラレータおよび割り当てられたデバイスとのやり取りの保護に役立つ可能性がある。

このモデルは、TDXに対するIntelの主張を支える。同時に、顧客が検証すべき範囲も広げる。セキュリティは今や、単一のエンクレーブ境界ではなく、接続されたシステムに依存する。

TDXロードマップは、実装の詳細、独立したテスト、クラウドでの提供状況によって評価されることになる。計画されている機能の一覧は、導入可能なハードウェアや再現可能なセキュリティ証拠の代わりにはならない。

セキュリティ実績には慎重さが求められる

SGXもTDXも、ソフトウェア脆弱性、サイドチャネル、独立したセキュリティレビューの必要性をなくすものではない。

IntelはSGX廃止の理由をセキュリティ上の欠陥には求めていない。同社は代わりに、採用状況、スケーラビリティ、導入の簡素さ、そして仮想マシン隔離を選好する業界の動向を挙げている。

それでも、信頼実行環境の歴史は慎重に読む必要がある。研究者らは、機密コンピューティング技術に影響するサイドチャネル攻撃、権限昇格経路、アテステーション関連の弱点を公表してきた。

SGXはいくつかの著名な攻撃ファミリーに直面した。その一部は、投機的実行やマイクロアーキテクチャ上の挙動を悪用し、保護情報を推測した。ほかは、Intelが定義した脅威モデルの外にある実装上のミス、ソフトウェアインターフェース、前提条件を標的にした。

TDXにも広範な精査が必要だった。Intelによれば、リリース前の研究には4人年分のセキュリティ分析が含まれた。この作業では数十件の脆弱性が特定され、12件を超えるアーキテクチャ面または多層防御面の改善につながった。

Googleは後にIntelと協力し、ライブマイグレーションや信頼ドメインの分割を含むTDX 1.5機能の評価を実施した。この研究ではバグが発見される一方、修正や堅牢化作業にも貢献した。

このプロセスは複雑なセキュリティ技術では通常のことである。プラットフォームが安全でないことを証明するものではない。しかし、完全な保護に関する主張が懐疑的に扱われるべき理由を示している。

機密コンピューティングは、特定のインフラストラクチャリスクを狭める。すべての悪意あるアプリケーション、侵害された依存関係、盗まれた認証情報、欠陥のあるアクセス方針を防御するわけではない。保護された環境でも、有害または脆弱なソフトウェアを安全に実行してしまう可能性がある。

脅威モデルとマーケティング表現の違いは重要である。TDXは、信頼できない、または侵害されたホストからゲストを保護することを目指している。そのゲスト内のすべてのコンポーネントを自動的に信頼できるものにするわけではない。

アテステーションは、測定値が期待される参照値と一致することを確認できる。測定されたアプリケーションにロジックエラーがあるかどうかは判断できない。また、信頼できる検証サービスと、慎重に管理された参照ポリシーに依存する。

ライブマイグレーションは別の課題を生む。クラウド事業者は、メモリを露出させたり信頼を損なったりすることなく、保護された仮想マシンをホスト間で移動させる必要がある。この機能には、研究者が検査すべきプロトコル、鍵、状態遷移、追加コードが導入される。

デバイスアクセスはさらに複雑さを加える。信頼できるI/Oは、デバイスの性能と管理性を維持しつつ、ホストが保護されたトラフィックを検査または改変することを防がなければならない。アクセラレータのファームウェアとデバイスセキュリティは、実用上の信頼性を構成する一部となる。

耐量子暗号も同様の疑問を提起する。Intelはこれを将来の投資領域として挙げているが、この表現は異なるアルゴリズムやシステムコンポーネントを含み得る。顧客は何がいつ変わるのかを知る必要がある。

したがってセキュリティチームは、Intel TDXへの移行をSGX保証ケースの自動的な継続ではなく、新たな評価として扱うべきだ。既存の脅威モデル、統制、コンプライアンス証拠は見直す必要がある。

復旧手順も確認すべきである。ハードウェアアテステーションシステムは、証明書、署名インフラストラクチャ、失効メカニズム、信頼されたサービスに依存する。障害やポリシーエラーにより、正当なワークロードがシークレットを受け取れなくなる可能性がある。

ベンダーの多様性も考慮に値する。AMDは、一般にSEV-SNPと呼ばれるSecure Nested Paging付きSecure Encrypted Virtualizationを提供している。これも、ホスト環境の一部から仮想マシンを保護する。

AMD SEV documentationでは、メモリ暗号化、完全性保護、ゲストアテステーションが説明されている。クラウド事業者はAMDとIntelの両方の機密仮想マシンオプションを提供でき、購入者にアーキテクチャと供給面での選択肢を与えられる。

Nvidiaのconfidential computingプラットフォームは、サポート対象GPUへ保護を拡張する。ArmのConfidential Compute Architectureは、Arm環境における保護実行を対象とする。各設計は成熟度、提供状況、脅威の前提が異なる。

したがってIntelは、プロセッサ性能以上のもので競争している。文書化、独立レビュー、クラウド展開、予測可能なセキュリティ保守を通じて信頼を得なければならない。

Intel SGXの段階的廃止は、Intelのロードマップを単純化する。顧客が答えるべきセキュリティ上の疑問を単純化するものではない。

SGX顧客にはワークロードごとの移行計画が必要

最も安全な対応は、今すぐSGXへの依存関係を棚卸しし、その後に各ワークロードを必要な保護境界へ対応付けることだ。

組織は発見から始めるべきである。SGXインターフェースを直接呼び出すアプリケーション、エンクレーブ対応フレームワークに依存するアプリケーション、依存関係を明示せずSGXに支えられたサービスを利用するアプリケーションを特定する必要がある。

マネージドサービスには特別な注意が必要だ。企業は、データベース、ブロックチェーンサービス、鍵管理製品、機密分析プラットフォームを通じてSGXに依存している可能性がある。顧客がエンクレーブを直接運用しているとは限らない。

その後、各ワークロードにセキュリティプロファイルが必要となる。チームは、保護対象資産、想定する攻撃者、信頼するコンポーネント、アテステーションプロセス、性能上の制約、規制上の義務を文書化すべきである。

このプロファイルが、TDXが許容可能な代替手段かどうかを決定する。最小限のエンクレーブ境界を前提として設計されたワークロードは、より大きなゲスト環境へ移行した際に同等の隔離を得られない可能性がある。

ほかのアプリケーションは、より容易に移行できる。主にクラウド管理者から完全なサービスを保護するためにSGXを採用したソフトウェアは、機密仮想マシンによく適合する可能性がある。TDXは、ハードウェア支援によるホスト隔離を維持しながら、カスタムコードを減らせる可能性がある。

Intelの移行ガイダンスは、いくつかの可能な経路を示している。これには、ライブラリOSワークロードの移行、SGX開発キットアプリケーションの再設計、機密コンテナの採用が含まれる。

機密コンテナは、コンテナワークフローとハードウェアで隔離された仮想マシンを組み合わせる。コンテナのインターフェースは使い慣れたまま、信頼ドメインがワークロードをホストから分離する。これは、すでにKubernetesとKata Containersを使用しているチームに適している場合がある。

テストは、アプリケーションの起動以上を対象にすべきだ。チームは、アテステーション、シークレットの解放、アップグレード、バックアップ、復元、可観測性、インシデント対応、ホスト間の移行を検証しなければならない。

性能も測定が必要である。TDX環境はより大きなソフトウェアスタックを保護し、SGXエンクレーブとは異なる方法でメモリを扱う。ワークロードの挙動は、プロセッサ、クラウド構成、デバイス経路によって変化し得る。

組織は、SGXサポートが終了するまであらゆる決定を遅らせるべきではない。規制環境では、ハードウェア調達、アプリケーション再設計、認証、サプライヤー承認に数年かかる場合がある。

同時に、不必要な緊急移行も避けるべきである。Intelは長期のサポート期間を約束しており、Diamond RapidsはSGX対応の次世代製品でもある。チームが代替手段を検証する間、既存システムが適切であり続ける可能性はある。

最も強力な移行プログラムは、旧環境と新環境の双方について証拠を維持する。セキュリティチームは、ハードウェア機能の名称だけでなく、実際の信頼できるコンピューティングベースを比較すべきだ。

調達契約の更新が必要になる場合もある。購入者は、クラウドおよびソフトウェアベンダーに対し、SGXサービスをいつまで提供し続けるのかを確認すべきである。また、TDXサポート、アテステーションインターフェース、信頼できるI/Oの予定についても求めるべきだ。

開発者には明確な責任分担が必要である。インフラストラクチャチームはTDXインスタンスをプロビジョニングできるが、アプリケーションチームは依然として依存関係、シークレット、認可を管理する。機密コンピューティングは、これらの責任をなくすものではない。

この決定は将来のアーキテクチャにも影響する。新しいSGXプロジェクトは、ハードウェアロードマップが狭まる中でもエンクレーブが必要である理由を正当化すべきだ。新しいTDXプロジェクトは、完全なゲストが許容可能なセキュリティ境界である理由を正当化すべきである。

したがってIntel TDXへの移行は、全面的な書き換えではなく、リスクベースのポートフォリオとして進めるべきだ。一部のワークロードは早期に移行できる一方、ほかは残されたSGXサポート期間を活用すべきである。

IntelがTDXを選択した後に注目すべき点

Intelがより整理されたロードマップを、信頼できるコンフィデンシャル・コンピューティング・プラットフォームへと転換できるかどうかを示す、3つのシグナル。

最初のシグナルは、Diamond Rapidsの詳細な提供時期だ。Intelは2027年のプロセッサをSGXの最終世代と位置付けているが、顧客には正確なプラットフォームのスケジュールと製品カバレッジが必要となる。

これらの詳細によって、実際の移行期限が決まる。安定したSGXサポートを備える幅広いDiamond Rapidsポートフォリオは、選択肢を維持することになる。提供範囲が限定されれば、特殊なエンクレーブ環境を展開している顧客への圧力は高まる。

2つ目のシグナルは、実運用可能なTDX Connectサポートだ。Intelは、コンフィデンシャルAIおよびデバイス接続ワークロードに向けた主要な拡張機能として、trusted I/Oを説明している。購入者が必要とするのは、出荷済みのハードウェア、互換性のあるアクセラレータ、ファームウェアに関するガイダンス、そして独立した検証である。

このシグナルは、IntelのエージェンティックAIに関する主張を強めるか、弱めるかのどちらかになる。幅広くテストされたサポートは、TDXがAI処理パスのより大きな部分を保護する助けとなる。遅延が生じれば、ソフトウェアによる回避策と分断された信頼境界が残ることになる。

3つ目のシグナルは、クラウドおよびソフトウェアベンダーの移行行動だ。Azure、Google Cloud、IBM Cloud、Alibaba Cloud、Red Hat、Canonical、VMwareは、すでにTDXエコシステムの一部を構成している。各社のサービスロードマップは、顧客がIntelの方向性に追随するかどうかを示すだろう。

新たなコンフィデンシャル仮想マシンのリージョン、より強力なアテステーションツール、コンフィデンシャルコンテナのサポート、SGXで支えられたサービスからの移行を文書化する動きに注目したい。また、ベンダーが特殊用途の提供形態としてSGXを維持するかどうかも見るべきだ。

競合他社の動きも、有用な比較基準となる。AMD SEV-SNPの採用拡大や、アクセラレータレベルでのより強力な代替手段は、市場が単一ベンダーへ収束せずともコンフィデンシャル仮想マシンを支持していることを示すだろう。

最大の不確実性は、セキュリティの粒度に関わる。TDXの運用上のシンプルさには価値があるが、SGXの狭いエンクレーブ境界を再現するものではない。厳格なコンパートメント分離を求める顧客は、より広い信頼ドメインを受け入れられるか判断しなければならない。

Intelはそうした顧客に時間を与えているが、ロードマップは無期限ではない。Diamond Rapidsは、XeonにおけるSGXの最後に計画された到達点となる。それ以降のすべてのIntelサーバー世代では、新規導入はTDXへと向かうことになる。

開発者とエンタープライズの購入者にとって、次に取るべき行動は具体的だ。SGXが本番システムを保護している箇所を棚卸しし、各エンクレーブが存在する理由を文書化し、TDXが必要な保証を維持できるか検証する必要がある。

終了予定日を号砲として扱ってはならない。サポート期間を活用し、アーキテクチャを比較し、アテステーションポリシーを検証し、ベンダーに具体的な導入コミットメントを求めるべきだ。

IntelによるSGX段階的廃止は、最終的にはエンクレーブの専門性よりも運用規模を重視する選択である。その選択が成功するかどうかは、セキュリティの証拠、エコシステムの実行力、そして実際の移行パスの質に左右される。