符号変換を利用して、異なる「番号」を必要に応じて紐付けする

共通番号/マイナンバーの保管と紐付け作業について

まずは、マイナンバーに関する以下の内閣官房の絵を見ていただきましょう。「番号」となっているのがマイナンバーです。

符号変換を利用して、異なる「番号」を必要に応じて紐付けする
(図1)番号制度における符号連携のイメージ

この絵ではマイナンバー(「番号」)が、情報保有機関A、情報保有機関Bと複数箇所に保存されています。

これにはどうしても違和感があります。なぜならば、これでは情報連携基盤を使う意味が殆どなくなってしまうからです。

マイナンバーを保存するか、「符号」だけにするかというのは、プライバシー面でも保有機関のリスク管理面でも大きな違いがあります。

マイナンバーが機関AとB両方に保管されていると、機関AとBは結託して名寄せをすることができます。また、機関A、Bからそれぞれ独立に情報漏えいが起きた時も、それぞれのデータを(悪意の)第三者が名寄せして、本人が望まない自己像を形成されるので、プライバシー被害が甚大になります。当然、管理する側からすれば安全管理コストも上がりますし、直罰規定による罰則を受ける可能性があることも大きなリスク要因となります。

これが、符号のみを保存しているかたちであれば、結託はできませんし、漏洩しても名寄せできないので、だいぶ被害が減ります。罰則も緩くて良いでしょう。情報連携は情報連携基盤を通じないとできなくなりますが、そもそも、情報連携基盤の役目はそういうものでしょう。マイナンバーをあちこちに保管するというのは、バックドアを作りまくっているのと同じなのです。

本来マイナンバーは、「符号」に相当するものを取得するのに使って、取得したら捨てるものです。米国の事例で言えば、国防総省は、給与の振込口座と職員番号を結びつけるにあたって、その紐付け用データとして社会保障番号(SSN)を一回だけ使って、以後はその目的では使わない(廃棄)しています。これが真っ当な使い方だといえましょう。

基本4情報で紐付け?

もう一つ気になっていることがあります。情報連携基盤技術ワーキンググループでも度々指摘されてきたことですが、情報保有機関が、利用番号(口座)とマイナンバー、符号とをどのように結びつけるかということです。

これは、各機関が住基ネットと同じ形式で基本4情報(以後、正規化された基本4情報ということにする)を整備し、それを連携基盤に送信することで取得するとされてきました。しかも、その正規化された基本4情報を、各機関は保存し、常に最新にキープするのだそうです。

これは、ナンセンスでしょう。理由を以下に述べます。

  1. プライバシーを担保するためにせっかく「符号」を使おうとしているのに、「正規化された基本4情報」という、「マイナンバー」とほぼ1対1のもう一つの「識別子」を属性にくっつけて保存し、台無しにしている。
  2. そもそも多くの情報保有機関は正規化された基本4情報を持っていない。したがって、コスト削減要因にはあまりならない。

そもそも「符号」を使っているのは、「番号」が広く使われると名寄せが容易になってしまい、プライバシーリスクが高まるからです。なのに、全保有機関が「正規化された基本4情報」という「識別子」を持ってしまったら、「番号」を広く使っているのと同じ結果になってしまいます。こんなことをするのだったら、情報連携基盤も「符号」も必要ありません。税金をドブに捨てるようなものです。

次に、多くの情報保有機関が基本4情報を持っていないという点ですが、これらの機関が4情報を取得しようと思うと、結局ユーザに連絡をとって4情報を教えてもらわなければなりません。それだったら、マイナンバーを教えてもらっても同じ事です。なぜわざわざ基本4情報を経由するのかわかりません。コスト増になるだけです。

マイナンバーは安全に管理されうるのか?

現状の案では、マイナンバーは全ての源泉徴収義務者(=全企業および一部の個人)が、支払い対象者から聞きとって保存することになっています。大企業はまぁ良いとしても、個人事業主のようなところで果たして安全に管理されうるのでしょうか?

はっきり言って、無理だと思います。しかし、マイナンバーは、安全に管理しないと直罰が来るという恐ろしいものです。これは、企業にとって迷惑千万です。自分の役には立たない、しかもいつ爆発するかもわからない危険物を渡されて、「システム投資も自腹でして、ちゃんと管理しろよ」というのですから。

ではどうしたら良いか?

つらつら考えるに、現状の案は、紙でしか作業できない人たちを念頭において作られているような気がします。たしかにそういう企業・個人もいるでしょうが、大部分は少なくとも携帯電話くらいは使えるでしょう。例外にあわせて全体のセキュリティ・プライバシーレベルを引き下げるよりも、例外は例外としておいておいたほうが良いです。

その前提で考えるならば、以下のようなかたちにすることができるでしょう。

  • マイナンバーは各個人に配る。
  • マイナンバーは保存禁止。マイナンバーを聞くのも禁止。
  • マイナンバーを「符号」に置き換えるには2種類の方法を提供する。
    • (個人が携帯などを利用可能な場合)個人が源泉徴収義務者の企業コードを聞き、国が提供するページにアクセス、取得した企業コードと自分のマイナンバーを入力して、当該企業向けの「符号」を取得、企業に通知する。[1]
    • (個人が携帯などを利用不能な場合)個人は、氏名、性別、生年月日の基本3情報と、マイナンバーの下4桁を企業に通知する。企業はこれらを情報連携基盤に送信、「符号」を取得する。[2]
  • 情報保有機関はこうして取得した「符号」を使って情報連携を行う。

こうすることによって、

  • マイナンバーがあちこちに保存されることがなくなり、プライバシーリスクが低減さる。
  • 企業は、マイナンバーを保存しないので、安全管理コストが下がる。
  • 情報連携は問題なくできる。

わけで、目的は達していると思うのですが、どうですかねぇ?

(サンフランシスコにて)

[1] 企業向けの「符号」を生成するには、基盤側で企業ごとの暗号鍵を管理して生成するのと、テーブル方式があり得る。暗号鍵方式だと長くなりすぎて手書きや口頭で伝えられないという指摘はある。例えば、AES128という比較的キー長の短いアルゴリズムで暗号化してもbase64変換の場合、24文字になってしまう。その意味と、マイナンバー変更に対する耐性、暗号アルゴリズム危殆化に対する耐性ではテーブル方式の方が良いかもしれない。

[2] 住所は良く変わるので、識別子としては良くない。基本3情報はあまり変わらないのでその点望ましい。本来は、現在の氏名ではなく、出生時の氏名にすればなお良い。同姓同名ランキングによると、一番多い同姓同名は「田中 実」で、2620人だそうだ。生年月日、マイナンバー下4桁あれば、ほぼ完全に一意に識別できるだろう。

「共通番号/マイナンバーの保管と紐付け作業について」への3件のフィードバック

  1. ピンバック: にゅーすのみっ1344

コメントを残す

メールアドレスが公開されることはありません。

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください