virtualization.info 日本語

VMware社が2年以上前にVMsafe APIを発表した祭、virtualization.infoはこの取り組みを高く評価し、この技術の出現はセキュリティ業界にとって久しぶりの素晴らしい出来事だと指摘した。それを支えるしっかりした戦略と、適切な実行力があればそうなるはずだった。
それから2年以上が経過したが、VMsafeは今のところ行き詰まっており、戦略の実行状況は完璧にはほど遠いといって間違いない。

VMware社がセキュリティ分野にアプローチできないことがその大きな要因となっているのかもしれない（同社のACE製品は、かなりゆっくりした速度でWorkstationに無償で統合されつつあるとの理由だけで今も存続する大失敗だ）が、真っ先にこの失敗の責任を問うべきは同社ではない。
実際、セキュリティベンダー各社はより効果的かつ効率的な方法で適切に仮想インフラのセキュリティを確保する作業をこれまでのところ全くしていない。
大規模なハードウェア仮想プラットフォームの具体的な採用例は2006年にさかのぼるので、セキュリティベンダー各社の有望な新技術に対するアプローチが慎重であることを加味しても、各社が何かをするための時間は4年あった。だが、2010年になってもMcAfee社、Symantec社、TrendMicro社などのトップベンダーや、無数の小規模ベンダーは仮想データセンタのセキュリティに対する顧客のニーズにまだ対応していない。
さらに悪いことに、ハードウェア仮想化がIaaS（サービスとしてのインフラストラクチャ）クラウドコンピューティングプラットフォームの到来を促進しており、ここではセキュリティの課題がさらに深刻で、前述のセキュリティベンダー各社はまだこの技術に全くコミットしていない。

このことを考慮すると、先週はじめにSynergy 2010カンファレンス（virtualization.infoの記事はこちら）で発表されたCitrix社とMcAfee社の新たな提携が歓迎されるとはどうしても思えない。

では、正確には何が発表されているのだろう？

両ベンダーは、仮想プラットフォーム向けの新しいセキュリティソリューションを二段階に分けて提供すべくコラボレーションを開始した。最初の、2010年中に製品化される現在進行中のものは、仮想デスクトップインフラのセキュリティ確保に重点を置いている。

このアーキテクチャは、既存のものに明らかに似ているようにしか思えない。VDI環境のセキュリティを確保するためには、同期スキャン、マルウェア削除、ウイルスやrootkitsなどの署名のアップデートを複数の仮想マシンで同時に実行するためにリモートから集中管理コンソールに接続された各ゲストOS内にエンドポイント用セキュリティエージェントをインストールする必要がある。

このアプローチで問題なのは、それぞれが同じスキャン／削除エンジンを搭載し、これらの各エンジンがほかのものの行動を認識することなく動作するなど、このような環境内での動作にエージェントが最適化されていない点だ。
このような重複は、物理リソースの無駄（最終的にはホストあたりのVM集約率を下げる）と、エージェントが定時スキャンや署名アップデートを実行する度にI/O処理が不要にピークに達することを暗示している。

McAfee社は、仮想インフラ上での動作に最適化されたエンドポイントセキュリティエージェントによってこの問題を解決しようとしている。Management of Optimized Virtual Environments（MOVE）だ。
これは、パッケージングが軽量になっていて、仮想ハードディスク上でのいくつかの動作を疑似ランダム化するが、何よりもスキャン／削除エンジンを搭載しないことが大きい。
実際、核となる機能はリモートにある専用の仮想アプライアンスでアウトオブバンドで実行される。

最適化されたエージェントが実際に行うのは、感染の可能性がある仮想デスクトップからセキュリティの仮想アプライアンスまで不審なファイルを安全なチャネル経由でコピーする作業だ。

もちろん、McAfee社は解析や除去作業のために各仮想デスクトップの仮想ハードディスク全体をネットワーク経由でコピーしたいわけではないので、それを回避するために多数のトリックを使っている。

まず、ホワイトリストの署名にマッチするOSファイルがすべてコピーされるわけではない。修正されないことが分かっているWindowsファイルを移動する必要はない。
次に、最適化されているエージェントは感染の可能性があるファイルの関連部分だけをコピーする。McAfee社には、ファイルのどの部分にマルウェアが存在するのか分かっていて、そこだけがアウトオブバンドで解析される。

用意されたダイナミックリソース管理（つまりXenMotion）でもこのアプローチが確実にうまくいくよう、McAfee社はマルチホスト仮想インフラにおける各仮想デスクトップの位置と状態を常に把握し、解析が必要な不審なファイルを最寄りのセキュリティサーバへと流す。

すべてが既存のMcAfee ePolicy Orchestratorによってコーディネートされ、それがXenDesktopの推奨バックエンドである限りは複数のハイパーバイザー（Microsoft Hyper-V、VMware ESX、そしてもちろんCitrix XenServerを含む）をサポートする。

その上、Citrix社はほかのセキュリティベンダー各社が活用できるオープンAPIのセット（XenDesktopの一部）をリリースすることでほかのサードパーティーも同じことができるようにしている。
基本的に、ここでCitrix社がしようとしているのは、機能ゲートウェイをコネクションブローカに移動することでハイパーバイザー（つまりVMware）の重要性（および依存）を低めることだ。

2011年に始まる今回の提携の2番目のフェーズでは、VMsafeのようなインターフェースをXenServerとXenClientに提供することに重点を置く。

VMsafe APIの目的の1つが、ハイパーバイザーを単一解析点として使うマルウェア検知で、これが複数のエンドポイントセキュリティエージェントの冗長性排除を可能にする。
VMsafeはそれを実現すべく、マルウェア検知で重要な値検索場所を見つけるためにセキュリティベンダー各社がデコードしなければならない仮想インフラのvRAMに関連する、構造化されていない膨大な量の情報を返す。

Citrix社とMcAfee社が開発に携わるAPIのアプローチは異なる。これらのセキュリティAPIは、攻撃を示唆するときのみ、仮想マシンの具体的なステータスの変更に関する情報だけを返す。
そのトリガを定義するのが両ベンダーなのか、顧客なのか、あるいはその両者なのかはまだ明確ではない。

virtualization.infoが新しいXenClientに関する先の記事で既に明らかにしたように、このプラットフォームはIntel Trusted Execution Technology（TXT）とAMD Secure Virtual Machine（SVM）も活用して関与する仮想マシンを検証する。

このAPIは非GPLだがオープンソースコードとしてXenコードにも反映され、Xen Cloud Platform（XCP）の方にも還元されることになる。

VMsafeよりCitrix社／McAfee社のアプローチの方が効率的で安全なのだろうか？判断するのはまだ時期尚早だ。
McAfee社の主張によると、このオフロードテクニックはVMの集約率を181％向上させ、ホストあたりの仮想デスクトップ数を32から90にするという。

このアプローチはIaaSクラウドコンピューティングの世界でも普及するだろうか？あまりそうとは思えない。そこでのセキュリティ要件は改めて仮想マシン周辺で解説する必要がある。

McAfee社は仮想データセンタで新世代セキュリティ製品を本当にサポートするのだろうか？見守る必要はあるが、競合各社が利用可能になるオープンソースAPIの開発に同社が同意したことには間違いなく注目すべきだ。  

今回の意欲的なプロジェクトにMcAfee社を技術パートナーとして選んだCitrix社は正しかったのだろうか？オープンソースと（セキュリティに対してものすごい野心を抱く）Microsoft社とのかなり密接な関係とに挟まれて同セキュリティベンダーがどこまで安心していられるかは今後判明するだろう。