情報セキュリティ: 2010年1月アーカイブ

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

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

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

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

（続く）

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

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

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

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

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

（続く）

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

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

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

（続く）

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

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

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

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

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

（続く）

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

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

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

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

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

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

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

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

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

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

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

（続く）