【 ここから本文 】
- TOP
- > Topics : IT基盤技術
- >
IT基盤技術
ソーシャルブックマークに登録 :
印刷用ページの表示
【解説】
クラウド・コンピューティングのインパクト[前編:定義と関連技術]
ユーザー/IT部門はどうとらえ、備えるべきか
(2008年08月29日)
クラウド・コンピューティングのミーム・マップ
このように整理してみると、クラウド・コンピューティングは、今までに何度も議論されてきたネットワーク中心型コンピューティングのさまざまなビジョンを総合的な概念として言い換えたものと言うことができよう。しかし、これをもって「クラウド・コンピューティングという言葉に意味がない」などと結論づけるつもりはない。
Web 2.0という用語が登場したときにも、「総花的で明確な定義がない」「すでに起きている現象の単なる言い換えであり新しい考え方ではない」といった批判が多く聞かれた。しかし、当時インターネットの世界で同時多発的に発生している多様なパラダイム・シフトを総合的に表現できる言葉(いわゆる、「アンブレラ・ターム」)としてWeb 2.0が登場したことで、Webの世界で起こりつつあるムーブメントを明確化できたという意義は大いにあっただろう。クラウド・コンピューティングという言葉も、Web 2.0という言葉が果たしてきたのと同様の役割を今後果たしていくのかもしれない。
ところで、Web 2.0という言葉が登場した当初は、米国O'Reilly Mediaの創設者、ティム・オライリー(Tim O'Reilly)氏によるミーム・マップがWeb 2.0の全体像を表現する図として使用されることが多かった。ミーム・マップとは関連する概念を列挙した図のことで(注3)、おそらくは、O'Reilly氏がブレーンストーミングのような場でホワイトボードに描いた図をそのまま使ったのであろう。
決して完全に整理されているとは言えないが、このミーム・マップによりWeb 2.0の理解が進んだ人は多いはずだ。ここでは、同様にクラウド・コンピューティングのミーム・マップを描いてみた(図2)。クラウド・コンピューティングの全体像が多少なりともクリアになるのではないだろうか。
以上、本稿では[前編]として、クラウド・コンピューティングという概念に関連する用語(技術)を整理したうえで、ミーム・マップを作成し、定義を試みた。続く[後編]では、この概念を推進していく背景、主要な要因を挙げて解説し、IT業界の各ビジネス層に与える影響を計ってみたい。
| 図2:クラウド・コンピューティングのミーム・マップ |
注3:ミーム(meme)は、生物学的遺伝によらずに人から人に伝えられ自然淘汰されていく、いわば文化的な遺伝子を指す言葉である
Side Story
クラウド・コンピューティングの利用で注意すべき「7つのセキュリティ・リスク」
Gartner、「サービス利用前のサードパーティへの評価依頼を推奨する」
Jon Brodkin/Network World米国版
米国の市場調査会社Gartnerは6月3日、「Assessing the Security Risks of Cloud Computing」と題した調査リポートを発表した。その中でGartnerは、クラウド・コンピューティングはセキュリティ上のリスクをはらんでいると警告しており、サービス利用の前には問題となりそうな点を厳しい目で洗い直し、中立的なサードパーティへの評価依頼を検討するのが賢明だとアドバイスしている。
このリポートによれば、クラウド・コンピューティングは、データの完全性や復旧、プライバシーなどのリスク評価のほか、電子情報開示、コンプライアンス、監査に関する法的問題の評価が必要だという。Gartnerはクラウド・コンピューティングを、「きわめてスケーラビリティの高いITシステムを『サービス』として提供するタイプのコンピューティング」と定義しており、Amazon.comの「Amazon EC2(Elastic Compute Cloud)」やGoogleの「Google App Engine」をその例として挙げている。
一方でGartnerは、サービスを利用するユーザー企業に対しては、セキュリティ・プログラムに関する詳細情報の開示を拒むクラウド・ベンダーの利用を避け、透明性を保てるように心がけねばならないと述べている。「ポリシー作成者/アーキテクト/コード記述者/オペレーターの持つ資格についてベンダーに質問し、リスク管理の手順や技術的な仕組みを確認することが必要だ」
また、「サービスや管理プロセスは意図したとおりに機能しているか」「予期せぬ脆弱性を把握する能力はあるか」などの検証テストをベンダー側がどの程度行っているかについても、顧客はチェックしなければならないとしている。
Gartnerは、クラウド・ベンダーを選定するにあたり、ユーザー企業がベンダーに確認するべきセキュリティ関連事項は大きく7項目あるとし、以下のような説明を行っている。
1.特権ユーザーによるアクセス
アウトソースされたサービスは、企業のIT部門が社内プログラムに対して行使する、物理的管理、論理的管理、人的管理の影響を受けない。そのため、社外で処理された機密性の高いデータは最初からリスクを含有している。よって、従業員の具体的な情報をベンダーに提供させ、特権を持つ管理者や彼らに対するアクセス監視/制御を行うよう求める必要がある。
2.コンプライアンス関連
たとえ管理するのがベンダーの側だとしても、自社データの安全性と完全性は、最終的に顧客が責任を持つことになる。通常のベンダーであれば、基本的に外部の監査や安全性のチェックを受けている。だが、この種の調査を拒否しているクラウド・ベンダーもいるため、そうしたベンダーには重要性の最も低いデータしか任せられないことになる。
3.データの保管場所
クラウド・コンピューティングの特性ではあるが、多くの場合、データがホスティングされる正確な場所は顧客にはわからない。したがって、「データの保管/処理は明確な法的権限に基づいて行われるのか」「現地のプライバシー保護規制に従うことを契約条件に盛り込めるか」といった点を、ベンダーに事前に確認しておきたい。
4.データの隔離
クラウド内のデータは、通常は他の顧客データとシステム環境を共有することになる。こうした環境下では暗号化が有効な対策となるが万全ではなく、どのような方法で保管しているデータを隔離しているのかを把握しておく必要がある。クラウド・ベンダーは、経験豊富な専門家と共に暗号化スキームを設計し、検証結果を顧客に示さなければならない。暗号化スキームに不備があると、データがまったく使えないという事態が発生する。ごく一般的な暗号化であっても、利便性を損なう場合がある。
5.データの復旧
クラウド・ベンダーは、たとえデータの保管場所を明らかにしないとしても、災害が起こった際に顧客のデータおよびサービスがどうなるのかは開示しておくべきである。データおよびアプリケーション・インフラのレプリケーションを行っていないサービスの場合、大規模な災害時に顧客が致命的なダメージを被ることになる。したがって、「完璧なリストアを実行するだけの備えがあるのか」「復旧までにどれぐらい時間がかかるのか」をベンダーに確認しておく必要がある。
6.調査に対する協力姿勢
クラウド・コンピューティングにまつわる不適切行為や違法行為は、現状では調査が難しい。多数の顧客のログイン記録やデータが共同保管されていたり、複数のデータセンターに分散保管されていたりする可能性があるため、クラウド・サービスの実態を追跡調査するのは非常に困難だ。特定の調査にベンダーが協力するという条件を契約に盛り込むことができる、もしくは当該のベンダーがそうした調査を積極的に受け入れてきたという実績がある場合を除き、調査や証拠開示に対する要求はまず通らないと考えたほうがよい。
7.長期にわたる事業継続性
理想を言えば、決して倒産せず、また、大手企業に買収や合併吸収されることのないクラウド・ベンダーを選びたいところだ。とはいえ、そうした出来事が起こった後もデータを利用し続けられるよう、ユーザーも準備しておく必要がある。契約を結ぶ可能性のあるベンダーとの話し合いでは、データの回収方法と、その際に利用するフォーマットが後継アプリケーションに移植可能なものであるか否かを確認しておきたい。
【解説】クラウド・コンピューティングのインパクト[後編:推進要因と各層への影響]


ユーザー/IT部門はどうとらえ、備えるべきか
[米国]アマゾン、「Amazon EC2」クラウドにブロック・ストレージ・サービスを追加

仮想マシンへの永続ディスク・ボリュームの割り当てが可能に
【解説】「Gmail障害」で浮き彫りになった、無料サービスを業務利用することのリスク


グーグル、2週間で3回発生したログイン障害を解決するも不安解消には至らず
【解説】MobileMe騒動――アップルに顧客満足度の高いクラウド・サービスは提供できるのか?


流出メールでジョブズCEOの改善策が判明。だが、そこに立ちはだかる“企業文化”
【IBM IT VISION】IBMの日米キーパーソンが語る、クラウド・コンピューティングの“あるべき姿”


「簡素化」「共有化」「ダイナミック」の3ステップでクラウド環境の実現を目指す
[米国]デル、「クラウド・コンピューティング」を商標登録申請

同分野でのイニシアチブ争奪戦が開始?
[米国]HP、インテル、ヤフーの3社、クラウド・コンピューティングの共同研究プロジェクトを発表

大規模なデータ集約型アプリや関連インフラを研究開発

