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であり、「クラウド」の一部である。特に大規模なユーザは、そのサービスが本当に自社が要求する規模の負荷に対応できるのかや、安全を担保できるかなどをきちんと見ておく必要がある。認証サービス事業者には意外と小規模な事業者も多いから、今はよくても、将来的に収容するユーザ数が増えた場合に、きちんとスケールしない可能性もあるからだ。
さて、ここまでひととおりのセキュリティ問題を見てみた。既におわかりかと思うが、基本的な要素は、クラウドでも大きくは変わらない。ある意味、すべて応用問題なのだが、一方で、単純な応用ではなく少しひねって考えなければいけない問題もいくつかある。それは、おそらくは、クラウドの特質であるスケーラビリティを確保する手段に関連している。たとえば、マルチテナントモデルの採用によて、通常よりもリスクを高く見積もるべき問題もいくつかある。だが、テクノロジーが既出のものである以上、基本問題はすべて既出なので、考え方は大きくはかわらないと思う。
こうして整理してみることで、少しは漠然とした不安を整理することができたら幸いだ。
さて、技術的な問題はここまでとして、ちょっと厄介な問題にも触れておこう。４章では、いわゆる「想定外」がもたらす困難を考えてみる。
（３章終り：続く）
コメントする