virtualization.info 日本語

VMworldカンファレンスがもう1週間後に迫っており、VMware社の競合各社にとっては、論争や同イベントの妨害を始める理由が1つ増えた。

一番の話題になっているのが攻撃対象領域に当てはまるハイパーバイザーの本体容量で、これはプラットフォームの全体的なセキュリティレベルを予測する際にも関連する。

Hyper-Vのメインバージョンにはその親パーティションとしてWindows Server 2008の完全版が付属するため、これはVMware社がMicrosoft社に対する一定の優位性を主張してきた分野の1つだ。
VMware社では現在、これを主要セールスポイントの1つと考えており、これを自社サイトで大々的に宣伝している。

Microsoft社は2週間前、一連のパッチ適用でハイパーバイザーの本体容量がどうなるのかを分析したが（パート1, パート2、およびパート3）批判には対応を取らなかった。

VMware社の方は、Console Operating System（COS）が付属しない軽量のESXiハイパーバイザーとフルバージョンのHyper-Vを自社サイトで比較している。Microsoft社にとってより公平な比較をするなら、ESXiと軽量のHyper-V Serverとを比較すべきだろう。
それにもかかわらず、同社は3種類の分析（重要なものとセキュリティパッチだけを含めたもの）を用意してきた。

• Hyper-V Server 2008対ESXi 3.5|2008年6月 - 2009年6月
  Hyper-V：26件のパッチで本体容量が82Mバイト増加
  ESXi：13件のパッチで本体容量が2.7Gバイト増加
• Windows Server 2008 Hyper-V対ESX 3.5|2008年1月 - 2009年6月
  Hyper-V：32件のパッチで本体容量が408Mバイト増加
  ESX：85件のパッチで本体容量が3Gバイト増加
• Windows Server 2008 Hyper-V対ESXi 3.5|2008年1月 - 2009年6月
  Hyper-V：32件のパッチで本体容量が408Mバイト増加
  ESX：13件のパッチで本体容量が2.7Gバイト増加

パッチ未適用の場合、Microsoft社では2つのプラットフォームで実際に攻撃を受ける可能性があるのは（ハイパーバイザーと仮想化スタックの合計が）ESXで32Mバイト、Hyper-Vで20Mバイトだと強調している。

VMware社も先週の終わりに正式な回答を出してきた。 
最初はパッチ未適用時のハイパーバイザーの本体容量だ。

…

Hyper-Vシステムのコードが何行になるのかは知らないので、インストールしたディスクの容量（仮想マシンのサポートに必要なファイルのインストールサイズ）をコード行数の妥当な代用値として採用した。

…

「df -h」コマンドを実行すると、「/bootbank」に対応するディレクトリ内の圧縮されたESXiブートイメージの合計サイズが59.3Mバイト（公表している70Mバイトよりやや少ない値）であることが分かる。

…

比較として、ESX 4.0「Classic」のディスク本体容量は約1.7Gバイトとなっている。  本体容量増加分の大半はLinuxベースのサービスコンソールが要因となっている。

Hyper-V R2 RTMで測定したディスク本体容量の方がはるかに大きかった。  Hyper-Vを有効にしたWindows 2008 R2 Server Coreは3.6Gバイトだった。  「見慣れたWindows」を残したいHyper-Vユーザの場合、Windows Server 2008 R2のフルインストレーションは10Gバイトに達する。

確かに、ESX「Classic」はLinuxベースのサービスコンソールを使用し、そのためにディスク本体容量も増えるが、VMware社はOSフリーのESXiアーキテクチャがわれわれの未来の方向性であることを公言しており、ESXiにはESX「Classic」の全機能が搭載されている。  Microsoft社では、Hyper-VのWindows依存を排除するような姿勢を見せていない。…

そして、パッチ適用後の本体容量だ。

…

ESXiはアプライアンスのようにインストールしてパッチを適用する（イメージ全体が交換される）ので、パッチが必然的にESXiのフルインストーラパッケージのサイズになる。  インストレーションの一貫性を保証し、実証済みコンフィギュレーションからの「パッチ適用による逸脱」を回避するため、われわれの顧客はこのアプライアンスのアプローチの方を好む。  Hyper-VではWindows Updateベースのパッチ適用手法が採用されており、パッチは小さくすることができるが、顧客がパッチ適用を飛ばしたり、見過ごしてしまうこともあり、これが安全性に欠ける一部パッチ未適用のコンフィギュレーションにつながる場合もある。

…

ESXもESXiも、VMotionやMaintenance Modeが再起動時のVMの代替ホストへの移行を容易にするため、パッチ適用後のホストの再起動には問題がでなかった。  Microsoft社の顧客がこれと同じ機能を待望のHyper-V R2で心待ちにしていることは間違いない。

…

われわれは、Hyper-Vが最初に出荷された2008年6月以来、Server Core Hyper-Vシステムで必要な「月例パッチ公開日」を追跡してきたが、ほぼ毎月、複数の「重要」もしくは「緊急」レベルのパッチが出た。  これらのパッチの大半はHyper-Vには関係のないものだが、ユーザはそれでもこれらをインストールし、ホストを再起動しなければならない。  また、ユーザにはうんざりするほど分かっていることだが、Hyper-V R1がライブマイグレーションをサポートしていないため、再起動のたびにVMにダウンタイムが生じることになる。  ダウンタイムはHyper-V R2で減少するかもしれないが、パッチの数はそうはいかない。…

両者の立場は極めて多岐にわたっており、なおかつ明確になっている。実際のところ、ここまでの引用は両社が分析でカバーした詳細のすべてを要約しているわけではない。

どこが正しいのか判断するためにはすべての記事を読まれることを推奨する。

いずれにしても、ハイパーバイザーのセキュリティは仮想インフラのセキュリティに部分的にしか影響しないということはすべての方に覚えておいていただきたい。
攻撃はどこから来るか分からない。virtualization.infoのセキュリティコラムニスト、Claudio Criscioneが「仮想インフラにおける現実のセキュリティ」（パート1、パート2、およびパート3。パート4は近日中に公開）という自身の連載の第1回でまさにこの話題について書いている。

ラベル: Microsoft, Security, VMware