【雲をつかむ話】クラウドコンピューティングの実際の最近の記事

SaaSのセキュリティといっても、表面について言うならば、いわゆるWebアプリのセキュリティだろうと思う。ユーザに委譲された範囲でのID管理はさておき、事業者側では、アプリケーションレベルでの脆弱性対策をしっかり考えておくべきだ。基本的には、不正入力に対するチェックをきちんと行って、インジェクション系の攻撃を防ぐことだ。ただ、一般のWebアプリとは異なり、基本的にマルチテナントでサービスを行うSaaSでは、ユーザ間のアクセス制御やリソースの分離にも神経を使う必要がある。たとえばデータベースを共用するような場合、アプリケーションからデータベースへのアクセス権限がユーザごとに分離されていないと、脆弱性に対する攻撃を正規のユーザが行った場合、被害は全ユーザに及んでしまう。基本的には、このようなことがないように、少なくともデータベースへのアクセス権限はユーザごとに管理できるようにしたい。

アクセスログの取得とユーザへの提供も重要だ。認証部分をSAMLなどで外出しできれば、認証ログについては、サードパーティーの認証サービスで対応できるが、データへのアクセスログはサービス事業者自身が提供しなければいけない。昨今の状況下では、情報の管理にアクセスログの取得が要求されるケースが多く、これが不可能なSaaSは、現実的には使いにくいのが正直なところだ。

SaaSの最も大きな特徴は、APIによるシステム連携が可能な点だと先に書いたが、多くの場合、このAPIは、XML Webサービス、つまりSOAPによって実装されている。表に見えるユーザインターフェイスとは違って、直接、コンピュータによってアクセスされるAPIは、自由度が高い分、リスクポイントも大きくなりがちだ。XML化されたデータの各要素がサーバサイドやクライアントサイドでどのように処理されるかによっては、不正入力が思わぬ副作用をもたらしてしまう。当然ながら、SQLインジェクションのような問題も生じることになる。最近は、Webベースのユーザインターフェイスにおいても、Ajaxのような非同期の仕掛けを使って、裏でサーバのAPIにアクセスしているケースもある。こうしたAPIの仕様は、たとえ公開されていなくても、ページのソースコードに記述されたスクリプトから簡単に読み解くことができるから、実際は公開APIとリスクの差はあまりない。ちなみに、ソース表示を禁止しても無駄である。そんなものは簡単に破ってしまうことができるからだ。

APIの問題はかなり複雑だ。単に、クライアントからサーバに渡された情報を、サーバ側がどう処理するかだけではなく、サーバからクライアントに渡されたデータをクライアントつまり、利用者側のシステムがどのように処理し、ユーザに表示するかも大きな要素だからだ。たとえば、なんらかの手段で、サーバ側から返されるデータに加工を加えることができれば、クライアントに対して副作用を引き起こすような内容を返すこともできる。サーバから持ってきた情報をそのまま使って、ユーザに表示したり、自前のデータベースに連携させたりする際に、この副作用が発生するとちょっと困ったことになる。つまり、ユーザは事業者のサーバから帰ってきた値を無条件に信用してはならないということだ。いや、すこしトーンを下げて言うならば、「信用しないほうが身のため」である。特に、ユーザインターフェイスへの表示や、データベース処理など副作用を起こしやすい処理に使う場合は、最悪の事態を想定して、きちんとサニタイズしておいたほうがいい。事業者、利用者の双方でこうした措置を講じることで、不測の事態が発生するリスクをかなり下げることができるだろう。

APIの話を除けば、SaaSレベルのセキュリティ問題の多くは事業者側の範疇にある。しかし、どうしても利用者側が逃れられないのが、自分たちのユーザの管理、つまり、事業者から買ったアカウント内部の管理だ。企業向けサービスの多くは、一定数のアカウントをグループ化して、利用者側で自由に管理ができるようになっている。契約数の範囲であれば、自由にアカウントの作成、変更、削除ができるほか、アクセス権限などの管理も自由にできるものが多い。また、そうでなければ一定規模以上の組織では使えないのも事実だ。だが、そうした権限委譲の結果、利用者側にも重い管理責任が生じる。たとえば、あるエンドユーザのパスワード管理が甘く、アカウントをクラックされ、情報を盗まれたとしても、一般にそれは事業者側の責任にはならない。事業者は、先にのべたように、ある利用者グループの不具合が他の利用者グループに影響しないようにする責任はあっても、利用者グループ内の問題には直接手出しができないからだ。

だから、SaaSの場合でもID管理はユーザ側の大きな責任である。この考え方は自社のシステムを使う場合とまったく同じである。しかし、自社システムの場合、必要に応じて自社の管理ポリシーに応じた機能を調達できるが、SaaSの場合、提供されている機能、たとえば、認証方法の選択肢や、パスワードなどの管理ポリシー（複雑性、変更頻度など）の強制の機能が不十分な場合も多い。ただ、先にもちょっと書いたが、多くの事業者のサービスで、SAMLやOpenIDといった標準的な方法で、認証を外部のサービスに委ねることができるようになっているから、これを利用して、自社のニーズに合ったシステムを自社に入れるか、認証サービス事業者のサービスを別途買うことで、自社のポリシーにあった仕様を満足する認証手段を得ることができる。自社で既にこうした連携が可能な認証手段を持っていれば問題ないが、新たに導入するのであれば、認証サービスを利用したほうが早いかもしれない。SaaS移行によって運用コスト削減をめざすのであれば、なおさらだ。ただ、認証サービスも一種のSaaSであり、「クラウド」の一部である。特に大規模なユーザは、そのサービスが本当に自社が要求する規模の負荷に対応できるのかや、安全を担保できるかなどをきちんと見ておく必要がある。認証サービス事業者には意外と小規模な事業者も多いから、今はよくても、将来的に収容するユーザ数が増えた場合に、きちんとスケールしない可能性もあるからだ。

さて、ここまでひととおりのセキュリティ問題を見てみた。既におわかりかと思うが、基本的な要素は、クラウドでも大きくは変わらない。ある意味、すべて応用問題なのだが、一方で、単純な応用ではなく少しひねって考えなければいけない問題もいくつかある。それは、おそらくは、クラウドの特質であるスケーラビリティを確保する手段に関連している。たとえば、マルチテナントモデルの採用によて、通常よりもリスクを高く見積もるべき問題もいくつかある。だが、テクノロジーが既出のものである以上、基本問題はすべて既出なので、考え方は大きくはかわらないと思う。

こうして整理してみることで、少しは漠然とした不安を整理することができたら幸いだ。

さて、技術的な問題はここまでとして、ちょっと厄介な問題にも触れておこう。４章では、いわゆる「想定外」がもたらす困難を考えてみる。

（３章終り：続く）

さて、話をレイヤ別の技術に戻そう。ミドルウエアレイヤのサービスを提供するＰａａSにおいては、そのうえで動作するアプリケーションが、提供される環境に大きく依存する一方で、利用者側にはある程度の自由度がある。これが、マルチテナントにおけるリスクを増加させていることは、間違いないだろう。このレイヤの障害やバグ、これがＣＩＡにかかわるものであれば、いわゆるセキュリティ問題になるのだが、これらは基本的には事業者側の守備範囲である。利用者側の自由度を高めれば利便性が増し、利用者にとってのメリットは大きくなるが、逆に、使われ方を想定した対策も考えにくくなる。これはビジネスとセキュリティのバランス問題あろう。いわばイージーオーダー既製服であるＰａａＳサービスを考える上では、利用者、事業者ともに難しい部分だ。

このレイヤでは、一部制限されたネットワークアクセス、データベースやストレージ、Ｗｅｂサーバやアプリケーションサーバと開発用言語などが、すぐ利用できる形で提供される。誤って、もしくは不正に使われる可能性がある機能については、特に、それが外部や他の利用者に影響をあたえることがないように、制限を加えたり、監視機構を組み込んだりすることは必要だ。これらから得られる情報は、基本的には利用者に対して(必要であればＮＤＡ下で）開示されるべきだろう。それによって、利用者は自分たちの守備範囲への責任をはたしやすくなるからだ。

利用者側は自分たちが作るアプリケーションに責任を負う必要がある。ＰａａＳ上に構築されるアプリケーションは圧倒的にＷｅｂアプリが多いが、今後、ＸＭＬ Webサービスベースのアプリも増加してくると予想する。これは、ＰａａＳを使うであろう利用者の多くが、一般ユーザを対象としたＳａａS事業者やスケーラビリティを求める大規模ユーザであることを考えると必然だと思う。これらについてのセキュリティ問題は既出だから、当然、そうした問題を回避する方策が求められる。この部分は、もうひとつ上のレイヤで併せて見ることにしよう。

さて、最後のレイヤがＳａａSである。これはいわば既製服だ。既製服にはスーツもあれば、ジャケット、ズボン、スカートなど単品もある。SaaSで提供されるサービスも同じような形だ。目的別の服を一揃えで提供しているサービスは使うほうも簡単だ。しかし、ちょっとヒネって着たい服があるように、サービスも違うものと組み合わせて使いたい場合もある。

スーツとして提供されるのが、既製のユーザインターフェイスやポータルアプリであり、単体として提供されるのが、個々の機能についてのＡＰＩと考えてみるとなかなか暗示的だ。セキュリティもこの２面から考えてみることにする。

（続く）

事業者のセキュリティについて言えば、よく調べると案外詳細な（というか適切な）情報が公開されている。たとえば、大手ＳａａSプロバイダのホームページやオフィシャルブログなどを見てみるといい。大手のほとんどが海外事業者だから、それなりの英語力は必要だが、公開可能な部分については、きちんと公開しているという印象を受けている。

一方、ブラックボックスが怖いという、ある意味での「都市伝説」がささやかれているのだが、それは本当にそうだろうか。セキュリティ情報の公開については、様々な議論はあるが、リスクゼロがありえない以上、そのリスクを下げるために情報を非公開にするというのも正しい判断のひとつだと思う。しかし、それでは利用者が実際のところどうなのかがわからないと困るから、第三者の監査を受けたり、セキュリティ認証を受けたりして、きちんとやっていることを客観的に評価してもらうわけだ。大手プロバイダもその多くが、なんらかの認証を取得している。はたしてそれで不十分だ、と言えるのだろうか。もちろん、いざインシデントが発生した時の対応への不安はあるのだが、それは大なり小なり、すべてのアウトソーシングに共通する問題だと思う。先にも書いたように、責任の分界点設定と価格のバランスの問題としてとらえるべきだ。コストを下げるには、利用者側も応分のリスクをシェアしなくてはならない。その意味はリスクをとる、というよりは自前で対策を考えるということだ。もちろんそのコストが、アウトソースの追加コストに比べて大きいものならば、その部分を事業者に任せるという判断もあるだろう。リスクそのものが小さいならば、とりあえず無視しておく判断もある。このあたりは、事業者、利用者の双方で少し意識をかえる必要がありそうだ。

インシデントハンドリングについて言えば、ハウジング主体のデータセンタへのアウトソースと、いわゆる共用リソースを使うホスティング、そしてそれをさらに進めた仮想化サービスでは、難しさが異なる。利用者ごとの環境の分離が難しくなるにつれ、インシデントハンドリングも難しくなる。マルチテナントのサービスを展開する事業者は、リソースを共有しながら、どのようにユーザごとのインシデントハンドリングを行うべきかについて、考えておく必要があるし、そのための機構も必要ならば導入しておくべきだろう。インシデントハンドリングにおいて、対象以外のユーザのデータにもアクセスしてしまう可能性がある場合、あらかじめそれを契約などに明記しておくべきだし、ハンドリングにあたっては、秘密の保持とその方法論も明確にしておくべきだと思う。なかなか安いサービスでそこまで要求するのは難しいとすれば、ユーザ側でのアクセスログなどをどの程度とっておけるかという点も重要だ。大きなインシデントが発生した場合、契約への記載の有無にかかわらず、利用者側で発生したものではないという証拠をある程度揃えて、事業者に対応を迫ることも可能だろうと思う。サービスを使うにあたって、認証部分をそのプロバイダ独自の機能ではなく、ＳＡＭＬやＯｐｅｎＩＤといった標準的な方法で、自社の認証サーバやサードパーティの認証サービスにゆだねるのも良い方法だと思う。多くの大手プロバイダのサービスはこれができるようになっている。また、認証サービス事業者側でも、マルティファクタ認証のサポートや様々なレポーティング、監視機能などを提供できるだろう。

（続く）

ＯＳの上には当然ながら、様々なアプリケーションが載るのだが、ＯＳから見たアプリケーションとしてではなく、サービス側のプログラムから見ると、間にもう一枚レイヤが存在する。いわゆる、ミドルウエアのレイヤである。

たとえば、Ｗｅｂアプリを機能させるためには、当然ながらＷｅｂサーバが必要だが、これらは、独立したパッケージ（商用、オープンソースを問わず）を使用する。また、アプリを記述する言語やその処理系、データベースなども、アプリケーションとは独立して、その直下のレイヤを構成する。ここまでのレイヤをサービス化するとPaaSになるのだが、そのレベルは様々だ。必要最小限のカスタマイズもしくは制限を加えたＯＳ環境のレベルから、ミドルウエアのレイヤをすべて統合して、アプリケーションから使いやすいＡＰＩとして提供するものまであって、ユーザの目的によって使い分けられる。

このレイヤでも気になるのが、これらのパッケージの脆弱性問題である。とりわけ、ネットワークレイヤに直接接するインターフェイスとなるミドルウエアは、外部からの攻撃やそれに伴うマルウエアなどの侵入というリスクにさらされることになる。これらがサービスとして提供されるならば、その部分の脆弱性対策は事業者側の責任だ。また、このレイヤでは、利用者側の不注意による問題や、悪意による問題を発見、もしくは防止、軽減するための措置を講じることもできる。ある利用者の挙動が、他者に影響しないような方策を講じておくことは基本だが、個々のユーザに対して、監視機能やより安全にサービスを使える機能を提供できれば、それが事業者の付加価値となるだろう。

ユーザがデータを保存するのもこのレイヤだ。ユーザが最も気にするのが、こうした情報の漏えいや破損、逸失である。これらについては、事業者、利用者の両面で対策を考える必要がある。最もわかりやすい分け方は、事業者は自分たちのファシリティや従業者の問題によって情報漏えいや破壊が発生しない対策をきちんと講じておくことが必要だし、利用者側は、扱う情報をきちんと仕分けして、事業者を使うことによるリスクを許容できるもののみを保存する必要がある。もちろん、利用者側が補完的な対策、たとえば独自の暗号化による保護策などを必要に応じて講じることができれば、クラウドの利用範囲はより広がるだろう。また、サービスを使うにあたってのアカウントの管理はほぼ１００％がユーザ側の責任である。これは、自社システムと、まったく同じ考え方で管理する必要があるだろう。

このレイヤから上でサービスを提供する事業者の多くが、マルチテナントモデルをとっている。つまり、複数の利用者グループで一つのＯＳ環境を共有するものだ。マルチユーザＯＳにおけるアカウントのグループ権限管理を考えればわかりやすいだろう。事業者側がこの点で周囲すべきなのが、利用者グループ間のアクセス権限や利用リソースの管理強化である。ユーザアカウント（グループ）の管理は利用者側に委譲されており、基本的には利用者の責任だが、事業者は万一、利用者側の管理が不十分で問題が生じた際に、問題をその利用者内に封じ込めることができなくてはならない。

この問題は案外難しい。自社内のアクセス権限管理であれば、多少の悪意は考慮したとしても、管理を比較的ゆるやかにして、本当に重要なシステムは物理的に分離する、といったことも可能だ。しかし、マルチテナントの場合、悪意の存在はより深刻な問題になるだろうし、ユーザの質も様々なのだから、想定すべき事項やその程度は大きく異なる。たとえば、あるユーザがＣＰＵやメモリを過剰に消費しないような対策も必要になるだろう。もちろん、それでもさばける能力を提供するのがクラウドではあるのだが、利用者には応分の負担をお願いしなければならないし、それが利用者側の不注意や意図しない不具合などによる場合は、特に日本の場合はモメるもとになるからである。脆弱性管理について言えば、ネットワークから攻撃可能な脆弱性だけでなく、システム内での権限昇格など、ローカルのアクセス制御に介入できるようなものやサービス妨害的なものについてもきちんと対策が必要である。当然ながらシステムへのアクセス権を持つユーザの悪意や不注意をより強く意識しなければばらないからだ。

（続く）

さて、ここまでの話は完全に事業者側の問題だが、ここから先は、サービスの形態によって対応責任の所在がかわるので注意が必要だ。

一般に、仮想化レイヤのすぐ上には、個々のゲストＯＳつまりは論理的な意味でのホストが存在する。一般にＩａａＳ事業者のサービスでは、ここから上の管理はユーザの責任となる。ＯＳそのもののセキュリティについては、いまさら言うまでもない。それを含めてＯＳのパッケージとして提供されるアプリケーションなどに関する脆弱性対策、ＯＳアカウントやＯＳに対して論理的、物理的に割り当てられているリソースへのアクセス制御、ネットワークアクセスの制御、マルウエア対策などについてきちんと考え、必要な対策を実装していくこと。そしてその見直しを適時に行うことである。仮想化システム上のＯＳとて、問題はまったく同じだから、１台のサーバを管理するのと同じことをすればいい。仮想化環境は、一種の仮想データセンタであるともいえる。そういう意味では、個々の仮想ホストが攻撃を受け、侵入された際のリスク（たとえば踏み台攻撃）、ネットワーク的にはそれが物理的なものか論理的なものかというだけで、まったく違いはないだろうから、論理的にネットワークを分離するとか、仮想アプライアンスとしてのファイアウォールを導入するとかいう対策も考え方は同じだ。この部分の管理責任は、ＩａａＳ事業者との契約形態やユーザのシステム構成によるだろう。

もし、複数のゲストＯＳと仮想スイッチのような環境を含めて、ユーザに管理権限が委譲されているならば、ユーザの責任はより重くなる。仮想的なネットワークの管理も含めて行う必要があるからだ。しかし、これも一般のデータセンタへのアウトソーシングとは特にかわらない。問題が増えるとすれば、仮想化システムのバグ等で、たとえば設定ミス等が他のユーザにまで波及してしまうことだ。この点においては、事業者側が適切な対策を講じる必要があるし、もし、そのリスクがあまりに高いようであれば、この部分の管理権限は事業者自身が押さえてしまうことが必要だろうと思う。ユーザの自由度を下げることにはなるが、安全性やユーザ側での管理の負担は大幅に改善するだろう。

唯一増えるリスクは、ひとつ下のレイヤでの脆弱性の影響で、侵入されたホストから本来は許されない操作が可能になってしまう可能性だが、これについては前段で述べたとおりだ。事業者としては、仮想ホストの管理について、こうしたリスクを下げるために利用規約上にガイドラインを設け、必要に応じてその手段を提供することで、ユーザにゆだねた管理のレベルを最低限の水準以上に揃えるという対応も考えるべきだろう。これはユーザにとっても大きな手助けにもなる。

（続く）

一般には最下層ととらえられてしまっているのが、本来、先に書いたような分散環境の上に構築されるべき仮想化レイヤである。最初に断っておくが、私は、こうした分散環境をまったく持たない仮想化環境は、単なるサーバ統合以外のなにものでもなく、「クラウド」などとは呼べない代物だと思っている。少なくとも、複数ＤＣ間でのダイナミックな形での処理分散、多重化が行われている必要がある。もちろん、理想形は先に書いた形であるが、百歩譲っても、（地理的な意味での分散も含め）最低限の分散環境を持たないクラウドはありえない。

苦言はさておき、仮想化層で一般にリスクとされているのが、ハイパーバイザの脆弱性問題だ。既に過去において、本来完全に分離されているべき個々の仮想ホスト環境とハイパーバイザの機能が脆弱性によってアクセス可能になる、といった問題が発生している。仮想化が進めば、そうした問題を悪用するマルウエアなどが出てくる可能性もあるし、ハイパーバイザを経由してバックヤードに存在する共有リソースが狙われる可能性もある。

こういうと、危なげに聞こえるのだが、このリスクはどれだけのものなのだろうか。たしかに、個々のホストが独立している環境に比べれば新たなリスクではある。だが、一方で独立したホストでも脆弱性問題は存在するし、それを狙ったマルウエアが蔓延するリスクもある。大変なのはむしろこうしたホストの管理であり、それは仮想化環境でもそうでなくてもかわらない。ハイパーバイザの問題については、事業者がどれだけ真面目に脆弱性対策や監視を行っているか、という点に尽きそうに思う。また、たとえば、仮想化ホストの場合、事業者側でテンプレート的な仮想環境を用意しておき、ユーザに提供するｊことも可能だ。このテンプレートの中に、標準で必要最小限のセキュリティ機能を入れておくことで、仮想ホスト全体のセキュリティベースラインを揃えることもできるし、必要に応じて集中監視、制御も一つのコンソールからできる。サーバ貸しでも同じことはできるが、単純にファイルのコピーですむ仮想化システム上での作業とは違い、手間がかかるから、コストも高くなりそうだ。

あとは、仮想化環境上で、ユーザのリソース（ストレージやネットワーク、ＣＰＵ、メモリほか）をきちんと管理し、相互に影響しないように分離することだろう。つまり、あるホストに問題がおきても、他のホストに影響しないように設計されていなくてはならない。しかし、これも、なにも仮想化環境だけの話ではないし、仮想化環境ならば、論理的に構成が可能なので、より作業は容易になるだろうと私は思っている。

そういう意味ではこのレイヤの問題もほぼクリアになっているだろうと私は思う。「脆弱性対策」という意味では、いわゆるベストプラクティスを淡々とこなしていくしかないのだろう。対策とモニタリング、そして最新情報の入手と対応の見直しというマネジメントサイクルがきちんと成熟した形で実装されている事業者ならば・・・の話ではあるのだが。そういう意味では、（個人的にはあまり信用していないのだが・・・）ＩＳＯ２７００１（ＩＳＭＳ）認証などは、利用者にとってはひとつの判断材料になるだろうと思う。

（続く）

まずは、レイヤ別の整理をしてみよう。クラウドの基盤が大規模分散環境、その上の仮想化基盤であるとするならば、まずはそれらに対する脅威、脆弱性とそのインパクトについて整理してみよう。言うまでもなく、このレイヤは事業者の守備範囲だ。

まず、分散環境だが、ネットワークを使う以上は、ネットワークからの攻撃の脅威にさらされることは間違いないだろう。ただ、ＶＰＮのような形でデータセンタ間のネットワークを作るのだとすれば、盗聴や侵入などの脅威はかなり低い（あえてゼロとはいわないが）と見ていいだろう。注意すべきなのは、マネジメント系システムへのアクセス制御だ。ここに侵入されないようにしないと、リスクは重大なものになる。ネットワーク的なアクセス制限をかけた上で、複数の認証機構を用意しておくことが望まれる。また、複数のセンターに分散する環境では、各センター内の基盤システムの運用は分離したほうがいい。このレイヤの保守・運用は基本的にはセンター単位でクローズした形で行い、管理機能は拠点で集中管理するような形がリスクが最も低いだろう。さらに、各センターに置くデータは暗号化もしくは秘密分散的な形で難読化して、鍵を管理拠点のみで管理しておくことで、データ漏えいのリスクは各センターのレベルではなくなる。管理拠点（複数）以外は管理機能にアクセスできないようにしておくべきだ。また、管理上の不正行為も大きなインパクトがあるので、管理拠点が複数あるならば、相互監視を、また、単一の拠点ならば、管理と監視の職務権限分離を行っておくべきだ。もちろん、各センタのファシリティの安全管理も十分に行っておく必要があるが、先に書いたようなセンタ間の機能分離が行われていて、さらにシステムが複数拠点に分散、冗長化されている前提では、ひとつのセンターでのインシデントはサービスダウン的なもに限られるので、システム全体に与えるリスクは性能の低下くらいだ。これは、災害対策的にも有効である。

 ちなみに、こうした形態での分散環境が提供されている「クラウド」事業者は、現在のところ私が知るかぎりではＧｏｏｇｌｅのみだ。単に、検索エンジンのおまけとしてのサービスだから安い、というよりは、もともとこうしたコンセプトで設計されたシステムだからこそできていることなのかもしれない。気になるのは、セキュリティだが、このあたりはまだ想像の域を出ない。公式ブログによれば、今年（２０１０年）にはＧｏｏgle　Ａｐｐｓに対して米国政府基準である FISMA （連邦情報セキュリティ管理法）対応認定を取得するとの話だ。ちなみに、誤解している人が多くいそうなので付け加えれば、同時に表明されている米国政府向けのコミュニティクラウドとＦＩＳMＡ対応の話は別物だ。ＦＩＳＭＡは一般のエンタープライズユーザ向けのシステムもカバーする。一方、政府向けクラウドはそれに加えて、より高度な要求に対応すると公式ブログには書かれている。こうした独自システムのセキュリティを測るには、このような認証や第三者監査による情報にたよるほかない。事業者には、是非積極的な取得や情報開示を求めたい。

（続く）

さて、Web2.0以降のインターネットにおけるムーブメントは、その多くがいわば、マーケティング主導つまりビジネスサイドが作りだしたパラダイムを広めるための動きだと言える。つまり、技術的な意味では、ある程度確立されている要素をあつめて再構成し、お化粧して全体をリニューアルするというやりかただ。ＩＴにおける根本的な技術的イノベーションは、ここしばらくの間、少なくとも直接的な形で目に見えるものがない。しかし、それでは個々の技術基盤で優位に立っている巨人を打ち負かせないと考えた小人さんたちが、巨人の足元つまり、既存のパラダイムを揺さぶる動きに出ている、というのが実際だと思う。

技術的には、基礎的な技術を組み合わせた応用問題だ。ただ、ここで注意しなければいけないのは、組み合わせるための新たな技術が必要になったり、脅威の組み合わせも増えるから、これまであまり気にしなかったような問題が顕在化する可能性もある。おそらく、セキュリティ屋さんたちが抱いている不安はその部分だろう。

だが、算数と同じで、応用問題は基礎がきちんとできていれば解くことができる。そこで、その基礎、つまりクラウドを構成している要素技術について、そのセキュリティ問題をおさらいしてみよう。

クラウドは、先にも書いたようにシステムのレイヤごとに規定されており、それぞれに固有のサービスモデルがある。また、導入する側の導入モデルもその形態でいくつかに整理されている。このあたりは、米国の標準化局（ＮＩＳT)が綺麗に整理した定義を出しているので、http://www.nist.gov　のサイトで　ｃｌｏｕｄ　computing を検索すると定義のドキュメントが見つかるだろうから、一度まず、読んでみてほしい。メディア諸氏には申し訳ないが、特に日本のメディアはちょっと世の中の混乱状態に振り回されすぎているので、絶対的な信頼を置くことができなさそうだから。

まずここでは、最初に各サービスレイヤごとの要素技術と、それらについて既出のセキュリティ問題を整理してみる。それから、導入モデルごとに、重要となる問題について考えてみよう。

（続く）

クラウド上の低価格なサービスについての、最も大きな誤解だと私が考えているのが、漠然とした「安かろう悪かろう」という感覚だ。たしかに、一般論としてこの言葉は成り立つことが多いのだが、「悪かろう」の中身をちょっと考えてみたい。

たとえば、オーダーメイドの服と既製品の服を比べてみると、たしかにオーダーメイドのほうがフィットする。しかし、極端な体形の人や、お金持ちを除けば、多くの人は既製品でもそれほど大きな不満は感じないだろう。一方お値段はといえば圧倒的に既製品のほうが安い。ならば、特別な場所に行くような際に着る服を除けば既製品で十分だと多くの人が思っている。もちろん、生地の質や耐久性など、しばらく着てみないとわからない部分はあるのだが、着心地や見かけが極端に悪いとかいうのでなく、値段が十分に安ければ、「服」としての一般的な価値はそれほど下がらないと私は思う。

これはちょっと極端な例だが、少なくとも商品として「欠陥」とされるのは、服の場合は仕立てに問題があったり、見かけが（誰が見ても）おかしかったりという点に絞られそうだ。それ以外は、主観的な問題になる。

システムについて言えば、使い勝手が極端に悪くて生産性が下がる（もしくは十分に向上効果が得られない）などの問題や、安全性、安定性の確保がいいかげんでなければいいわけだ。

ＳａａＳが提供する独自のＵｉについて言えば、「使い勝手」は様々である。基本的にはＷｅｂベースで可能な限界という意味では、同種の自前システムと同様な制限はある。しかし、それはパッケージでも自社開発でも同じだ。これは日本ＩＴのカルチャーの問題かもしれないと私は思う。日本では、これまでシステムを業務に合わせてきた。たしかに、慣れた業務の流れをいじるよりは、補助的にＩＴを導入したほうが短期的には効果が大きいかもしれない。しかし、そもそもＩＴを最大限に使うためには根本的な仕事の流れの変更が必要だろう。「使い勝手」の悪さは、多くの場合、業務とシステムのミスマッチから起きるという点に注意が必要だ。

先にＳＯＡの話を書いた際に、ＢＰＲの必要性について述べたが、結局はこの問題の大部分もそこに帰結するように感じている。

さて、使い勝手の話はさておき、この章の本題に入ろう。「悪かろう」が安全性や安定性にかかわる問題であっては困る、ということだ。クラウドのサービスについて、その安さからこれらを疑問視する人たちもいる。しかし、これはきわめて感覚的な不安感だ。むしろ、専門家の間では、サービスがブラックボックス化することに危惧を感じている人たちが多いようだ。たとえば、先の感覚的な不安に対して感覚的な答えを返すとすれば、大手クラウド事業者の資金力や、安全が損なわれることによるダメージを考えれば、当然のように通常以上のセキュリティが保たれているはずだということになる。しかし、この答えもまた不安同様に感覚的だ。事業者からは契約上、ほとんど保証がない。唯一すがれるとすれば、セキュリティや内部統制関連の外部認証を取得している事実くらいだろう。もちろん、それは一定の判断基準になる。しかし、忘れてはいけないのは、外部認証の多くは、事業者自身のセキュリティに関するものであり、事業者の守備範囲の中に限られたものだということだ。もちろんそれは必要なことだが、利用者の安全はそれだけでは守られない。

たとえば、事業者がどれだけセキュリティを固めようとも、利用者側がユーザＩＤやパスワードの管理をきちんと行わなかったらどうだろう。もし、利用者側に悪意を持った人がいたらどうだろう。事業者は問題を発見したり、リスクを軽減するための仕組みは提供できるかもしれないが、直接的にこの問題には対応できない。つまり、これは事業者の守備範囲外の出来事であり、基本的に利用者側が負うべき管理責任の範疇にはいるわけだ。事業者はある利用者（企業）の問題が他に波及しないようにはできるし、そうすべきだが、その利用者内で発生する問題については、どれだけ頑張っても間接的なサポートしかできない。当然、どんなアウトソース契約にもこうした事項は利用者側の責任として書かれているし、事業者側の責任は多くの場合限定されている。

つまり、こうした問題はクラウドという言葉が世の中で広まるずっと以前から存在していたわけだ。事業者と利用者の責任分界点をどこに決めるかという問題はずっと昔から双方にとって頭痛のタネだった。どちらも責任はできれば負いたくない。だからできるだけ相手側の責任を多くしようとする。利用者側は自分側の責任をＩＤ管理のように、どうしても負わなければいけないものだけに限定したいが、事業者側にしてみれば、突発事故的なものの責任までは負いたくない。どうしても負えと言われるならば、保険をかける意味で高い料金を設定せざるをえない。この部分はこれまで日本のＩＴ業界では、あまり明確に語られてこなかった部分だ。つまり、互いにあいまいなままでフタをしてきたのではないかと私は考えている。だから、何か大きな問題が発生した際には、まず責任のなすりあいが発生する。しかし、ほとぼりがさめると、またこれらはうやむやにされてしまう。そんなことを続けてきたのではなかろうか。しかし、この不景気と、コストダウンを主目的としたクラウド導入圧力が高まると同時に、価格と責任のバランスという問題が顕在化してきたのだろうと思うのだ。本来このバランス感覚で考えなければいけない問題をうやむやにしてきた人たちほど「安かろう悪かろう」という言葉を発しがちなようだ。つまり自分たちの責任が増えることを「悪」と感じているのだろう。しかし、どう考えても値段を下げて責任だけは残すなどということは理不尽極まりない話である。

こう考えてみると、クラウドへの不安はなにもクラウド固有のものではなく、従来からあるアウトソーシングモデルに共通して存在する問題であることがわかる。それを、そろそろうやむやにできなくなってきただけのことなのだ。うやむやになってきた原因は、おそらく事業者、利用者双方にある。責任を語れるだけの知識や経験を持った人材を持たない、いや持とうとしない利用者側と、セキュリティをコストダウンの聖域と位置付けてしまって、その上にあぐらをかき、なおかつ利用者が責任をとれるだけの情報をきちんと開示してこなかった事業者側双方の問題である。そこにはＩＴ人材とりわけセキュリティの専門家が事業者、ベンダ側に偏在しているという日本固有の環境条件もあるかもしれないなと私は思う。こうした環境も含めて変化を要求される時代になってきているのだとすれば、これはもしかしたら日本のＩＴ全体にとって大きな変革のチャンスなのかもしれない。

技術的に見ても、クラウドは、これまである程度熟成されてきた技術の上になりたっている。つまり、個々の要素についてみれば、そのセキュリティについては、ほとんど解が用意されていると私は思う。もちろん、まったくイノベーションがないわけではないが、どちらかと言えば、クラウドに関する問題はほとんどが、これまでの基本問題を組み合わせた応用問題だと言えるだろう。

ちょっと視点を技術に移して、クラウドの要素技術とセキュリティの関係を考えてみよう。

（続く）

３．漠然とした霞のような不安

クラウドコンピューティングの混沌は、コンセプトや定義だけの話ではない。むしろ、クラウドを使うことへの漠然とした不安が、霞となって、余計に雲の全体像を見えにくくしているのではないかと思う。

私のようなセキュリティ屋は、かつて、新しいものに対して警鐘を鳴らし続けることが仕事だと思っていた。セキュリティを考えずに新しいものに飛びつくのは危険だと訴え続けてきた。それは今でも間違ってはいないと思う。ただ、そこに重要な視点が一つ欠落していたことに最近気がついた。ちなみに、ここで言う「セキュリティ」は、いわゆる情報セキュリティを意味する狭義の「セキュリティ」として使うことにする。

セキュリティは何のために存在するのだろうかという素朴な疑問に対する答えである。そりゃ、インシデントのリスクを下げることで、ビジネス上の損失を減らすことだろう、とそこまではまっとうなセキュリティ屋なら考える。企業におけるリスクマネジメントを考えた時、そのリスクはいくつかの種類に分類されるのだが、大きく分ければ、市場リスクや為替リスクのように、ゼロをはさんでプラス、マイナスの両方に振れる量のマイナス側を（期待に対するマイナス差分をといったほうが正確かもしれないが）をリスクと考えるものと、そもそもプラスが存在せず、マイナス側の絶対値をリスクと考える、いわゆるオペレーショナルリスクのようなものに分類できると思う。セキュリティリスクは明らかに後者の話だし、この場合、いわゆる「対策」はいかにしてリスクを減らすかということにフォーカスすべきだというのは、ある意味自明である。

一方、前者のリスクは、プラスを大きくしようと考えれば考えるほど、一般に大きくなる。いわゆる、「ハイリスク・ハイリターン」という特性を持つわけだ。目標を高くもてばリスクは増える。このバランスで考えて、ある時はリスクを多少負ってでも、利益を追求する判断もある。

こうして分類してみると、セキュリティの目的に対する先の解答は１００点の解答であるように思うのだが、ここでちょっと違う視点でリスクをみてみよう。最近ＥＲＭ（Enterprise Risk Management）の中でセキュリティをとらえようという動きがある。実際、これまでは、ビジネス市場のリスクはマーケティング部門が、為替、投資に関するリスクは企画部門や財務・経理部門が、環境リスクは総務部門が、そしてセキュリティについてはＩＴ部門や専門のセキュリティ管理部門が・・・といった形で、それぞれに特化して管理が行われてきた。しかし、リスクマネジメントプロセスは近年、かなり標準化が進んでいて、とりわけＩＳＯ規格化されているリスクマネジメントのスキームは、ほぼ同一である。これを別個に取り扱うことがほんとうにいいのだろうか。ＪＳＯＸにからんだ一連の動きは、この疑問を拡大した。「内部統制」という広い概念に基づくリスク評価と管理が要求されたため、この対応は、既存のすべてのリスクマネジメントと必然的にからむことになるからだ。こうした点を考えずに内部統制への対応をはじめた会社は、その多くが失敗や多くの無駄な努力を経験していると思う。つまり、これらは、すべて「ビジネス」を進めていく上でのリスクとして同じ土俵の上で考えられるべきものなのだ。

言うは易し、だが、その動きは徐々にはじまっている。そうした中で、これまで自分の分野に閉じていればよかった個々のリスクマネジメントは、ビジネス課題との整合性ということをより意識する必要に迫られる。ビジネスつまり市場に直結したリスクマネジメントは、これまでも市場環境の変化や経営戦略と密接に連携してきた。しかし、いわゆるオペレーショナルリスクについては、ある意味でお荷物的な、つまり、ちょっとネガティブな扱い方をされてきたように思う。マイナスを減らすわけだが、それは確定的なマイナスではない。あくまで確率的なものだ。それをどう見積もるかによって、対策にかける意気込みやお金もかわる。経営が積極的ならば、必要なリソースが提供されるが、消極的ならば、セキュリティ屋から見て、絶対やらなければいけないことにも金やリソースが出てこない。だから、セキュリティ屋はこれまで、どう経営にリスクを説明するかに腐心してきた。しかし、それが少しゆがんだ結果をもたらしてしまう。つまり、リスクを説明するのはいいとして、それに少し誇張を加えないと理解してもらえないと考え始めたわけだ。極論してしまえな、いわば経営陣を脅して自分たちの立場を引き上げ、リソースを引き出そうとするわけだ。この作戦は、最初はかなりうまくいった。（最近では「狼少年」の例にもれずになってしまった部分もあるのだが・・・）特に、個人情報がらみでは、実際にあちこちで被害が発生していることもあって、むしろ脅しは効きすぎるくらいに効いている。その結果としておきたことといえば、いい例がノートＰＣの持ち出し禁止や自宅での作業の禁止といった杓子定規なルールの制定である。また、脅しは経営層だけではなく、一般の従業員に対しても行われる。万一問題が起きた時の処遇に関するプレッシャーだ。ルール違反で事故をおこした場合の懲戒は当然としても、そのルールによって、たとえば出張中に、他の顧客のサポートができない・・・・といった不便さを強要されることになる。自分の業績を最大限上げたい営業マンにとっては深刻な事態だ。自己責任でルールを破っても、業績向上をとるのか・・・というような判断を個人のレベルで迫られることになる。これはどうかんがえてもおかしい。本来、そうした判断は組織的に行われるべきだ。しかし、それを強いているセキュリティ屋さんたちにとってみれば、自分たちの業績、つまりインシデントを減らすことが至上課題なのである。そこに現場レベルでの利害対立が生じてしまう。こうなると、最終的には「政治問題」として、戦いは空中戦にもつれこんで泥沼の戦いのなる可能性が高い。そうしなければ、現場のモティベーションが下がってしまうからだ。もちろん、「政治力」のない部署は、意欲をそがれてしまうわけだが。

ここまで言えば矛盾点は明らかだと思う。いわゆるオペリスク対策は、ビジネスに対してマイナスのインパクトを与えてしまうことも多い。しかし、「脅し」がきいた経営陣はその事実を具体的な検討もなしに容認してしまう。本来、企業において、すべての組織は「ビジネスの推進、業績の向上」が最上位の目的であるはずだ。本来、オペリスクの低減は、損失を減らすことで、結果的に業績の向上に寄与するはずのものだが、それがビジネスの足を引っ張るインパクトが必要以上に大きいと本末転倒になってしまう。あくまで、ビジネス目標とのバランスで考えなければならないのだ。これが、リスクマネジメントを統合すべき大きな理由のひとつである。

米国のコンファレンスに毎年行って感じることがある。それは、セキュリティ屋さんたちの考え方の違いだ。ベンダ側に専門家が偏在している日本とは異なり、米国ではユーザ側に多くの専門家がいる。そして、彼らのモティベーションは明らかに日本とは違う。たとえば、一昨年、あるコンファレンスで基調講演をした某有名軍需産業のＣＩＳOは、セカンドライフを導入するにあたって、その問題点をすべて洗い出し、安全に「使うための」ガイドラインを作ったという。クラウドについても、リスクを評価し、「使うための」基準を考える、それが自分たちの仕事だ、と明言した。お堅いイメージの軍需産業においても、技術競争はし烈だ。ここでいう「技術競争」は、本業となる軍事技術だけではない。ビジネスの効率をあげたり、ＩＴのコストを削減しつつ、質を向上させる技術を獲得することが、企業の命運を左右することだと彼らは考えている。だから、新しいものを先取りして検証し、それが世間で使われる頃には、ガイドラインができあがっている。そういう意味での先見性がなければできないことだ。

ある企業のＣＩＳＯは、セキュリティはビジネスの「イネーブラー」つまり、そのビジネスを安全かつ迅速に進めるための推進剤でなければならないと言いきった。無難なベストプラクティスを押しつけるのではなく、自分たちのビジネス目的に沿ったプラクティスを考え出す力がないと、少なくとも企業においてはセキュリティ屋としての責任放棄とならざるをえず、もはや失格なのだ。

これから書くことは、そういう前提で書いていることを覚えておいてほしい。

（続く）

そろそろおわかりかもしれないが、クラウドの基盤となるシステムとは、要するに「大は小を兼ねる」ようなものである。IaaS, PaaSはいわずもがな、ＳａａＳにおいても、それが汎用的なビジネスツールやシステムに必須の「汎用部品」として使えるようなものであれば、同じである。

そもそも、「パブリック」「コミュニティ」「プライベート」といった区分けで、インフラに必要な条件はまったく差異がないだろうと私は考えている。アクセスコントロールの良しあし、といった問題もあるが、それは本質ではない。なぜなら、パブリッククラウドでも、しっかりとしたアクセスコントロールの仕組みは、少なくともコンセプトとしてあるからだ。もちろんその実装レベルには差はあるのだが、しかしその違いはそう大きくはないと思う。

強いていうなら、ユーザまたはそのグループがより低いレイヤで分離されているかどうか、つまり隔壁の高さや強度が違うのかもしれないが、少なくとも「クラウド」にふさわしい、スケーラビリティと低コストを求める前提であれば、それも問題の本質ではない。

ここに、もうひとつの「まやかし」が潜んでいる。「インターネット」「共有サービス」「低価格」といったキーワードの裏に潜む漠然とした霞のような不安感を、ことさらに煽る動きがあるからだ。「セキュリティ」が問題だ、という人たちも多いが、では、この「セキュリティ」とは何だろうか。これも騒がれているわりには意外と整理されていない。クラウド否定論者を問い詰めてみると、最後には彼らの言うセキュリティは、単なる技術的な切り口のいくつかに断片化されてしまうことが多い。木を見て森を見ず、というのが私の彼らに対する意見だ。

次の章では、この「セキュリティ」について、じっくりと考察してみよう。

（２章終）

さて、ここまでは雲の階層（レイヤ）の話だったが、今度は雲の大きさ、広がりを見てみよう。言うまでもなく、もっとも広がった雲は、GoogleやAmazonに代表される、いわゆる「パブリッククラウド」である。このカテゴリのサービスは、多くのユーザが必要とする一般的な機能、サービスもしくはインフラを必要とするすべてのユーザに提供する。このレベルでのサービスには、言うまでもなく高いスケーラビリティが必要になる。なぜなら、多くのユーザ、しかも、規模も使う頻度も違うユーザ（企業）をストレスなく収容しなければならないからだ。そのためには、ある程度の規模のインフラが必要になる。もちろん、スモールスタートはあるだろうが、ユーザに意識されない形で随時、増強が可能なインフラでなければならない。こうした、幅広い企業やコンシューマを相手にするサービスは、価格の面でも要求がきつい。はっきり言って、安くなければ誰も使わないからだ。だから、ある程度の初期投資をして、規模を稼ぎ、さらにはユーザの負荷をうまく平準化してインフラを最小化することが必要になる。そういう意味で、最も敷居の高いサービスだといえるのかもしれない。大手優位の構造が最もはっきりするタイプのカテゴリだろう。

 もう少し、絞り込んで、特定の業種やビジネス上の企業集団などのレベルで考えると、共通する業務はより多くなる。たとえば、ＥＤＩや、部品の取引市場、行政サービスなどを考えてみるとわかりやすいだろう。このレベルで共通な業務をサービス化してクラウドで動かそうというのが、いわゆる「コミュニティクラウド」だ。これは、どちらかといえば、システムの標準化とインフラの共用によるコストダウンを狙うものと考えられるだろう。もちろん、対象となるコミュニティの規模や広がりによって必要とされるインフラの規模はかわる。たとえば、グローバルな取引システムなどは、時差による負荷の平準化も可能だが、日本国内のようなタイムゾーンがひとつの地域内のサービスでは、その効果は薄い。むしろ、共同システム運用的な要素が強くなる。クラウドという意味合いを強調するのであれば、たとえば、複数の会社や自治体のような機関が、それぞれ得意な部分のシステムを運用し、相互に乗り入れたり、バックアップしたりするようなモデルがいいのではないかと私は考える。クラウドというなら一か所にまとめる必要はないだろうし、それによる地理的な意味でのリスクも大きくなるからだ。たとえば、きちんとしたＩａａＳ／ＰａａＳ事業者がそういう大規模でスケーラブルな分散環境を用意してくれるのであれば、その上にまるごとのせてしまう手もあるだろう。いずれにせよ、クラウドコンピューティングというものが、ネットワーク上に分散された環境をうまく利用して効率のいいシステムを作るための技術だとすれば、そのような形で作るのでなければ、それは単なる共同計算センターにすぎなくなってしまう。ここがまた、「まやかしクラウド」の入りこむ隙間だろうと思う。

さて、では、ひとつの企業や団体、機関のレベルでの、「プライベートな」システムのクラウド化は可能なのだろうか。結論から言えば、可能だと私は思う。但し、それは、本来の意味でのクラウド基盤を提供できるＩａａS／ＰａａＳ事業者の存在なくしては困難だ。自社でこうしたスケーラブルなクラウド基盤を構築できる会社は、世界中で見てもそれほど多くはないだろう。通常の、特に自国内中心の商売をしている企業などのクラウド化は、上のレイヤで考える必要があると私は思っている。このようなクラウド化は「アウトソーシング」の一種ではあるが、これまで、一般のデータセンタ事業者に対して行われてきたものとは根本的に考え方が異なる。最も異なる点は、コストに対する考え方だ。アウトソーシング自体は、企業が本来自分たちの本業ではないＩＴリソースを保有せず、外部のリソースを利用して、こうした本業外のリソースを保有することのコストやリスクを下げようというものだ。ある程度規模のある事業者にシステムの運用管理やユーザサポートを委託することで、こうした目的はある程度達成できる。特に、人的リソースを保有しなくて済むことで、管理コストを含めた人件費とそれにかかわるリスク、たとえば、自社技術者のスキルへの依存やＩＴ技術の変化による人材の再教育、入れ替えといったリスクを軽減できることは大きい。しかし、それ以上のメリットをどれくらい享受できているのだろうか。

多くの場合、システムのソフトウエア、ハードウエアはユーザ側の資産である。従って、この部分の調達費用はユーザ側の負担だ。また、運用やサポートのアウトソースに関する費用も決してバカにならない。意外と高くつくのが、必要なＳＬＡ（サービスレベル保持契約）の締結だ。ＳＬＡを結ぶことは、事業者にとってはリスクのを負うことにほかならず、当然、保険の意味で高い料金を要求することになる。実際、それは、自社要員で運用するよりも、高くつくことが少なくない。それが認められていたのは、それでもユーザは人的なものを含めたリスクを負いたくないからだと私は思う。ただ、事業者にしてても、ユーザごとにシステムが異なる以上、そうせざるを得ないだろうと私は思う。共通化できるのはファシリティとネットワーク基盤くらいである。ここを一歩打開しようとするのが、仮想化基盤を使ったハードウエアの共有化だ。平たくいえば、個々のユーザが持っているシステム性能の余裕部分を共有化することで、この部分のコストを下げようという考え方である。注意が必要なのは、仮想化でハードウエアを共有したとしても、ＳＬＡがある以上は、個々のユーザの処理性能は保証しなければならない点だ。したがって、事業者としては、それをカバーできるだけの規模のシステムは最低限必要になる。

ここは本来、事業者側の腕の見せ所だ。たとえば、個々のユーザの利用統計をもとに、同じ仮想基盤にのせるユーザのピークが重ならないようにするとか、異なる性格のシステムをうまく混在させるとかして、負荷をできるだけ平準化し、必要なハードウエアリソースとその運用、保有コストを減らすといったことだ。このために、システムを動的に仮想環境上で管理できるような基盤も必要になる。ただ、先にも述べたように、これは一事業者の範囲ではなかなか容易ではない。しかし、ここをクリアできなければコストダウンはできず、ユーザのコストダウン要求と自社の利益とのはざまで板挟みになることになる。何度も言うが、ユーザにとってのクラウドとは、コストダウン以外の何物でもない。つまり、クラウド化は事業者に対しても劇的なコストダウン努力を求めることになるのだ。

こうした前提で、個々の企業が、事業者のインフラを安価に借り受けて自社システムを動かすことができれば、はじめてそれは「プライベートクラウド」と呼ぶことができるのだろうと私は思っている。

（続く）

さて、クラウドの代名詞といえば、SaaSつまり、Software as a Service なのだろうと私は思っている。しかし、SaaSがどのようなものか、という理解はかなりブレている。これがクラウドを最も見えにくくしている元凶なのではないだろうか。そもそも、「クラウド」なんて言葉がはやるずっと以前から類似のものは別の名前で存在していた。いわゆるASP（Application Service Provider）である。多くの人は、いまだに、この区別がついていない。SaaSをうたい文句にしている（その多くは、ついこの前まで自分たちをＡＳＰと称していた）サービス事業者の多くもしかりだ。

１章で、これまでの情報システムとそれをとりまく環境の流れを書いたのだが、それにあてはめて考えてみよう。ＡＳＰはお手軽な形で、必要な情報システムを手に入れられるという意味では、ＳａａSと同じではある。しかし、ＡＳＰは多くの場合、自分のサービスだけの世界で閉じている。つまり、それだけで最低限必要なすべてを提供するかわりに、それ以上のもの、たとえば機能やスケーラビリティを望んでも、それは事業者をのりかえるしか方法がない。しかも事業者を乗り換えれば使い勝手は大きく変わってしまい、利用者を戸惑わせることになってしまう。

さて、そこで質問だ。どのようにすれば、スケーラブルでなおかつ、適宜必要な機能を低コストで追加していける情報システムを作っていくことができるのだろうか。

この答えはすでに出ていると思う。それは、ＳａａＳをSOA化されたバックエンドサービスとして扱うことだ。SOAという視点から見たSaaSは、ユーザＩＴ部門を、縛り付けられていたパッケージから解放するものだ。特定のパッケージを使ったり、自社で開発するのだったら、ＳＯＡのありがたみはない。部品として使えるサービスが選べてはじめてＳＯＡの意味があるのだとすれば、ＳａａＳこそが、それを可能にするものだと私は思っている。つまり、逆の言い方をするなら、そういう使い方ができないＳａａＳはＳａａＳではなく、単なるＡＳＰである。もちろん、独自のＵＩは、それのみを使いたいユーザにとっては必要だ。しかし、より高度なことを考えるユーザにより一般的な機能をサービス（ＡＰＩ）として提供できることが、ＳａａＳの条件だろうと思っている。

（続く）

ＩａａＳが、インターネットにおけるＩＳＰだとすれば、ＰａａＳ（Platform as a Service）は、さながらクラウド基盤の上に構築されたレンタルサーバやホスティングサービスだろうか。いささか、この定義はＩａａSともかぶるが、大規模分散と仮想化環境の提供がIaaSだとすれば、PaaSは、その上に作られた個別のホスト環境や、そのうえで、様々なサービス構築のためのツールを提供するようなサービスだと言える。

PaaSのレベルは様々だ。有名なところで言えば、Amazonは、個々の利用者に仮想マシンつまりＯＳを載せる環境を提供できる。そのぶん、スケーラビリティはある程度制限をうけるものの、利用者の自由度は高く、様々なソフトウエアをその上で動作させることができる。一方で、Google が提供する Google Appエンジンは、Webサーバとそのうえでアプリケーションを構築するための Python による開発環境と様々な Googleが提供する機能やアプリケーションへのＡＰＩを提供している。できることは制限されるが、この環境自体がGoogleの大規模分散環境にのっかっていることから、アプリケーションを変更することなく、小規模から超大規模のサービスまで柔軟に対応できるのが特徴だ。つまり、自由度とスケーラビリティの間には逆相関の関係がある。利用者は、これをうまく使い分ける必要がある。たとえば、自社やそのグループ、その他中小規模のコミュニティレベルに独自仕様のサービスを提供するような、いわゆるプライベート、コミュニティクラウドサービスの構築は、自由度の高い環境を、一方で、コンシューマのような大量の利用者を相手にするＳａａSなどのパブリッククラウドサービスを提供するつもりなら、スケーラビリティを選ぶことで、必然的にどちらの形態を選べばよいかが決まる。もちろん、料金は定額から従量制、その組み合わせまで様々だから、これも考慮に入れてサービスを選択する必要がある。

PaaSは、そのレベルによって差異はあるものの、ユーザが自分たちの仕様で自由にアプリケーションを構築でき、なおかつ自分たちが構築したレイヤより下の運用は意識する必要がないため、運用コストの大幅な低減に役立つ。一般に、情報システムを構築、導入する際のコストインパクトは、基本的に減価償却対象である初期投資と、毎年発生する運用コストにわかれ、前者はＢ／Ｓつまり貸借対照表上の資産として、後者はＰ／Ｌ（損益計算書）上のコストとして取り扱われる。資産は複数年度で償却され、単年度予算（Ｐ／Ｌ）へのインパクトは相対的に低いのに対し、運用経費はそのまま単年度のＰ／Ｌにインパクトをあたえる。企業のＩＴ部門が運用コストをより削減しようとするのは、そういう理由からだ。特に昨今のような経済状況下で、単年度のＰ／Ｌが重視されるような時はなおさらである。これが、大手企業をしてまで、クラウド化に走らせる理由だとしたら、ある意味で、一般企業が利用するのは、基本的には、このPaaSから上のレイヤでなくてはならない。私は、このあたりの整理をあえて、あいまいにする「まやかし」が今の「自称」クラウド事業者の一部にあるのではないかと危惧している。

（続く）

ただ、寡占化がすべて悪というわけではない。IaaSというレベルで、利用者側の視点から見れば、これはクラウドそのものではなく、あくまでシステムを「クラウド化」するための基盤である。それは安価で信頼性が高いものである必要がある。１社で独占されるのは困るが、ある程度体力のある大手が競争している状況が生まれれば、これは利用する企業にとってはいい話だ。この基盤は、企業の情報システムの基盤となるだけではない。後で述べる上のレイヤのサービス事業者のサービス基盤としても利用できるからだ。サービス基盤として考えた時のIaaSも、やはり価格とスケーラビリティが最重要課題である。サービス事業者はこの基盤を賃借して、その上に「付加価値」としての独自サービスを組み立てて売ることになる。このレイヤでもサービス価格は低く抑える必要があるから、基盤の賃借料は安いにこしたことがない。その要求は個々の企業よりも切実だ。つまり、ここでも大手優位の構造が出来上がってしまう。

問題は、現在、乱立気味の中小データセンタの行く末だ。これはかなりお寒いものであると私は思う。大手に対抗できるスケーラビリティを確保し、価格を下げるためには、１社の努力だけではもう無理だ。彼らが選ぶべき道は、仮想化基盤の標準化と、同規模のデータセンタ事業者による相互補完のためのアライアンスしかないと思う。回線だけは借りなければいけないのがネックだが、細い（つまり安い）回線で効率よく通信できる技術もあるから、コストはある程度おさえられるはずだ。これを阻んでいるのが、仮想化環境の相互接続性である。１種類のハイバーバイザですべてそろえるのが最も簡単だが、理想的なことを言えば、仮想マシンとハイバーバイザ、そしてハイパーバイザ間のインターフェイスが標準化されるとより柔軟な構成が可能になるだろう。

ともあれ、これから投資をしてこのレイヤに参入、というのは現実的ではない。あくまで、既にどっぷりひたって、途方に暮れている中小事業者の今後の話である。

では、これから参入する事業者はどうすればいいのか。せっかくＩａａＳ事業者が作ってくれた安価でスケーラブルな基盤があるのだから、これを利用しない手はない。クラウドにおけるIaaS事業者は、インターネットビジネスにおけるＩＳＰと同じ存在になるだろうと思う。ＩＳＰも最初は乱立したものの、最終的に淘汰が進んだ。むしろビジネスはこうした大手ＩＳＰが作った通信網の上に花開いている。これと同じ状況がクラウドでも起きると私は思っている。

（続く）

このレイヤを「クラウド」と位置づけて、一生懸命商売をしようとしているのが、サーバメーカーとか、仮想化ハイパーバイザやOSベンダ、そしてそれにのせられたデータセンタ事業者である。ちょっと皮肉っぽい言い方をするが、これは雲の断片を売るようなものだ。先にも書いたが、クラウドの神髄はスケーラビリティにある。たった一社で提供できるようなものを「クラウド」と私は言いたくないのだ。もちろん、日本でも例外的にこれができそうな会社が２～３社はあるのだが、やがては日本でのクラウドは、この２～３社の寡占状態になりかねないなと危惧している。

クラウド基盤の提供、つまり今風に言えば、IaaS　（Infrastructure as a Service）は、たしかに事業として面白いが、ユーザがこれに何を期待するかはきちんと見ておく必要があろう。それは、少なくとも今のところはコストダウンだ。しかも、かなり劇的なコストダウンである。しかし、そうしたコストダウンできる基盤を用意しようと思えばスケールメリットを稼ぐしかない。Googleなどを見てもわかるように、そのための投資は莫大だ。その結果として低価格でも損益分岐点を超えて利益が出るだけのユーザを収容できる。日本のデータセンタ事業者は安全性を強調するが、Googleのセンターに勝てるセキュリティを確保できると契約に明記できる事業者は皆無に等しいだろう。そもそもセキュリティとはそういうものである。この話は後半でするつもりだが、クラウドのセキュリティを語る場合には、いくつかの異なる視点が必要だ。ファシリティや基盤のセキュリティはその切り口のひとつでしかないのだ。

話を基盤に戻すが、結局は、処理能力をいかに効率よく配分し、負荷を平準化できるか、ということがクラウドとして見た時の重要な点である。だから、仮想化と大規模な分散環境、そしてそれを支える高速なネットワークが必要なのである。これを今、すべて自社で保有している企業は非常に少ない。持たざるものは借りてくるか自前で作るしかない。いずれにせよ、相当な費用や投資が必要であり、なかなか安い値段では売れない。ならば、と「付加価値」を強調してみても、結局、今の経済状況下では、ユーザに見向きもされない結果となってしまう。少なくとも今は、コスト削減が至上課題だからだ。大手は、この時とばかりに、価格競争に入るだろうから、もし、近い将来、景気がよくなったとしても、その頃にはユーザの多くは大手に囲い込まれてしまっているはずだ。

さて、そうならないようにどうしなければいけないのだろうか。それは、「持たざる」事業者がその命運をかけて考えるべき事柄である。

（続く）

現在言われている仮想化技術の原型はもうずいぶん前に作られている。メインフレーム時代、ＩＢＭのＭＶＳというＯＳは、今で言うハイパーバイザとして機能し、そのうえで複数のＯＳ環境を作ることができた。ＰＣの世界ではＶＭＷＡＲＥが、ＰＣのＯＳ上で別の仮想ＯＳ環境を起動できる仕組みを、これも比較的早い時期から実用化し、私なども検証用に複数の環境が必要な時に重宝したものである。

仮想化、ということがサーバ側で本格的に言われだしたのは、ここ数年だ。追い風になった要因は様々だが、たとえば、不景気によるコストダウン圧力からＴＣＯ削減を目的に始まった、サーバ統合、これは電力消費の削減と平準化という意味ではエコでもあり、それもまた追い風になっている。ＪＳＯＸなどを皮切りに日本では、ＢＣＰの一環として、情報システムの災害対策が一気に進んだが、バックアップシステムを新たに作るにあたって、既存システムを仮想マシン化し、仮想化環境の上で動作させることが多くなっている。

こうしたニーズを受けて、仮想化プラットホームも進化していく。もともと１台のサーバリソースの有効利用だった仮想化は、複数サーバ、しかも遠隔地にあるサーバ間での仕事の受け渡しが、限定的ながらも可能になった。あと少し進化すれば、複数のデータセンタと高速な通信回線を基盤として、データセンタグリッドを作る条件が整う。これができれば、クラウドコンピューティングのスケーラビリティは格段に向上する。しかし、経済的な問題はついてまわる。１社で大規模な複数のデータセンタを配置し、高速な回線を占有できる会社は限られているから、ここでも放置すれば寡占化が進んでしまう。独立系のデータセンタ事業者は、そろそろこれに対抗する策を真剣に考えないと生き残りが難しくなってくるかもしれないと思う。Ｇｏｏｇｌｅの例を見れば明らかなように、大規模化と負荷の平準化によるハードウエアリソースの削減は低価格化を促すからだ。タイムゾーンが重なる日本でも、多くの異なる業種のユーザを共存させることで、ある程度の平準化は可能だろう。したがって、そのようなことができる一定規模以上のファシリティを用意できない事業者は価格競争に勝てない可能性が高いのである。

（続く）

なんとなくネガティブな響きがするが、決してクラウド全般が儲からない、といっているわけではない。現に、大手はかなり利益を上げる商売をしている。問題は、これのまともに太刀打ちしても儲けにならないという点だ。では、どうやって利益を享受していくのか、このあたりは今のところビジネスモデルとからんで、私の会社の企業秘密でもあるから、書くのは最後にしておくことにしよう。

ここで、世の中でクラウドと呼ばれているものを、ちょっと整理してみる。

まずは、漠としたクラウドコンピューティングの広義の意味だ。「クラウド」つまりは、ネットワークの模式図に書かれる雲のマーク。広域通信網、多くの場合はインターネットを意味する絵柄である。つまりは、インターネットを使ってコンピュータリソースを共有し、効率よく、低価格の情報処理を行おう、ということだ。

たとえば、インターネットを使ったグリッドコンピューティング、皆さんご存じの Seti@homeに代表される、大規模な計算を分割してネット上に分散して、大量のＰＣを使って高速に計算しようという、いわばクラウドスパコンなども、クラウドコンピューティングだと言えるだろう。また、悪名ばかりが広まってしまったＰ２Ｐ技術は、こうしたグリッドの基盤になる技術であると同時にデータ共有、分散処理の基盤にもなりうる。実際、最近のＰＣグリッドはＰ２Ｐ技術の基盤の上に作られているものも多い。私は、これらの技術が本来のクラウドコンピューティングの最下層の基盤だろうと思っている。今のところ、これらはまだ不完全だが、よりリアルタイムに最適化された分散処理が可能になれば、クラウドの可能性は格段に広がるはずだ。

しかし、こうして多数のコンピュータリソースを統合することが出来ても、大量のデータ解析やシミュレーションのような用途以外では、そこまで大規模な計算能力を必要としない。そこで、リソースをうまく配分して、個々の処理、またはＯＳ環境に振り分けるための処理レイヤ、つまり仮想化ハイパーバイザが必要になる。今のところ、世間ではこのレイヤがクラウドの最下層だと認識されているが、本来ならばこの下に分散リソースの管理レイヤが存在するはずだ。現在の仮想化ハイパーバイザはきわめて限定的な形で、このレイヤを一部サポートしているが、完全ではない。

ともあれ、なぜ、クラウドに仮想化が必須なのか、それは、そのうえで動く環境に意識されない形で、各種のリソースを制御し、配分する必要があるからである。

（続く）

２．混沌とした「雲」

「クラウドコンピューティング」が言われて久しいが、最初は比較的形がはっきりしていた「雲」は、どんどん広がって、いまや空一面を覆い尽くして、形も、その先にあるものもよく見えない。ベンダ側は都合よく整理をしているのだが、ユーザから見ると、それがどのように自分の役に立つのかはわかっても、それを自分たちの情報システムにどう位置づけ、どう使っていくのかという点では、まだ整理がついていないのだろうと思う。

「クラウド」＝「コスト削減」というのが、ユーザ側の入り口だ。コストを下げるのだから、多少は我慢も必要だと思っている・・・、というよりも、経営からの「劇的な」コストダウン要求の前では、そう思わざるを得ないのが実情だと思う。一方、ベンダはいわゆる「パブリッククラウド」だけでは儲からない。大手クラウドベンダのサービスを売るだけでは、ほとんど利益にならない。薄利多売の世界だ。だから、なんとか「付加価値」の名のもとに独自のサービスや仕組みを売ろうとする。しかし、ベースとなる大手クラウドサービスの値段があまりに低いので、それ以上の価格をつけると、それだけでユーザは拒否反応をおこしてしまう。クラウドブームに乗って商売を広げたいが、ユーザにとってのクラウドは「コストダウン」が第一義だから、どう考えても、これまでと同じ投資は得られないし、投資の大半は大手のクラウドサービス事業者に持っていかれてしまう。つまり、リセールモデルは成り立たない。付加価値も安く上げないと売る理由にはならない。つまり、付加価値部分もクラウドサービスとして提供せざるを得ないのだ。

しかし、大手のグローバルなサービス事業者が年間数千億の投資をしているのに比べ、少なくとも日本での事業者が投資できる額は限られている。地理的要因もある。世界を相手にするサービスには大きな利点がある。システムの稼働率を利用者のタイムゾーンに合わせて最適化できるのだ。ひとつのタイムゾーンしかない日本では、利用者のピーク時間帯は集中する傾向にある。毎朝の通勤電車のような状態が、システムにも発生するわけだ。たとば、始業時間直後や終業直前のようなピークに行われる仕事には急ぎのものも多いから、ここでシステムのレスポンスが落ちてしまってはユーザから不満が出る。だから、この負荷にある程度耐えられる規模のシステムを用意するのだが、そうするとピーク以外の時間帯はその半分以下の規模のシステムで十分なほどの負荷でシステムの大半を遊ばせるしかないのだ。これが、設備投資が過大になってしまう理由だ。ある意味、サーバメーカーの思うツボである。故に、価格もあまり下げられない。一方、世界を相手にする場合、ピーク時間帯はかなり分散され、負荷が平準化されるので、相対的なサーバ台数は少なくて済む。うまくやれば日本のピークをさばける程度の能力で世界を相手にできるだろう。そもそも、そういうハンデが、大手事業者と新参者の間にはあるのだ。つまり、張り合うのは無謀であり、新規参入する事業者は、大手を補完するようなサービスで、「コバンザメ」商法に徹するしかなくなるのである。

（続く）

ＳＯＡなんか使えない、そんな声も聞く。ある意味でそれは正しい。なぜなら、ＳＯＡ化を成功させる要素がいくつか欠落しているからだ。ＳＯＡそのものの目的と自分たちの目標とするものが一致しているのかという根本論からはじまって、（必要最小限の）ＢＰＲの欠落、機能仕訳の甘さ・・・などなど。しかし、最も大きいのは、優良なサービス、つまりサーバサイドの部品の選択肢が少ないことだ。ＳＯＡの真価はサーバサイドの汎用化、部品化によるコストと工期の削減にある。しかも、たとえばより処理性能のいいサービスと入れ替えたとしても、フロントであるユーザインターフェイスへの影響は少ないし、ユーザにとっての使い勝手は変える必要がない。しかし、サービス、つまり、サーバ側の部品の選択肢が、少数のパッケージベンダが提供する独自仕様のサービスのみであったとしたら、苦労をしてＳＯＡ化する意味も薄れてしまう。こればかりはユーザがいくら頑張っても、解決は難しい。

ＳＯＡに至るシステムアーキテクチャの流れは、小さな湖でせき止められてしまうかに見えた。しかし、やがて、この流れも、あふれて大きな海に流れ込む。インターネットという大海にだ。そこで、他の水と混ざり合い、新たな命をはぐくむことになる。

こうして、インターネットという海は、すべてのＩＴの流れを受け止めて、大海となり、水はまた空に戻って雲となる。この雲の中には、すべての川の流れによって持ち込まれた水が混在している。いや、存在していなければならないのだと私は思う。次の章では、雲の成分について、少し詳しく考えてみよう。

（１章終り）