読み物の最近の記事

今朝も気温4℃とちょっと寒い朝。天気は快晴。そしていつもどおりの散歩。

そういえば、道沿いにこんな白い早咲きの桜。遠目に白梅だと思っていたのだが。よく見たら桜のようだ。

なんとなく昨日よりも空が澄んでいる感じがする。

今日の日中は気温も上がって、春らしさが戻ってきた。

いつもの河津桜にもそろそろ葉が見え始めている。

春景色とはうらはらに、今日も杉花粉は飛びまくっているようで、少し外出するとすぐに目が痒くなるのが困りものだが。

公園のチューリップもいつのまにか結構のびてきた。

こういう景色もうつろいやすいもの。時とともにどんどん変わっていくが、壊れるわけではない。今日は、この前のRSAキーノートで紹介されていた本を少し読んでみた。Black SwanのNassim Nicholas Talebが書いた、 Antifragileという本。fragileとは、飛行機に乗るときに壊れ物を預けるとつけられるタグに書かれている単語。文字通り「壊れ（やすい）物」という意味。Antiが付くので「壊れにくい」と逆の意味に（近く）なるのだが、それは「堅固=robust」とか「回復力=resilience」といった表現とは異なる。著者いわく、むしろこの２つが表す物は、fragileのほうだという。確かに堅い物は壊れやすい。多少回復力があっても、それを越える力が加わってしまうと壊れて戻らなくなってしまう。Black Swanという言葉は想定外の災害（的な事象）を意味する。これは天災のみならず、たとえば恐慌のようなものや、誰も想定できなかった破壊的な事態を総称していて、想定内の事象に耐えられるように作られたすべてを打ち砕く物という意味合いだ。これによって回復不可能なダメージを受けてしまうものをfragile、一旦は壊れたかに見えて、それによって新たな形や意味を獲得するようなものをAntifragileというわけだ。人工物の多くが前者であるのに対し、自然は後者である。物事を整理すればするほど、純粋にすればするほど、理論立てれば立てるほど、fragileになっていくと著者は言う。まだ、プロローグを読んだだけだが、なかなか目からウロコの感がある。最後まで読み込んでみたい一冊だ。久々に英語の本を真面目に読もうかと思った。

そんな感じで今日も夕暮れ。昨日失敗したパンスターズ彗星探しに再挑戦。しかし、今日もとうとう目視できず、最後にとりあえず少し長めの露光で撮った数枚だが、後で見たら2枚だけに写っていた。先のポストで書いているが、原画はこんな感じ。

右手の中央ちょっと上にうっすらと見えている。300mmズームでこれくらいなので、目視はなかなか難しいだろう。もう少し高度が上がると目視出来るようになるかもしれないが、当初期待されていたほどの光度にはまだなっていないようだ。切り出して背景光を落とす処理をするとこんな感じになる。

もう少し観測条件がよくなったら、今度は望遠鏡を使って撮影してみよう。

読書でも・・・というのが普通だが、私はあまり文学物を読もうという気にならない。おそらくは、小学校4年くらいまでの間に、少年少女文学全集全50巻を読破し、たぶん、古典的な文学作品を読み尽くしたことで、燃え尽きてしまったのだろうと思う。以来、科学物、SF物しか読まなくなってしまった。なので、逆に秋の夜長に、自分で書いてみるというのも一興かもしれないと、思いつくままに・・・・。

冗談めかして書いてしまったけれど、見通しがつかない原発事故。本当にゴジラがいるなら、コスモクリーナーがあったなら・・・などと考えてしまう。現状、関係者は最大限の努力をしているだろうし、我々はそれを見守るしかない。日本だけでなく、人類にとってのひとつの試練だろうと思う。関係者の奮闘と、なによりも幸運と安全を祈りたい。

コスモクリーナー

NASAによれば、NASAは通信の解読に成功した。JAXAの関係者によれば、内容は驚くべきもので、発信者は大マゼラン星雲の中のサンザー星系第８惑星イスカンダルのスターシャという宇宙生命体とのこと。地球よりもはるかに進んだ科学力を持つイスカンダル星はなんらかの方法で日本の危機を察知し、援助の手をさしのべようとしているとのこと。イスカンダルのスターシャはコスモクリーナーという放射能除去装置の提供を申し出ているが、イスカンダル星にはそれを地球まで運ぶ宇宙船がないとのこと。宇宙船の設計図を送ることは出来るが、建造には時間がかかる上、現在の地球の技術水準では完成できない可能性もあるため、緊急援助をイスカンダルとは双子の惑星であるガミラス星のデスラー総統に依頼したという。デスラー総統は快諾し、最新鋭の艦隊を急遽、地球に差し向ける予定である。ただ、スターシャによれば、ガミラス星は死に瀕しており、デスラーはどさくさにまぎれて地球を侵略する可能性があるため注意が必要とのことだ。現在の地球の科学水準ではとうてい太刀打ちができないため、スターシャは万一に備えて、コスモクリーナーにデスラーの攻撃能力を奪う仕組みを付加し、万一の場合はその起動方法を教えるとのことである。

NASAおよびJAXA関係者によると、本日日本時間午前２時過ぎにNASAが受信した宇宙からの謎の通信は、大マゼラン星雲の方向から届いていることがわかった。また、この信号は特殊な歪みを有しており、ゆがんだ時空を通ってきた可能性が高いという。通信の内容は解析中だが、送られてきたデータの冒頭には辞書と思われるデータが添付されており、NASAはこれを使って翻訳を試みているという。

政府筋によれば、米国政府からNASAが宇宙からの謎の通信を傍受し、それが日本の今の状況に関連があるのではないかという情報を得たという。JAXAの専門家が現在、NASAと共同で解析にあたっている。

政府筋によれば海自艦が発見した巨大生物は形状から見てゴジラである可能性が高いとのこと。専門家に寄れば、ゴジラは放射能を好むため、福島第一原発の沖合に引き寄せられた可能性があるという。しかし、別の専門家によると、ゴジラは非常に知能が高く、現在の日本の状況を理解しており、おそらく海上に姿を見せることはないだろうとのこと。人々に恐怖を与えることなく、海中の放射能を吸収しているようだ。生みの親の日本への恩返しなのではないかと政府筋は見ている。

本日午前０時過ぎに、福島県沖で海自イージス艦がソナーで検知した海中の巨大な物体は、専門家によれば巨大生物の可能性があるという。政府は引き続き情報収集を急いでいる。

防衛省筋および内閣危機管理センター関係者によれば、本日午前０時過ぎ、災害支援中の海自イージス艦が、福島県沖で正体不明の巨大な海中物体を検知したという。詳細は不明。政府は事実確認を急いでいる。

最近、脳波で機器をコントロールする技術がどんどん進んでいる。既に、簡単な操作ならば少しの練習でできてしまう機器が出回りはじめた。これは障害を持つ人にとって大きな助けになるだけではなく、健常者のためのコンピュータユーザインターフェイスとしても有望視されるものだと思う。

人間の脳の不思議なところは、訓練でどんどん新たな動きを学習できることだ。たとえば、運動に関連する脳波を拾い上げることはできるが、実際にそのパターンが何を意味するかは、最初は機械も脳もわからない。これは推測だが、おそらくある脳波を特定の動きに置き換えて視覚化することで、それが脳にフィードバックされ、脳の中で関連づけが行われるという学習過程の積み重ねなのだろう。

ただ、少し危惧もある。本来、別の意味を持つ脳波にそれとは異なる意味づけを持たせてしまったらどうなるのだろうか。それが心理的な問題に結びついたりはしないだろうか。GUIでは、マウスの動きが仮想的な運動として認識されるような学習が行われるのだが、これは実際にマウスを動かすという手の運動と結びついている。しかし、こうした実際の運動と結びつかないような脳波パターンをコンピュータの動作とひもつけてしまったら何が起きるのだろうか。実は、数年前、ネットでそんな話を読んだことがある。当時は眉唾と片付けてしまっていたのだが、今から考えると、もしかしたら・・・と思う内容だった。

ある技術者が、脳波に意味づけを持たせて、それを記号化してネットで通信するという研究を始めた。最初は、ランダムに選んだフラクタル図形と複数部位の脳波のフーリエ変換を対応させて、それを視覚にフィードバックさせることを繰り返したのだそうだ。もちろん、被験者本人の意識には単にランダムな図形が表示されているとしか感じられない。これを数週間繰り返してから、一定時間表示された図形を記録しておき、時間をおいてから被験者に見せるという実験を行ったそうだ。そうするとその瞬間に脳波パターンがその図形が記録された時と同じになり、被験者には、その時考えていたことがデジャブのようによみがえったというのだ。

この技術者は、さらに実験を次の段階に進めた。今度は、ある人の脳波を基準に作ったパターンを他の人に共有させる試みだ。最初は単純な色、基本図形、単純な言葉などからはじめ、段階的に、より複雑な風景や文章、音楽、さらには抽象的な概念に進んでいく学習過程を数ヶ月間行ったところ、不思議なことに、脳波をパターン化した図形で、単純なコミュニケーションができるようになった。つまり、このパターンを思考を代弁する一種の抽象言語として脳が学習してしまったのだ。言葉に比べると正確さには欠けるが、感情や感覚、印象などはかなり正確に伝わる。受信者にそれを言葉にしてもらい、送信者に返す試みも行ったが、おおむね送信者の考えと一致した内容になっていた。不思議なことに、違う国の、言葉が違う人たちでも、この方法ならば、言葉を超えたコミュニケーションができたのだ。ちょうどこれは一種のテレパシーのようなものである。これはすばらしいコミュニケーション手段になるはずだった。しかし、事故は突然に起こった。被験者の一人が突然、意識を失ったのだ。互いに相手の脳波パターンを見ながらコミュニケーションが可能かどうか、という実験の最中だった。記録によれば、その直前の数十秒に異常な脳波の起伏が繰り返し現れていた。どうやら、互いに相手の脳波パターンに影響を受け、それがループを構成して、一種のハウリングが発生したらしい・・・。その後、様々な治療が試みられたが、その被験者の意識はとうとう戻らなかった。身体的には何も異常がないのに、意識だけがない状態、いわば植物状態に陥ってしまったのだ。

問題はそれだけでは終わらなかった。今度は、その相手方の被験者に奇妙な現象が発生したのだ。突然、聞いたこともないような言葉をしゃべり出したり、まったく違う人格が出現するという、いわゆる多重人格の症状が現れたのである。しかも、その人格、言葉は意識を失った被験者のものに近かった。もしかしたら・・・・、実験の最中に一方の人格が他方へ移動してしまったのだろうか・・・。まさかそんなことはないだろうと誰もが考えた。そして、危険な副作用が出るから、という理由で実験は中止された。

しかし、話はそれで終わらなかった。この実験を行っていた技術者自身が、その後、意識不明に陥ってしまったのだ。身内の話だと、実験の失敗を苦にして、数ヶ月、実験室にこもって原因を調べていたらしい。ある日、心配した家族が部屋を覗くと、彼は倒れていた。あわてて病院へ運んだのだが、結局、現在にいたるまで意識は戻っていないとのことだ。事件性を疑って警察が捜査したところ、彼のコンピュータから、一種のウイルスコードが発見された。このコードは、現在の分類で言えば、いわゆるボットに相当するものだ。ソースコードが残っていたので、それが彼自身の手によるものであることがわかる。そして、そのボットは、フラクタル図形が構成するパターンを媒介するように作られていた。さらに、rootkit技術を使い、ウイルス対策ソフトでも検知が難しいように作られている。彼はいったいこれを何のために使ったのだろうか。警察は多くの専門家に解析を依頼したが、結局、結論は出なかった。ただ、このボットがすでにネットに放たれており、世界中の数十万台以上のPCに感染している可能性があることはわかった。さらに、このボットは自己変異を繰り返しており、一旦駆除しても、そのうちまた変異型に感染するというきわめて駆除が難しいものだ。おそらくは、自己変異で新しいOSにもどんどん対応していくので、ネットがある限り、どこかで生き残っていくのだろう。おまけに、P2Pベースで通信を行うため、サーバレスのボットネットを構成することができる。さて、彼はどうしてこのボットを作り、ネットに放ったのだろうか。それは、誰にもわからない。

ただ・・・・、身内や知人たちに、その後不思議なことが時々起こっているそうだ。意識を失った彼からのメールが届くのだ。僕は元気にしているから心配しないでくれと。いつも近くで見守っているから・・・と。

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

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

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

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

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

（続く）

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

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

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

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

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

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

（続く）

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

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

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

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

（続く）

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

 

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

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

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

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

（続く）

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

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

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

（続く）

 

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

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

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

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

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

 

（続く）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（続く）

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

 

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

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

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

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

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

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

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

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

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

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

（続く）