IaaSセキュリティの勘所はハイパーバイザーのセキュリティにあり

ハイパーバイザーの脆弱性はクラウドセキュリティの脆弱性そのものだ。ハイパーバイザーをものにできれば、各テナントの仮想環境に自由にアクセスできるからだ。

公開 2012年10月02日 08時03分

著者

Char Sample

[TechTarget]

印刷する Googleで優先するソースとして追加

　IaaS（Infrastructure as a Service）の台頭は、仮想環境の普及によるところが大きい。従って、仮想環境のセキュリティが、IaaSセキュリティの“要”になる。このセキュリティこそ、サービス運用の基盤だ。仮想環境とセキュリティ確保の関係を考えるときに注目すべき領域としては、ハイパーバイザーのセキュリティ、リソースの再利用、テナントの管理がある。

IaaSのセキュリティに関する記事

ハイパーバイザーのセキュリティ

　仮想環境を作成し管理するハイパーバイザーは、主要な攻撃対象の1つになっている。ハイパーバイザーをものにできれば、各テナントの仮想環境に自由にアクセスできる。これは、従来のIT環境で見られた、特権ユーザーの権限悪用の問題に似ている。ただしクラウドの場合は、セキュリティ侵害の被害が1組織にとどまらず、全ての仮想環境に影響する点が異なる。1台のサーバで平均20組織をサポートできる環境なら、ハイパーバイザーが侵害されると、20の組織全てが不正な特権ユーザーの問題に直面することになる。

　ハイパーバイザーの脆弱性は幸い多くはないが、ゼロではない。あるマルウェアがハイパーバイザーを乗っ取り、それが検知されなければ、マルウェアの作者にぬれ手で粟をつかむ機会を与えることになる。1台の物理サーバに侵入しただけで多数の組織の情報を入手し得るのだから。

　最近報告された「Stuxnet」（産業インフラに感染するマルウェア）、「Duqu」（Stuxnetに類似したマルウェア）、「Flame」（国家の施設を標的とする高度なマルウェア）は、ベストプラクティスとされるセキュリティソリューションの多くが役に立たなかったことを示した。検出されるまでにかかった時間と、この3種類のマルウェアによる被害の大きさを考えてみてほしい。その上で、これらのマルウェアのほとんどがセキュリティソフトウェアを実装しているクラウドサービスではないネットワークに対して、攻撃を成功させていることを考えてほしい。クラウドは、いいかもをまとめて差し出しているようなものだ。

ボットネット攻撃に関する記事

　Duquのようなマルウェアは情報をモニターしてひそかに外部に送る。ハイパーバイザーをターゲットとする同様のマルウェアが作られれば、仮想環境の作成時や運用時の情報だけでなく、環境の破棄についての情報さえも盗み出せるだろう。この情報はひそかに外部に送られるため、存在し続ける。従って、仮想環境を破棄しても、データの破棄は保証されない。

　また、ハイパーバイザーを標的とするDuquのようなマルウェアがあったとしたら、仮想環境についてのログ情報を変更することもできるだろう。これをどう利用するかというと、ログを破壊して攻撃者の特定を難しくすることと、ハッカーがクラウドの仮想環境を攻撃拠点として悪用できるようにすることだ。

　現時点では、これらの攻撃シナリオはどれも実際には発生していない。また、筆者の意図したところは、読者の恐怖心を煽ることではない。情報を提供して、クラウドへの移行が理にかなうかどうか、また移行するのであれば、どの程度のデータをクラウドに移行し、ローカルにどの程度残すのかを検討する際に、読者に十分に注意してほしいという思いからである。

セキュリティを考慮したIaaS選びに関する記事

IaaSのセキュリティ：リソースの再利用とテナントの管理

　仮想環境では動的にリソースを割り当て／解除できるが、これは法律上面倒な問題になる可能性がある。

　IaaSクラウドが攻撃拠点に利用され、クラウドサービスプロバイダー（CSP）がこの攻撃に気が付かなかった場合、攻撃に使用された仮想環境をCSPが保存する前に、テナントである攻撃者はその環境を削除できる。ユーザーがCSPと契約を結ぶ際は、通常、ログデータを保存するよう求めるが、クラウドを攻撃拠点として使用することをもくろんでいる場合は、ログなどのデータの保存を求めるとは思えない。クラウドから攻撃を仕掛ける攻撃者は、所有権の問題や法域がいまだ確定していない、法のグレーゾーンに入ろうとするだろう。

　クラウド内での攻撃は、当然ながら対応が違ってくる。クラウドの場合、CSPが各利用者のポリシーに従ってセキュリティ問題に対応することになっている。攻撃が行われた場合にCSPが従うポリシーや手続きは、各利用者とCSPとのサービスレベル契約（SLA）に規定される。このようにSLAに対処方法を盛り込んでおくとテナントに対して攻撃が仕掛けられた場合に有効だ。テナントの連絡窓口（POC）には直ちに連絡が行く。ただし、攻撃の対象がCSPであった場合は、テナントのPOCには最初に連絡は来ないだろう。従って、許容できる通知期限もSLAに盛り込んでおく必要があるが、即時の通知は期待できないだろう。

　動的であるというクラウドの性質は、いささか手を出したい気持ちにさせる。ネットワークリソースの動的プロビジョニングや必要に応じての再割り当ては、多くのビジネスが持つ「ジャストインタイム」の性質に合う。必要なものを必要なときにプロビジョニングできれば、無駄を省け、費用の節約になる。しかし、攻撃の調査が必要になったときに、このような動的な環境では、既に削除された情報の一部しか見つからないとしたら、調査はますます難しくなる。また、たとえデータを回復できたとしても、今度は「見つかった」データの所有者が問題になる。

　CSP各社は本気でユーザーデータの分離と保護に取り組んでいる。しかし、CSPとクラウド利用者間で交わされるSLAでカバーできるのは既に認識されていることだけだ。これは、クラウドのセキュリティの問題の核心である。次に見つかる脆弱性とそれが悪用された場合の影響を予測し、対策をとることまでは規定されていない。理想的には、SLAで条件を明示しておきたい。

　クラウドセキュリティの持つ曖昧さは、クラウドをハッカーや犯罪者、サイバー兵士にとって魅力的な標的になっている。クラウド利用者は、ベストプラクティスに従って対策を講じていても、クラウドにゼロデイ攻撃が仕掛けられた場合、データが攻撃者の手に渡る可能性がある。このような事態が実際に発生すれば、新しい法域が整備されるだろうが、その結果がどうなるかは分からない。ただし、過剰なクラウドへの期待から一歩身を引き、より賢明なクラウドの移行パスを確立するためには、法の整備が必要だ。

印刷する

この記事の著者