概要

この記事は、Web サイト上で個人情報を安全に利用するためにどのようにしたら良いかを考察する雑記である。
2022 年現在で利用可能な技術をベースしつつ、現在の仕組みに対して抜本的な変更を考える。

あくまでも雑記とするため、関連論文などは調査していない。
そのため、私個人の考えるメモとしてこの記事を残す。

解決すべき課題

本メモで扱う課題は以下のとおり。

Web サイト上で個人情報を安全に利用するにはどのようにしたら良いかを考える。
現在の個人情報の取り扱い方法は、Web サイト上にユーザー登録を実施するため、自身の個人情報をサイト側で管理することが前提となっている。

そのため、サイト管理者の不備で自身の個人情報が漏洩したり、自身の個人情報を消すための手続きが明確でないなどの問題が起きている。
また、Google ログインや Line ログインなどの IdP の台頭により一部のシェアの多い IdP にユーザーの個人情報管理が依存するという問題も発生している。

このことから、自身の個人情報管理は、自身の責任化で安全に管理するためにはどうしたら良いか、また特定の企業に依存せずにログイン管理を行うためにはどのようにしたら良いかを主な課題として考察する。

内容

ビジネスの目的を考えたとき、サイト運営に必要とする情報は何かと問うと「ID」や「パスワード」ではなく「個人情報」である。

現在の Web サイトは、個人情報を利用するために「個人情報を取得するためのユーザー登録」や、「個人情報を参照するためのログイン管理」がされているが、これはビジネスの目的に対して必須のものではない。
Web サイトというのが、サーバーからの一方向のものから双方向のものになったときに、ログインはその当時の技術として個人情報を管理するため発明されたものである。

今回考える仕組みは、現在のユーザー登録と、ログイン処理に相当する機能をブラウザ側に任せ、サイトは都度送られてくる個人情報を利用するに限定することを骨子とした検討である。

そのため、今回考える仕組みとしては、以下の要素は利用しない。

サイトにログインするための ID・パスワード・MFA
サイトを利用するためのユーザー登録
サイトを利用するためのセッション管理
ユーザーを管理するためのデータベース
ログインを簡易にするための IdP (Google ログインなど)

ユーザーは自己の責任において完全な個人情報管理が可能となり、サイト管理者はユーザー管理により発生する（ビジネスとして価値のない）個人情報の管理業務から開放される。
この仕組みは、以下のステークホルダーに対して以下のメリットを提供する。

利用者
- サイトに対して自身の情報をどのように渡すか判断するだけで利用可能となる。
- 特定の企業の IdP に自身の個人情報が集約しない。
- 自身の個人情報の管理を自身の責任で任意のブラウザに任せることが可能。
- 自身の責任において、任意のタイミングでサイトに対する許可の取り消しが可能。
- ログインがブラウザ側管理となるため、フィッシング詐欺に対する保護が可能。
サイト管理者
- 単一の仕組みによるユーザー認証の実現。
- ユーザー保護の仕組み検討の省力化。
- 利用登録、ログイン処理の省略。
- （個人情報を保持しないことによる）各種法令への対応の省力化。
- MFA などの追加の管理策を必要としないことによる省力化。
個人認証局
- 新たなビジネスの創出

全体図

仕組みの詳細

今回検討する仕組みは、大きくブラウザの役割の拡張と、個人認証局の考え方からなる。

ブラウザの役割の拡張では、新しく「個人情報の管理」を必須の機能として取り込み、現在のサイトのユーザー登録やログインに関わる機能を代行する。
具体的には、個人情報と、それが後述する「個人認証局」で保証されていることを確認してサイトに伝達する。

個人認証局では、ユーザーがブラウザが提供し、サイトに通知される個人情報に対して一定の「保証（その個人情報が真にその個人であることの証明）」を与える。
具体的には、メールアドレスの検証や電話番号の検証、（より強力な場合は）国が発行した証明書と本人を照合するなどの方法を用いて、その個人情報が真に本人であることを保証する。

上記の 2 つが機能することにより、以下のような個人情報の利用が可能となる。

署名済み個人情報の発行

署名済み個人情報は、ユーザーの個人情報に対して個人認証局が一定の保証を行った署名をしたものである。

ここでいう個人情報の保証は、現在の商習慣に合わせて複数のパターンが考えられる。

ログインのために、氏名などは不要で一意の個人であれば良い（一般サイト）
発信者特定のため、メールアドレスや電話番号が確認できていれば良い（SNSなど）
本人の氏名や住所、クレジットカード情報など正しいことが必要（通販など）
本人の氏名や住所が、免許証やマイナンバーなどの国によって発行された文書をもって正しいことが必要（携帯電話の契約など）
利用者の統計のための性別、年齢、趣味などのオプトインであるべき情報（必要とするサイト）

これらの保証の強さにより、費用を最小化して個人を保証することが可能となると考える。
これらの保証は、サイトごとではなく、個人に対して 1 度だけ発行が必要なもので、その管理はブラウザで行うものとする。

個人認証局は、現在の認証局のように一般の企業同士の相互認証によって成立するものと考えれば、特定の企業や国が個人を管理することにならず運用が可能であると考える。

個人情報の利用

サイトが個人情報を必要とするとき、以下のような手順で個人情報を取得する。

Step.1

サイトは、自身が個人情報を必要とするとき以下の情報をブラウザに伝える。

個人情報を利用する範囲（サイトのドメインなど）
必要とする保証内容
自身のサイトのプライバシーポリシー
契約書などのサイト利用のための付属文書

Step.2

これらの情報を受けたブラウザは、サイトから受領した内容をユーザーに提示し、個人情報の提供を実施するか確認する。

Step.3

ユーザーの確認が取れた場合、ブラウザはサイトとのすべての通信に対して個人情報を付与する。
※この際の通信は、ステートレス通信となる。

Step.4

署名済み個人情報を受けたサイトは、署名を確認することにより個人情報の保証を確認し、自身のサイトで利用する。
その際、サイトはディスクやデータベースなどの永続化可能な領域に個人情報を保存しない。

上記の仕組みにより、個人情報の利用を安全に実施することが可能になると考える。

考慮点

なぜ、ブラウザで署名付き個人情報の管理を実施するのか？

指紋や虹彩、顔認識などの高度なセキュリティ保護が可能なアプリは、ブラウザしかない。
FIDO 認証などと同様に、ブラウザで高度なセキュリティを実施すべきと考える。

なぜ、ブラウザでユーザーに個人情報の提供を確認するのか？

ユーザーは、自身の選んだブラウザの一定の方法で確認されることで、誤操作による個人情報の提供リスクが回避できる。

また、現在はサイトごとにインターフェイスが異なっており、意思の確認手段として不適切だと考える。
一定の方法で提供にポリシー等を確認することができることにより、ユーザーが正しく判断することが容易となる。

なぜ、IdP 利用では不足しているか？

IdP を利用すると考えた場合、以下の点がリスクであると考える。

サイトの利便性が、シェアのある IdP に依存する。
IdP の乱立により、サイト管理者の負荷が増加する。
多数のログイン規格に対応するため、サイト管理者の負荷が増加する。
IdP を騙ったフィッシングなどに対して脆弱である。

そのため、 IdP ではなくブラウザで個人情報を管理するべきである。

なぜ、フィッシングを防げるのか？

フィッシングの原因は、本家のサイトと詐欺サイトが見た目上区別がつかないことである。
今回の方法の場合、ブラウザの補助によりサイトの利用実績の有無などを調査可能であり、フィッシングなどに対する保護が可能となる。

なぜ、ステートレス通信を行うのか？

Cookie などを利用したセッション管理は、サイトに一時的であれ個人情報が保持されるため、すべての通信はステートレス通信として運用すべきである。

現在のステートフル通信と、今回のステートレス通信を比較検討すると以下の通りとなる。

サイト表示にかかる通信量は、個人情報に限定すれば都度送信しても多くならない。
都度送信するため、サイトは一時領域内にも個人情報を保存しない。
ステートフル通信は、インメモリデータベースを利用するため、メモリ負荷が高い。
ステートレス通信は、都度検証するため、CPU 負荷が高い。

そのため、ステートレス通信を前提としても、大きくデメリットは発生しない。

毎回個人情報を送付して安全なのか？

考慮しない。
通信の安全性は、SSL／TLS などの暗号化通信により担保すべき問題。

サイトが、個人情報を保持していて漏洩したら意味がないのではないか？

考慮しない。
サイト上での扱いは、ユーザーとサイト管理者の契約の問題。

署名済み個人情報が改ざんされたらどうするか？

考慮しない。
署名による正当性は、公開鍵暗号方式により担保すべき問題。

Web サイトが、署名済み個人情報を詐取したらどうするか？

特定のサイトのみで利用可能な検討が必要。
具体的には、署名の範囲として利用先のドメインや、範囲（パスや、拡張子など）を含むべきと考える。

リプライ攻撃に対して、どのように保護するのか？

検討が必要な課題。
署名の時間を短期間にするなど、漏洩時のリプライ攻撃に対する保護の検討が必要であると考える。

複数のサイト間で、ユーザーが一意に紐づく問題をどのように解決するべきか？

検討が必要な課題。
一意に指定するキーは、ユーザーの許可ごとに一意であることが望まれる。

ビジネスとして、他社による保証でなく自社による保証が必要となる場合どうするか？

自社で、自社サイト用の個人認証局を運営し、サイトで利用する際に Pinning することで対応可能と想定する。

個人情報の管理はしていないから自分には関係ない

ログイン確認のためのメールアドレスなども個人情報であると認識してください。

夢物語、かかるコストを見ていない

実現に対するハードルが高いことを理解しているため、雑記として公開しています。

以上