2014年8月4日月曜日

集中から分散へ

個人情報の漏洩 2014年7月9日以来の報道によれば、ベネッセホールディングズが保有する多数顧客の個人情報が漏洩し、名簿業者に売却され、ジャストシステム等に渡った。そのデータは5000万人分に上るとも言われており、その内容は住所・氏名・電話番号・家族構成やクレジットカードの番号にも及ぶらしい。 ベネッセの社内システムは24時間監視され、全社員や委託先の従業員に個人情報の取り扱いに関する教育をし、定期的な外部監査も受け、個人情報を適切に管理しているという旨の「プライバシーマーク」もベネッセは取得していた。社内で顧客の情報にアクセスできるのは、透明のガラスで仕切られた小部屋にある専用端末のみであり、その部屋に入るには、事前の予約とセキュリティーカードによるチェックが義務づけられ、端末から顧客情報を取り出す際には、パスワードの入力が必要だという。 このように一見まともな管理がなされていたわけだが、今回の犯人はグループ会社の下請けのSEとのことで、その管理が十分に行き届いていなかったことになる。このような個人情報漏洩のリスクはベネッセのみならず多くの事業者が抱えている。以下では、前回まで説明してきたPLRによって個人情報の漏洩がいかにして防げるかについて考えてみよう。 暗号化 少々復習しておくと、PLR (personal life repository; 個人生活録)とは、個人が特定の事業者に依存することなく本人のデータを自ら蓄積・管理しつつ自ら指定する他者(家族や友人や事業者)と共有して活用するためのスマートフォン等のアプリである。PLRは、利用者の個人データを暗号化した状態で端末内およびクラウドに保存する。多くのユースケースにおいては、復号されたデータはプログラムの実行時のメモリ空間に一時的に存在するのみであり、他のプログラムからアクセスできる形で保存されることはない。 このような暗号化の運用によって管理が行き届きやすくなることが期待できる。つまり、PLRのような仕組を業務に用いる場合、ベネッセのように情報システムの管理を部分的に外注する際は、非公開のデータを復号する必要のない作業に外注の範囲を限定し、データの復号が必要なメンテナンス作業を内製化することにより、個人情報漏洩等のリスクを低減できるだろう。 しかし、業態によっては、システム管理作業においてデータを復号せざるを得ないことが多く、それをすべて内製化できない場合もあるだろう。そもそも、個人データを集中管理している限り、そのデータが一挙に漏洩する恐れは常にある。 アドホックなデータ収集 したがって、大量データの漏洩を防ぐには集中管理をなるべく避けねばならない。しかし、ビッグデータの分析のようなことをするためにデータを集めたくなるのも人情である。 そこで、いきなり大量のデータを集めてずっと抱え込んでおくのではなく、分析が終わったらその結果だけ残して元データを破棄してしまえば、漏洩のリスクが減るだろう。現状では、何のためにどう使うのかよくわからないような大量の個人データを不用意に集めて管理コストと漏洩リスクを無闇に高め、金をドブに捨てて経営を危険に晒している事業者が多い。 多数のPLR利用者とつながっていれば、いきなり大量の個人データを集めるのではなく、分析の目的と方法と効能が十分明らかになった後にPLR利用者からデータを本格的に集めることができる。その気になればいつでも再びデータを集められるから、分析し終わったデータはすぐに消去して構わない。大量のデータを保管してわざわざ漏洩のリスクに晒す必要はない。 従来、各事業者は自ら提供するサービスに直結するデータは普通に取得できた。たとえば、クレジット機能付の会員カードを顧客に使ってもらえば、顧客別の購買データが取れる。同様のデータをPLRによって取得することは易しい。クレジット機能付会員カード等によって自分のID付きの購買データを事業者が取得することに同意していた顧客であれば、代わりにPLRを使って自分のID付きの購買データを提供することに抵抗はなかろう。 さらには、顧客が他の事業者からの購買のデータや日常生活行動のデータや医療記録やバイタルデータをPLRで蓄積していれば、事業者はそれも顧客本人の同意の下で見せてもらうことができる。通常のクレジットカードと違ってオンラインでつながっているので、顧客にポイントを付与するだけでなくクーポンを配ったりオンラインで広告を配信したりキャンペーンを打ったりできることは言うまでもない。しかも、そのために購買記録等の個人データをすべて常に保管しておかなくて済む。必要に応じてアドホックに顧客から集めれば良い。 だが、データを集めることができるということは、集めたデータが漏れる恐れがあるということだ。データ利用の利便性と漏洩のリスクは同じコインの表裏である。データの利用を便利にしながら漏洩のリスクを下げるなどという都合の良い方法は原理的にあり得ない。したがって、氏名や住所や電話番号や医療記録など機微性の高いデータの収集・利用を面倒くさくすることによってその漏洩のリスクを低減させるしかない。 そのためには機微なデータを集める際の認証を厳しくすれば良い。PLRを使えばそれは簡単である。各個人にとって機微性の高いデータを開示する際には本人のPLRが通常より厳しい認証を要求するわけだ。個人のPLRの設定を変更する権限は原則として本人だけにあるので、事業者がその設定を変更して機微性の高いデータを大量に集めるのはほぼ不可能である。このように、PLRによって個人データの主たる管理者を事業者ではなく本人とすることにより、事業者からのデータ漏洩をかなりの程度まで防止できるだろう。個人が本人のデータだけを管理するという意味での分散管理は、一度に漏洩するデータを1人分に限るゆえに集中管理より圧倒的に安全であることは前回述べた通りだが、事業者によるデータ収集を統制しやすいという意味でも安全性が高い。 VRM (業者関係管理) さらに言うと、個人データを本人がPLRのようなもので管理していれば、事業者は個人データに直接触れずに結構いろいろなことができる。 たとえば、イベントや新商品のお知らせを個人に届けるためにダイレクトメールや電子メール等が使われてきたが、その際に各個人に合ったお知らせを送るには当該個人に関する情報が必要である。ベネッセの事件では、漏洩したデータが家族構成等の情報を含んでおり、名簿屋からデータを購入したジャストシステム等はそれを用いてダイレクトメールの送付先を選んだわけだ。 しかし、事業者が個人にダイレクトメール等を送り付ける代わりに、個人利用者が用いる何らかのアプリ(これを「VRMアプリ」と呼ぼう)が利用者のPLRに蓄積された個人データを参照することにより事業者の広報サイトから利用者に適合した情報を抽出して利用者に通知することも可能である。たとえば、ある事業者がコンサートの開催予定を広報しているとき、そのコンサートの演目やアーティストを好む利用者だけが自分のVRMアプリからコンサートに関する通知を受け取る、といった具合である。このように個人が自分に合った商品やサービスの情報を自分のアプリで取ってくれれば、事業者はダイレクトメール等の送り先を選ぶための個人情報を必要としない。ベネッセのような事業者も、顧客の住所や家族構成等の情報を持たずに各顧客に合った情報を提供できる。 VRM(※1)とはVendor Relationship Management (業者関係管理)である。CRM (Customeer Relationship Managemet; 顧客関係管理)とは事業者が顧客への売り方を最適化するということだが、VRMは顧客が事業者からの買い方を最適化するということである。個人のデータを本人が蓄積・管理していれば、個人はいかなる事業者よりも本人のデータを多く持つから、自分に適した商品やサービスを事業者よりもずっと正確に同定できる。B2C事業者は個人情報管理を含むCRMのコストとリスクから解放される。上記のVRMアプリの機能はVRMの一部である。 当然ながら、VRMが普及すれば事業者が顧客を囲い込むのが難しくなる。しかし事業者は、先行してVRMに対応することにより、CRMのコストとリスクを低減させつつVRMに即した事業を早期に開始し、市場における競争優位性を確保できるだろう。 補遺 一方、ビッグデータを1か所に集約せず分散させたままリアルタイムで分析や学習を行なう技術も進歩しつつある。上記のVRMに加えてこのような技術を使えば、個人データを集める必要はあまりなくなるのかも知れない。 しかしながら、管理を個人(だけ)に任せられない個人データもある。たとえば、納税者はなるべく税金を払いたくないので、課税の根拠となる個人の収入や資産のデータは国や自治体が集中管理すべきだろう。それがマイナンバーを導入する目的のひとつである。また、個人と事業者との間の契約書も、個人にとって不利な内容を含む場合には事業者が保管する必要がある(※2)。 だがそのような場合でも、通常はなるべく集中管理されているデータを使わずに個人ごとに安価に分散管理されているデータを使うことにより、セキュリティを格段に高めることができるのではないだろうか。個人は課税の根拠や契約書を改竄したくなるかも知れないが、政府や企業が正しいデータを持っているのでそれは無効である。契約書の場合は事業者の電子署名によって真正性を保証することもできる。このあたりの仕組みの詳細は業態に依存するだろうが、いずれにせよ自律分散協調的なシステムは非常に広い範囲で有効と考えられる。 ※1)Doc Searls...






WirelessWire Newsで全文を見る

0 件のコメント:

コメントを投稿