事業者のセキュリティについて言えば、よく調べると案外詳細な（というか適切な）情報が公開されている。たとえば、大手ＳａａSプロバイダのホームページやオフィシャルブログなどを見てみるといい。大手のほとんどが海外事業者だから、それなりの英語力は必要だが、公開可能な部分については、きちんと公開しているという印象を受けている。
一方、ブラックボックスが怖いという、ある意味での「都市伝説」がささやかれているのだが、それは本当にそうだろうか。セキュリティ情報の公開については、様々な議論はあるが、リスクゼロがありえない以上、そのリスクを下げるために情報を非公開にするというのも正しい判断のひとつだと思う。しかし、それでは利用者が実際のところどうなのかがわからないと困るから、第三者の監査を受けたり、セキュリティ認証を受けたりして、きちんとやっていることを客観的に評価してもらうわけだ。大手プロバイダもその多くが、なんらかの認証を取得している。はたしてそれで不十分だ、と言えるのだろうか。もちろん、いざインシデントが発生した時の対応への不安はあるのだが、それは大なり小なり、すべてのアウトソーシングに共通する問題だと思う。先にも書いたように、責任の分界点設定と価格のバランスの問題としてとらえるべきだ。コストを下げるには、利用者側も応分のリスクをシェアしなくてはならない。その意味はリスクをとる、というよりは自前で対策を考えるということだ。もちろんそのコストが、アウトソースの追加コストに比べて大きいものならば、その部分を事業者に任せるという判断もあるだろう。リスクそのものが小さいならば、とりあえず無視しておく判断もある。このあたりは、事業者、利用者の双方で少し意識をかえる必要がありそうだ。
インシデントハンドリングについて言えば、ハウジング主体のデータセンタへのアウトソースと、いわゆる共用リソースを使うホスティング、そしてそれをさらに進めた仮想化サービスでは、難しさが異なる。利用者ごとの環境の分離が難しくなるにつれ、インシデントハンドリングも難しくなる。マルチテナントのサービスを展開する事業者は、リソースを共有しながら、どのようにユーザごとのインシデントハンドリングを行うべきかについて、考えておく必要があるし、そのための機構も必要ならば導入しておくべきだろう。インシデントハンドリングにおいて、対象以外のユーザのデータにもアクセスしてしまう可能性がある場合、あらかじめそれを契約などに明記しておくべきだし、ハンドリングにあたっては、秘密の保持とその方法論も明確にしておくべきだと思う。なかなか安いサービスでそこまで要求するのは難しいとすれば、ユーザ側でのアクセスログなどをどの程度とっておけるかという点も重要だ。大きなインシデントが発生した場合、契約への記載の有無にかかわらず、利用者側で発生したものではないという証拠をある程度揃えて、事業者に対応を迫ることも可能だろうと思う。サービスを使うにあたって、認証部分をそのプロバイダ独自の機能ではなく、ＳＡＭＬやＯｐｅｎＩＤといった標準的な方法で、自社の認証サーバやサードパーティの認証サービスにゆだねるのも良い方法だと思う。多くの大手プロバイダのサービスはこれができるようになっている。また、認証サービス事業者側でも、マルティファクタ認証のサポートや様々なレポーティング、監視機能などを提供できるだろう。
（続く）
コメントする