【雲をつかむ話】クラウドコンピューティングの実際: 2010年2月アーカイブ

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になるのだが、そのレベルは様々だ。必要最小限のカスタマイズもしくは制限を加えたＯＳ環境のレベルから、ミドルウエアのレイヤをすべて統合して、アプリケーションから使いやすいＡＰＩとして提供するものまであって、ユーザの目的によって使い分けられる。

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

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

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

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

（続く）