クラウド内の脆弱性と脅威を回避する

クラウド内のセキュリティーに関して組織は何を知っておくべきか

Web 2.0 以来、クラウドは最も多くの議論がなされてきた技術の 1 つです。クラウドはコストの削減が約束されるものとして称賛されてきましたが、多くの組織はセキュリティー上の理由から、クラウド・ベースのソリューションを追求することをためらっています。他のすべての技術と同様、クラウドは悪意のある攻撃を受ける可能性があります。しかしクラウドで直面する可能性があるセキュリティー上の難題を理解すれば、クラウドに保存したリソースを十分セキュアに維持できることがわかります。

Jeff Orloff, Freelance Technology Writer, Sequoia Media Services Inc.

Jeff はフリーのテクニカルライターであり、School District of Palm Beach County (パームビーチ郡学区) の技術コーディネーターでもあります。彼はセキュリティーを専門に、一貫して Web 技術を扱ってきました。彼はこれまで、SafeWave の技術担当ディレクター、Applicure Technologies のセキュリティー・エバンジェリスト、Developer Drive (Web サイト開発に関するチュートリアルを専門とするブログ) の編集者を務めた経験があります。



2012年 2月 10日

概要

Gartner のシニア・アナリストの 1 人は、クラウド・コンピューティングが「今はやりのフレーズ」であると言っています。IT (情報技術) に関わっている人であれば、このフレーズが今後も当分の間よく使われそうであることがわかるはずです。実際、Gartner はクラウド・コンピューティング市場が 2013年までに 1500 億米ドルに達すると予測しています。Merrill Lynch も同様であり、2013 年までに 1600 億米ドルに急成長すると予測しています。

このようにクラウド・コンピューティングがよく話題になる理由は、クラウド・コンピューティングがリソースと費用を節約するように構築されているためです。ソフトウェア、ストレージ、e-メール等々をクラウドに移行することで、組織はそれらのサービスに必要なリソースのみを用意すればよくなります。ストレージ・スペース、計算処理能力、メモリー、さらにはライセンスさえも用意したのに、それらが使われる機会を待っているということがなくなります。それらが必要になると、クラウドに用意されたものが使用され、使用した分だけ費用が支払われます。図 1 は Wikimedia Commons からの引用ですが、この図はクラウド・コンピューティングの概要を示しています。

図 1. クラウド・コンピューティングの概要
クラウド・コンピューティングの概要

組織はさらに、クラウドによる人員の削減にも注目しています。IT サービスをクラウド・プロバイダーにアウトソースすることで、組織は IT スタッフを減らすことができます。組織はそれらの人員をビジネス推進のプロジェクトに専念させることができ、クラウド・プロバイダーで対応可能なサービスのサポートに彼らが時間を費やす必要はなくなります。

コストを削減できる可能性があるにもかかわらず、なぜ組織はデータ、ソフトウェア、その他のサービスをクラウドへ移行するのをためらうことがあるのでしょうか。その理由を理解するには、クラウドにまつわるセキュリティー・リスクについて考えてみる必要があります。ほとんどのアンケートによれば、IT リーダーがクラウド・ベースのソリューションへの移行をためらう最大の理由はセキュリティーです。LinkedIn で行われた最近の調査では、回答した 7,053 人のうち 54% が、クラウドへの移行に関してセキュリティーを最大の懸念事項に挙げています。

他のすべての IT サービスと同様、クラウドには攻撃の対象となりうるセキュリティーの脆弱性があります。しかし、これらの脆弱性とその対処方法を理解する IT 専門家が増えるにつれ、クラウドはより安全な場所になります。実際、Mimecast の調査によれば、調査に参加した人の 57% が、クラウドに移行したことによってセキュリティーが改善されたと答えています。そう答えた人の大半は、クラウド・コンピューティングが安全だと感じる理由として、彼らがクラウドでの脅威を理解し、それらの脅威を軽減する方法を学んだことを挙げています。

この記事では、クラウド・コンピューティングに付随する一般的なセキュリティー・リスクと、それらのリスクを軽減するために組織がとり得る手段について、その概要を説明します。

共有技術リソース

クラウド・コンピューティングは 4 つのデプロイメント・モデルに分類することができます。表 1 はその 4 つのモデルを説明したものです。

表 1. クラウド・コンピューティングのデプロイメント・モデル
モデル説明
パブリック・クラウドサービス・プロバイダーはインターネットを介して誰もが利用できるようにリソース (アプリケーション、ストレージ等) を公開します。
コミュニティー・クラウドいくつかの組織がリソースを共有します。
プライベート・クラウドインフラストラクチャーは 1 つの組織専用です。
ハイブリッド・クラウドこのモデルは他の 2 つ以上のデプロイメント・モデルを組み合わせています。

パブリック・クラウド・モデル、コミュニティー・クラウド・モデルに加え、ハイブリッド・モデルの一部でも、さまざまな顧客が仮想化を利用してリソースを共有します。このコンピューティング・プラットフォームには以下に挙げる潜在的な弱点があります。

  • 異なる仮想マシン間の通信、または仮想マシンとホストの間での通信は、共有ディスク、仮想スイッチ、あるいは VLAN (Virtual Local Area Network) と共有 I/O もしくは共有キャッシュを介して行われます。
  • 汎用のドライバーによってハードウェアがエミュレートされます。
  • ハイパーバイザーの脆弱性により、ホスト上で任意のコードをハイパーバイザーの特権で実行することができるため、攻撃者がすべての仮想マシンとホスト自体を制御できてしまう場合があります。
  • 仮想マシン・ベースのルート・キットによってハイパーバイザーのシステム・コールを変更し、ホスト・オペレーティング・システムを呼び出して悪意のあるコードを実行することができます。
  • VM エスケープとして知られる攻撃では、ある 1 つの仮想マシン上の 1 つのプログラムが共有リソースを介して無制限にホストにアクセスします。
  • 1 つの仮想マシン上で実行される DoS (サービス不能) 攻撃により、同じホスト上で実行される他の仮想マシンが動作不能になる場合があります。

これらの弱点を突いた攻撃から守るために取るべき最初のステップは、作業対象となる環境を理解することです。法律、標準、業界規制により、データや他のリソースに対してセキュアな環境が必要な場合には、どういったタイプの環境を使用するかに注意した上で、それらの要件を反映した手法をとる必要があります。当然ですが、このシナリオに適したソリューションは、プライベート・クラウド、あるいは場合によってはハイブリッド・クラウドであり、機密データ、トランザクション、サービスをプライベート・セクションでホストすることにより、組織はセキュリティーとアクセスに関して、より詳細な制御を行うことができます。

次に、クラウド・プロバイダーに対する評価を行う必要があります。上記の脆弱性を突いた攻撃から守るためにクラウド・プロバイダーがどのような手段を講ずるのか、特にハイパーバイザーの脆弱性を突いた攻撃から守る手段について議論する必要があります。プロバイダーがどのような仮想化ソフトウェアを使用しているのか、またパッチやアップグレードに対するスケジュールについて、彼らに問い合わせる必要があります。ハイパーバイザーに変更が加えられることがないように、ホストは信頼するに足るプラットフォーム・モジュールを使用しているのかどうか、またそのモジュールとハイパーバイザーとの関係は信頼するに足るものかどうかを確認する必要があります。

さらに、DoS 攻撃から守るために、きわめて大量のリソースが使用されている状況を検出できるようにハイパーバイザーが構成されているかどうかを確認する必要があります。


データの消失と漏洩

「Data Leakage Prevention and Cloud Computing (データの漏洩防止とクラウド・コンピューティング)」という記事の中で、KPMG LLP は次のように述べています。「パブリック・クラウドにデータが公開されると、その組織が配備した DLP (Data Leakage Prevention) は、そのデータの機密保護には役に立ちません。また提供モデルが SaaS (Software as a Service) の場合も PaaS (Platform as a Service) の場合も、パブリック・クラウドに保存したデータの機密性をその組織が直接制御することはできません」。この記事の完全な内容については「参考文献」を参照してください。

米国では 1996年に HIPAA (Health Insurance Portability and Accountability Act: 医療保険の相互運用性と説明責任に関する法律) が発効され、PCI DSS (Payment Card Industry Data Security Standard: クレジット・カード業界データ・セキュリティー基準) が採用されているなかで、組織はデータの保護を真剣にとらえる必要があります。クラウド内でのデータ漏洩を防ぐために何をすればよいのでしょう。

市販のデータ漏洩防止製品を利用することが最善のソリューションのように思えますが、これらの製品はデータの完全性や可用性のための製品であり、データのセキュリティーのための製品ではありません。また、これらの製品は通常、インフラストラクチャーを制御できない環境にデプロイすることはできません。

漏洩防止のためにはそうした製品を利用するのではなく、データの格納と送受信のシステムを強化する必要があります。

それには何よりもまず、クラウド・プロバイダーはデータを扱う場合 (データが保管されている場合と送受信される場合の両方で)、高度な暗号化を採用する必要があります。また、皆さんの組織とクラウド・サービス・プロバイダーとの間でサービス・レベル・アグリーメント (SLA) を必ず締結する必要があり、その中で、クラウド内のデータのセキュリティーについて役割と責任を明確に定義する必要があります。さらに、クラウド・サービス・プロバイダーが永続性のあるメディアをプールにリリースする際には、必ずそのメディアのデータを消去してからリリースすることを、SLA に記載する必要があります。

PCI DSS に準拠するための別の手段として、組織は必ず、Web アプリケーションのためのファイアウォールを適切に構成し、Web ベースのアプリケーションを無数の攻撃から保護する必要があります。いずれかの SaaS プロバイダーと契約する前に、組織の IT 部門は Web ベースのソフトウェアに対する保護のレベルについて議論する必要があります。可能であれば、皆さんの会社が使用する任意のアプリケーションに対して侵入テストを実行する必要があります。

そして最後に、クラウドでのデータ漏洩を防止するために、社内で一連の手段を講じることができますが、そのためにはデータに関するポリシーを変更する必要があります。データ漏洩を恐れる組織であれば、データを機密度に応じて分類し、さまざまなレベルのデータの処理方法に関する基準を提供するポリシーを用意する必要があります。簡単に言えば、一部のデータはクラウドへの保存には適していないかもしれません。


セキュアでない API

顧客がクラウド・ベースのサービスとやり取りできるように、プロバイダーは API (Application Programming Interface) を使用します。プロビジョニング、管理、オーケストレーション、監視にはすべて、これらのインターフェースが使用されます。そのため、クラウドで提供されるサービスの基本的なセキュリティーは、これらの API がどれほどセキュアなのかに依存します。

匿名アクセス、トークンやパスワードの再利用、平文によるコンテンツの認証や送信、柔軟さに欠けるアクセス制御、不適切な承認方法は、どれもセキュリティーの面で深刻な問題があります。さらに、顧客が行う監視やロギングの機能には制限があることを考えると、顧客は基本的に、支払い対象であるリソースに誰がアクセスするのかについて、プロバイダーに一任せざるを得ないように思えます。

また、サードパーティーによって作成された API の問題もあります。これらの API は顧客への付加価値サービスとして作成されることが多いのですが、これらのアドオンは必ずしも他の API と同じ種類の審査やレビューを受けているわけではありません。そのため、API には複雑なレイヤーがさらに追加され、セキュリティー・リスクが高まります。さらに、サードパーティーの API は、その API で提供されるサービスにアクセスするために、組織がクレデンシャルを放棄することを (場合によっては、組織が知らないうちに) 想定している場合があります。

こうしたリスクへの主な対策として、クラウド・プロバイダーのセキュリティー・モデルを評価、分析し、API をセキュアにするためにあらゆる手段が講じられているかどうか、確認する必要があります。

組織は認証とアクセスの制御について精査し、送信データが暗号化されているかどうかを確認する必要があります。また、契約を締結する前に、依存関係を追跡して各 API を理解し、その API で何が要求されるのかについても理解しておく必要があります。


乗っ取り

これらの脆弱性の大部分は主にクラウド・プロバイダーの肩にかかっていますが、アカウントやサービスが乗っ取られる脅威の可能性に関してはプロバイダーと顧客の両方に責任があります。

ソフトウェアに脆弱性がある場合、攻撃者が元々のデータ・ソースからアカウント情報を盗むことは可能ですが、それがユーザーのクレデンシャルを盗む手法として一般的なわけではありません。一般的には、攻撃者はフィッシング攻撃、悪意のあるソフトウェアによる傍受、詐欺的行為などにより、ユーザーのログイン情報を盗みます。人々はさまざまなサービスに対して同じユーザー名とパスワードを使用する場合が多いため、攻撃者は多くの場合、最も容易にクレデンシャルを乗っ取れる方法を見つけ出そうとします。乗っ取りの対象は、犠牲者がクラウド・プロバイダーとは別に使用している別のサービスかもしれません。攻撃者がユーザーのクレデンシャルを自在に使えるようになると、彼らはクラウド内に保存されたデータの完全性と機密性を脅かします。彼らはさらに、これらの同じクレデンシャルを使用して他の人々に対する攻撃を開始し、組織の評判に深刻なダメージを与えるかもしれません。

クラウド・プロバイダーのセキュリティー・ポリシーを理解することに加え、組織はクラウド・ベースのサービスのアクティビティーに対して何らかの形で先を見越した監視を行うことで、無許可のアクセスやアクティビティーを監視できるようにする必要があります。

また、ログインのクレデンシャルを必ず一意にし、パスワード・ポリシーを強化することも、ユーザー情報が共有されることによる悪用を防止する上で効果的です。2 要素認証の手法を使用すると、上記の種類の攻撃によるリスクをさらに抑えることができます。


内部関係者がもたらす脅威

組織は通常、従業員を雇用する前や、従業員に特定の情報へのアクセスを許可する前に、十分な人員選別を行います。クラウド・プロバイダーに関して言えば、彼らの従業員管理のプロセスや手順は透明性に欠けています。

通常、クラウド・プロバイダーにサービスを任せるということは、依頼元の組織のリソースに対して (物理的にも仮想的にも) 誰がアクセスするのかわからない、ということです。クラウド・プロバイダーは、彼らが従業員をどのように監視するのか、またポリシーに準拠しているかどうかをどう分析、報告するのかについて、顧客に知らせません。

機密データや財務データを扱えるという機会は、悪事を働くハッカーや産業スパイにとって大きな魅力です。彼らはクラウド・ベースのサービスを提供する企業で働くことにより、ほとんどあるいはまったく危険を冒すことなく、機密データを入手したり、クラウド・サービスを完全に制御したりできてしまう可能性があります。

顧客は最初のステップとして、プロバイダーが悪意のある内部関係者を見つけ出すために、また内部関係者による悪事を防ぐために、何をしているのかを理解する必要があります。情報セキュリティーと管理の実践について透明性を求めるだけではなく、セキュリティーが侵害された場合の通知プロセスについても知っておく必要があります。通知までの時間や報告プロセスが受け入れがたい場合には、別のプロバイダーを探す必要があります。


まとめ

クラウド・コンピューティングには、協力作業が容易である、世界中の遠隔地で作業が可能である、コストを削減できるなど、大きな魅力があります。クラウドへ移行することに付随するリスクはありますが、それらのリスクは社内でサービスがホストされる場合よりも大きいわけではありません。主な違いは、クラウドは攻撃者による攻撃対象としては、これまでになかった新たな対象であるという点です。

少し時間をかけ、クラウドに存在する脆弱性を理解し、それらの脆弱性を突いた攻撃を防ぐ手段を理解すれば、クラウド・ベースのサービスは皆さんの組織の LAN や WAN でホストされるサービスと同じくらいセキュアなものになります。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=791369
ArticleTitle=クラウド内の脆弱性と脅威を回避する
publish-date=02102012