クラウド型メールが自社運用(オンプレミス)のメールシステムと大きく異なるのは、ログイン画面が社外、つまりインターネット上に用意されていること。Webブラウザーさえあれば、だれでもログイン画面にアクセスできる。

 もちろんURLが分からなければ接続できないし、IDとパスワードを知らなければログインできない。しかしそれだけでは企業のシステムとしては心もとない。そこで、セキュリティ面で第一に考えなければならないのが、ユーザー認証の強化である。

 大半の企業向けクラウド型メールは、ユーザーIDとパスワードのほかに、ログインしようとするユーザーのIPアドレスや携帯電話の端末IDなどを認証材料として使えるようになっている。しかし、代表的なクラウド型メールのGoogle Appsでは、ユーザーIDとパスワードしか使えない。認証材料を増やすには、外部の認証サービスを利用するか、認証サーバーを自社内に構築するかして、それをGoogle AppsとAPI連携させる必要がある(図1)。

図1●Google Apps導入企業がユーザーIDとパスワード以外の認証機能も使いたいなら、外部の認証サービスを併用すればいい
図1●Google Apps導入企業がユーザーIDとパスワード以外の認証機能も使いたいなら、外部の認証サービスを併用すればいい
利用できる端末や場所など接続条件をユーザーごとに制御したい場合、Google AppsのAPIを使って連携する外部サービスと組み合わせて使う。
[画像のクリックで拡大表示]

 Google Appsと認証サービスの連携には、グーグルが公開しているシングルサインオン用のAPIを使う。ユーザーがブラウザーを使ってアクセスしてきたときに、Google Appsから外部の認証サーバーにアクセス要求を転送(リダイレクト)する仕組みである。リダイレクト先となる認証サーバーで、ユーザーの利用環境を判別し、認証処理を実施。Google Appsに認証結果を送り返す。

ユーザー判別に使える認証情報はまちまち

 Google Appsの導入サポートを手掛けるインテグレータによっては、この認証機能をクラウドサービスとして提供している(表1)。ただし、認証に使えるユーザー情報の種類はサービスによって異なる。

表1●Google Apps向けの主なクラウド型認証サービス
表1●Google Apps向けの主なクラウド型認証サービス
ユーザーの要望に応じたアクセス制御ルールの追加も可能なサービスが多い。POP3:Post Office Protocol version 3、IMPA4:Internet Message Access Protocol 4、LDAP:Lightweight Directory Access Protocol。
[画像のクリックで拡大表示]

 クラウド型の認証サービスの多くは、基本的には、接続元のIPアドレスを識別し、自社拠点から接続するユーザーだけをログインさせる。しかし、社外にいるユーザーがモバイル端末を使ってアクセスするときのように、IPアドレスの範囲が変わってしまう場合は適用できない。その際には、携帯電話の端末ID、ブラウザーの種類などの情報を使う。POP3IMAP4などプロトコル単位で受信手段を制限できるサービスもある。

 「そもそもログイン画面をインターネット上には公開したくない」という場合は、外部のメールサーバーまでの接続手段を、インターネットではなく通信事業者の閉域網だけに限定する手段が選択肢に上る。NTTコミュニケーションズのクラウド型メール「Bizメール」は、基本的にNTTコムの閉域網を利用するユーザーを対象にしている。

 このほか、NTTPCコミュニケーションズのクラウド型メール「Mail Luck!」や、ソフトバンクテレコムのクラウド型メール「ホワイトクラウド メールサービス」などは、オプションで閉域網経由の接続手段を提供する。

 日本マイクロソフトのクラウド型メール「Exchange Online」の場合、スタンダード版はインターネット経由でしか接続できないが、専用サーバーをホスティングするDedicated版なら閉域網も利用できる。

 Google Appsには今のところ、ログイン元を閉域網内に限定するソリューションはない。ただし、ソフトバンクテレコムが2011年第2四半期中にも、同社の閉域網経由で接続できるソリューションを提供するとしている。