virtualization.info 日本語

セキュリティ仮想化の新興企業、Altor Networks社は先週、DAG Ventures社、Juniper Networks社、Accel Partners社、およびFoundation Capital社などから1000万ドルの資金を新たに確保したことを発表した。

Accel社とFoundation社は既に前回の資金調達を主導しており、2008年4月のこのときは600万ドル相当を投資している。

ただ、今回が2回目となるのか、3回目となるのかは明らかでない。同社は今回が2回目だと主張しているが、600万ドルの調達発表時に次のような話があった。

…Accel Partners社およびFoundation Capital社主導による第2回目の資金調達で600万ドル確保したことを本日発表する。

ラベル: Altor Networks, Funding, 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

セキュリティベンダーの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

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