情報連携ネットワークにおける情報連携の仕組み(既出?)

Administrative Lawyer CIO Contribution Strategy University

はじめに

以前、このブログでマイナンバーにおける情報連携の話題を採りあげた。

マイナンバーにおける情報連携についてあれこれ (5月23日)

その際に、「符号」を使った情報連携の仕組みについて、わからないことがあったのだが、既出だったものもあったので、ここで補足しておくことにする。

紐づけの仕組み(伝聞形)

まず、これまでの経緯を引用しておく。

内閣官房のマイナンバーシステム仕様書案が公開(スラッシュドット 2013.11.14)

当時の仕様案のポイントは、次のとおりなんですと。

  1. 「連携用符号」は、「住民票コード」から生成する。
  2. 「機関用符号」は、さらに「連携用符号」から生成する。
  3. 各機関が各利用者用の「機関用符号」を受け取る際には、「個人番号」あるいは「氏名」「住所」等からいったん「住民票コード」を受け取り、その「住民票コード」から「機関用符号」を受け取ったら、即座に「住民票コード」を捨てる。

で、これを実装する事業者(NTTコミュニケーションズ)の提案評価結果は、こんな感じ。

○提案書審査結果(集計表) 件名:情報提供ネットワークシステム等の設計・開発等業務(2014年4月25日?)

ちょっとこれだけではよくわからない。実装方式は変更されているようにも見える。そもそも調達に関連した仕様は応札者以外開示されていないものもあるので、推測の域を出ない。

また、当時みずほ総研が想定していた連携はこんな感じ。

日本の番号制度(マイナンバー制度)の概要と国際比較(みずほ総研)

ちなみに、これまで私たちがよく見てきた情報連携のイメージ図は、これだったはず。

?bango_renkei出典:番号制度における情報連携のイメージ(総務省資料)

先日、総務省から配布された資料を見ると、情報連携のイメージ図が幾分か変わっている。(赤字の手書きはメモです)

1493555_865488713529784_5084285340500891544_o

変化があったのは、「連携用符号」が住基コードから生成されることが明記されたこと(これは当初の仕様書案と同じということだろう)、「連携用符号」を暗号化したものが「機関別符号」になること、「機関別符号」が各機関の団体内統合宛名番号と紐づけされるように見えることである。

連携用符号は住基コードから不可逆変換で得られるのに対し、機関別符号への紐づけは「暗号化」となっており、これは復号が可能であることを意味する。

住基コード ⇒ 連携用符号

連携用符号 ⇔ 機関別符号

機関別符号 ⇔ 団体内宛名番号

気になるポイント

気になるポイントはいくつかある。

連携用符号の価値

この連携用符号、住基コードでないものの、個人を一意に特定できる符号であることに変わりはないので、これが漏えいするような事態になると、ちょっとヤバい。

年金機構でも国賠請求の話が出ているくらいなので、私ならば当然国賠を請求する。

連携用符号の暗号化の意図

おそらく、連携先の機関や対象者ごとに暗号のシード(連携先機関の番号をシードに用いるのかも)を変えて、指定した相手のみに連携できる仕組みを実装するのだろうと推測できる。

でも復号できるのはなぜだ? 復号できなければ連携できない仕組みということか。

現時点では、この暗号化が公開鍵暗号なのか秘密鍵暗号なのかもわからない(多分公開鍵だと思う)。

紐づけ情報の保持

上述のとおり、以前は連携用符号と機関別符号との紐づけは、その都度行われて、情報連携が終わったら紐づけ情報は破棄する旨の説明があったはずだが、このあたりは相変わらず不明。

連携用符号も厄介な情報だが、どちらかというと紐づけ情報(1:多リレーションのテーブル)の方が価値が高い。永続的な紐づけ情報が漏洩されたら、もうダメだろう。これも国賠請求に値する。

情報照会先を指定する方法がない、あるいは不明

これは団体内統合宛名システムの仕様を見ていて思っていることなのだが、情報をどのように照会するのかがイマイチ不明。少なくとも、現在の仕様では情報照会先を指定できないようだ。(6月26日時点で確認したところ、実際は指定できるようです。下記にその後の補足説明を加えています)

以前のブログの記事では、「アクセストークン方式」による認証の話を書いたが、アクセストークン方式は情報照会先を指定しなければ成立しないはず。ということで、私の中で矛盾が生じている。

仮に全国照会しか存在しないのであれば、1件照会する度に約2000機関へ照会することになる。それぞれの機関が1件照会するだけで、全体のトラフィックは

20002 = 4,000,000 件

となる。そしてその照会に対しての回答のほとんどが「該当なし」になるはずだ。ファイル渡しでバッチ処理をするのならば、なかなか大変な仕組みだと思う。

まとめ

まぁ、この段階でも私は妄想しかしていないので、詳細が明らかになることを望んでいます。判れば話は早いのかもしれないし。

補足説明(6月26日)

行政関係者限りの仕様書を見ると、情報照会先を行政機関単位で指定できるようだ。そのような画面イメージがありました。逆に全国照会は行えないようにも見える。(あくまでも画面上の照会であり、システムを経由した直接連携ではどうなるのかは未確認)

画面から情報照会先を指定し、要求する情報を1件(1名分)指定することで、後ほど(これがどのくらいの時間なのかは不明)照会内容が得られる仕組みと、あらかじめ照会対象者のリスト(複数名分)を作成し、それを情報照会先を指定した上で送信することで、後ほど(これも時間は不明)、照会内容が得られる仕組みがあるようだ。

逆に今度は複数照会先が指定できないところが厳しい。例えば生活保護の申請をある行政機関が受けた際、他の自治体で既に生活保護を受けられているか否かを確認する必要がある。そうしないと生活保護の二重支給になってしまうからだ。

これまでは、近隣の行政機関や転入前の行政機関などに個別に照会をかけていたのだが、これを情報連携で行うことができれば、多少はこの制度のメリットを感じることができる。

ただ現在の仕様では、それぞれの照会先に問い合わせる操作を繰り返し行わなければならないようだ。

 


« »