機密VMは中が見えない｜Arm CCA研究解説 | 情報セキュリティーあれこれ

クラウドの機密VM（コンフィデンシャルVM）は「事業者にも中を見せない」ことが売りですが、その裏返しとして持ち主である自社からも中が見えなくなります。2026年8月13日にarXivで公開された査読前論文「RealmEye」は、この盲点に対して、Arm CCAの最も信頼される層に監視機能を置いてVMの中を覗く方式を提案しました。テスト用ルートキットによるプロセス隠蔽とsyscallテーブルのフックを検出できたと報告しています。

Arm CCA自体はまだ本番ハードウェアが出回っておらず、明日から使える話ではありません。ただし「機密VMを使うと既存の監視・バックアップ運用が効かなくなる」という問題は、AMD SEV-SNPやIntel TDXを使う今日のクラウドですでに現実です。導入検討中の情シスにとっては、先に押さえておくべき論点が詰まっています。

この記事でわかること
機密VM（コンフィデンシャルVM）とは何か
なぜ「守られているのに危ない」のか
研究「RealmEye」は何を提案したのか
1. 実験で何が確認できたのか
限界と留意点（ここを外すと誤読する）
今日の実務にどう効くのか
1. 機密VMを入れると、既存の運用の何が止まるのか？
2. 導入検討時に先に決めておくこと
現場目線の所感
情シスはどうすべきか
まとめ
出典

この記事でわかること

機密VM（コンフィデンシャルVM）とは何で、自社のどこで使われうるのか
「守られているのに監視できない」という構造的なジレンマの中身
査読前論文「RealmEye」が提案した方式と、実験で確認できたこと
今日のAzure／Google Cloudの機密VMで実際に使えなくなる機能（公式ドキュメント確認済み）
導入前に決めておくべき運用設計のポイント

機密VM（コンフィデンシャルVM）とは何か

機密VMとは、CPUのハードウェア機能でメモリを暗号化し、稼働中のデータをクラウド事業者やハイパーバイザからも読めなくする仮想マシンです。「保存時（at rest）」「通信時（in transit）」に続く「処理中（in use）」の暗号化、と説明されることが多い技術です。

誰が、どんな場面で使うのか。個人情報・医療情報・決済データなど、クラウド事業者にすら預けたくないデータを扱う業務や、自社の学習済みモデル・推論データを守りたいAI案件で選ばれます。コードを書き換えずに移行できるため、「規制対応のためクラウドに出せなかった業務」の移行先として提案されるケースが増えています。

重要なのは、これが「特別な製品」ではなくVMサイズの選択肢として存在している点です。Microsoftの公式ドキュメントによれば、Azureでは DCasv5／DCadsv5／ECasv5 といった系列（AMD SEV-SNP）や DCesv6／ECesv6 系列（Intel TDX）、NVIDIA H100搭載の NCCadsH100v5 が機密VMにあたります。Google CloudもAMD SEV／SEV-SNP／Intel TDXに対応した Confidential VM を提供しています。「うちは機密コンピューティングなんて使っていない」と思っていても、業務部門やベンダーが規制対応・AI案件の推奨構成としてこれらのVMサイズを選んでいることがあります。まずはクラウド課金明細やIaCのVMサイズ指定に、上記の系列名（先頭が DC / EC で始まるもの）が混ざっていないかを確認してください。

なぜ「守られているのに危ない」のか

機密VMの脅威モデルは「ハイパーバイザとクラウド事業者を信用しない」ことを前提にしています。だからこそ強力なのですが、ここに落とし穴があります。

従来の仮想化環境では、ハイパーバイザ側からゲストVMのメモリを読み取って解析するVMI（Virtual Machine Introspection＝仮想マシン内観）という手法が使えました。ゲストにエージェントを入れなくても、外側から「隠されたプロセス」や「改ざんされたカーネル構造」を見つけられる、という考え方です。

ところが機密VMでは、そのハイパーバイザこそが信用できない存在に格下げされます。結果として、外からの内観は原理的に封じられます。残るのはVMの中に入れたエージェント（EDRなど）ですが、ネットワーク経由の攻撃やサプライチェーン経由で混入した不正なカーネルモジュールによってカーネルレベルを取られれば、そのエージェントに見える世界そのものが偽装されます。

機密VMのメモリ暗号化は外からの覗き見を防ぐ機能であって、中で動くマルウェアを防ぐ機能ではない——この当たり前の事実が、ここで効いてきます。むしろ暗号化が「攻撃者にとっての隠れ蓑」として働いてしまうというのが論文の問題意識です。OS以前・カーネル以下の層に潜られると検知が急に難しくなる構図は、UEFI脆弱性とブートキットやBYOVD攻撃と同じ根を持っています。

研究「RealmEye」は何を提案したのか

一文でいえば、「ハイパーバイザより上位の、CPUが保証する最も信頼される層に監視機能を置いてしまえばいい」という研究です。

舞台となるArm CCA（Arm Confidential Compute Architecture）は、Armv9-Aで導入された機密コンピューティングの仕組みです。従来のNormal world／Secure worldに加えてRealm worldという実行環境を設け、そこで動く機密VM（Realm VM）をホストOS・ハイパーバイザ・TrustZoneのいずれからも隔離します。このRealm worldを管理するのが、R-EL2で動く小さな信頼されたソフトウェア層 RMM（Realm Management Monitor） です。

RealmEyeは、このRMMの中に内観ロジックそのものを実装しました。主なポイントは次の4点です。

設計上の選択	何がうれしいか
監視ロジックをRMM（R-EL2）に置く	信用できないハイパーバイザを経由せずにVMのメモリ・レジスタを読める
保護対象のRealm VMを改造しない	ゲスト内に特権エージェントを入れる必要がない＝エージェントごと欺かれる経路を断つ
自走型（self-driven）の定期スキャン	ハイパーバイザが「スキャンを呼ばない」ことで検査を握りつぶす共謀を防ぐ
結果はハードウェア構成証明（attestation）付きの経路で返す	遠隔にいるVMの持ち主が、検査結果そのものの真正性を検証できる

3番目の「自走型」は地味ですが本質的です。監視のトリガーを信用できない相手に握らせない、という発想は、権限分離の設計として素直に納得できます。4番目の構成証明については、その信頼の起点となる実装自体にも脆弱性が見つかることがある点は、TPM 2.0参照実装の脆弱性の例が示すとおりです。

実験で何が確認できたのか

評価はArm FVP（Fixed Virtual Platform＝Arm公式のCPUシミュレーション環境）上で行われました。検体には Diamorphine が使われています。DiamorphineはLinux向けの公開されたLKM（ローダブルカーネルモジュール）型ルートキットで、syscallテーブルをフックしてプロセスを隠蔽する機能を持ち、暗号採掘プロセスの隠蔽など実際の攻撃キャンペーンでも使われてきた、この分野の定番の検証対象です。

論文は、このDiamorphineによるプロセス隠蔽とsyscallテーブルのフックを検出できたと報告しています。性能面については、オーバーヘッドがプリミティブの呼び出し回数から線形に予測できるとしており、「どれだけ細かく監視すればどれだけ重くなるか」を見積もれる形になっている点が実務的には重要です。

限界と留意点（ここを外すと誤読する）

査読前のプレプリントです。2026年8月13日にarXivへ投稿されたもので、査読を経ていません。結果や主張は今後変わりうるものとして読む必要があります。
評価はシミュレータ上です。Arm FVPでの検証であり、実機での性能・安定性は別途確認が必要です。
Arm CCA対応の量産CPUはまだ広く流通していません。RMEはArmv9.2-A以降のオプション機能で、主要クラウドの標準メニューに載るのはまだ先です（Google CloudのConfidential VM公式ドキュメントにもArm対応の記載はありません）。今すぐ買える製品の話ではない点は明確に区別してください。
「最も信頼される層」にコードを足すトレードオフがあります。（ここからは筆者の考察です）RMMは「小さく保つことで信頼できる」という設計思想の層です。そこへ内観ロジックを追加すればTCB（信頼の基盤となるコード）は太ります。監視機能そのものにバグがあれば、それは機密VM全体の前提を崩しかねません。この観点の評価は今後の議論を待つところです。

今日の実務にどう効くのか

機密VMを入れると、既存の運用の何が止まるのか？

答え：バックアップ・災害復旧・ライブマイグレーションといった、ハイパーバイザ側からVMに触る前提の機能が軒並み使えなくなります。これは研究の話ではなく、すでに公開されている仕様です。Microsoftの公式ドキュメントは、Azure機密VMが以下をサポートしないと明記しています。

Azure Backup
Azure Site Recovery
ライブマイグレーション
Accelerated Networking
ブート診断のスクリーンショット
動的メモリ
Azure Compute Gallery のサポートは限定的

「中が見えない」という性質は、セキュリティ監視だけでなくバックアップや障害調査にも一律に効いてきます。起動しなくなったVMの画面すら見られない状態で原因を切り分ける場面を想像すると、運用設計を後回しにしたときの苦しさが分かります。

導入検討時に先に決めておくこと

可視性の代替手段：外からの内観が使えない前提で、ゲスト内エージェントとログ転送をどう設計するか。EDR／XDRの守備範囲がどこまで残るかは、XDRとEDR・SIEMの違いを踏まえて整理すると議論しやすくなります。
バックアップとDR：プラットフォーム機能が使えない以上、ゲスト内エージェント方式やアプリケーションレベルのバックアップへの切り替えが必要です。導入後に気づくと手戻りが大きい部分です。
構成証明の検証を誰が運用するか：検証結果を誰がいつ確認し、失敗したら誰が止めるのか。仕組みを入れただけで運用が無ければ、証明書の期限切れと同じ形で形骸化します。
そもそも本当に必要か：機密VMは「クラウド事業者を信用しない」ための技術です。自社の脅威モデルにその要件が無いまま採用すると、可視性と運用性だけを失いかねません。

現場目線の所感

この論文を読んで最初に浮かんだのは、「守りを固めるほど自分の目も塞がれる」という、情シスにはおなじみの感覚でした。暗号化を強めればログが読めなくなり、権限を絞れば調査が遅れる。機密VMは、そのトレードオフをハードウェアのレベルで固定してしまう技術です。ソフトウェアの設定なら後から緩められますが、CPUが強制する境界は交渉の余地がありません。

そして厄介なのは、この決定がしばしば情シスの外で下される点です。「規制対応のためにこの構成で」とベンダー提案書に書かれたVMサイズが、そのまま調達に乗る。監視の穴に気づくのは、たいてい何かが起きてログを探しに行ったときです。新しい構成の話が来たときに「それ、バックアップとログはどうなりますか」と一言聞けるかどうかで、後の苦労がまるで違ってきます。

研究としてのRealmEyeに感じたのは、方向性の健全さです。「ゲストに入れたエージェントを信用する」でも「ハイパーバイザを信用する」でもなく、信頼の階層を素直にたどって一番上に監視を置く。軽量EDRの研究のときにも感じたことですが、この分野は「どこを信用の起点に置くか」の設計勝負になってきていると思います。

情シスはどうすべきか

機密VM固有の設定手順は各クラウドの公式ドキュメントが一次情報になるため、ここで独自のチェックリストは並べません。土台となる公的指針を挙げます。

ログ取得・保全と体制づくりの出発点として、IPAの中小企業の情報セキュリティ対策ガイドライン。組織規模を問わず「何をどこまで決めておくか」の目次として使えます。
「見えない環境で事故が起きたら誰がどう動くか」を試すなら、IPAのセキュリティインシデント対応机上演習教材。ログが取れない前提を意図的に混ぜて演習すると、設計の穴がはっきり出ます。
侵入の入口はカーネルルートキットに限らず日常的なメールやWebの操作です。地道なユーザ啓発には、IPAの対策のしおりが配布資料としてそのまま使えます。

まとめ

機密VMは事業者から中身を守る一方、持ち主からも中が見えなくなる。メモリ暗号化は外部からの覗き見を防ぐ機能であって、中で動くルートキットを防ぐ機能ではありません。
査読前論文「RealmEye」は、Arm CCAのRMM（R-EL2）に内観機能を置く方式を提案し、Diamorphineによるプロセス隠蔽とsyscallフックの検出をシミュレータ上で確認した。ただしArm CCA対応の量産ハードはまだ広く流通していません。
「可視性の喪失」は今日の課題である。Azure機密VMはAzure Backup・Site Recovery・ライブマイグレーション・ブート診断スクリーンショットなどをサポートしません。導入検討時に監視・バックアップ・構成証明の運用を先に決めてください。