導入イントロ：なぜ今、TEE／TDXで“機密AI”を守るのか
生成AIや機密データを扱うワークロードは、クラウド上での処理ニーズが高まる一方で、ハードウェアやクラウド管理者レベルでの不正アクセスリスクも増大しています。コンフィデンシャルコンピューティング（Trusted Execution Environment：TEE）は、これらのリスクを軽減するための重要な技術スタックであり、特にIntelのTrust Domain Extensions（TDX）はVMレベルでの隔離を提供する実務的な選択肢として注目されています。
本記事は、要件定義から設計、運用チェックリストまで現場で使える実務ノートを提供します。最新の実装・運用上の注意点（カーネル／クラウド対応、既知のサイドチャネル脅威、ライブマイグレーション時の留意点など）を踏まえて解説します。
設計フェーズ：要件・脅威モデル・アーキテクチャ選定
1) ビジネス要件とデータ分類
- 保護対象：トレーニングデータ、学習済みモデル、推論時の入力／出力、暗号鍵、ログなどを明確に分類する。
- コンプライアンス要件：GDPR、金融規制（例：DORA）や医療情報保護など、データ処理の法的要件を反映する。
2) 脅威モデル
最低限カバーする脅威：
- クラウド運用者やホストOSの不正操作（内部者攻撃）
- サプライチェーン／イメージ改ざん
- 物理アクセスを伴うサイドチャネル攻撃（研究報告の事例を考慮）
TEEは多くの攻撃から保護するが、万能ではありません。既知の物理側路（例：論文や報告で指摘された攻撃）や実装不備により情報漏洩のリスクが残ることを前提に、補完的な対策（KMS分離、監査ログの外部保護、最小権限化）を設計する必要があります。
3) 技術選定（SGX／TDX／SEV-SNP の比較）
| 観点 | SGX | TDX | SEV‑SNP |
|---|---|---|---|
| 隔離単位 | プロセス／アプリ | 仮想マシン（TD） | 仮想マシン |
| 導入容易性 | 既存コードの改修が必要 | VMベースで比較的導入しやすい | クラウドプロバイダー依存 |
| 適用範囲（AI） | 軽量／低レイテンシ向け | モデル・データを含むフルVM保護に適 | VM全体の保護 |
実務的には、既存のVM運用やGPU活用を前提にする場合、TDXベースのConfidential VMを選ぶケースが増えています（クラウドプロバイダの対応状況を確認）。
運用設計：構成要素と具体的運用ルール
主要構成要素
- ハードウェアTEE（例：Intel TDX）と対応カーネル／ハイパーバイザ
- リモートアテステーション基盤（証明書・エンドースメント管理）
- 鍵管理（KMS）とキー分離／HSM連携
- CI/CD／イメージ署名、SBOM、ランタイム・監査ログの保護
- 監視とアラート（TEE内外のテレメトリを統合して整合性を検証）
運用上の注意点
- アテステーションの自動化：デプロイ時にアテステーションを取得・検証し、合格しない場合はデプロイを拒否する。
- 最小権限と分離：KMSアクセスや運用APIの権限は分離し、運用者と暗号鍵管理者の職務分離を徹底する。
- 証跡の不可変保存：TEE外の監査ログは改ざん防止のため署名＋WORMストレージへ保管する。
- パッチとカーネル更新：TEE関連のホスト側更新は慎重に計画し、再アテステーションとローリングで適用する。
- ライブマイグレーション／スナップショット：TDX等ではライブマイグレーション機能に脆弱性や運用上の制約があるため、設計段階で制限や検証を行う。
実務チェックリスト（導入・移行・日常運用）
以下は現場でそのまま使える簡易チェックリストです。項目ごとに『責任者』『頻度』『合格基準』を決めて運用に組み込みます。
| 段階 | 項目 | 責任者 | 頻度 | 備考 |
|---|---|---|---|---|
| 事前評価 | データ分類と保護要件の確定 | セキュリティPM | 1回（導入時） | 機密度ごとに扱い方を定義 |
| 設計 | 脅威モデルの作成（内部者/物理/サプライチェーン） | リードセキュリティエンジニア | 導入時／年次見直し | 攻撃シナリオを列挙 |
| 実装 | アテステーション自動化の実装とテスト | クラウドOps | 導入時＋変更時 | 合格基準を明文化 |
| 実装 | イメージ署名とSBOMの導入 | DevSecOps | CI実行毎 | 署名検証の阻害は即ロールバック |
| 運用 | KMSアクセス権レビュー | IAM担当 | 四半期 | 権限は最小化 |
| 運用 | アテステーション失敗時のフェイルオーバー手順確認 | クラウドOps | 月次 | リカバリ手順を自動化 |
| 監査 | TEE関連イベントの外部検証（ログ整合性） | 監査チーム | 年次／重大変更後 | 第三者による監査を推奨 |
| インシデント | 既知のサイドチャネル脆弱性対応計画 | IR/セキュリティリード | 初動及び脆弱性発覚時 | 緊急パッチと緩和策の手順化 |
注：TEEは強力な防御を提供するが、研究コミュニティから新しい攻撃手法が報告され続けているため、運用体制として脆弱性対応フローと外部評価を組み込むことが不可欠です。
まとめと推奨アクション（短期・中期）
短期（0–3ヶ月）
- 守るべきデータ/モデルを分類し、パイロットでTDXベースのConfidential VMを検証する。
- KMSとアテステーションの自動化設計を優先する。
中期（3–12ヶ月）
- CI/CD統合（イメージ署名・SBOM）と監査ログの不可変化を実施。
- 外部によるアセスメント／ペネトレーションテストを定期化する。
実務上の心構え：TEE／TDXは“ゼロリスク”の魔法ではありません。ハードウェアや実装の改良、研究発見に対応する持続的な運用プロセスと、アテステーションを中心とした自動化が安全実現の鍵です。最後に、ベンダー／クラウドのアップデート情報とコンフィデンシャルコンピューティングに関する標準（Confidential Computing Consortium等）を定期的にウォッチすることを推奨します。