クラウドの最近の記事

昨夜は午前2時に再度就寝、どうにか7時前に起床。今朝もこんな感じの朝の景色。

今朝も8時からキーノート開始。最初のセッションはこんな話。

最初の方は、自社と自分の宣伝ばかりでちょっと退屈したのだが、要は、クラウドに限らず、セキュリティ屋は常に経営視点で考えろということが言いたかったようだ。米国のコンファレンスのキーノートでこの話は、いまさら感が強いのだが、イノベーションのスピードがどんどん上がる中、新しい物をいちはやく取り込んでいくことがビジネスの成功に繋がるのだとすれば、それを前提にしつつ、リスクをどうそのメリットと引き合うくらいまで押さえ込むかという思考パターンがセキュリティ屋には必須になる。要は、これまで以上にそれが重要になってきたということなのだろう。質問で、経営者とのコミュニケーションの極意はあるのかと聞かれて、とにかくまず話を聞いて、聞いて、聞いて、相手が話し飽きてから要点を押さえた質問をしろ・・・と答えていたのは印象的だ。どこの国でもお偉方の扱いは同じらしい。

二つ目の話は、いわゆるAPTからクラウドインフラをどう守るかという話。企業や政府のシステムがクラウド事業者に集積するとなれば、そこが主要なターゲットになることは自明である。インターネットはすでに重要インフラとして位置づけられているわけだが、その上でサービスのネットワークを提供するクラウドもまた重要インフラのひとつとなりつつある。

（本来の）クラウドの特性を考えれば、標的となるデータやシステムはその地理的な、もしくはネット上のアドレスとしてのロケーションを特定しにくい。これは攻撃者にとっての難易度を上げる。そういう意味では表玄関からの攻撃は難しくなるだろう。なので、攻撃者は、事業者の管理システムに狙いを定めることになる。管理システムにアクセスできれば、物理的なロケーションは関係なくなるからである。たとえば、勝手に仮想マシンのスナップショットを取得して取り出すことも可能だ。とりわけ、裏で国家が関与しているような攻撃では、従業員へのソーシャルエンジニアリングあたりから始まって、社内の管理システムに侵入するための様々な攻撃が実行されることになるだろう。これまで仮想化システム、いわゆるハイパーバイザの脆弱性などが取りざたされてきたが、これらを攻撃するよりも、管理システムを狙った方が技術的な敷居は低いし、攻撃者にとってのリスクも少ない。ネットから隔離されたシステムに忍び込む方法は、既に有名になったいくつかのマルウエアで実証済みである。100％隔絶されたシステムと異なり、クラウド事業者の管理ネットワークはシステムを通じて間接的にネットと繋がっている。一旦入り込んでしまえば、そこから外に出る方法は比較的簡単に見つけられるだろう。これらを考えると、管理システムとその関係部署はクラウド事業者が最もセキュリティに力を入れるべき場所のひとつとなる。たとえ、それが他のネットワークと切り離されていたとしても、侵入する切り口は少なくないからである。従って、クラウド事業者のセキュリティ認証などにおける重点監査項目としても位置づけられるべきだろうと思うのだ。

そのあとのブレークアウトセッションでは、開発系の話をちょっと聞いた。CSAとSAFECodeという団体が共同で出したクラウド開発ガイドの紹介セッション。ソフトウエア開発のセキュリティという意味では、他の開発と基本は同じだ。しかし、マルチテナント環境や、様々なリソースを共用するクラウド環境において特に注意すべきことも多い。

そういう意味では、クラウドやモバイルアプリケーションの開発者は一読しておくのがいいだろう。

さて、今日のお昼は自前のランチなので、ちょっと近場のデニーズまで出かけてみた。最近、ネットワーキングランチをなくしたり減らしたり、有償にしたりするコンファレンスが増えてきている。ちょっと寂しい感じもするが、毎日同じような（しかも、それほど美味しくない）料理を喰わされることを思うと、このほうがマシな気もする。

昼飯はサラダで軽く済ませた・・・のだが、このあと展示会場でデザートと飲み物が出たので、ケーキをつまんでしまったから、カロリー的にはあまり軽くなくなってしまった。

午後のセッションでは、Open Data Center Alliance (ODCA)という団体の取り組みを聞いた。ステアリングメンバーとして日本の某超大手SI（＠江東区）が入っている。先行している会社が独走してどんどん新しい仕組みを作り込んでいくクラウドの世界だが、結果、ユーザはこうした先行企業にロックインされてしまう。事業者間でユーザが簡単にシステムを移行できたり、異なる事業者やオンプレミスにシステムを分散、バックアップしたりということを容易にするためには、事業者間の互換性が不可欠だ。そういう視点では面白い取り組みなのだが、先行企業のスピードが速すぎて、いまひとつうまくいっていない感じがする。クラウドのスピード感についていけていない感じだ。面白いなと思ったのは、ユーザに対してクラウド事業者へのRFPを作成するツールを配り、共通の仕様を要求させようという試みだ。いくつか大手のユーザ企業もメンバーに加わっているのだが、まだまだこれも道半ば、といった印象である。

次に聞いたのが、いわゆるクラウドインテグレーション（CI）の話である。自分たちの業務に最適のSaaSとオンプレミスのシステムを組み合わせて、いわゆるハイブリッドクラウドなシステムを構築するというのは、もともとクラウドの大きなコンセプトの一つである。しかし、多様なAPIやサービス事業者の柔軟性の問題等、様々あってなかなか技術的には難しい。実際に構築した事例を聞けるのは面白い。社内のIDMやデータベースとESBを介してクラウドサービスを接続し、SAMLのSSOで認証統合して利用するパターンの実際の実装モデルを見たのはこれが初めてである。

ちなみに、米国ではユーザのSaaS利用率がかなり高い。IaaSに偏っている日本とは大きく違う点だ。そもそもクラウドの発想はSaaS, PaaSなどの上のレイヤから生まれてきたのだが、日本はベンダ主導でそれがねじ曲げられてしまっているように思う。もう一つは、日本企業が使えるまともなSaaSが、SalesForceくらいしかないこともある。国内事業者がIaaS偏重になってしまっているので、有力な国内SaaSが生まれないからだろう。そういう意味で日本のユーザ企業は損をしていると思う。

さて、二日間のコングレスも大詰め、最後のクロージングキーノートセッション。でも、目玉のスピーカーの到着が遅れて、順番入れ替え。先にあったのが、最近CSAが始めた、Software Defined Perimeter　（SDP)の話である。Jim Reavisとこのプロジェクトを進めているBob Floresの対話形式でのセッション。SDPは、これまでのようにファイアウォールのような物理的な（固定された）境界防御ではなく、ソフトウエア的に制御された動的な境界で攻撃から防御しようという、チャレンジングな取り組みである。たとえば、NACのような仕組みをインターネット上のクラウドにまで広げようというような話だ。まだまだコンセプトの段階で、技術的な課題は多いのだが、面白そうなプロジェクトである。現在、ボランタリーな参加者を募っているところなので、興味がある人は参加してみるといいだろう。

最後を締めたのが、元NASAのセキュリティ責任者だった、Chris Kempである。飛行機が遅れたため、ぎりぎりの到着となった。（Jimがロケットで飛んでこないのか・・・と冗談を言う一幕も・・・）

NASAのような、日々、Nation Sponsoredな相手からの攻撃に曝されている組織でのセキュリティ対策の実際の話をあれこれとしてくれた。対策の項目そのものは基本的だが、相当な緻密さを要求されるという印象である。NASAのシステムはその性質上、プライベートながら巨大なクラウドの塊である。こうしたクラウドと従来型システムの性質の違いを示してくれたのが下のスライドだ。

最後の結論がちょっと興味深い。電子証明書（公開鍵）認証を使うなら、Root CAは自前で立てて管理しろという。PKI屋が聞いたら髪の毛を逆立てそうだが、考えて見れば内部のシステムの認証に民間CAの証明書は不要だ。おまけに、CAそのものが攻撃される事例も少なくない。そういう意味では、こうした重要なシステムの認証にPKIフレームワークを使う場合は、自前Rootはありだと思う。

他にもクラウドを意識した話がいくつか書かれている。実際に、これらを実行するにはそれなりのリソースが必要であることは間違いないが、重要インフラや国家的な研究機関のようなところでは、それが必要なのだろうと思う。それは、今後、重要なインフラに位置づけられていくであろう、クラウド事業者も同じだ。

さて、そんな感じでイベントは終了。三々五々・・・となる。

今日は結構疲れた。例によって部屋に帰って寝てしまい、10時過ぎに起きて目が冴えてしまっているのだが、まぁ、もう時差ぼけを気にする必要も無いので、体が要求するままに行動しておこう。

明日は一日フリーなので、またシーワールドに行ってみるつもりだ。

今日から、CSA Congress 2013のメインセッション。朝の8時からキーノートというのは、アメリカらしい。日本だとなかなかこうはいかないわけで。勤勉と言われている日本人だが、仕事のメリハリや時間の活用という意味では、アメリカ人には大きく水をあけられている感じがする。経済停滞とともに、そろそろこれも都市伝説のたぐいになりつつあるのはちょっと寂しい。

最初に、Jim Reavisから開会の挨拶。これも毎年の光景。

そのあと、キーノートはアマゾンから。自分たちはこれだけセキュアなんだぞという宣伝ではあるが、結構説得力がある。

確かに、どんな大企業でも、政府機関でも、クラウド化することで、セキュリティ強化かつコストの低減につながるシステムは少なからずあると思う。それが証拠に、こうした組織で、手薄な部分が狙われたインシデントが頻発しているわけで・・・・。実際、大企業と言えどもすべてに潤沢な予算があるわけではない。集中と洗濯、もとい選択を繰り返すごとに、何かが抜け落ちていくのも事実。自前で管理するコストを割けないなら、いっそセキュリティがきちんとしたところにアウトソースしてしまうのも手である。一方、クラウド事業者は、もっとセキュリティを意識してユーザにアピールすべきだ。クラウドのスケールメリットはその主たるサービスだけではない。当然セキュリティについてもスケールメリットを出せるはず。ならば、個別にシステムを作って対策するよりも安価にセキュリティも提供できるはずだ。少なくともクラウドの世界で「安かろう悪かろう」はあってはいけないと思っている。単なるアウトソーシングではなく、「クラウド」を標榜するなら、セキュリティやサービス品質とコストダウンを両立させなくてはいけない。そういう意味では、アマゾンは一歩リードしているように思えるのである。サービスのレイヤは違うが、こちらの会社も同じような路線だ。

引き続くプレナリーセッションで登場したのがマイクロソフト。Office365は、日本国内でも有力企業が採用し始めているなど、ある程度信頼感醸成に成功しているようにみえる。そういう意味で、一部の大手を除いた日本の事業者は、いまだに「安かろう悪かろう」路線から脱却できていないように思えるのだ。最終的には、それが自分のクビを絞めることになってしまうのだが・・・。

その後聞いたクラウドのインシデント対応に関するセッションは、ちょっと期待外れ。スピーカーの女性は話はうまいのだが、中身がいまいち。（米国で時々あるパターンで・・）ケーススタディーと称して、実際は漠然とした内容に終始していたのは、残念。

その後のランチはちょっと時間が短くて、食べた後休む間もなく午後のセッションへ。午後一は、クラウドの標準化関連。CSAも多くのSDOに入り込んでいるのだが、まずは、ISO関連。数年前、クラウドを語る際に必ず引き合いに出された、NISTのモデルだが、どうやらもう賞味期限切れになってしまっているらしい。こうした用語やリファレンスアーキテクチャはISO/IEC17788/89で定義され、こんな感じになっている。

NISTモデルはある意味でシンプルかつわかりやすかったのだが、なにやらこちらは複雑怪奇な感じだ。それもそのはず、ITU-Tなど他のところでやっていた、いくつかのワークをまとめた結果こうなったわけで・・・。このスピーカーは、NISTモデルを語る奴には、耳元で、「あんたは3年遅れている」とささやけと言っていたのだけど、さて、どちらが良いのかは微妙な感じがする。

ともあれ、CSAはこうしたSDOに様々な形で関わって、影響を与えている。目下の目玉は、STAR認証。つまり、これまで、事業者の自己チェックリスト公開による透明性確保の手段だったSTARを、さらに進めて、第三者認証化しようというもの。既に、欧州主導でBSIとの連携で動き始めている。日本国内でも、BSIジャパンが早々とアナウンスしているのだが、正直言うともう少し時間はかかりそうな感じだ。目下、日本で一番の課題となっているのが、ISO/IEC270xxシリーズとの整合性の部分である。とりわけ、27017は某官庁肝いりで日本が旗振りをしている手前、国内ではこれと矛盾した規格は流行らない。セッションの後でスピーカーと少しこの話をしてみたら、彼の答えは明確だった。CSAはそれ自体で標準や規格を作るつもりはない。むしろ、CSAのナレッジをSDOに供給して国際規格をより洗練させることが重要であり、そのような流れの中で、現在多少の食い違いがある部分も、互いに影響し合って整合していくということなのだそうだ。そういう意味では、日本国内でも、様々なすりあわせが必要になってくるだろうと思う。

午後二番目のセッションは、例のNSA騒ぎの話。セッションタイトルがいきなり変わっていたので、これはどこかの圧力？とか思ったのだが、オブラートにつつみつつ、結構面白い話をたくさんしてくれた。まぁ、こういう話はNSAやクラウド事業者に限った話では無いということ。どこの国でも起きうるし、どんな事業者や会社でも、そこに目的があれば起きうる話だと言うことである。なので、基本は自己防衛。本当に見られて困る情報なら、どこに置くにしても自分で保護措置を講じておけ、ということである。たとえば、信頼できる暗号アルゴリズムと実装を使って暗号化し、鍵は自前できちんと管理しておくといった基本的なことだ。たとえば、ストレージサービスと暗号化サービスで違う事業者を使うだけでも、リスクはかなり下がる。（データと鍵のロケーションを分離できるからだ）要は、そのコストと情報の価値が折り合うなら、やり方は様々あるということである。

さて、夕方、軽いレセプションの後、部屋に戻ったら、こんな光景が。ちなみに、このホテルの部屋の電話はCISCOのIP電話である。なにやら、エラーが出ている。実は昨日もこのエラーが出ていた。XMLのパースエラーのようだが・・・ちょっと怪しい感じがしてしまうのは職業病だろうか。

そんな感じで今日も暮れた。

このあと、実はちょっと横になったら午後10時頃まで寝てしまった。しまった・・・と思ったのだがもう遅い。しかたがないので、ちょっとラウンジに降りたら、CSAのボードメンバーやスピーカーたちが何人か飲んでいたので合流して軽く飲んで来た。しかし、この時間（午前1時をまわっている）でもまだ目が冴えてしまっている。今日はどうにか寝ずにすんだのだが、明日は危なそうだ。なんとか頑張って寝るとしよう。

昨夜からの雨が残って、今朝はちょっと天気が悪かった。とりあえず、ホテルの前の交差点を渡ってしまえば、あとは会場まで屋根が続いているので、傘はなくてもなんとかなる。

今日も一日、Cloud Asia / CSA APAC Congressの会場詰め。朝のキーノートはスパコンねた。Exa Flopsクラスの開発競争が始まっているというお話とか。シンガポールの研究機関の人のプレゼン。そういえば、日本も「京」の後継開発の話が出ていた。クラウドやグリッドコンピューティングがスパコンを凌ぐ、という話もあるのだが、これは通信遅延などの問題で難しいから、用途によっての棲み分けが進むだろうという話には納得する。

その後、CSA の Dannieleが、OCFの話をした。これが、そのロードマップ。

ロンドンの時と同様に威勢はいい。アジアでは、一部、先行した取り組みも始まっているのだが、CSA側の意気込みに比べると、ヨーロッパ同様にちょっと様子見気分が強いようにも見える。ただ、どんどん枠組み作りが進んでいるのは確かなようで、これとISO27017などとの折り合いをどのようにつけていくのかといったあたりが、普及の肝になっていくのだろう。CSAはそうした標準化団体にも入り込んでいるので、そのような中で、CCMと国際標準の折り合いをつけていくことになるだろう。これは、各標準化団体などとCSAとの関係図。

CSA APACのディレクターでもあり、トレンドマイクロのKen Lowのプレゼン。このスライドは、いまさらの話だがインパクトがある。ウイルス対策をやっていても、９０％の組織が内部に活動しているマルウエアを飼っている・・・という話。ありがちとは思うものの、アンチウイルスベンダからこの話が出てくるというのがちょっと怖い。たとえば、日本の重要インフラ企業の中にも感染PCがあっても不思議では無いということだから、たぶん、我々はもっと真剣にそれを見つけ出す努力をしないといけないのだろう。それが本格的に活動を始めた時点では、もう被害を止めようがないのだから。

一日の終わりに、Cloud AsiaとCSAのプレナリーセッションがあるのだけど、今日はクラウドの導入に向けた課題についてのパネル。

Jim Reavisは言わずもがな、どちらかと言えばイケイケ推進派のパネリストたちに対して、モデレータが鋭い突っ込みを入れて、なかなか面白いパネルになった。会場からの質問も含めて見ると、セキュリティもさることながら、ITガバナンスの面での危惧も多いような感じだ。このあたりは、使う側から見れば世界共通なのだろう。とりわけ、政府の関与が強いアジアやヨーロッパでは、どうしても、そちらの顔色をうかがいながら・・という雰囲気も見える。

そんな感じでイベントは終了。とりあえず、今夜日本に帰る人たちをまじえて晩飯を食って、しめくくる。

とりあえず、これで情報収集モードは終了。残る２日はシンガポールを少し歩いてみるつもりだ。

さて、CSA JCの課題も多いな・・・というのが実感。APACの動きが速い（日本から見ると少々暴走気味にも見える）ので、あまりのんびりしてはいられないだろう。さっさと方向性を決めないと、置いていかれそうな感じだ。このあたりは帰ってからの議論。

とりあえず、そのあたりは帰ってから考えよう。

今日も天気はおおむね良好。昨夜も就寝が遅かったので、今朝は７時前に起床。今週はちょっと生活時間が狂い気味。とりあえず、散歩は裏山、公園から高台の前半部のみ。

道沿いも、秋の雰囲気が漂っている。さすがに今朝は短パン半袖は寒かったので、ズボンと長袖シャツで散歩。それでも、汗はそれほどかかない。

とりあえず、公園までのアップダウンを一気に歩いて、少し汗をかき、この高台でちょっと風に当たって景色を眺める。

猫たちはもういないかなと思ったらこいつ一匹だけが残っていた。

雲はあるものの、かなり高い雲。これも秋の雲だろう。

今日は、CSAジャパンと某監査法人の共催セミナーで、お昼前に都内へ。ついでに、綱島に寄ってうちのメインバンクから車の購入代金をディーラーに送金。ATMだとこの金額は送金できないので、一旦、銀行窓口で制限を解除してもらってから送金する。その方が、窓口で送金依頼するより手数料が安く上がるらしい。静脈認証を登録してあれば、そこいらのＡＴＭから送金できるのだけど、カード交換が必要なのが 面倒なので普通のＩＣカードしか持っていないから、いずれにせよ窓口には行かないといけない。これで、購入手続きは終了。来週末の納車を待つだけだ。

セミナーは、パネルの司会役。思った以上に客席からの質問カードが集まってしまい、どうしようかと考えながらやっていたら、終了時間を間違えて、２０分ほど早く終わらせるところだった。まぁ、延びるよりはマシだが、とりあえずもう一度、質問回答コーナー再開で、とりあえず時間まで。主催が主催なので、集まった人たちは、そちら系な人たち（内部監査とか・・・）が多く、あまりテクニカルな話はできない雰囲気。トップのかけ声でクラウドに取り組む会社が多い中で、もういちどクラウドとは何か、なぜクラウドなのかを問い直すきっかけにはなったんじゃないかなと思う。

ちなみに、CSAのガイダンス翻訳をしていると、これを書いた人たちは、パブリッククラウドの利用を中心に考えて、低価格であまり融通がきかないサービスに対して、どうしたら、利用者、事業者双方の負担にならないようにガバナンスをきかせるか、という視点で書いているのがよくわかる。一方で、日本を見ると、「プライベートクラウド」全盛。しかし、プライベートクラウドという言葉の使い方も少々ブレているばかりか、結局、クラウドといえる規模でプライベートクラウドを展開出来る会社は限られているような気がする。コスト対効果を重視するのならば、クラウドも使い分けや組み合わせを利用者側がきちんと考えていく必要があるだろうと思う。多くの場合、クラウド化したのはいいけれど、あまりコスト削減にはならなかった・・・というような、「お高いクラウド」になってしまうんじゃないだろうか、と危惧するわけで。まだまだ、考えるべきことは多い。

このところ飲み会続きだったので、懇親会はパスして帰ってきた。今夜は早寝して、ちょっと生活時間を戻そう。

昨夜は結構飲んだせいか、今朝は7時半まで寝てしまい、ちょっとぎりぎりの起床。今朝は、目覚ましセッション（ベンダセッション）があって、Googleのセッションを聞いてみた。まぁ、例によって自慢話に終始していたのだけど、それなりに潤沢なリソースをつぎ込んで、セキュリティを固めているのはわかる。セキュリティチームが250人体制というのは、その十分の一でいいからうちに、いや日本にくれ、といいたくなったのだが。（苦笑）で、それからキーノート。

今朝のキーノートはZSCALERのCEO。なんとなく宣伝っぽい感じの講演だったのだが、モバイルも含めて、ネットとの接続点は会社が制御できないほどに増えてしまっているのは事実。会社の社員数だけインターネットとのゲートウエイが（事実上）存在しているというのは、あながち誇張でもないかもしれない。まぁ、だからセキュリティもクラウドで・・・・というあたりから完全に我田引水になっていたのは残念だが、まぁ、ひとつの切り口ではあるだろう。

昨日も含めて、あまり技術的に突っ込んだようなセッションは少なく、どちらかといえばマネジメント系のほうが多い感じ。今日はパネルセッションを中心に聞いたのだけど、クラウド事業者を選択する際、米国ではセキュリティやガバナンス関連の開示の多さがひとつの基準になるようだ。事業者のセキュリティやシステムの運用状況をユーザ側（の管理者）が常に把握できるようなしくみがほしいというのは、わかる気がする。結局、なにかあれば選んだ利用者側が責任の多くを負わなければならないのだから。そういう意味では、日本のクラウド事業者はかなり寒いなと思う。先日のJNSAの日韓シンポでの発表にもあったのだが、日本の事業者のこうした開示は、米国の事業者に比べて極端に少ないのが実際だからだ。昨日の話なども含めて、やはり日本のクラウドはガラパゴス化しつつあるのではないか、という不安が大きくなった。そもそも運用コストを減らしたいのに、あれこれ根掘り葉掘り聞いたり調べたりしないと、管理状況がわからないようでは、ユーザにとっては本末転倒。事業者側から積極的に開示する姿勢が必要なのだろう。別の意味で、日本に入っている米国系はどうだろう。日本の因習をたてに、米国では開示される情報を出し渋るようなことをしていないだろうか、というのもチェックが必要だ。外資系の日本法人には曲者も多いので。

朝方は雲が多い感じだったのだけど、昼ごろには晴れ間が広がって、外の気温が結構上がっていたのだけど、中は冷房がきいて寒いくらい。上着がないとちょっと辛い。午後のセッションで面白かったのはこれ。

ユーザ V.S ベンダの戦い？。中身は、アウトソースに際しての基本的な考え方についてのもの。参加者にユーザサイドの人が多かったので、あれこれ活発な議論になった。RFPでセキュリティの要件をきちんと提示するのは基本で、その回答提案の吟味の仕方とか。たとえば、RFPの文章をコピペして、それに全部 'Yes' で回答してくるようなベンダは危ないとか。そんなベンダは、プレゼンさせて、あれこれ質問してボロを出させるのだとか。あとは、実績ベースで、それが可能であることを説明できないベンダはダメとか・・・・。一方で、RFPを出す側も、ベストプラクティスにたよるのではなく、正味のところで自分たちが必要な要求を書かないとダメとか。日本人にとっては耳が痛い話ばかりだが、一方で、米国でもベンダというのはそういうものなんだなと、ある意味納得。でも、こういう場所に出てくるユーザはたぶん、ずいぶんしっかりしたユーザなんだろうね。

それからクロージングキーノート。クラウドに関する7つの禁句というような感じのプレゼン。クラウドでよく出てくるキーワードをあげて、それに関する間違いを考えるというような内容。最後のほうのスライドに意外な絵が・・・・・。

どーも君ってこんな凶暴なキャラだったっけ？

2日間のコングレスもこれでおしまい。CSAの人たちとちょっとお話して挨拶をし、ホテルに戻った。いい感じの夕暮れ時。

ふと見たらホテルのロビーにこんなものが出来ていた。そろそろクリスマスモードかな。子供たちがまわりに集まっていて、大人はカメラをかまえているという感じでファミリーモードな感じだ。

それから日本組の人たちで食事して、今回の予定はすべて終了。あとは帰るだけだ。ちょっと酔い覚ましに庭を散歩。遠くで花火の音がしている。

さて、明日は8時半のフライトだが、ホテルでのMagic Kingdom Expressのピックアップは5時半。早起きしないといけない。たぶん4時半おき。まぁ、あとは寝て帰るだけなので。とりあえず、寝過ごさないようにしなくては。ということで、おやすみなさい。

さて、今日からCSAコングレス。会場のDisney Yacht ClubはEPCOTエリアの中にあるリゾートホテル。こんな感じで、おとぎの国っぽい。

朝のキーノート会場。CSA代表のJimの姿もみえる。

今朝のキーノートは、最近のサイバー攻撃関連の話とクラウドの関係とか・・・・。即時利用、即時解約、リソースの即時追加や削除などAgilityやElasticity のないサービスはプライベートといえどもクラウドとはいえないね、という日本の「なんちゃってクラウド」プロバイダには耳の痛い話とか、APTは標的型メール攻撃のことを言うんじゃないよ、とか、やっぱり世界の常識はこっちだよね、というのを再確認。

午前のセッションでは、クラウドのインシデント対応の話とか。でも、事業者との責任切りわけとか、とにかくモニタしろ的な聞き飽きた話でちょっとがっかり。

お昼は、各地の支部の代表メンバーが集まってのランチ。自己紹介とかしながら、各地の状況報告など。

午後からは、ビッグデータのセキュリティ関連の話とか、セキュリティとビジネスのバランスの話とか・・・、前者はなかなか面白かったのだけど、後者はなにやら教科書どおりのことを述べただけにとどまって、不満が残る講演。言うように行ったら苦労はしない。一度やってみなさい、といいたい内容。でも、面白かったのは、「とりあえずNoという」セキュリティ屋のマネだけはしないように、というくだり。やっぱ、どこの国にもいるのだね、こういう人種が。

昼休みとか、休憩時間にちょっと外を歩いてみる。こんな感じで花が多い周辺。

会場は結構にぎわっている。国際色も豊か。欧米系も多いが、アジアも日本、韓国、中国あたりからそれなりに参加している。

ちょっと時差ぼけと格闘しながら、早くも夕方。

夜は展示会場でレセプション。ここでビールをちょっと人だ後で、日本組み何人かで晩飯に。ヒルトンホテルにある日本食屋さん。

ホテルに帰ってからバーでちょっと一杯引っ掛けたのだけど、たのんだカクテルになにやら光る氷状の物体。3色のLEDが入った角氷風のプラスチック。これはなかなか面白い。

さて、明日も一日こんな感じの予定。

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から上のレイヤでなくてはならない。私は、このあたりの整理をあえて、あいまいにする「まやかし」が今の「自称」クラウド事業者の一部にあるのではないかと危惧している。

（続く）