virtualization.info 日本語

このコラムはvirtualization.infoのセキュリティコラムシリーズ（パート1、パート2、およびパート3参照）の最終回となっており、セキュリティの高い環境に対する仮想化の影響について解説する。

ご存じのように、仮想化ベンダーは各社の重要なセールスポイントとしてセキュリティ関連のマーケティングを展開している。扱いやすさの改善、マシンのメモリの完全表示、そしてローレベルで各プロセスを検査する機能は、間違いなくセキュリティ分野のどのハイパーバイザーにとっても重要かつ決定的な機能となっている。 
では、われわれはベンダー各社の主張を信じるべきだろうか？仮想マシンの方が一方のハードウェア版よりも「はるかに安全」だと考えて良いのだろうか？

ことCPUへのローレベルアクセスに関しては、仮想化は全く透過的でない。CPUの機能にはエミュレートできない（あるいはそうすることが賢明でない）ものもいくつかあり、ここまで詳細なレベルまで見た場合、仮想と物理の両システムの同等性はほとんど現実的とは言えない。
もちろん、この技術のそのような側面を浮き彫りにすることに関心を示すベンダーは1社もなく、ユーザもここまでローレベルの分析にはさほど関心がないようだ。

現実問題、このような状況であることは何年も前から有名な話で、セキュリティ研究者らは仮想化インフラに対してローレベルの攻撃を仕掛け、この問題を何度も利用してきた。
ところが、これらの攻撃の大半は控えめに言っても実行が難しいが、実世界に深く関係する問題も多い。

まずは大胆な主張から始めよう。現行の最先端仮想化技術を考えた場合、仮想マシンで完全なハードニングを行うこと（あるいは少なくとも物理マシンと同等のセキュリティを確保した仮想マシンを持つこと）は不可能ではないにしてもかなり難しい。

ハードニングは、「縦深防御」として知られる侵略者が防御の最前線を突破しても攻撃の影響を緩和することを目指した一連の複雑なセキュリティ手続きの重要なコンポーネントの1つだ。一般的に、サーバのハードニングにはサーバ上で動作するOSやサービスのセキュリティを高めるための複数の処理が関係してくる。

このプロセスとしては、ベストプラクティスの適用、パーミッションの強化、OS専用機能の有効化などによるソフトウェアコンフィギュレーションのセキュリティレベル向上も含まれる。今日Linux OSの存在が大きくなったUNIXの世界におけるサーバのハードニングの場合、システムの基本的動作の変更や、場合によってはOSのコアコンポーネントであるカーネルへのパッチの適用が必要になる場合も多い。

これらの手続きの背景にある最大の目標は、たとえ攻撃者が1つ以上のネットワークサービスに障害を引き起こしても、必ず侵入領域を可能な限り最小限にとどめ、ビジネスへの影響も最小限にとどめるようにすることだ。

たとえば、適切なハードニングが行われたサーバでは、攻撃者がウェブアプリケーションに障害を引き起こしても、ハードニングが行われていないサーバのように攻撃者が権限を引き上げてネットワーク上のほかのマシンにまで攻撃を拡大するようなことは防ぐことができる。

特定のハードニングテクニックを適用すれば、マシンに対する管理者権限までも与えてしまうような決定的な脆弱性（その脆弱性が既知ものであってもなくても）を悪用する攻撃も阻止できる。

仮想化はハードニングに強い影響を与える、という言う場合はまさにこれらのテクニックのことを指している。ここで1つの例を考えてみよう。

GRSecurityは知名度の高いLinuxカーネル用パッチセットで、そのセキュリティレベルを大幅に引き上げることができる。  インターネットから見える公開拠点サーバで幅広く利用されており、セキュリティの知識が深いシステム管理者の間で知名度が高い。

UDEREFは高度なハードニング機能で、GRSecurityに実装されている。x86アーキテクチャの内部に関する深い知識が必要なためUDEREFの細かい動きには触れないが、UDEREF機能がLinuxカーネル上における多くのKernelレベルの悪用（マシンに対する管理者権限を与えてしまう最も危険なタイプの攻撃）をうまく無効にできることは事実だ。

UDEREFは、Linuxカーネルによるメモリセグメントの処理方法を変更し、いわゆるユーザランドとカーネルスペース間のデータの移動に関連したセキュリティ侵害を事実上ブロックする。大半のOSではユーザランドとカーネルメモリスペースを処理する方法が要因となり、カーネルのバグの多くが（ある程度まで）悪用される可能性がある。
しかし、ではそれが実世界とどう結びつき、仮想環境においては何を意味するのだろうか？

そこで登場するのがvmsplice()バグだ。

Linuxシステム管理者の大半は良くご存じのように、有名なvmsplice()バグは昔からあるカーネルレベルの攻撃で、ローカルユーザならだれでも普通に使ってroot権限（管理権限）を取得できる。見つかったのは2006年で、すぐに公に知られるようになり、アンダーグラウンドで流行し、blackhat攻撃で幅広く利用されている。

UDEREFは、vmsplice()（および関連する各種攻撃）による悪用を不可能にした。つまり、どのLinuxシステムもある程度の時間無防備だったが、UDEREFを使ってハードニングが行われたマシンがそうなったことは一度もなかった。ことミッションクリティカルなサーバに関してはとてつもなく大きな違いだ。

なぜこれが関係してくるのだろう。それは、VMwareなどではUDEREF対応のカーネルをVMとして動かすことができないからだ。もっと正確に言えば、可能ではあるものの、パフォーマンスがあまりにも劇的に低下するためVMware環境を検知すると自動的に無効になってしまう。

仮想化環境では動作しないGRsecurityのもう1つの機能であるPAGEEXECでも同様のことが言える。これらの障害はコミュニティーでも有名で、Hardened Gentooチームはハードニングが行われたVMwareゲストをかなり以前からテストしてきた。

Hardened Gentooは、拠点サーバやリスクの高いインフラで利用するLinux OSの高セキュリティディストリビューションをサポートするオープンソースプロジェクト。

仮想化ベンダー各社は、マシンのセキュリティレベルを劇的に改善し、場合によってはこれまで見えなかったrootkitsをネット上で検知できるようなアーキテクチャを提案している。

これらの機能はセキュリティに対するわれわれの考えを確実に変えるだろうが、結局、仮想化ベンダーが自分たちの主張を裏付けられるようになるまで、仮想ゲストが物理マシンと同等のセキュリティを確保することはできないのだ。

ラベル: Security

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

virtualization.infoは先ごろ、EAL4+認定取得に向けてCommon CriteriaラボがVMware VI 3.5とvSphere 4.0の両方のテストを進めていることを伝えた。

VMware社では既にVI 3.0.2でEAL4+認定を受けているが、そこまで高い格付けを得たハイパーバイザーはESXだけではない。

実際、Microsoft社もHyper-V 2008（発売直後のR2ではなく最初のリリース）が  EAL4+認定を受けたことを発表したばかりだ。

Microsoft社が、Windows Server 2008のフルバージョンに組み込まれたHyper-Vのリリース候補バージョンと、同ハイパーバイザーを1.0 RTMにアップグレードする「KB950050」緊急パッチでこの認定を取得したことは注目に値する。

Microsoft社ではHyper-Vの認証を取得するのに、Windows Server 2008 Server Coreに組み込まれたバージョンや、スタンドアロンのHyper-V Server 2008など、攻撃対象の少ないエディションを使う必要さえなかったのだ。

これは、Hyper-VがWindowsのフルバージョンに付属するのに対しESXは本体がかなり小さいため後者の方が前者より安全だ、という典型的な議論が正しくないことを明確にするはずだ。ただし、virtualization.infoが何度も示唆しているように、Common Criteria認定の絶対的な価値に異論を唱えるのでなければの話だが。

ラベル: Microsoft, Security

VMware社は2008年、VI3でCommon Criteria Evaluation Assurance Level（EAL）4+に到達した。同社はそれ以前にもVI3.5をEWA Canadaテストラボに申請し、同レベルを取得している。

vSphere 4.0の登場を受け、VMware社では当然新プラットフォームでの3番目のEAL4+取得を目指している。

virtualization.infoが既に書いているように、提出されたProtection Profile（PP）が有意義な参照モデルである限り、この認定には価値がある。
VMware社がVI3 EAL4+認定取得のために提出したPPがこちらだ。

同社ではvSphere 4.0のEAL4+認定取得を2010年後半と予想している。

ラベル: Security, VMware

前回の第2回までは、（テンプレートとしての）仮想マシンの管理方法や仮想インフラの管理部分を悩ます技術の脆弱性など、仮想化の核心部分からやや離れた部分の問題に重点を置いた。
しかし、仮想化のセキュリティ分野で頻繁に起こるように、これは全体のほんの一部でしかない。

仮想環境を見るときは、（いつもより以上に）われわれ自身がセキュリティに対して本当に総合的なアプローチを取るようにしなくてはならない。仮想化は複雑な問題で、その境界はあいまいで、直線的でないことが多く、境界線はITインフラに対するあらゆる種類の統合や操作を行うための有益なエントリーポイントだと見られることが多い。
これは確かに真実ではあるが、現代のハイパーバイザーや管理環境の「オープン」な特性のおかげで仮想化ベンダーやインテグレーターが提供できる多くの利点を考えると、このような重要なインフラと外部システムの安全な統合に関しては相当な注意が必要になる。
これまで自分たちの管理インターフェースの安全を確保し、コアハイパーバイザーを常に最新かつ安全に保つことができていても、外部ツールの管理に関する認識や注意が足りなければ、すぐにでもセキュリティが侵害される可能性がある。

われわれは一般に、仮想マシンやハイパーバイザーのすぐ外で動作し、仮想インフラと密接に（もしくはある程度）統合されたすべてのソフトウェアをエコシステムと呼んでいる。パワフルで有益なエコシステムはハイパーバイザーにとって競争上強力なアドバンテージとなり、ベンダー各社はAPIやアクセスポイントを増やしてインテグレーターやサードパーティー開発者の力を強化している。
残念ながら、セキュリティの場合と同様こちらにも代償が伴う。

われわれは調査を進めるなかで（多くのセキュリティ研究者らはわれわれの調査結果を異なるツールで確認している）、バックアップ、一元化されたマルチプラットフォームの仮想マシン管理、そしてパフォーマンスモニタなど、さまざまな作業の実行が可能な各種サードパーティーツールを検査した。
ほんのいくつかのケースを除き、これらの製品に影響を与えるセキュリティの問題は重要なものも含めて特定することができた。
これがセキュリティの観点から重要なのはなぜだろうか？

このような疑問に答えるには、これらのツールがどのような役割を果たしているのか考えなくてはならない。
バックアップの方がセキュリティの問題としては考えやすい。もしバックアップソフトウェアに危害が加えられれば、ソフトウェアのコンフィギュレーションや、もしかすると重要なデータまで含め、攻撃者が仮想マシンにアクセスできるようになってしまう。
だが、これは従来の「鉄壁の」データセンタにあるどのバックアップソリューションにも当てはまることだ。では、違いはどこにあるのだろうか？
繰り返すが、仮想化は大局的に見る必要がある。われわれは、あらゆるシステム（おそらく、社内の公開と非公開のマシンとで異なるバックアップシステムがある）に適用してきたものと同じ標準ポリシーで管理および安全を確保されるネットワークのコアコンポーネントとしてバックアップソリューションを持つことに慣れ親しんでいるが仮想化された環境ではそれが常に当てはまるわけではない。
仮想マシン用のバックアップソフトウェアは、「基盤インフラ」の一部として簡単に考えることができ、ハイパーバイザーとちょうど同じように、セキュリティ分野「外の」コモディティソフトウェアと見なすことができる。だが、それは言うまでもなく全くの見当違いである。このようなシステムは常にネットワークやインフラの一員であり、それに合わせて安全の確保と保護を行う必要があるのだ。
これと同じことが一元管理されたクロスプラットフォームの管理コンソールにも当てはまる。これらのシステムは、ハイパーバイザーへのダイレクトアクセスを認められる（あるいは証明が一切保管されていなくてもエントリーポイントとして利用される）ことで「支配権のカギ」を握っているのだ。
もしこのようなシステムに、ウェブインターフェースのセキュリティの低さや、ネットワークレベルのコントロールの欠如を利用して（われわれのテストで分かったように）攻撃者がキーロガーや トロイの木馬をインストールできたらどうなるだろう？
そうなれば、われわれは重大なセキュリティ侵害に直面するだろう。セキュリティコミュニティーで以前から知られていたこのような問題（管理コンソールやワークステーションの保護は知名度の高いベストプラクティス）は、仮想化の分野では一段と重要になる。あなたの仮想マシンホスティングプロバイダーはこれらの仮想マシンをどのように管理しているだろうか？慎重にコンフィギュレーションとセキュリティ確保を行ったハイパーバイザーのクラウド周辺にはどのようなエコシステムがインプリメントされているのだろうか？

全能のエコシステムは、仮想環境のセキュリティの領域を拡張しつつある。われわれは、それが提供する機能を利用することが可能（であるし、そうすべき）だが、それに伴うリスクも十分に認識する必要がある。領域やクラウドの形を正確に把握することは、仮想化のセキュリティに関してわれわれが対応を迫られている新しく、難しい作業の1つなのだ。

ラベル: Security

virtualization.infoによる新しいセキュリティコラムの第2回目だ。本シリーズは実世界における仮想インフラのセキュリティリスクから始まり、先週の第1回は具体的に仮想マシンのテンプレートに関連したリスクについて述べた。
今回の話題は、仮想インフラ管理インターフェースのリスクだ。

仮想化業界で働くセキュリティ専門家の大半にはたった1つだけ悪夢がある。ゲスト・ツー・ホストの悪用だ。
これはつまり、ゲスト仮想マシン（管理権限さえ不要かもしれない）から攻撃を仕掛けてホストシステムを乗っ取ってしまうという、ほとんど魔法に近い攻撃だ。これは今のところ最もおそれられている状況で、あらゆる恐怖を具体化していて、仮想化に対して懐疑的な人々からは「だから言っただろう」的なコメントが相次いでいる。
われわれは既にこのような事件をCloudburstエクスプロイトコードで少なくとも1回は目にしているが、その影響は特定のデスクトップ指向製品に限定されており、大企業では安全が守られ、セキュリティ管理者らは不思議がっている。
このような攻撃は至高の目標であり、技術観点から見た真の問題だと考えられている。研究者らは、極めて高度な攻撃がハードウェアの問題を悪用し、ローレベルの命令セットのセキュリティを無効にしていることを明らかにしている。

しかし、（仮想化セキュリティのスキーマ全体にあることは確かだが）これらの懸念や攻撃はあまりにも誇張されすぎているというのが私見だ。
これまでは、サポートと管理インフラの脆弱性という、仮想化環境にとって最も重要な脅威だと考えられるものを本気で分析した人は皆無に等しかった。
ハイパーバイザーが複雑な部品からなるソフトウェアで、攻撃するのが極めて難しいことはよく知られている。これらは簡単に最小限の内容に抑えることができ（その大半はほんの数千行で書けると言われてきた）、そのほとんどはセキュリティやソフトウェアエンジニアリングの高いスキルを持つ筋金入りのコーダーによって書かれており、やや無名のOS（Nemesis-XENのケースを参照）上で動作する。

どの仮想化ソフトウェアにもこのことが当てはまるわけではないが、うるさいDoS（サービス拒否）の副作用のリスクを負うことなく企業環境で「安全」に使える信頼性の高いエクスプロイトコードを開発するのははもちろんのこと、これらのシステムで脆弱性を見つけるのにもたいていの攻撃者はかなり苦労する。
だが、侵略者たちは強化されたアーキテクチャの弱点につけ込むことが大好きだ。仮想化の場合、管理機能を提供したり、メインではない機能をサポートする部分が弱点になるケースが多い。

仮想化ベンダーがリリースしたセキュリティ勧告を見ると、この主張を裏付ける例がいくつかある。たとえば、VMware ESXはホストシステムの悪用と乗っ取りにつながるリモート攻撃を受けやすい。この脆弱性（2つのバッファオーバーフロー）は、ESXiとESXの両方のOpenwsmanコンポーネントのなかにあり、リモートからコードを実行できるようになり、それに伴いホストやゲストが乗っ取られてしまう（本シリーズではこれについて今後探求していく）。

ハイパーバイザーのベンダー各社が基本サービスのコードの大半を書き直していても、核となる機能については標準技術を利用していることを忘れてはならない。OpenwsmanのバグはNovell SUSEセキュリティチームによって見つかっており、そうでなければ仮想化技術とは関係がない。
つまり、仮想化以外の問題が突然仮想化に特化したセキュリティにとって非常に興味深いものになっているのだ。

だが、まだある。ウェブインターフェースだ。
セキュリティ業界が良く分かっているように、ここ最近はウェブアプリケーションが過去最大の攻撃源となっている。セキュリティがこのように低い原因については諸説あるが、われわれはそれを当然のこととして分析する。多くの（大半の）ウェブアプリケーションはセキュリティ問題の影響を受ける。コードベースを大幅に変えることなく数年前から存在している有名な監査付きアプリケーションもしかりだ。新しい攻撃が開発され（数カ月前のHTTP Parameter Pollutionのことはだれも知らなかった）、既知のアタックベクトルが洗練されているため、かなり安全なウェブアプリケーションでも新しいリスクにさらされる可能性を秘めている。
その上、複雑であるために障害が発生しやすいアプリケーションスタックは攻撃者のメインターゲットになることが多い。アプリケーションサーバをターゲットにしたエクスプロイトコードが増えつつあり、このようなソフトウェアで決定的なバグが発見される間隔は業界平均と比較して極めて短い。

まさにこのような環境にあるのが管理ウェブインターフェースだ。大半の仮想化ベンダーは、仮想マシンの起動やシャットダウンなど、核となる最低限の管理作業を実行できるウェブインターフェースを（仮想化ソリューションのコア部分もしくは外部「プラグイン」、アプライアンス、あるいは同様の成果物として）提供している。
これらのインターフェースは、完全なアプリケーションサーバスタック上で動作するウェブアプリケーションにほかならない。アプリケーションを提供する一部デーモンはすべてもしくは一部をカスタマイズすることができるが、大体の場合は、標準的なウェブとアプリケーションサーバしか目にしない。さらに、ウェブやアプリケーションサーバの運用といった難しい作業を処理するカスタムコードの方が大半の標準ソリューションのなかでもセキュリティが低いとされている点は指摘しておきたい。

では、実世界に存在する侵略者はどこを攻撃してくるのだろうか？おそらく、今のところ最も簡単に餌食になるウェブベースの管理インターフェースや基盤のスタックにある問題を狙ってくるだろう。
大半のベンダー各社が管理ネットワーク上の管理コンソールへのアクセスを制限するようユーザに強く求めていることは確かだが、このベストプラクティスはまだ実際の脅威による裏付けがなく、大部分は無視されている。
残念ながら、先ごろのXENCenterウェブ悪用など、管理インターフェースに対する攻撃は発生頻度が高まっており、企業や組織にとってさらに脅威なのは、これらの大半が古いバージョンにも影響を与える点だ。仮想化ベンダーがすみやかにパッチでTomcatなどのセキュリティの問題に対処しても、アップグレードがテストされ導入される間にも特定の脆弱性が残っている。これまでの経験から、ベンダー各社はウェブベースの管理インターフェースを動かすアプリケーションサーバのセキュリティ修正のリリースまでに、開発者が最初にそれを投入してから5カ月を要している。

これは「現在」において大きな問題なのだろうか？ネットワークからはインターフェースに一切アクセスできないようにすべきなのだろうか？絶対にそうすべきである。
ウェブアプリを狙うゼロデイ攻撃（明らかにされておらず、そのためパッチも用意されていないバグを利用するためコミュニティーに知られていない攻撃） の方がネットワークデーモンを狙った流行遅れのエクスプロイトコードより格段に一般的で、アプリケーションサーバに影響を与えるバグや新しいウェブアプリケーション攻撃テクニックの開示から、動作するエクスプロイトコードが開発されるまでの期間は非常に短い。...

仮想化のユーザは可能性の低い、もしくは極めて複雑な攻撃を心配することは（少なくとも平均的スキルの攻撃者が利用できるようになるまで）やめて、侵略者に悪用されやすいインターフェースの部分に対応していくべきだ。
あと2回ほどエクスプロイトコードが登場すれば、ウェブベースの仮想化管理インターフェースに対応するワームも出てくることだろう。

ラベル: Security

virtualization.infoに新コラムの登場だ。このコラムでは、大部分が未知の分野である仮想化のセキュリティについて探求していく。

研究者らはかなり以前からこのテーマに取り組んでおり、ベンダー各社もセキュリティガイドやベストプラクティスを定期的にリリースしている。それでも、仮想化における現実のセキュリティの課題は、じっくりと議論されたことも、大半の大企業のセキュリティ統治に統合されたこともない。

仮想化のセキュリティについて考えるとき、われわれはきっとCPUのレジストリ、リソースロック、そしてタイムベースの隠れチャネルが関連した技術的に高度な問題を考えてしまう。本稿は、これが仮想化のセキュリティのすべてではないことを示す一連の記事を集めることから始める。

本稿では、業界のベストプラクティス、標準、および経験のおかげで簡単に管理できる自分たちが熟知しているものと、水面下に隠れ、新しい仮想化の世界で直面している未知の（もしくは少なくとも知名度の低い）リスクとの違いに重点を置くことに努める。

実際、まず第1回目は、問題を議論することから始めたい。まずは、誤った管理と常識の欠如という簡単なものからだ。
それから、もっと技術的な内容に進み、侵略者が仮想化のインフラに攻撃をかけてくる場合に可能性が高い形を探究する。
また、ハイパーバイザー自体の問題も探求し、セキュリティに関してソフトウェアのエコシステムが果たす役割や、全く新しい脅威が出てくる場所について議論する。
最初のシリーズは、魔物が潜む細かい詳細に重点を置くところまでとする。セキュリティや仮想化を考えるときに考慮しなくてはならないわずかな違いであり、被害を受けるマシンと安全なものが決まるかもしれない細かい詳細だ。また、ハードニングと、それに対する仮想化の対応に重点を置く。いずれ分かるが、これらはなかなかうまくいかない。

では、まず仮想世界におけるテンプレート管理（生まれ変わった古くからの脅威）から始めよう。

仮想世界におけるテンプレート管理（生まれ変わった古くからの脅威）

サーバ管理において最も顕著で、仮想化に直接結びつく改善部分の1つが、一般に「テンプレート」という名前で知られているものだ。

ベンダーごとに異なる用語（プロファイルやクローンなど）でこの概念を指していても、基本的な概念は変わらない。骨格となる仮想マシンをある時点で作成しておき、新しい本番用サーバの提供を加速させたり、テストや開発を簡略化するために将来的に再インスタンス化を行う。
これは、本稿で何度もカバーする「セキュア仮想マシンライフサイクル」の一部に過ぎないが、比較的新しく小さいインフラでも一般的に導入されるためかなり興味深い。
テンプレートはハイパーバイザーで直接サポートされないが、このような機能は仮想マシンの「ゴールデンマスター」を保管し、何度もくり返しコピーすることにより、何とかエミュレートすることができる。
経験豊かなシステム管理者には同じような手法がよく知られているが、これは仮想環境だけに関連しているわけではない。ディスクイメージ化ソフトウェア、Microsoft Sysprepのようなツール、あるいはリモートイメージダンパもかなり以前から存在しており、大企業では幅広く活用されている。

ではなぜ、このテンプレート処理が仮想化のセキュリティコミュニティーと関連しているのだろうか？
その答えを出すには、仮想化登場前にあったものと、今あるものとの違いに焦点を当てる必要がある。

まず、現在はテンプレートの導入に関し、セキュリティのベストプラクティスが欠けている。
ディスクのイメージ化ソリューションがあると、DVDや外部ディスクのコンテンツがマシンにコピーされるとすぐ管理者がシステムをブートする。業界のベストプラクティスでは、パスワードを変更して適切なコンフィギュレーションを行ったり、安全な環境でサーバをハードニングするため、これは隔離されたネットワークで行われる。
もともと仮想化されていた環境についてはどうだろうか？管理者はおそらく、本番もしくは開発中の仮想スイッチでマシンをブートし、パスワードを変更し、あとでサービスをコンフィギュレーションして、サーバが各種攻撃を受けてしまう状態にしておく。これ自体は技術的問題ではなく、管理者は簡単にネットワークインターフェースを無効にし、サーバを安全にコンフィギュレーションすることができる。

しかし、セキュリティ分野における経験から分かるように、標準の手順でも、厳密な技術的プロセスでもないものは、たいていはインプリメントされず、仮想管理コンソールを使っていると、標準導入時の常識（ケーブルを抜くだけ）も簡単に見落とされてしまう。

パスワードやデフォルトコンフィギュレーションだけの問題ではない。エクスプロイトコードによるリモート攻撃が頻繁に見つかる世界では、パッチを当てていないサーバはものの数分で悪用される可能性がある。確かに、アップデートをチェックし、場合によってはアップグレード作業も行うセキュリティチームがいずれはサーバの面倒を見てくれるだろうが、意識の高いシステム管理者は、サーバがアプリケーション管理チームに貸し出される前に、利用可能なすべてのセキュリティアップデートを完全インストレーションプロセスの最後で実行する。

テンプレートベースの仮想環境では何が起こるのだろうか？核となる複雑な基準ソフトウェアをインストールしたテンプレートでは、タイムリーにセキュリティアップデートを適用するための修正は行われるのだろうか？それとも、数カ月間もいじられることなく、その後インスタンス化された各サーバは、少なくともアップデートがインストールされるわずかな間、脆弱性にさらされるのだろうか？
思い浮かべたであろう答えは大半の環境においては後者であり、仮想化ベンダー各社も、「VMware Update Manager」（VUM）や「Microsoft Offline Virtual Machine Servicing Tool」などのテンプレートを直接扱うツールをリリースすることでその事実を認めている。だが、ISVによるこれらのツールのサポートには改善の余地があり、その採用率は登場以降大きく伸びていない。

テンプレートのもう1つの問題は、テンプレートデータベースへの攻撃に関するものだ。管理者はゴールデンマスターをどこに置くのだろうか？
このストレージシステムは本番環境レベルのシステムセキュリティを持つのだろうか、それとも、テンプレートは使い捨てツールと見なされ、ネットワークファイル共有に残されたままで、攻撃者が簡単にアクセスできてしまうのだろうか？
筆者はカスタム実証ツールを自ら探求する機会に恵まれているが、オフラインのゴールデンマスターに対して書き込みアクセスを持つ攻撃者にとって、ルートキットを埋め込むのは何でもないことだ。これが改ざんされたテンプレートをベースにしたすべての仮想マシンに運ばれてしまう。

解説してきたこの問題は、従来のテンプレートベースのインフラに対する攻撃と共通点が多いが、こちらの方が仮想化環境との関連性がはるかに高い。この事情の認知度は、ベンダー各社やセキュリティを熟知した仮想化管理者たちの間で高まりつつある。　
だが、提案されているソリューションは包括的なものとはほど遠い。標準のハイパーバイザー管理システムに安全な仮想マシンライフサイクル 管理が完全統合されるまで、ここが絶対にセキュリティの脅威とならないよう、企業や組織は適切なセキュリティポリシーや手順を用意および実施する必要がある。

次回は、仮想化管理ウェブコンソールのセキュリティについて解説する。ご期待いただきたい。

ラベル: Security

さあ来た。Altor Networks社は、VMware社の新しいVMsafe APIをフル活用する全く新しいカーネルを搭載した同社のVirtual Firewall（VF）の第三世代を7月7日にリリースした。

同製品のコア部分を書き直すという選択によりその安定性が懸念されるところだが、そこには重要な理由がある。

VMware社はVMsafeのネットワークAPIを利用するために「Slow-Path」および「Fast-Path」という2つのモードを用意している。
セキュリティベンダーは「Slow-Path」を使うことで専用VMsafe仮想アプライアンス内の仮想トラフィックのコピーを要求し、保護されたVMを相互接続する仮想スイッチをつなぐ。
このアプローチは遅く（コンテキストスイッチングの実行が必要になる）、VMsafe仮想アプライアンス事態が攻撃対象になる可能性があるため、リスクのポテンシャルもある。 
代わりに「Fast-Path」を使うと、セキュリティベンダーがESX vKernelの内部から完全な透過モードで仮想トラフィックを処理できるようになる。
残念ながらFast-Pathを統合する方が難しいものの、パフォーマンス、柔軟性、そしてセキュリティ上のメリットが生まれるため、ベンダー各社は両方のモードを利用してハイブリッドソリューションを提供している。

Altor Networks社では、Fast-Pathモードだけを利用するよう自社製品のカーネルを手直しすることにし、スループット分析の概要からも分かるように、かなり低価格のハードウェアでも（そして新しいIntel Xeon 5500 CPUがなくても）競合各社の製品に対してパフォーマンスが10倍から20倍以上向上することを明らかにした。

さらに、Fast-Pathのアプローチでは仮想ネットワークのコンフィギュレーションをいじって複数のvSwitchインスタンスを導入する必要がないため、Altor Networks社はこれまで不可能だったCisco Nexus 1000Vを即座にサポートできるようになる。

VF 3.0には、圧倒的な人気を誇るオープンソースエンジンの「Snort.」をベースにした侵入検知システム（IDS）モジュールも搭載されている。Altor Networks社では、Snortの保守を行うSourcefire社との間で市販のアタック署名を再販するOEM契約を結んでおり、顧客が複数のゼロデイアタックを認識できるようにしている。
ほかの多くのセキュリティベンダーとは異なり、Altor Networks社はセキュリティエンジンをバンドルするだけでなく、それらを統一されたインターフェースでまとめようとしている。
同社は、IDS（将来的にはほかの各種モジュールも加わる）からの情報を使ってVFのルールベースをダイナミックに再配置することで、より密接な統合を目指している。
このアプローチには複雑な面もあるが、ほかの外見だけの多数のオールインワンソリューションよりこちらの方が興味深いことは間違いない。

大事なことを言い忘れていたが、新しいVF 3.0にはそのままの金額ですべての冗長コンポーネントが付属し、管理／コントロールモジュールのホットスタンバイコピーもある。
これらのパーツは、自社開発ツールでフェイルオーバーをコントロールしたいクラウドコンピューティングプロバイダー向けにAltor Networks社が開発した専用のAPIによって外部から管理することができる。

Altor Networks社をvirtualization.infoの仮想化レーダーに追加した。

ラベル: Altor Networks, Releases, Security

5nine社は仮想化市場参入から1カ月も経過していない全く新しい新興企業だ。
同社はプラニングフェーズだけでなく、実際にP2V移行までも行うHyper-V用のキャパシティプラニングツールを発売した。　

5nine社は最初の製品に集まった関心を利用するのではなく、同じくHyper-V用となる「Virtual Firewall」という第二弾の製品を発売してきた。

つまり、セキュリティベンダーの大半がVMsafe APIの利用が可能なVMware環境向けの革新的な製品のリリースを競い合う一方で、この新興企業は基本的にMicrosoft社の市場で孤軍奮闘していることになる。

これらのベンダー各社がVMsafeを利用するに先立ち受けた厳しい批判は5nine社にも当てはまる。仮想マシン内でソフトウェアファイアウォールを実現しても、それが仮想ファイアウォールになることは絶対にないということだ。ホストの物理リソースに何台の仮想マシンのアクセスが集中するかが完全に予測不可能であるため、このような製品のパフォーマンスが「仮想」になるのがせいぜいだ。 
そしてもちろん、仮想ネットワーキングやゲストOSと対話せずハイパーバイザーのカーネルと透過的にやりとりできるVMsafeライクなアプローチをHyper-Vが実現するまでは、5nine社、Microsoft社（Hyper-V VM内でISA Serverをサポート）、そしてほかのベンダー各社にもこれが当てはまる。

これ以外にも、最初のバージョンはホスト間とのトラフィックのフィルタリングにしか対応しないなど、Virtual Firewallには制限がかなりある。現在は、VM間のネットワークアクティビティを検査およびブロックする方法が全くない。
大事なことを言い忘れていたが、セキュリティ業界全体が高度なステートフルインスペクションを提供する一方で、同製品の核となっているのはシンプルなパケットフィルタリングエンジンのようだ。

5nine社がHyper-Vを採用するであろうSMBユーザ層にとって使いやすいものを提供しようとしていることは理解できるが、今回の最初の試みはやや弱く、「pfSense」のような無償だが極めてパワフルな製品には完敗だ。もちろん、同社の開発者はこれを「仮想ファイアウォール」とは呼んでいないが、顧客はこれを仮想マシンに導入し、仮想ネットワーキングを完全に保護できるよう再設定することができる。

ラベル: 5nine, Releases, Security

先週、主なITニュースポータル（NetworkWorldなど）はどこもがIBM Internet Security Systems社（ISS：IBM社が2006年に13億ドルで買収した人気の高いセキュリティベンダー）セキュリティ戦略担当主任であるJoshua Corman氏のコメントを引用していた。

Corman氏はネバダ州ラスベガスで開催されたInteropカンファレンスで、セキュリティや仮想化のほかの専門家が以前から言い続けていたことを語った。

x86の仮想化は、仮想化と、それによって生じるセキュリティのリスクに対して人もプロセスも準備が整っていないことから、高度に統制されたミッションクリティカルなアプリケーションではリスクの高い提案となる場合が多い。

Corman氏はまた、本番環境ではType-2 Virtual Machine Monitor（VMM：仮想マシン・モニタ）を使用せず、ハイパーバイザーだけに頼るよう提唱した。
この主張に対するKVMやLinuxコミュニティーの反応が楽しみだ。

ラベル: IBM, Security

virtualization.infoが何度もお伝えしているが、「VMsafe API」の発表により、VMware社にはセキュリティ業界を再編するまたとないチャンスが訪れている。
しかし、IT業界においてVMware社が多くの市場セグメントで技術革新を推進するこのような特権的立場にいる限り、その課題と責任はほかの多くのベンダー各社を大きく上回るものとなる。

VMsafe構想はちょうど1年前に発表された。この12カ月間、新しいAPIで何ができて何ができないのかを実際に目の当たりにできたのは、VMware社が募集した限られた数のセキュリティパートナーだけだった。

VMsafeが「vSphere 4.0」プラットフォームの一部としてリリースされようとしていることを受け、新たな詳細が明らかになり、少なくともそのなかの2つが不安をもたらしている。

1つ目の不安は、セキュリティベンダー各社はVMsafeの機能を完全には解除できない点だ。

同APIは、最初のリリースでは仮想インフラ内のあらゆるリソースの帯域外検査を可能にする。仮想メモリ、ストレージ、そしてネットワーキングが保護されるゲストOSの外にあるセキュリティ製品に完全に見えてしまう。

そのため、セキュリティパートナーは仮想マシン内から自社の検査/改善エージェントを削除し、貴重なリソースを節約し、これを無効にしようとする攻撃を防げるようになり、仮想データセンタ内のどこで、どのようにマルウェアが広がっているのかを全方位から見渡せるようにする。

ただ残念ながら、VMsafeインターフェース公開時にセキュリティベンダー各社がこのようなことをすることはないだろう。

現在の開発状況では、基本的には仮想メモリ、仮想ネットワーキング、あるいは仮想ストレージのダンプとなっている膨大な数の非構造化データをAPIが提供する。

この大量の情報のなかではセキュリティベンダー各社もさほど問題なく有名なマルウェアの署名を見つけ出すことができるが、マルウェアが隠れたファイルシステム構造やファイルなどの特定では間違いなく深刻な問題を抱えることになる。

このような理由から、VMware社のパートナーはどこも実際にはVMsafeを使ってマルウェアを削除することはないだろう。
APIは検知目的だけに利用され、ゲストOS内の悪質なコードを削除するには顧客が相変わらずエージェントをインストールする必要がある。
これはもちろん、どのような攻撃手法でも完全に無力化される前に保護機能を無効にしうようと試みることが可能であることを示唆している。

つまり、われわれの仮想データセンタ内に本当の帯域外セキュリティインフラが登場するまでにはまだ時間がかかるだろう。

2つ目の不安は、すべてのセキュリティベンダーがVMsafe APIを使えるわけではない点だ。

VMsafe公開後のあるタイミングでVMware社はAPIを一般公開するが、実行のためのカギは相変わらず認定されたセキュリティベンダー各社のみに渡す。

現在、そして当面は、ベンダーの身元確認とAPIの利用計画に関する詳細な資料を提出しないとVMware社が新しいVMsafeパートナーとして受け入れてくれない。
審査手続きに費用はかからないが、手続き自体は必須となっている。

同社によると、これは信頼できないところがインターフェースにアクセスしたり、一段レベルの高い攻撃ツールを開発するのを回避するための手続きだが、基本的にはインターフェースにアクセスできるところとできないところをVMware社がコントロールする意味合いのものだという。

これには危険な影響がある。

• APIをどこよりも早く利用できるため、大規模ベンダーの信頼性はセキュリティ分野において他社に対する競争上のアドバンテージを与える。
• 正式発売前の技術革新を守ろうとする新興企業には、その計画を明らかにしない限りVMsafeのコードを利用する機会が与えられない。
• VMware社は、一部申請者の審査プロセスを遅らせることにより、直接的もしくは間接的にセキュリティ市場に影響を与える可能性がある。

etc.

もしVMsafeがセキュリティ業界にとって重要なものになれば、VMware社は本気でこのアプローチを再考しなくてはならなくなるかもしれない。

ラベル: Security, VMware

2008年10月、VMware社はセキュリティベンダーのBlue Lane Technologies社（物理と仮想の両環境に興味深いインラインパッチ技術を提供していた）を買収した。
うわさによると、経済的な混乱と、Blue Laneの黒字を維持する力が限定的だったことを考えると、これはかなりうまく機会に乗じた買収だったという。

それが本当かどうかは別として、セキュリティを通じて仮想化を推進し、その市場のリーダーになるという願望がVMware社にあることは明らかだ。
同社は既にソフトウェアパッチコンポーネントの「Update Manager」（Shavlik Technologies社のOEM供給）を提供しているが、Determina技術ベースで構築された新しいホスト侵入防止システム（HIPS）もリリースし、VMsafe APIが提供する革命的な検査／防止ポイントの恩恵を同社の全製品が受けるようになる。

先週のVMworld Europe 2009開催中（virtualization.infoによる第1日および第2日の速報参照）、VMware社は「Blue Lane VirtualShield」が「vShield Zones」に分類されるようになったことを正式に発表した。
同製品は2009年中に、まもなく登場する「vSphere 4.0」プラットフォームの一部として発売されると見られている。

何らかの理由から、VMware社はこの製品に添えるメッセージを大幅に変更している。vShield Zonesはプロキシになって複数のレイヤ7攻撃を遮断、ブロック、修正できるとする代わりに、どの仮想ネットワークに導入されているどの仮想マシンでもセキュリティコンプライアンスを実行できる（VMware ACEと同様の）セキュリティラッパに近い形で説明している。

つまりVMware社は、このツールは従来のファイアウォールと競合することができ、代替することもできて、DMZが含まれるネットワークアーキテクチャを不要にできると示唆しているように思える。大変なことだ。

VMware社は、ACEで犯した過ちを繰り返そうとしている。同社はセキュリティ技術をサーバ管理者に、そして仮想化技術をセキュリティ担当者に販売できると考えているのだ。それは違う。

サーバ、ネットワーク、そしてセキュリティの各部門は、文化的に、そして機能的に異なる。それぞれが違う考え方をし、それぞれに信頼するベンダーで構成される独自のエコシステムを持ち、社内インフラに対して独自の認識を持って、それぞれのアプローチで課題を解決する。
このような違いから、これらの部門間ではたいてい摩擦が多く発生する。彼らは一緒に昼食をとるようなこともなく、仮想化に関する素晴らしい経験を語り合うことなど絶対にない。

VMware社は過去5年間、ACEが素晴らしい製品であるにもかかわらず、その販売には失敗してきた。それは、同社がこの違いを一度も加味しなかったからだ。
その結果、ACE技術は今日では「VMware Workstation」の一部として無償に近い形で配布されている。　

そして今度は、社内ファイアウォールもDMZもない100％の仮想インフラをVMware社が望んでいるという。これはうまくいかないだろう。
vShield Zonesを社内にあるCheck Point社のファイアウォールと同時に使用するという考えでさえうまくいかないだろう。セキュリティ担当者は自分たちが管理するすべての製品でポリシーを維持し、オブジェクトデータベースの整合性を維持するにあたって既に大きな問題を抱えている。
彼らにとって、仮想化とは管理しなくてはならない複雑性とセキュリティがさらに一段上がることに過ぎない。

VMware社が拡張を行えば行うほど、その限界を理解するための複雑性も上がることになる。
VMsafe APIはセキュリティ史上有数の素晴らしい技術になっていく。加えて、VMware社が自社製セキュリティ製品をリリースすると、その度に同社はかなり危険な未知の領域に踏み込むことになる。

もし同社がセキュリティベンダーの役割を担いたいというのならば、自社のアプローチをうまく変更することを考えるべきだ。

ラベル: Blue Lane, Security, VMware

セキュリティベンダーのAltor Networks社は2月18日、「Virtual Firewall（VF）」のバージョン2.0をリリースした。

この新バージョンでは、仮想マシンの刻々と変化するIPアドレスではなく、そのUUIDを使ってセキュリティポリシーを設定できる。

さらに、VF 2.0はVMware Infrastructureの最も強度が低いピア（ESX COS）とのトラフィックのやりとりも監視する。

同社はVMwareプラットフォームとの統合で全体的に素晴らしい仕事をしている（新しいインストレーションウィザードは本当に使いやすい）が、この統合の重要な部分はいまだに欠けている。VMsafe APIのサポートである。

VMware社が待望のセキュリティインターフェースをいつまでたっても（現時点でもう1年経過する）リリースしていないため、Altor Networks社や競合各社は、仮想マシン内部に製品を投入してサポートする従来のセキュリティベンダーに対して現状以上の差別化ができずにいる。

virtualization.infoではこの話題を既に何度も取り上げてきた。

ただ朗報なのは、Altor Networks社がVMware社と密接に協力を進めてきており、実現可能になり次第、VMsafeフレンドリーなVirtual Firewallのリリース準備を整えていることだ。

もしかすると、来週のVMworld Europe 2009で運良く「vSphere 4.0」が登場するかもしれない。

ラベル: Altor Networks, Releases, Security

Unisys社の主任セキュリティアーキテクト（そしてvirtualization.infoの2008年のベスト仮想化関連ブログ）であるChristopher Hoff氏は2008年10月、PCI Standard Councilが仮想化にあまり関心を示さなかったことを非難した。

それからちょうど1カ月後、VMware社が同Councilに参加してきた。

そして今、PCI SSC技術ディレクターのTroy Leach氏が伝えるように、不思議なことに仮想化のSpecial Interest Group（SIG）が設置されようとしている。

仮想化SIGは2009年中に設置されるが、まだ今のところは、その日時も目的も確定していない。作業に貢献できるのは、参加するわずか500社から600社の企業や団体（VMware社、Microsoft社、Dell社などを含む）もしくは1800人以上がいるセキュリティ査定者のみとなっている。これらの数字から想像できるように、手元には既に数千ページ分のフィードバックがあるが、われわれにはこれらすべてのコメントやアドバイスに目を通す義務がある。

このニュースを提供してくれたChristopher Hoff氏に謝辞を述べたい。

ラベル: Security, Standards, VMware

Microsoft社が同社の仮想化製品の顧客向けに「Hyper-V Security Guide」（Hyper-Vセキュリティガイド）という重要な新しいドキュメントの準備を進めている。

どのようなハイパーバイザーでも担うミッションクリティカルな役割を考えると、このガイドは最初から用意しておかなければならないものだ（ただし、セキュリティガイドを用意しなかったことを非難されるべき仮想化ベンダーはMicrosoft社だけではない）。

この資料は以下の3章構成となっている。

• Hyper-Vの強化
• 仮想マシンの管理と委譲
• 仮想マシンの保護

今のところ内容は特に十分とはいえず、これを有用な情報リソースにするためにはMicrosoft社が第1章を大幅に強化する必要があるが、「Hyper-V Attack Surface Reference Workbook」（Hyper-Vの攻撃対象領域参照ワークブック）などの貴重な情報も既にいくつか提供されている。

Hyper-V Security Guideは現在（公開）ベータ版であるため、現在はだれでもプログラムに参加してこれをダウンロードすることができる。

ラベル: Microsoft, Security

Third Brigade社はIDS、IPS、ファイアウォール、ファイル 整合性チェッカなどのモジュール型ソリューションや、「Deep Security」の名前でも各種モジュールを提供するセキュリティベンダーだ。

同社は12月8日、最大100台の仮想マシンを無償でプロテクトする同プラットフォームのスケールダウン版を投入して危険地帯に参入する。
この軽量バージョンは「VM Protection」と呼ばれ、IDS、ファイアウォール、そしてファイル整合性監視機能を搭載するほか、「VMware vCenter」と統合されている。

ただ、危険が存在するのは「クラウド対応のセキュリティを導入」とか「PCIなどの各種規制への準拠を実現」と主張するコミュニケーションの部分だ。

virtualization.infoに参加した新しいセキュリティ専門コラムニストのChristofer Hoffは、仮想化やクラウドコンピューティングの分野にセキュリティ規制が欠けていることを自身の個人ブログで既に指摘している。
彼の意見は至極もっともで、VMware社はData Security Standardに働きかけるべくPCI Security Standards Councilへの参加を余儀なくされている。

PCIにもできないことをThird Brigade社はどのようにして約束するというのだろうか？

ラベル: Security, Standards, Third Brigade

VMware社がPayment Card Industry（PCI）Security Standards Councilへの参加意向をつい先ごろ発表した。

仮想化業界をリードする同社には、仮想化がセキュリティ遵守の障害とならないようPCI Data Security Standard (DSS) に働きかけたい考えがある。
実際、Unisys社の最高セキュリティ責任者であるChristopher Hoff氏が11月14日に自身の個人ブログで指摘したように、PCI Councilは仮想化を優先事項のトップに持ってくる行動を一切取らなかった。

さらに、VMware社は自社が描くクラウドコンピューティングのビジョンを売り込むのに非常に忙しく、自社のデータをクラウドに移行させるべく大企業を説得したい場合は、そのシナリオをサポートする何らかのセキュリティ標準を用意する方が有利だ。そうしないと、このようなことが起こってしまう可能性が高い。

また、PCI標準に関心を示す仮想化ベンダーはVMware社が最初ではない。3月にはFortisphere社がPCI Security Vendor Allianceに参加してDSS標準準拠への意気込みを示している。

ラベル: Security, VMware

virtualization.infoでは2年ほど前から何度もお伝えしてきたが、仮想インフラでセキュリティを実現する現行の取り組みは残念なところが多い。

整理統合された新しいセキュリティベンダー各社にとって現在可能な最善策は次の通りだ。

1. ファイアウォール、IDS、ウイルス対策などの従来のツールを仮想マシンに移す。
2. 仮想トラフィックが上述の仮想化されたセキュリティツール内や周辺を通過するよう、仮想インフラの管理者に仮想ネットワークの設定を見直させる。
3. 並はずれた新しいものをサポートする。　

だが、これらはどれも良くない。

1は、ハイパーバイザーレベルで仮想インフラ全体を監視できるものが導入可能であるにもかかわらず、同じツールのコピーを複数導入する必要がある（実際には仮想ネットワークの内容に依存するが、最悪の場合、ウイルス対策エージェントがVDI環境にあることを考えたい）ため非常に効率が悪い。また、これは物理資源を大量に無駄にする。

残念ながら、VMware社がVMsafe APIをリリースする（そしてベンダー各社が続く）までは、できることがあまりない。

2は仮想化が実現する機動力の前提を覆すため制約が多すぎる。管理者が保護された仮想マシンのライブマイグレーションを始めると、仮想ネットワーキングはたちまち混乱し、仮想化されたセキュリティツールは選択肢から外れてしまう。

VMware社では、この問題の緩和に取り組んでおり、VI 4.0では「vNetwork Distributed Switch」と呼ばれるものが導入され、ライブマイグレーション中も同じ仮想ネットワークコンフィギュレーションが維持される。
この技術は興味深いが、この問題の一部しか解決できないことは間違いない。

3は信頼性がかなり低い。ベンダーがどれほどコミットしても、同じ仮想ホスト上で同時に最大何台の仮想マシンが動作し、仮想化された製品のパフォーマンスにどのような影響があるのかを予測することは不可能だからだ。

リリースされたばかりのOVF標準を利用すれば、メタデータレイヤを介し、サービスレベル合意（SLA）といった各仮想マシンの具体的な特性を定義できるようになるが、本格的な普及にはほど遠い。

ソリューションとして考えられるのは以下だ（完全な詳細ではない）。

• 各仮想マシンをセキュリティレイヤでラッピング（「VMware ACE」、「Kidaro Workspaces」、および「Sentillion vThere」などの製品では既に以前から実現済み）し、そこで管理者が具体的なセキュリティポリシーを定義する。
• 各VMセキュリティラッパのポリシー要件を読み込み、その要件を満たすセキュリティ製品が接続されているかどうかハイパーバイザーに問い合わせるセキュリティコーディネーターの役割を果たす独立層（仮想化管理レイヤは候補者として不十分）を用意する。
• ハイパーバイザーに接続される複数のセキュリティ製品を用意し、セキュリティコーディネーターからの処理要求を待つ。

Altor Networks社では、説明を読む限り前述のアーキテクチャーを一部実現しているように思える「Virtual Firewall」を発表したばかりだ。

だが残念ながら、ネットで公開されている最も技術的に詳しいパンフレットを分析したところ、いくつか疑問点が浮かび上がった。

…Altor VFは仮想アプライアンスとして各仮想ホストにインストールされ、各VMゲストを往復するトラフィックを検査する。管理者らは、ソース／行き先／プロトコル別の許可／不許可、対応処理といった従来のファイアウォールルールをウェブベースの管理コンソールを使って定義し、集中管理する。ルールはすべてのVM、コネクティビティおよびセキュリティに関して同様のニーズを持つVMグループ（ウェブサーバなど）、あるいは1つのVMに適用することができる。これらのルールに基づいて作られたポリシーは、グローバル、グループ、そしてVM単位の各レベルで適用することができる。…

実際のところ、ほかのどの製品とも同じように、この製品も仮想ネットワークのコンフィギュレーションを見直す必要があり（VirtualCenterと連動する便利なセットアップによってプロセスが自動化されているかどうかは関係ない）、1台の仮想ホストに導入された1台の仮想アプライアンスのセキュリティポリシーを別の1台に複製し、それを別の仮想ホストに導入するようだ。
同社は、こうすることでライブマイグレーション時でも仮想マシンが保護されると主張している。

仮想ファイアウォールは常にVMに「結びついて」おり、VMotionのイベント時も一緒に行動する。これにより、ライブマイグレーションの前後そして途中でもセキュリティポリシーが継続的に適用される。同様に重要なこととして、Altorのソリューションは、移動させるVMのなかのすべてのアプリケーションの接続状態を維持する。

Altor Networks社はESX仮想マシン用セキュリティラッパの作成方法を本当に見つけ出したのだろうか？

ラベル: Altor Networks, Security

virtualization.infoがつい先ほど得た情報によると、VMware社がセキュリティベンダーのBlue Lane Technologies社を買収したという。

インラインパッチ技術で人気の高い同社は、2007年初頭に仮想化市場に参入し、ここ2年の間に、活動の重点をVMware Infrastructureへと完全に移してしまった。

どの競合製品とも同じように、同社の「VirtualShield」は現在もESXハイパーバイザー専用の統合ができず、従来のVM同士のやりとりが必要になる。同製品は、プロキシとして機能する仮想マシンの内部にインストールする必要があり、仮想ネットワークは設定をし直して保護された仮想マシンをすべてそれにポイントさせる必要がある。

VMware社がVI4と一緒に2009年に投入するであろう「VMsafe」セキュリティAPIの登場により、このシナリオは劇的に変わり、Blue Lane社は、ようやくコンフィギュレーションをし直すことなく仮想インフラを透過的に保護できるようになるだろう。
しかし、VMware社が買収してしまった今となっては、これももはや不要になるかもしれない。

今回の買収は、同社がセキュリティ分野に並々ならぬ力を注いでいることを再確認するものだ。実際、VMware社は2007年、複数の手段でセキュリティ分野への投資を進めている。

• （2007年8月）パッチエンジンをVI 3.5 Update Managerで利用するためVMware社がShavlik Technologies社とOEM契約を締結。
• （2007年8月）VMware社がDetermina社を買収。
• （2008年2月）VMware社がVMsafeを発表。

今回のBlue Lane社により、（少なくとも公開会社を数える限り）VMware社は9社を買収したことになる。
最後に買収したのは2008年5月のB-hive社（同社の技術も「AppSpeed」の名前でVI4に投入される）。

今回の買収は詳細が分かり次第詳しくお届けする。

ラベル: Acquisitions, Blue Lane, Security, VMware