2010年1月アーカイブ

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

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

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

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

（続く）

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

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

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

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

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

（続く）

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

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

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

（続く）

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

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

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

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

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

（続く）

この美しい景色を見るために、ここまで長い時間を旅してきた。漆黒の空に浮かぶ、光り輝く星の渦。星の雲という呼び名は、いにしえの船乗りが見上げた夜空に見た光る雲のようなものが由来だ。それを、自分は今、目の当たりにしている。

アンドロメダ大星雲、メシエカタログの３１番目。Ｍ３１という番号でも知られているこの星雲。光の速さでも３００万年かかる距離を超えて、ここまで来ることができるなどとは、ほんの数年前ならだれも考えなかっただろう。子供のころに読んだＳＦによく登場するワープ航法、しかし、そもそも空間をひんまげるなどという発想そのものが、今は珍妙に思えてならない。

反対の空には、故郷の銀河が染みのように浮かんでいる。これは、自分が生まれる６００万年以上前の姿なのだ。なぜ６００万年なのか、光は３００万年でここまで到達する。つまり、私の時間で、私が生きている間にここまで来られたということは、その時間はほとんど誤差に等しいから、およそ３００万年前でなければいけないはずだと思うだろう。要するに、その差が、つまり私がここにいられる理由なのだ。

３００万光年という空間的な距離をほぼ瞬時に越えてきた私。しかし、その旅は同時に３００万年という時間を遡る旅でもあったのだ。相対論的同時航法、数年前に見出されたこの理論は、一種のタイムトラベルでもある。アインシュタインは光の速度を越えられない限界と定義し、光で見えるもの以外に「同時性」を定義することはできないと述べた。つまり、ある意味では、今、光で見えているものが自分と同時に存在していると言ってもいいわけだ。簡単に述べれば、新しい理論は空間的には、このアインシュタインの理論と矛盾しない。しかし、そこに時間をさかのぼるという塩味を加えてある。自分の固有時間的には、ほぼ瞬間移動しているのだが、同時に、３００万年をさかのぼり、自分が地球を飛び立つときに見たアンドロメダ星雲そのものに到達したのだ。もし、アンドロメダ近くの、私の船を見られる望遠鏡が地球にあったとすれば、今頃は私の船が見えているはずだ。

物理学者は、長年、時間というものを特別扱いしてきた。それは、すべての尺度を決める基本である。相対論ですら、固有時間をとなえながらも、特定の座標系における空間と時間を区別している。近年の物理学では、時間を含めた４次元の外に余剰次元を導入して各種の場の理論を統一する試みが行われてきたが、時間の特別扱いはより鮮明になる。４次元ではなく３＋１次元というような表現を物理学者が使い始めたからだ。もちろん＋１次元は時間の次元である。

この発想をひっくり返した素人物理学者がいる。素人だからできたことなのかもしれないが、時間も他の次元と同等に扱って理論を再構築したのだ。これによって、空間を移動するように時間も移動できるようになった、というよりは、他者の時間を自分の固有時間下では空間移動に変換できるのだ。つまり、実空間と時間を同時に自由に移動できることになる。但し、この変換は一方通行だ。つまり過去に遡る方向にしか移動できない。また、光で見えている以前に戻ることもできない。自分の固有座標系で、ほぼ光速に近い早さで移動ができれば、少なくともどんな空間的な距離でも自分の固有時間において瞬時に越えることができる。もちろん、時間も同じだけ遡る。計算式上は、移動距離は速度ベクトルの方向に対してマイナスというおかしな値になるが、これは、時間の流れが逆になっている影響にほかならない。見方を変えれば、もともと自分が、３００万年前のアンドロメダから地球に移動したとして、その時間を巻き戻していると言ってもいいのだろう。

であれば、これはタイムマシンパラドックスを引き起こすのだろうか。つまり過去に戻った自分が自分の過去に影響を与えてしまい、未来が変わるのだろうか。いや、その心配はない。光速は依然として越えられない壁であり、今ここにいる私が、地球に影響を与えられるのは少なくとも３００万年後になる。つまり、私が地球を飛び立った後になってしまうわけだ。

では同じやりかたで、ここからさらに地球の過去に戻ったらどうなるのか。それは時間の枝分かれを引き起こすだろう。そもそも今の理論では、タイムマシンパラドックスは成立しない。たとえ、私が６００万年前の地球に戻って、今の自分の生い立ちに影響をあたえることがあったとしても、自分が地球の過去に戻った瞬間に時間が枝分かれするから、自分自身の固有時間における過去とは別の時間の流れに乗ってしまうことになる。

では、今の自分はもう元の世界には戻れなくなってしまうのだろうか。いや、必ずしもそうではない。ここまで来たのと同じ方法で地球の過去に戻り、時間を枝分かれさせるというような馬鹿な真似さえしなければ、いやもっと厳密にいえば、相対論的同時航法で少しでも地球に近づくような動きさえしなければ、ちゃんと元の世界に戻る方法がある。それは単純な光速航行を使うことで実現できる。相対論では、光速に近い速度では、固有時間の流れは遅くなる。自分自身にとっては瞬時だが、実際には３００万年かけて、アンドロメダから地球に戻れば、時間は自分が地球を旅立った少し後になる。つまり因果律的には一切矛盾がない。なんと美しい理論だろうか。そして、それを考え出した自分が、今ここにいるのだ。

目的は果たした。さて、あとは元の地球に戻るだけだ。私はもういちど、美しいアンドロメダ銀河の姿を目に焼き付けると、操縦席に座り、出発のコマンドをたたいた。グリーンの表示が点滅し、カウントダウンがはじまる。まばたきするほどの時間で地球に帰れるはずだ。

カウントゼロ、その瞬間に、目の前の星が一気に流れた。そして、次の瞬間、美しい青い星が眼前に現れる。完璧だ。さて、地上では祝宴の準備をしているだろう、大気圏突入前に、アンドロメダの美しい画像でも送ってやろう。

私は、種子島の基地を呼び出した。ミッションルームの全員が今頃は抱き合って喜んでいるだろう。そう思って、スクリーンの前に立ったのだが・・・・、なぜか応答がない。故障だろうか・・・。操縦席に戻った私は、自己診断プログラム起動のコマンドを打ち込んだ。この船のコンピュータは言葉こそ喋らないが、一種のＡＩである。問題があれば瞬時に発見して解決策を講じてくれるだろう。ほら・・・。

・・・・。スクリーンを見た私は、目を疑った。「異常なし」そして、その表示の下には、チェック完了時刻が表示されている。私は愕然として、計器パネルをみつめた。その一角にはＲＣＤという文字が点滅している。

私は大きなため息をつき、目を閉じた。美しいアンドロメダ姫に心を奪われた私は、とりかえしがつかないミスをおかしてしまったようだ。ＲＣＤつまりは、相対論的同時航法を解除し忘れていたのだ。既に私の時間は枝分かれし、違う未来を持ってしまったのだ。これからアンドロメダまでは戻れるが、そこから地球にまた戻っても、同じ現在が待っているとは限らない。むしろ、大きく変わってしまっている可能性が高いのだ。もしかしたら、地球そのものが存在しない可能性もある。

しかたないな。こうなったら、とことんやってみるか。戻れないのだったら行ける所まで行くだけだ。宇宙の果て、時間の果て、つまりビッグバンの時間まで戻って、それで私の人生も終わりにしよう。それは、世界そのものを完全に違うものにしてしまう行為だが。でも、自分が知っている人達や地球に迷惑はかからない。なぜなら、宇宙はその始まりの時点で枝分かれしてしまうからだ。

既に、気持ちは決まっていた。大きく深呼吸した私は、コマンドをたたいた。そしてカウントダウンがはじまり・・・。

目の前が急に光であふれたような気がした。

「光あれ・・・そして新たな世界を・・・・」

昨日は、毎年誕生月恒例の日帰り人間ドックの日。不摂生な性格なので、年に１回くらいはきちんとチェックしてもらわなきゃ・・・。というわけで朝から某クリニックに缶詰。まぁ、結果はと言えば、正月の後遺症その他でＬＤＬコレステロール値がかなり上がったくらいが問題点。薬を飲んでるのにこの値はねぇ・・・と医者にあきれ顔された。このところまたしても、ちょっと甘いものにハマってしまっているのも原因か。血糖値指標（ＨｂＡ１ｃ）も少し高め。ちょっと食欲を抑えないとヤバいかも。

とまぁ、そんなこんなんで、終わってからおなかがゴロゴロなので、そのまま会社を休んで家で休養。昼寝してたらいつのまにか日が暮れて・・・。

夜空には月と木星がなかよく並んでる。

なんだか、夜空がウインクしてるみたいで、なんとなくいい感じな宵。でも寒い・・・・。

それから、ここ２，３週間ハマっている家のネット改造計画の最終段階、新防火壁の設定作業をすこし。新製品（Juniper SRX100）なので、ちょっとてこずってる。会社の後輩のサポートで、ようやくプロバイダにつながるようにはなったものの、内部のルーティングなどの設定のせいか、内部から通信できても、DMZからは通信できなかったり、DMZがOKになったら今度は内部から通信できなくなったりと試行錯誤の繰り返しで４，５時間潰して、結局タイムアウト。おかげで、このサーバも長時間ダクン・・・。元の防火壁（NetScreen 5GT）に戻して昨夜は終了。今日、もう一度、製品担当の後輩に聞いてみよう。

一夜明けて、今朝もいい天気。さて、頑張って仕事にいきますか。

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

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

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

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

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

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

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

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

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

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

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

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

（続く）

とにかく、あれこれてこずりましたが、このサーバをちょいとリニューアルしました。テストをかねてこの顛末を・・・。

サーバをリニューアルするにあたって、もろもろ考えて、仮想化環境にのせることにして、まず、メインマシンをクアッドコア化した際に余ったマザボCore2Duo 3GHz とメモリ4GBなどなどで、仮想化環境を作るところから・・・。１２月に組み立てたはいいけど、電源が頻繁に落ちるトラブルで、結局年越し、マザボや電源を交換したりして、結局原因がＣＰＵヒートシンクの取り付け不良による過熱と判明。

さて、ハイパーバイザを入れようとしたら、オンボードＮＩＣがサポートされておらず、インストールができない。ドライバを入れる方法を模索したのだけど、結局、サポートされているインテルのＮＩＣを買ってきて、ようやくハイパーバイザをインストールできたのが、先週末。

そこからFreeBSD8.0ベースでサーバを再構築しはじめたのだけど、このMovable Typeを入れるのに必要なPerlのモジュール集めと、最後に　ＩｍａｇｅＭａｇｉｃｋパッケージのコンパイルエラーで四苦八苦。無理やりソースコードをいじってエラーを取り、なんとか立ち上がった次第であります。

はぁ、疲れた。

今回、サーバ仮想化にあわせて、宅内ネットワークのＶＬＡＮ化を実施。サーバとスイッチはトランク接続（802.1Q tag VLAN）したので、ネットワークとサーバの構成をあれこれいじって遊べるようになった。あとは、防火壁を新品に交換する作業が残っているのだけど、設定に意外と手間取っていて、まだ古いものを使用中。交換すればスループットが１０倍以上に上がるので、光回線の帯域をフルに使えるようになるのだけどね。某Ｊ社製品、最近ファームが統合されたんで、コマンドラインがすっかり変わってしまっていて、一から勉強し直し。コンフィグのシンタックスエラーふが取れずに悪戦苦闘中。ＧＵＩの出来があまりよくないのが不満。結局ＣＬＩに頼らなきゃいけないなんてね。そういう意味では前のＮ社系ファームのほうがよかったな。

なんとか今週末には入れ替えよう。そしたら今度はｖ６に挑戦だ。

酔狂だわなぁ・・・・しかし。

おっと、画像が・・・。そういや画像ディレクトリをコピーし忘れてるし・・・。こりゃ今夜中に終わるかな・・・　（＾＾；）

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

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

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

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

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

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

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

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

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

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

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

（続く）

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

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

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

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

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

（２章終）

正月を実家で過ごし、今日、自宅に初帰宅。今日の午後から明日いっぱいのフライトは満席。とれたのは、けさ１０：２５発の羽田便。ちょっと早いけれど、お昼すぎには自宅に戻ってきた。

今朝の小松は曇り。幸いにも雪はなく、強風は続いているものの、飛行機に遅れはなし。先の便の乗客でセキュリティが混雑してたので、とりあえず展望デッキで時間をつぶした。

ちょっと見慣れない飛行機・・・と思って見てみたら、静岡－小松間を就航しているフジ・ドリームエアラインの機体。乗客はどのくらいいるのだろうか・・・・。

時間をつぶしていたら、ＪＡＬ機（東京便）が離陸し、続いてＡＮＡの福岡行きがプッシュバック開始。

ところが、普通ならば、誘導路に平行になるまでプッシュバックするのに、途中で停止。なにやら、係りがあたふたと走り回っている。

そのうち、牽引車が外され、エンジンがかかった・・・・のだけど。

なぜかゲートまで戻ってきてしまった。

故障かなにかだろうか、めずらしい光景を見た。結局、この飛行機は、私が乗った飛行機の直前に離陸して行った。なにかのマイナートラブルだったようだ。

そして、こちらも無事に離陸。一面の雪雲のせいで、巡航高度に上がるまでの間は結構揺れたけど、あっという間に雪雲を越えて太平洋側へ。気がつけば、御前崎から駿河湾上空へ抜けるところ。

で、やがて伊豆諸島も眼下に・・・。

羽田へのアプローチは、やはり強風の影響でかなり揺れて、機内には子供の泣き叫ぶ声が・・・。とりあえず無事、快晴の羽田に着陸。荷物も３番目に出てきて、混雑にもかかわらず、あっさりと自宅まで帰ってくることができた。

さて、明日一日休んだら、また忙しい日常が戻ってくる。とりあえず今日はのんびり、ちょっと算数本を読んでいたら眠くなった(＾＾；)ので、昼寝していたらまたしても熟睡。気がついたらもうこんな景色が。

皆さん、今年もよろしくお願いします。

そういえば、行方不明になったディスカバリー号を探しに、「ソ連」の宇宙船で木星に・・・・・というのは今年という設定だったな。ＨＡＬの復活、ボーマンの幽霊・・・・。結局、人間の宇宙旅行はまだ月どまり。宇宙ステーションだって、いわば宇宙のプレハブくらいのものしかないし、コンピュータは当時想像できなかったくらいに高速、大容量になってネットも発達したけど、鉄腕アトムもＨＡＬも鉄人２８号（違？）もまだいない。ソ連はもうとっくの昔に崩壊してるし、世界の破滅は１９９９年から２０１２年に予言を変更。未来予測がいかに難しいかを物語っているのかもしれない。

そんな２０１０年だけど、これもひとつの区切り。でも、２１世紀は確実に進んでいる。東京の景色はこの１０年に大きく変わった。超高層ビルがあちこちに林立しはじめて、新しい電波塔であるスカイツリーもその頭角を現しつつある。５０インチの大画面テレビが普通に自宅の居間にある姿も、子供のころに描いた未来の一部だろうけど、実際、今はそれが普通になってる。でも、こうして田舎に帰ってみると、周囲はあまりかわっていない。イノベーションの恩恵はどうやら都会に集中してしまっているようである。

この１０年、いやこれからの１０年も、２０世紀と２１世紀がせめぎあって、混在し、だんだん２１世紀が勝っていく過程をみることになるのだろうと思う。できるなら、都会だけではなく、地方もその恩恵を受けられるようになってほしいものだ。不要な土木工事ではなく、もっと生活に密着したところで、ハイテクを使った生活を支えるシステムを、地方でこそ実現すべきではないかと思う。それが、暮らしにくい都会に人が集中することを防ぎ、少子化など現代の問題を解決する道なのではないかと思う。

ネットワークがこれだけ発達した社会。クラウドコンピューティングが発達すれば、その基盤システムは、土地の高い都会にある必要はない。広大な土地が信じられない値段で手に入る田舎にこそ、こうした施設は作られるべきだ。「雲をつかむ話」でも最後に書くつもりだが、真のクラウドコンピューティングが実現すれば、こうしたことがたやすくなる。システムは高度に分散、多重化された基盤の上で動くから、障害対応のためにデータセンタに走る必要はなくなる。なぜならば、システムの運用と仮想化された基盤の運用が分離できるからセンターが田舎にあっても何も問題はなくなるからだ。センターの要員はハードウエアとそのセンターに閉じたインフラのメンテナンスができればいい。システム全体は集中制御で、数か所の拠点センターが受け持つという形だ。これができれば、クラウド基盤の提供コストも大きく下げられるだろうと思う。

クラウドだけではない。たとえば、大きな敷地が必要な太陽光発電所などを、土地が安い田舎につくることもできる。たとえば、太平洋側、日本海側の季節による天候の変化、東西の日照時間の違いなどをうまく使って電力を融通するようなこともできるかもしれない。冬場は天気が悪い日本海側は風力発電などと組み合わせると面白いかもしれない。今の送電システムでは限界があるのだが、米国のスマートグリッドをずっと大きくしたような全国レベルのグリッドができれば、面白いことができるんじゃないだろうかなどと妄想してみる。

さて、今年はこの「雲」にどっぷりと浸る仕事をしなくちゃいけない。年明け早々、課題も多いのだけど、この休みのあいだにエネルギーをためて、ロケットスタートをかけたいものだと思う。本当の意味でのクラウドコンピューティングとは何かを追求し続けたいなと。セキュリティのほうは、クラウドを取り組む中でいっぱい考えなきゃいけないことがありそう。ただ、考える前提はクラウドを「使えるものにする」という前提。セキュリティは新しいテクノロジーやビジネスの「イネーブラー」、推進剤として機能しないと、単なるセキュリティ屋の自己満足、我田引水や責任回避におわってしまうから。

プライベートでは、これまでの趣味に加えて、ちょっと学生時代に挫折した勉強をやりなおしてみようかなと思う。まずは、算数のお勉強のしなおしかな。本当は古典力学、電磁気学、相対論や量子力学あたりから、現在のブレーン理論までざっと見直してみたいのだけど、そのための算数をちょっと勉強しなおさないと、算数がネックなのが挫折の原因だったので。ま、ゆくゆくは老後の楽しみで大発見でも目指そうかと。

家は昨年９月に思い切った大掃除をしてから、その状態を保っているので、今年はその維持と、もう少し、モノを整理して使い勝手をよくすることが目標。それから宅内ネットとサーバの仮想化。年明け早々に新しいＦ／Ｗが来るので、ネットワークをＶＬＡN化して・・・・なんて、やりたいことが多過ぎ？

まぁ、とにかく、今年も、周囲からあきれられるほどの「元気おやぢ」でありたいと思う元旦であります。