最近のIT業界では仮想化が流行りの言葉のようで、コスト削減、ROI（費用対効果）、容易な管理が可能になるといわれています。これらの利点に関心が向くため、実際にどのような問題が起きうるのかを想像するのはなかなかできることではありません。しかしどんな新しい技術でもそうであるように、仮想化にも対策の必要なセキュリティリスクが存在するのです。

以前にInfoQの記事「仮想化入門」に書いたように仮想化には主に2つのタイプがあります。つまり複数のリソースをひとつのリソースのように統合するもの、そしてひとつのリソースを複数のリソースのようにするものです。このどちらの仮想化にしても対策を取るべきセキュリティ問題が存在します。それには情報漏えい、権限とアクセスコントロール、情報資産の改ざんなどがあります。

この記事で詳しく見ていく前に、ひとつはっきりしておきたいのは、この記事は仮想化を持ち上げるものでも誹謗中傷するものでもないということです。仮想化にはいくつもの利点がありますが、セキュリティをしっかりしようとすればそのためのコストは高くつきます。同時に、それはシステムやネットワークの仮想化がセキュリティを下げるということでもないのです。

セキュリティとはなにか？

セキュリティについて語るときによく出るテーマは次の3つです。 

• 機密性（Confidentiality）
• 完全性（Integrity）
• アクセシビリティ（Accessibility）

ISOの定義では機密性とは「アクセス権限をもつ者だけが情報にアクセスできることを保証すること」を意味します。機密性は必要のあるユーザだけがデータの利用することを可能にし、他の全ての人のアクセスを禁止します。機密性のためによく用いるのは、ファイルのアクセス権限、ネットワークアクセスコントロール用リスト、ファイアウォールのルール設定です。

Wikipedia（英語版）によると、完全性とは「データが”欠けてない”あるいは完全であることを意味し、データがどのような操作（転送、記憶、復旧など）の最中でも完全に等しく維持されること、意図された利用のためにデータを保護すること、ある種の操作に関して期待されるデータ品質を維持すること」です。完全性はユーザが意図どおりにデータへアクセスできることを保証します。システム完全性のチェックによく用いられるのはMD5のようなチェックサムやハッシュ、CVSや Subversionのようなバージョン管理ツールです。

データについてのアクセシビリティとは必要なときに望んだシステムやデータにアクセスできることです。機能停止やデータ損失によって求められた時にデータが利用できなくなることがあれば、セキュリティに大きな影響を与えます。アクセシビリティを確保するために企業がよく用いるのは、高可用性のあるシステム構成、フェイルオーバ（エラーが起きた時に処理を引き継ぐ機能）、ホットスワップ可能（稼働中でも交換可能）なドライブです。

セキュリティが何に対してのものなのかをはっきりしておくのも大切なことです。次の定義はセキュリティについて議論する上で役立つでしょう。

• 脆弱性（Vulnerability） - 攻撃者によってシステムの完全性を破られるようにしてしまうシステム上の弱点です。ソフトウェアのバグや誤った設定、強度の低いパスワードなどは脆弱性の原因となります。
• 危険性（Threat） - 脆弱性は危険性、つまり脆弱性を悪用できるようにしたり悪用させる可能性を増大させます。危険性は攻撃の可能性につながります。そのため、強度の低いパスワードは攻撃の手口にされやすく、一方で攻撃があるまで何年もソフトウェアの脆弱性が存在しつづけることもあります。
• 悪用手段（Exploit） - これはバグ、ミス、脆弱性を利用して意図や予期をしない振る舞いを引き起こすソフトウェア、大量のデータ、一連のコマンドのことです。つまり脆弱性を利用するためのコードや入力のことです。

ハードウェアとサーバが1対1であればセキュリティは比較的簡単な問題です。システム管理者OSの設定をおこなったり起動時にデバイスをセキュアにするスクリプトをインストールしたりできますし、データベース管理者やディベロッパは固定のパスを使ってアプリケーションを設定できます。ネットワークエンジニアやセキュリティチームであればファイアウォールやルータで固定のルールを設定して特定のサーバ、ディスク、サービスへのアクセスを制限することができます。このような固定的なセキュリティ対策をおこなえるのは、システムがひとつのハードウェアに対応付けられ、決められたデータセンターの決められたサブネット上にあるからです。別のサブネットやネットワークへシステムを移すには、物理的にサーバを動かしたり、サーバがつながっているケーブルを差し替えたりしないといけません。しかし、仮想化を使うとサーバを停止させコピーし別のネットワークへ移動させて起動させるということができてしまいます。このようにシステムがネットワークの上を簡単に行き来できてしまう、あるいはネットワークから消えてしまえることは、新たな対策の導入が必要とされることを意味しているのです。

セキュリティで用いられる仮想化

セキュリティは仮想化を最初に取り入れた分野のひとつで、その原動力である可用性と機密性に焦点があてられていました。このことは、以前流行った次のような言葉で表されることが仮想化における最初の試みだったことからも分かります。

VPN - Virtual Private Networkは危険なインターネット上で非公開あるいは機密のデータを安全にやり取りできるようにしたものです。VPNでは送信するデータ本体を転送前に暗号化することで機密性を保とうとします。厳密には複数のネットワークを結合するのでなく、単一のパブリックネットワークを通じて複数のプライベートチャネルをつなげています。

MPLS/VLAN - Multiprotocol Lavel SwitchingおよびVirtual Local Area Netoworkはどちらも異なるネットワークを同一のハードウェアで機能させるものです。この言葉どおりのものであれば、あるネットワークは別のネットワークから分離し、よくできたものであればある仮想ネットワークから別の仮想ネットワークへのアクセスも分離するはずです。

ファイアウォールのパーティショニング - ファイアウォールを別々のネットワークに対して分けて利用することで、複数のファイアウォールルールを作ったり、同一データをログ用デバイスや不正侵入検知システムへ送ることができるようにするものです。さらに、どのポートが使われているかに応じて複数のルールを適用することもできます。このようなことによってファイアウォールは単なるゲートウェイではなくトラフィックの優れた見張り役として機能することになります。

仮想ホスト - VMwareのようなソフトウェアを使うと、システム管理者がシステムのイメージをコピーするだけで同一のシステムを配布することができます。最新のパッチのようなシステム設定を変える新たなセキュリティアップデートも、それを適用してから配布することができます。さらに、イメージを定期的あるいはシステムが汚染された事態に、きちんとした元イメージから再構築することもできます。

ネットワークポート隠蔽 - ホストにポート隠蔽機能をインストールすると、ハッカーがネットワークを容易にスキャニングできないようにすることができます。攻撃者がネットワークに対してポートスキャンをおこなう時には、1から65535までの全ての（TCPおよびUDPの）ネットワークポートをスキャンします。空いているポートが見つかったなら、攻撃者は応答メッセージにもとづいて脆弱性を見つけようとするでしょう。ポート隠蔽ソフトウェアを使うと、ホストは（0番を含む）全てのポートについて不正確な応答メッセージを返すようになります。たとえばWindowsサーバなのにUnixサーバのような応答をしたり、まったく応答しなかったりします。

セキュリティテーマ

アクセシビリティ - サーバファーム（複数のサーバを集約したマシン（あるいは場所））がひとつのシステムとして動くことで、サーバファームの半分がメンテナンスのため停止しても他の半分が動いていればユーザはその停止に気づきません。単一あるいは複数のハードウェア障害も、システムの他の部分が機能してユーザのリクエストに応答していれば、気づかれることはありません。さらにシステム更新やパッチ適応が実行されている時にも、情報が利用可能な状態に保たれます。このように、仮想化の利用はアクセシビリティの向上につながりますが、反対の影響を与えることもあります。:

1) ハイパーバイザ（仮想化においてハードウェアとソフトウェアの仲介をするレイヤ）のエラーが起きると一度に多くの仮想システムがダウンするでしょう。異なるホストマシンにシステムを配置して冗長化するとしても、ホストマシンごとで異なるアプリケーションが存在するとシステムがダメになるかもしれません。このようなシステムをきちんと整えておくことは難しく、特にドキュメントの整備は管理者のTODOリストでは一番最後に位置しているものです。

機密性 - これは仮想化のセキュリティにおいてとりわけ確実なものにするのが難しいテーマです。仮想システムは移動されることがあり、仮想ネットワークも管理者の入力ミスのせいで変わってしまうことがあるため、セキュリティ管理者が対処する時間がないうちにセキュリティの対象となる全体があっという間に変わってしまう可能性があります。次の２つのケースに仮想化の危険性が表れています。

1) 高いセキュリティをもつ仮想LANであるvlan4で稼働することを前提に、比較的ゆるめのセキュリティ設定がされたサーバがあったとします。このシステムが移動されることになった時、ネットワーク管理者が誤ってインターネットへアクセス可能なvlan5の上にサーバを設置してしまいました。ユーザは自分たちのホストにアクセスできるのでこの問題に気づきません。１週間後、アクセス可能とされているホスト以外のホストへのアクセスが起きます。このようなことは物理的に配線されたネットワークやスイッチ専用装置を使っていればそうそう起きることではありませんが、仮想化がおこなわれ、タイプミスが起きてしまうと多くのホストマシンへの侵入が起きる可能性があります。

2) ある仮想ホストが人事データベースへアクセスするシステムのアプリケーションサーバとして設定されています。セキュリティ対策はこのホストに対しておこなわれ、データベースへのアクセスもアプリケーションを通して正しくおこなわれています。このサーバの設定がうまくいっているのをみて、別のアプリケーションチームがこのサーバの仮想イメージをほしいと思い、それを手に入れました。このコピーが作られる時、サーバが人事データベースへ接続できるようにするためのスクリプトや環境設定がユーザ名やパスワードまでも含めてコピーされてしまいました。アプリケーションチームのディベロッパが仮想ホストを起動してみると、給与情報や個人を特定できる情報をふくめ、全ての人事アプリケーション情報にアクセスして読み取ることが可能になっていました。

 

どちらのケースでも仮想化が問題の原因ではないのですが、セキュリティへの影響を考慮しないで用いられたために、意図しないユーザへデータをさらすことになったのです。

完全性 - 仮想システムを使った時にはデータ完全性の問題が起こりえます。この問題が一番起こりやすい状況のひとつは、仮想マシンがコピーされ移動される時です。次の２つのケースがこの問題をよく表しています。

1) データベース１に接続して全ての読み書きが実行できる仮想マシンVM-Aがあったとします。このVM-AがVM-Bにコピーされると、両方の仮想マシンがデータベース1にアクセスできるようになります。使われているメカニズムにもよりますが、このことでデータの上書きや正しくないコミットが起きてしまう可能性があります。そのため、複数の仮想マシンにインストールされることが想定されるアプリケーションが作られる時には、データアクセスが適切に管理されているかを保証するような考慮が必要となります。

2) 仮想マシンのコピーから複製したVM-1からVM-5までのサーバからできたサーバファームがあるとします。ある夜にVM-1が障害により停止し、夜勤のシステム管理者はダウンしたサーバが仮想マシンだと気づかないままサーバに修正を加えてしまいます。こうなると全く同じであるべき5つのシステムで同期ができなくなります。これはパフォーマンスの問題を起こす原因になりますし、あの恐ろしい監査が始まるとコンプライアンス問題になるかもしれません。このような理由から、障害が起きていずれかの仮想マシンに変更が加える場合は、元のコピーにも同じ変更を加えないといけません。緊急事態が過ぎて、修正をちゃんと評価した後で、元のコピーにも変更を加え、そしてそれを他のホストにコピーをおこなう必要があるのです。

 

注意事項

新しいテクノロジが発表される時はいつも、それが全ての問題を解決し、少ないリソースでおこなえるようになり、燃費が良くなると発言する誰か（大抵はその有り難いものを作ってくれた人）がすぐに現れます。仮想化もご多分にもれません。そしてその売りの一つが仮想化が支援する上記のようなセキュリティ性です。しかしそれらの利点も考えなしでは得ることができません。

ハイパーバイザの攻撃 - 物理的なシステムには攻撃をおこなう場所として複数のレイヤがありましたが、仮想化はさらにもう一つのレイヤを加えます。物理的なネットワークやシステム、アプリケーション、そしておそらくはデータベースも含むレイヤに加え、仮想化を利用することで仮想マシンのハイパーバイザへの攻撃を許すことになりえます。その攻撃の種類には次のようなものがあります。

• サービス停止（DoS） - 初心者クラッカーたちお気に入りのDoS攻撃は、ハイパーバイザひいては多くのマシンをダウンさせることができ、一方で攻撃者は時間をかけずに次々と攻撃をおこなうことができます。物理的なシステムに対するDoS攻撃に比べると、仮想システムはその多重通信ができるという利点のゆえに大きな損害を受けることが考えられます。
• 仮想マシン越え - ハイパーバイザのセキュリティホールを悪用することで、ある仮想ホストにログインしていたユーザが別のホスト、たとえばあるWindowsホストから別の Windowsホストにログインすることが可能になることが考えられます。このようなセキュリティホールはまだ見つかっていないものの、これから見つかることはありえます。実際、VLANが最初に導入された頃にはシステムの802.1qタグ（1つのポートで複数のVLANスイッチを接続するための規格）を変えてしまうことが可能で、それによりVLANをまたぐことができたのです。
• ホストトラフィックの横取り - ゲストOSからホストOS、そしてハードウェアへのシステムコールはいつかは起きるものですが、ハイパーバイザを悪用できるとそのシステムコールを読み取られる可能性があります。さらに、ページングファイルやメモリ、ディスク書き込みの管理システムを攻撃者が破壊することができるなら、それらを読み取られる可能性もあります。

まだハイパーバイザの脆弱性はほとんど見つかっていませんが、これは仮想化がまだ初期段階にあるからでしょう。どんな新しいテクノロジでも、注目を集め出せば脆弱性が見つかってくるものです。OpenBSDの生みの親であるTheo de Raadt氏の言を引用すると「あなたの頭が悪くなかったとして、OSやアプリケーションをセキュリティホールなしには作れないエンジニアであっても、仮想化レイヤなら途端にセキュリティホールなしのものが作れると考えているのなら、はっきり言ってあなたは欺されてます。」この言葉では仮想化は役に立つのと同じくらい問題も引き起こしえるという事実がうまくまとめられています。

新しい考え方

仮想化をおこなっているときには、本番サーバへ仮想ホストやハイパーバイザを移す前にその影響範囲を調べることが重要になります。解決すべき問題の中には、どのアプリケーションを同一のハイパーバイザ内においていいか、仮想化システムをどのように移動させるべきかについてのポリシーの問題があります。

ポリシーは、重要なアプリケーションの組が同一のハイパーバイザに存在しないように更新される必要があります。たとえば、セキュリティ対策が全くあるいはあまりされていないアプリケーションは、インターネットに仮想ホストがさらされているシステムには置いてはいけません。まだ今は何の危険性もありませんが、明日脆弱性が見つかったとしたらそのアプリケーションもそれ以外のものも危険にさらされることになります。論理的な観点からシステムがどのように分離されるべきか、アプリケーションサーバとデータベースは分離すべきか、など、世の中にはすでに多くのセキュリティポリシーが存在します。しかしこれらポリシーは仮想化が適用された時点で有効性を失います。実際に適用する前にポリシーやガイドラインを更新することで、多くの悩みの種や移行時のセキュリティスタッフによる反対を抑えることができるようになるでしょう。

ポリシーが更新される必要があると思われる2つめの点は、仮想ホストの移動に関するルールです。ある物理的なホストに存在するアプリケーション・データベースあるいはシステムというのは、データを切り離すのが難しくしばしば再構築がおこなわれます。この理由から、比較的利用側でデータを管理することができます。しかし仮想化では仮想ホストがコピーできることで新しい問題が起きます。オリジナルはそのままでデータのコピーを持ち出すことが可能なため、データ盗難が起きる可能性がありますし、もし2つの仮想マシンが同じデータベースにアクセスするような設定になっていたらデータ破壊も起きえます。これらの理由からポリシーは仮想システムも含めたものに書き直す必要があります。

おそらくみなさんが仮想化の別の利用方法として考えるのが「マスタ」仮想マシンの利用でしょう。マスタを使うことで、本番環境のコピーをハイパーバイザに配ることができます。何か変更があった場合には、その変更をどこかで行えば、他のコピーへ順次反映されていきます。変更が順次反映されるということはシステムが応答可能であり続けているということで、何か問題があった時にロールバックすることも可能です。さらにマスタコピーを使うことで開発環境やテスト環境をマスタと同じ状態にリフレッシュすることができます。

まとめ

仮想化はシステム管理者や開発現場にとって約束されている大きな恩恵を得られるものとして理解されていると思います。しかしそのポテンシャルが完全に理解されるには、セキュリティ面が注意深く考慮される必要があります。どんなテクノロジでもそうであるように、セキュリティ配慮は本番で利用される前におこなう必要があります。ビジネス面と機密性・完全性・アクセシビリティからなるセキュリティ面とで仮想化を評価することで、ベンダの言葉にのせられた目的のためではなく道理にかなった目的のために仮想マシンの利用ができるのです。

原文はこちらです：http://www.infoq.com/articles/virtualization-security
（このArticleは2008年7月13日に原文が掲載されました）