オンラインサービスH&Aプロトコル

オンラインサービスの会員情報が洩れる事件が相次いでいる。数万件ではもはや驚かないが、数百万とか数千万とかいう数字が連日のように飛び出していて、さすがにこれでは不安になってしまう。

この問題を回避するには、本質的には会員登録をしないことだ。だが会員登録をしないと個々の手続きは毎回大変になる。住所の自動入力なども、まあAIでできなくはないのだが、これが例えばお歳暮とか年賀状とかになると入力の量も相当なもので、間違いも起きやすいし確認も大変だ。

そこで、会員登録せずとも迅速にサービス加入状態に突入できるよう、サービス側とユーザの個人情報提供サービスを結合するのはどうだろうと考えた。ログインの一瞬でAPIを繋げて情報を送信し、会員登録しているのと同じような迅速さで操作ができるようにするというものだ。

これを仮に、ヒット＆アウェイプロトコルと呼ぶことにする。以下のような仕掛けを考えた。

• まず、個人IDと個人情報を保持するオンラインサービスを用意する。このサービスは、ユーザが目的とする具体的なサービス(預金や通販など)ではなく、それらの具体的なサービスに対して個人情報を提供するためだけのサービスだ。これを仮にIDサービスと名付ける。
• 一方、具体的なサービスの側には、会員一人一人に対し、➀このIDサービスの名称(IDサービスのID：URLなど)、②会員ID、③認証情報、④一時領域、が保持される。
• ユーザは、IDサービスに自分の端末からログインしておき、具体サービスにはIDサービスを通じてログインする。
• 具体サービスが個人情報を要求したら、IDサービスから送る。具体サービスはこの個人情報を④の一時領域に置き、サービスの実行に使用する。使用し終わったら、ないしはタイムアウト・ログアウト等によって、直ちに削除する。再度必要になったらその都度要求する。
  • 具体サービスは、ユーザがログアウトしている間にも、この要求をする可能性がある。例えば通販において、発送したときや配送するタイミングなどでメールを送る場合があるが、この際のメールアドレスすら保持せず、いちいち要求して入手し使用する。
  • ユーザは、IDサービスに対して、ログアウト中の具体サービスからの個人情報要求に対してどう対応するかをあらかじめ指示しておく。自動で返信するか、ユーザの確認によるか、無視するか。

IDサービスのイメージとしては、Googleアカウントでログインできるようになっているサイトは多いが、そのGoogleアカウントの追加サービスとして実装するようなものだ。

この仕掛けの特徴は、以下のようになる。

• 個人情報はIDサービスに集約するため、具体サービス側に対してサイバー攻撃を掛けるモチベーションが大きく低下する。
• 具体サービス側が(人間相手の)認証手段を持つ必要がないため、一定レベルのセキュリティが保てる。（BtoBの認証は最初から強固なものが採用できる）
• ユーザ側が、どこにどんな個人情報を提供したかを完全に把握できる。
  • IDサービス側に記録が残るため。
  • 情報漏洩が起きたときに、相手を特定しやすくなる。
  • 住所変更などが発生した際、どこに連絡をすればよいかが即時に分かる。
  • 具体サービス間での情報連携がやりやすい。

具体サービス側に個人情報が全く残らないわけではない。例えば通販なら購入履歴に送付先として残る(都度要求を徹底することで、それも残らないように作ることは可能だが)。だが多くの場合、認証情報と具体サービスの実務情報は分離管理されており、後者は更に内部にあるため、認証情報よりは安全度が高い。そしてこれが漏れてしまうようなら、もう会社はオシマイだろう。

IDサービス会社は、MicrosoftやGoogleなどが適している(Appleは閉鎖的なのであまり適していない)。今のサービスにちょっと付け足してやるだけで良いし、サービス料ビジネスもできるはずだ。検討する価値はあると思う。