VPSのConfidential Computingとは？

VPS における Confidential Computing の実際の意味

VPS における Confidential Computing とは、プロセッサが仮想マシンのメモリを、ハイパーバイザーが保持しない暗号鍵で暗号化することです。これにより、物理マシンの運用者はサーバーが処理している内容を読み取れません。現在販売されている VPS で、この方式を採用しているものはほとんどありません。通常の VPS では、プロバイダーのハイパーバイザーがゲストのメモリを 1 バイト単位ですべて読み取れます。ディスクを暗号化しても、この点は変わりません。

公開されているガイダンスは 2 つの利用者層を対象としており、VPS テナントはそのどちらにも該当しません。Canonical の Confidential Computing に関する資料は、ハイパースケーラー上で起動するイメージ（特定の Azure サイズや Google Confidential VM）か、所有するハードウェアを Confidential VM ホストにする手順のいずれかです。どちらも、読者がハイパースケーラーであるか、ホストを運用していることを前提にしています。すでに料金を支払っている 4 GB VPS に、これらの機能が実際に適用されるかを説明する資料はありません。まず脅威モデルを定義してください。実用的な回答はすべて、そこから導かれます。

現在、VPS のメモリを読み取れるのは誰か

VPS はゲストです。VPS を作成し、メモリを割り当て、物理コア上でスケジュールする別のシステムが存在します。Linux VPS ホスティングの多くは KVM 上で動作します。この場合、ゲストの RAM はホスト上の QEMU プロセスに属する通常の匿名メモリです。ホストの root ユーザーは、他のプロセスと同じ方法でそのプロセスのメモリを読み取れます。/proc/<pid>/mem を使う方法や、ゲストのメモリ全体をファイルへ書き出す virsh dump を使う方法があります。VM 内の要素でこれを防ぐことはできません。また、VM 内の要素でこれを検知することもできません。実行主体が、検知を行う層を制御しているためです。

これは、特定のプロバイダーの欠陥ではありません。仮想化の仕組み上、当然の動作です。ハイパーバイザーはゲストのメモリを管理するため、メモリを読み取る能力も設計上備わっています。そのため、実際のワークロードに VPS ホスティングを使用して安全かどうかは、技術ではなく、運用者の実務とスタッフのアクセス制御に左右されます。技術だけでは、運用者の操作をまったく制限できないためです。コンテナベースのプランでは境界がさらに薄くなります。LXC または OpenVZ のゲストはホストのカーネルを共有するため、ホストはメモリダンプを作成しなくても、ゲストのプロセスを読み取れます。価格を比較する前に、この違いを理解しておく必要があります。KVM、Xen、LXC の仮想化方式の違いは、ここにあります。

フルディスク暗号化ではこの問題を解決できない理由

VPS のフルディスク暗号化には導入する価値がありますが、この問題には影響しません。LUKS（Linux unified key setup）は、ディスクへ書き込む際にブロックを暗号化し、読み戻す際に復号します。そのため、ボリュームをマウントしている間は、ボリューム鍵を kernel メモリに保持する必要があります。つまり、鍵はメモリ上にあり、復号済みのデータもメモリを通過し、メモリはまさにホストが読み取れる領域です。

保存データの暗号化で得られる効果は確かなものです。建物の外へ持ち出されたディスクは、読み取れないままになります。故障してベンダーへ返却するドライブも保護されます。誰かが放置した切り離し済みのバックアップボリュームも保護されます。これらは、稼働中のホストが稼働中のゲストを読み取るリスクとは異なります。どちらも同じ言葉で説明されるため、「すべてのストレージを保存時に暗号化している」という表現は事実でも、別の問いへの回答になります。

レンタルマシンには、もう 1 つ固有の落とし穴があります。root ファイルシステムを暗号化すると、起動のたびにパスフレーズを提供する必要があります。同じマシン上の keyfile や暗号化されていない initramfs に保存すると、ホストが読み取れます。プロバイダーが運用するコンソールに入力しても、ホストが読み取れます。別の場所から起動時に取得すると、信頼先を移しただけで、信頼をなくしたことにはなりません。鍵を配布するサービスは、要求しているマシンが、想定したマシンであることを確認する方法を必要とするからです。この最後の要件こそ、attestation が解決するために設計された問題です。

AMD SEV-SNP と Intel TDX が実際に行うこと

別々の2つの機能です。これらを分けて考えることが、最も重要です。メモリ暗号化とリモートアテステーションです。

まず、メモリ暗号化です。AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) は、各ゲストに専用のメモリ暗号化キーを割り当てます。このキーは、同じチップ上にある別のコアである AMD Secure Processor 内に保持され、ハイパーバイザーからは見えません。メモリコントローラーは、対象ゲストが所有するメモリに対してのみ、書き込み時に暗号化し、読み出し時に復号します。ホストはそのメモリのダンプを取得できます。ただし、取得できるのは暗号文です。

Intel TDX (Trust Domain Extensions) も、別の方式で同じ結果を実現します。ゲストは trust domain になり、そのメモリには秘密鍵の識別子が付与されます。ゲストの内外へのすべての遷移は、TDX module によって監視されます。TDX module は署名済みの Intel コードであり、ハイパーバイザーが入れないプロセッサーモードで実行されます。テナントから見ると結果は同じです。ハイパーバイザーはメモリを割り当て、CPU をスケジュールできますが、メモリを読み取ることはできません。

SEV-SNP の SNP の部分は見落とされがちですが、重要な役割を担います。暗号化によって、ホストがページを読み取ることは防げます。しかし、ホストがページを移動することまでは防げません。ゲストの物理ページを再マッピングできるハイパーバイザーは、古い内容を再生したり、2つのゲストアドレスを1つのページに割り当てたり、ゲストの下でスワップされたページを返したりできます。これらは、復号せずに実行可能な攻撃へとつながります。SNP は Reverse Map Table を追加します。これは、アクセス時に CPU が参照する構造で、各ページの所有ゲストを記録します。ゲストが要求していない再マッピングは、成功する代わりに fault になります。TDX にも同等の仕組みがあります。この整合性保護層がなければ、受動的なホストに対するプライバシーは得られても、能動的なホストに対する保護はありません。

どちらも変更しない点があります。ホストは引き続き VM を起動し、停止し、CPU コアを割り当てるタイミングを決め、VM を破棄できます。Confidential computing が保護するのは機密性と完全性です。可用性と性能は完全にホスト次第です。そのため、ノイジーネイバーによる CPU steal time はこの仕組みの影響を受けません。

暗号化だけでは証明できないことをリモートアテステーションで証明する

暗号化だけでは、次の点が未解決のままです。プロバイダーに confidential VM を要求すると、VM が提供されます。しかし、メモリ暗号化が有効になっていることをどう確認できるでしょうか。ゲストに尋ねても確認できません。ゲストから見える世界全体をハイパーバイザーが提供しており、そのハイパーバイザー自体を確認しようとしているからです。不正なホストや、単に設定を誤ったホストは、通常の VM をそのまま提供できます。その VM 内で実行するすべてのコマンドには、信頼していない層が応答します。

リモートアテステーションは、この確認の循環を解消します。CPU 自体が署名付きのレポートを生成します。SEV-SNP では、レポートは物理チップごとに固有の鍵で署名され、AMD 自身の証明書チェーンによって認証されます。このチェーンはプロバイダーではなく AMD から取得します。TDX では、Intel が発行したアテステーション鍵に基づく quote が生成されます。レポートには起動時の測定値が含まれます。これは、VM の起動時に存在した正確なメモリのハッシュであり、firmware、kernel、initrd、kernel command line を対象にします。マシンの外部で、シリコンベンダーのルートに基づいて署名を検証し、測定値を想定していた起動内容と比較します。

効果を明確に述べます。アテステーションにより、マシン上にいない当事者でも、そのマシンを信頼するかどうかを判断できます。これを実用化するパターンが、アテステーション後の秘密情報リリースです。データベースのパスワードと復号鍵を、イメージ内に最初から保存しておくことはありません。それらは別の場所にあるサービスが保持し、そのサービスは新しいレポートを検証し、想定した測定値を確認した後にだけ秘密情報を渡します。ホストが変更された kernel を起動した場合や、SEV-SNP を有効にせずに VM を実行した場合、測定値が変わるか、有効なレポートが届きません。その場合、秘密情報はリリースされません。アテステーションなしの暗号化は、すでに信頼すると決めたホストからデータを保護します。信頼するかどうかを自分で決めなくて済むようにするのが、アテステーションです。

ツールはオープンであり、内容を確認できます。snpguest コマンドラインツールは AMD guest 内の /dev/sev-guest device と通信し、レポートを要求して証明書チェーンに対して検証します。ここではプラットフォームの違いが重要です。Azure confidential VM では、通常の方法でこの device を guest に公開していません。そのため、ツールには別の build と別の flag が必要です。アテステーションは動作しますが、すべての環境で同じように動作するわけではありません。

Confidential Computing が保護しないもの

侵害されたゲスト。 SEV-SNP は外部から VM を保護します。すでに内部へ侵入した攻撃者については何も保証しません。CPU から見ると、その攻撃者もあなた自身だからです。パッチが適用されていない Web アプリケーションや、自分の kernel への container escape は、confidential VM 上でも同じように成立します。ホストもそのメモリを検査して支援できないため、暗号化は侵入者のためにも機能します。RAM が暗号化されていても、侵害後の VPS の復旧が容易になるわけではありません。

自分のアプリケーション。 境界は VM の端で止まります。コードがログファイルへ書き込むデータや、third-party API へ送信するデータは、TEE（trusted execution environment、保護された領域の名称）の外へ出ています。暗号化されたメモリによって、コードが監査されるわけではありません。

盗まれた認証情報。 attestation report は、どのソフトウェアが起動したかを示します。その後に誰がログインしたかは示しません。漏えいした SSH key があれば、他の VM と同じように confidential VM に侵入できます。そのため、これを読むほぼすべての人にとって、VPS の SSH アクセスの強化のほうが依然として重要です。

メモリ以外のすべて。 SEV-SNP と TDX は RAM を暗号化します。自分で暗号化しない限り、virtual disk、network traffic、snapshots、backups は保護されません。hyperscaler の confidential VM 製品では、OS disk は独自の key management を備えた別の仕組みで処理されます。CPU 機能が OS disk に及ばないためです。

物理攻撃。これは扱いにくい問題です。 公開された一連の研究により、memory bus は弱点になり得ることが示されています。BadRAM（CVE-2024-21944、2024）は、メモリモジュール上の SPD chip を改変し、約十ドルの部品で CPU に物理アドレスの alias を作らせました。Battering RAM（2025）は、CPU と DRAM の間に約50ドルの interposer を設置し、その対策として追加された起動時の alias 検査を回避しました。TEE.fail（2025）はこの手法を DDR5 に拡張し、server hardware 上の現行 Intel および AMD confidential computing に対する ciphertext の抽出を報告しました。Deterministic memory encryption も関係します。同じアドレスにある同一の plaintext は同一の ciphertext になるため、学術研究ではこれ自体が side channel に利用されています。これらの攻撃には、いずれもマシンへの物理アクセスと、対象を単独で扱える時間が必要です。誰がその条件に該当するかに注目してください。Confidential computing は、ホストによるメモリの読み取りを、1つのコマンドで行える状態から、hardware、物理アクセス、労力を必要とする状態へ変えます。これは実質的かつ大きな改善です。ただし、「ホストには読み取れない」と言うよりは、限定された主張です。

機密性の高い VPS は今日購入できますか

2026年8月時点で、Confidential VM は大手クラウド事業者の製品ラインです。Microsoft Azure では SEV-SNP 対応サイズと TDX 対応サイズを提供しています。Google Cloud では Confidential VM を提供しています。AWS では、一部のリージョンにある限られたインスタンスファミリーで AmdSevSnp CPU オプションを利用できます。独立系の VPS ホストがこの機能を掲載している例はほとんどありません。SEV-SNP 対応を明示する事業者も少数ありますが、数が少ないため、想定せずに問い合わせるのが確実です。

その理由は構造的なものです。理由を把握しておけば、得られた回答を正しく判断できます。

• 使用するシリコンが限定されます。SEV-SNP には第3世代 AMD EPYC 以降が必要で、TDX には比較的新しい Intel Xeon Scalable が必要です。コアあたりの価格を基準に何年もかけて調達したフリートは混在するため、この機能を使えるノードと使えないノードが生じます。
• ホストソフトウェアが新しいものです。Ubuntu は 24.04 LTS から SEV-SNP ゲストをサポートしていますが、ホスト側の対応（QEMU と OVMF firmware の有効化）はそれより後の 25.04 で導入されました。これは、安定運用を重視するホスティングプラットフォームが採用するスタックより新しいものです。
• ライブマイグレーションが難しくなります。実行中のゲストをホスト間で移動するにはメモリをコピーする必要がありますが、ホストはそのメモリを読み取れません。プロバイダーはメンテナンスのためにノードからゲストを退避させる際、ライブマイグレーションを使います。そのため、これが使えないとプラットフォーム全体の運用方法が変わります。
• 密度が低下します。1台のホストで同時に実行できる Confidential VM の数はハードウェアによって制限され、大規模なノードで実行できる通常のゲスト数を大きく下回ります。低価格の VPS は、この高い密度を前提に成り立っています。
• Attestation は継続的なサポート負担になります。テナントが証明書チェーンを取得でき、どの測定値を期待すべきか把握していなければ、レポートには意味がありません。そのためプロバイダーは、firmware の更新ごとに変化する情報を公開し、維持する必要があります。

これは、どのプロバイダーへの批判でもありません。この機能が現在の位置付けになっている理由を説明するものです。

ホストで SEV-SNP または TDX が利用可能か確認する方法

サポート窓口は、質問された内容に答えます。曖昧な質問をすると、意味のない安心材料になる回答が返ってきます。データが暗号化されているかを尋ねると、保存時にはすべてのストレージが暗号化されているという説明を受けます。これは事実ですが、ディスクについての説明です。代わりに、対象を限定した質問をしてください。次の5つは、そのまま送る価値があります。

1. ゲストで AMD SEV-SNP または Intel TDX を有効にしたインスタンスを提供していますか。提供している場合、どのプランですか。
2. これはインスタンスの作成時にインスタンスごとに選択できますか。それとも、利用者が選択できないホストの属性ですか。
3. ゲスト内からハードウェア構成証明レポートを取得できますか。また、/dev/sev-guest は含まれますか。
4. そのレポートを CPU ベンダーに対して検証するために必要な証明書チェーンを提供またはパススルーしていますか。
5. 対応するリージョンとホスト世代はどれですか。また、サイズ変更や移行に制限はありますか。

回答は次のように読み取ります。質問1への回答が yes で、質問3と4への回答が no なら、検証できないメモリ暗号化を利用していることになります。再販されたメモリモジュールへの対策としては一定の価値がありますが、ホストに対する対策としての価値は限定的です。これは、事業者の説明を信頼しなくて済むことが目的の機能について、事業者の説明を信頼しているためです。コンプライアンスや暗号化全般について説明する回答は、no と同じです。質問5への回答がない場合、通常は1つのリージョンにある1つのインスタンスファミリーだけを意味します。

料金とインスタンスの選択肢については、単純な追加料金ではなく、選択肢が狭くなると考えてください。Confidential サイズは、サイズ数とリージョン数が少ない別のファミリーとして提供される傾向があります。実際のコストは、時間単価よりもこの制約になることがよくあります。実際に運用するサイズの料金を確認してください。

既に利用している VPS の確認方法

これらはゲスト内で実行し、1 分ほどで完了します。表示内容は確証ではなく、有力な手がかりとして読み取ってください。ゲストから見える情報はすべてハイパーバイザーを介しているためです。

systemd-detect-virt
systemd-detect-virt --cvm

1 つ目は、kernel が検出した仮想化技術を表示します。2 つ目は Confidential VM の技術を報告し、sev、sev-es、sev-snp、tdx などの値を返します。--cvm は新しい選択肢なので、システムが認識しない場合は先に systemctl --version を実行してください。

sudo dmesg | grep -i -E 'sev|tdx|memory encryption'
sudo journalctl -k | grep -i -E 'sev|tdx|memory encryption'

AMD のメモリ暗号化を有効にして実行しているゲストでは、Memory Encryption Features active: で始まる boot 行が表示され、使用中の技術がその後に列挙されます。Trust Domain では、boot 初期段階に独自の TDX 行が表示されます。長時間稼働しているサーバーでは dmesg ring buffer がラップアラウンドし、boot メッセージが破棄されている可能性があるため、journalctl 形式も実行してください。

grep -m1 ^flags /proc/cpuinfo | tr ' ' '\n' | grep -i -E 'sev|tdx'
ls -l /dev/sev-guest /dev/tdx-guest

CPU flags は慎重に解釈してください。/proc/cpuinfo は hypervisor が表示用に選択した CPU モデルを示すため、sev flag があっても、実際の silicon がその機能をサポートしているだけで、VM が使用しているとは限りません。tdx_guest のほうが直接的な指標です。この flag はゲスト自体を示すためです。Attestation tool が必要とするのは device file です。AMD では /dev/sev-guest、Intel では TDX guest device が該当し、ls を実行すると、存在しない場合はそのような file がないことが明確に報告されます。プラットフォームによっては、VM が Confidential VM であっても device をゲストから意図的に隠すことがあります。そのため、この確認は裏付けにはなりますが、否定材料にはなりません。

何も検出されなければ、そのサーバーの答えは「いいえ」です。通常の VPS hosting では想定される結果であり、問題が発生していることを示すものではありません。

答えが「いいえ」の場合に行うこと

実際には「いいえ」になるでしょう。重要なのは問いを諦めることではなく、その答えによって生じるコストを小さくすることです。いくつかの習慣で大部分に対応でき、特別なハードウェアも必要ありません。

box から出るデータは、box 上で暗号化する。 バックアップが最も重要です。restic や age などのツールは、データが保存先に到達する前にクライアント側で暗号化します。そのため、ストレージプロバイダーが保持するのは暗号文だけで、鍵を保持することはありません。自分で運用するサーバー間のトラフィックにも TLS（transport layer security）を使用してください。プロバイダーのプライベートネットワーク内であっても同様です。プライベートネットワークも、自分で管理していないネットワークだからです。

secret をイメージや git の外に置く。 VM イメージに埋め込まれた secret やリポジトリにコミットされた secret は、それらを読み取れる全員に公開されます。その人数は、hypervisor を運用する人よりはるかに多い可能性があります。secret は暗号化ストアに保管し、デプロイ時に復号してください。Ansible Vault で secret を暗号化する方法は手順が少なく、ほとんどの小規模なサーバー群には十分です。

各サーバーが信頼する範囲を限定する。 これは結果を変える習慣です。このマシンのメモリ全体を攻撃者に読み取られた場合、その攻撃者が何を持ち去れるかを考えてください。10 年分の顧客記録を復号できる鍵が含まれるなら、hypervisor は問題の半分にも達していません。その鍵は、外部公開された Web サーバー上に置かれているからです。各 box には、役割を果たすために必要な最小限の credential だけを与えてください。有効期間を短くし、実際に試したローテーション手順も用意します。そうすれば、ホストにメモリを読み取られても、その box がもともと実行できた操作の範囲に被害を限定できます。

ローテーションできない VPS に鍵を置かない。 ローテーションは、現実の環境でも機能する対策です。このページの他の内容は、問題を発見できることを前提にしています。発見できない場合に行うのがローテーションです。

実際に攻撃されている箇所を修正する。 ほとんどの読者にとって、breach に至る現実的な経路は、データセンターの技術者が RAM を読むことではなく、未パッチのサービスや盗まれた credential です。サーバーに既知の CVE がないか確認することや、Ubuntu Pro がサーバーのパッチ適用範囲に追加する内容を確認することは、CPU の機能よりもリスク低減に役立ちます。新しいマシンでは、新しい VPS で最初の 10 分間に行うことが、最も低コストで実施できる対策です。

ハードウェアによる信頼境界が本当に必要なワークロードが 1 つあるなら、そのワークロードだけを対象にしてください。その部分を、該当するサービスを提供するプロバイダーの confidential VM、または自分で管理するハードウェア上で実行し、残りは費用を抑えられる環境に残します。機密性に応じてシステムを分割するのは一般的なアーキテクチャであり、現在利用できます。confidential VPS については、まだ同じことが言えません。

FAQ

VPS プロバイダーはサーバーのメモリを読み取れますか？

一般的な VPS ホスティングでは、読み取れます。ハイパーバイザーがゲストの RAM を割り当ててマッピングするため、ホスト上の root ユーザーは、たとえば /proc/<pid>/mem の QEMU プロセス経由で読み取ったり、ゲストのメモリをファイルにダンプしたりできます。ゲスト内の機能で、それを阻止したり検知したりすることはできません。AMD SEV-SNP と Intel TDX はこの機能をなくすための技術ですが、ほとんどの VPS プランでは提供されていません。通常の VPS でプロバイダーによるアクセスを制限するのは、技術ではなく、プロバイダー独自の管理策とスタッフ向けのポリシーです。

フルディスク暗号化で、ホスティングプロバイダーから VPS のデータを保護できますか？

サーバーの稼働中は保護できません。ファイルシステムを読み取るにはボリューム鍵をカーネルメモリに保持する必要があるため、鍵と、鍵で処理されるデータの両方が、ホストから読み取れるメモリ上に存在します。ディスク暗号化は、保存中のデータを保護します。たとえば、故障してベンダーに返却されるドライブや、切り離されたまま忘れられたバックアップボリュームなどです。これらのリスクには対策する価値があります。ただし、稼働中のホストが稼働中のゲストを読み取るリスクとは別のものです。

VPS が AMD SEV-SNP または Intel TDX を使用しているか確認するにはどうすればよいですか？

ゲスト内で systemd-detect-virt --cvm を実行し、続いて sudo dmesg | grep -i -E 'sev|tdx' と ls -l /dev/sev-guest を実行します。AMD のメモリ暗号化が有効なゲストでは、Memory Encryption Features active: で始まるブート行が表示されます。Intel の trust domain では、/proc/cpuinfo に tdx_guest フラグが含まれます。これらの結果はすべてハイパーバイザー経由で取得されるため、判断材料にとどまります。唯一の証明は、マシンの外部で CPU ベンダーの証明書チェーンに照合して検証する、署名付きのアテステーションレポートです。

メモリ暗号化に加えて、アテステーションで何が得られますか？

暗号化が実際に有効であり、想定したソフトウェアでマシンが起動したことを証明できます。検証できないメモリ暗号化では、運用者の説明を信頼する必要があります。アテステーションレポートには CPU の署名が付与され、ファームウェア、カーネル、initrd、カーネルコマンドラインを含む VM の初期メモリの測定値が格納されます。また、マシンの外部でシリコンベンダーのルート証明書と照合できます。これにより、別の場所で保持する Secret を、レポートの検証に成功した場合だけ VM に渡す構成を実現できます。

コンフィデンシャルコンピューティングに追加料金を支払う価値はありますか？

インフラストラクチャーの運用者を脅威モデルに含めるかどうかで決まります。規制対象のデータや、他者のデータを保護する鍵を扱う場合、利用できる唯一の技術的な対策です。ハイパースケーラーのコンフィデンシャルインスタンスの料金は、代替策と比べれば小さいものです。個人サイトや小規模サービスの場合、同じ費用をパッチ適用や認証情報の適切な管理に使うほうが、より高いセキュリティを得られます。ハードウェア機能を探す前に、自分がどちらの環境を運用しているのかを正直に判断してください。