今回は信頼するベンダーに認証情報を預ける方法を見てみよう。前回の記事で説明したセキュリティ対策3)だ。この方法では、ベンダーが提供する認証サービスを利用する。「“国内”の“信用度”のある企業に認証を任せられるというところに認証サービスの価値があります。主要なクラウドサービスは海外の企業が提供しているため、データセンターも海外にあります。何かあったら駆けつけたいというユーザーは結構いますが、海外だと難しいでしょう」(富士ソフト ソリューション事業グループ クラウドユニット ユニット長の間下 浩之さん)。

ベンダーの認証サービスを使う

 認証サービスを使う場合、ユーザーは認証サービス事業者のデータセンターを経由してから、クラウドサービスにアクセスすることになる(図5)。クラウドサービス事業者と認証サービス事業者それぞれの認証サーバーは、先ほど説明したシングルサインオンで連携している。

図5●認証サービスを使ってユーザー認証やアクセス制限を強化<br>国内の事業者の認証サービスを使うと、認証情報を国内のデータセンターに置ける。また、サービスによっては複数の認証手段やアクセス手段を利用できる。
図5●認証サービスを使ってユーザー認証やアクセス制限を強化
国内の事業者の認証サービスを使うと、認証情報を国内のデータセンターに置ける。また、サービスによっては複数の認証手段やアクセス手段を利用できる。
[画像のクリックで拡大表示]

 多くの認証サービスは複数の認証手段を用意している。例えば富士ソフトが米グーグルのクラウドサービス「Google Apps」向けに提供するサービス「FSCloud PACK for Google Apps」は、(1)ID/パスワード、(2)ユーザー企業の内部からのアクセスか外部からのアクセスか、(3)端末(登録してあるパソコンなのかスマートフォンなのか)──という三つの情報でユーザーを認証する。ほかにも生体認証やワンタイムパスワードなどの認証手段にも対応が可能だ。これを活用すれば、自社で認証機能を作り込むよりも簡単に認証を強化できる。

 複数の認証手段やアクセス手段を提供するだけでなく、ほかのクラウドサービス事業者のデータセンターとを安全につなぐ認証基盤サービスがNTTコミュニケーションズの「BizCITY(ビズシティ) for SaaS Provider」である。この機能を利用したサービスとして、同社の認証基盤とセールスフォースのデータセンターとを専用線でつなぐ「Salesforce over VPN」が提供されている。

 ここまで見てきた「認証情報をクラウド上に置かない」という対策では、認証を連携させるシングルサインオンの仕組みとしてすべて同じ仕様が使われている。この仕様を「SAML(サムル)2.0」という。クラウドサービスのシングルサインオン機能はSAML2.0対応のことが多いので、認証サービスや認証用の装置を選ぶ際はSAML2.0対応かどうかを確認しておこう。