マイナンバーとプライバシー：識別子と超過リスク

前回、「マイナンバーとプライバシー：識別子に対する要件」で、以下のように書きました。

次に、仮想例として、税と社会保障（含む年金）の共通番号というものを考えてみましょう。これは、基礎年金番号と納税者番号双方の要件を満たす必要が出ます。つまり、年金管理が要求する「長い期間」と、税が要求する「広い範囲」の掛け算が必要になります。つまり「長い期間広い範囲で安定的」な識別子が必要になります。これは、要件３を満たしませんので、筋の悪い組み合わせだと言えます。

今回はこれを素材として、識別子のもたらすリスクの特性について考えたいと思います。

識別子の種類

さて、まず本題に入る前に識別子の定義を復習し、その種類をまず見てみましょう。

識別子：＝ある集団の中で、その個人（やモノ）を一意に他と区別（識別）うることができる属性の組み合わせ

そうです。普通に考える「個人番号」のようなものだけでなく、「氏名・性別・生年月日・住所」（基本４情報）のようなものも識別子なのでした。

これらの分類にあたっては、今回は、「利用範囲」「利用期間」「再利用性」の３種類を使います。「利用範囲」はどれだけの人・企業・団体などがその識別子を使うか、「利用期間」は、どれだけの期間その識別子が使われるか、「再利用性」はその識別子が他の人に対して再利用されることがあるかどうかです。

期間×範囲でとらえる識別子の名寄せリスク

プライバシー侵害のリスクは、様々なことに起因します。たとえば、新聞などでよく報道される「情報漏えい」などは代表的なものです。しかし、ここでは「名寄リスク」を主要なものとして取り上げます。なぜならば、本当のところは「情報漏えい」自身がプライバシーにまつわる実際の被害を起こすのではなく、漏洩した情報をもとに他の情報（例えば被害者の知人が持っている事前知識）と「名寄せ（リンク）」して、本人の望まない「本人像」が形成されることこそが被害を生むからです。たとえ情報が漏洩しても、それが誰の目に触れることもなく海のそこにでも沈んでしまえば、ほとんどリスクは無いのです。

識別子による名寄のリスクの一面は、次の図のように期間×範囲の面積でとらえることができます。

横軸がその識別子が流通する期間、縦軸がその識別子が流通する範囲です。期間は、その識別子がどのくらいの期間にわたって利用されるか、範囲はどこまで利用が広がるかです。たとえば、webのcookieは、そのサイトでしか利用されませんから、流通範囲は極めて狭いと言えます。いわゆるセクトラル方式の識別子も、そのセクターでしか使われませんから狭いと言えます。一方、米国のSSNなどは、いたるところで利用されますから、識別子の流通範囲は広くなります。

図1では、識別子の流通期間は長いけれども、識別子の流通範囲は狭いものを図にしています。年金番号などはこのようなタイプの識別子です。これに対して、図2は、逆に、識別子の流通期間は短いけれども、流通範囲は広いという識別子の例を表しています。たとえば、年ごとに変わる税番号などはこのたぐいのものになります。

こうした識別子を併用した場合のリスクは、それぞれの場合のリスクの和です。

一方、識別子を統合した場合には次の図のようになり、統合せずに併用した場合よりもリスクが増えてしまいます。利用目的を、別々だった時のそれぞれの用途に限るとメリットは変わらないので、この増分がはメリットなきリスク増加と言えます。これを超過リスクと呼ぶことにします。

「税と年金の共通番号は筋が悪い」としたのは、このように超過リスクが生じてしまうからです。

連携のコスト

さて、このように超過リスクが生じてしまう方式を推進する人がいるのはなぜでしょうか？おそらくは「連携にはコストがかかる」というものでは無いかと思います。このコストには、業務上のコストとシステム上のコストの２種類があると思われます。

まず業務上のコストですが、これは連携だと上がってしまうのでしょうか？

もともと業務は個別の番号／識別子で遂行されていたはずです。であれば、連携にしたからとてコストが上がるとは思えません。適切に「範囲」を設定すればすむ話です。（これが、セクトラル方式においては、セクターの定義が重要と言われるゆえんです。）

次にシステムコストを見てみましょう。確かに統合してしまえば、異なる識別子を変換する手間はなくなりますから、その分は安くなります。では、どの位安くなるのでしょうか？ちょっと変換コストを弾いてみましょう。

Doing aes-128 cbc for 3s on 16 size blocks: 21715758 aes-128 cbc’s in 3.00s

結論

（脚注）