マイナンバーにおける情報連携についてあれこれ

CIO Contribution Strategy

はじめに

ご承知のとおり、番号制度に基づく番号通知が今年の10月から順次行われる。

並行して、行政機関をまたいだ情報連携の仕組みも整備され、実際に情報連携が行われるのは平成29年1月(国の機関間)、7月(自治体まで拡大)の予定である。

これまでも情報が幾度となく小出しにされることで、肝心の仕様はなかなか理解できないまま振り回されている感がある私個人が、自らの理解の範囲で情報連携について、まったく別の視点で考えてみることが本稿の目的である。

そのため、ずいぶんと冗長な記述であることをご容赦願いたい。

中間サーバ、団体内統合宛名システム、情報提供ネットワークシステムの関係について

以前、このブログの記事の中で、団体内統合宛名システムと中間サーバの接続に関する図を描いたことがある。そう、セキュリティゴロの話題の時だ。

Fig-5

図1.団体内統合宛名システムと中間サーバの接続

この時、少し不正確な表現をしている。「情報提供ネットワーク」というネットワークがあるかのような表現をしているが、実際には中間サーバを仲立ちとして情報連携の旗振りをしているシステムが置かれるようだ。このシステムのことを「情報提供ネットワークシステム」と呼んでいる。インフラがどうなるのかは、ちょっとわからない。(LGWANかな?)

で、当初は中間サーバを各行政機関で導入し、管理することとしていた。

fig2図2.中間サーバを個別導入した場合

ところが、中間サーバは東西の二ヵ所に集約され、相互バックアップを取りながら管理されるという方針転換が、2014年の3月頃に示されることになる。(通知の公文書は見つけられなかった)

社会保障・税番号制度導入に向けた準備について
(住民基本台帳ネットワークシステム調査委員会(第24回)平成26(2014)年3月24日(月))
http://www.soumu.go.jp/main_content/000283915.pdf

これにより、次の図のようなネットワークとなる。

fig3

図3.中間サーバを集約した場合

このネットワークを抽象化すると、こんな感じ。

fig4

図4.抽象化してみる

いわゆる、ツリー型のネットワーク構造である。ツリー型の場合、ルート(ハブ)にあたる部分にトラフィックが集中するので、負荷はかかるものの、管理は比較的容易となる。情報の流通経路を制御するという観点で言えば、この手法は望ましいものといえる。

ただ、一見すると過去の説明と矛盾しているかのような誤解を与えてしまうところは、心配でもあるが。

fig5

図5.内閣官房からの説明資料(http://www.cas.go.jp/jp/seisaku/bangoseido/gaiyou.html)

誤解を与えてしまうのは、まさにこのネットワーク構造によるものである。また、少し微妙な言い回しのため、後日詳細が明らかになった際に、騙されたような印象を受ける可能性はある。

  • 中間サーバが集約されることにより、外見上ハブの役割を果たすように見えるが、中間サーバを所管しているのはそれぞれの行政機関であるため、情報の一元集約にはあたらない。(という解釈もできるが、ちょっと心配)
  • 中間サーバや情報連携ネットワークシステムを経由して情報連携する際に用いるキーは「符号」である。この符号は個人番号とは異なる番号である。(これはそのとおり。ただ、符号がどのようなものなのかはよくわかっていない。「符号」≒「行政機関コード+団体内宛名番号」としなければ、連携のための個人を特定することはできないのではないか。そういう意味で、確かに個人番号は使っていないが、個人を特定する別の番号を使う可能性はゼロではない)
  • 個人番号は確かに連携のキーにはなっていないが、技術的には連携データのひとつとして個人番号を流すことは可能。(もっとも、これを監督するためにPIAや特定個人情報保護委員会がある。もっと言えば、ツリー型のネットワーク構造を適切に管理しているのであれば、仮に連携データとして個人番号を流したとしても意図しない個人番号の漏えいは少ないのではないか)

個人番号の不正流通に関するリスクについて

さて、情報連携がある程度「管理された」仕組みで運用されるのに対して、個人番号の取扱いについてはいささか雑な運用を国民に任せているような印象を受けるのは私だけだろうか。(そんなことないよね、という反語です)

番号法では個人番号の不正な収集や名寄せに対して、罰則が設けられている。ただ、(国民の立場で)明らかにアウトなのは、悪意を持って番号を不正収集すること、不正に提供すること(名寄せはこの中に入るだろう)だと思われるが、実際にこの線引きをするのは難しい。悪意を証明することは難しいのだ。

結果、意図しない形で個人番号は収集され、紐づけられてしまう可能性はあると思う。さらに本当に悪意をもっている人の抑止になるのかは、よくわからない。そもそも番号を管理する国民の意識が低いのであれば、事故をゼロにすることはできないだろう。

となると、この個人番号は管理されていないランダムネットワーク(普通に考えればインターネット)を通じて流通することになる。

fig6

図6.ランダムネットワーク

ランダムネットワークの厄介なところは、ロバスト性があるところだ。つまり、どこかの経路が途切れても、どこかのノードが無くなっても、迂回してデータを流すことができるのである。そもそも一旦データが流通してしまうと、それらを回収することが難しいのはご存じのとおりである。

このように、じわじわと個人番号はランダムネットワーク中に広がり続ける。これがどの程度の影響を持つのかは推定できない。携帯電話番号ぐらいの話かもしれないし、クレジットカード番号ぐらいの話かもしれない、それ以上かもしれない。最終的には番号に対する感覚がマヒしてくるかもしれないし、本当はそういう未来が望まれているのかもしれない。

「符号」を使った情報連携の仕組みについて

実のところ、情報連携ネットワークシステムで稼働する連携の仕組み(仕様)は明らかにされていない。

「一般国民や自治体職員はそんなこと知らなくてもよいのだ」というのならば、それには異議を唱えておきたい。情報連携の仕様を秘匿しておくことが連携の仕組みの安全性を高めるものだと思うのならば、大間違いである。

ということで、今のところ見えている範囲で、この点についても考えておきたい。

情報連携は「アクセストークン方式」というものが採用されるようだ(伝聞形)。アクセストークンと言えば、OAuth2.0を思い浮かべると思うのだが、事実公開されている図を見ると、確かにOAuth2.0を援用した仕組みになるようだ。

fig7

図7.公開されている図(http://www.cas.go.jp/jp/seisaku/jouhouwg/goudou/dai1/siryou5.pdf)

最近の私は不勉強でOAuthの仕組みについて、完全に理解しているとは言えないのだが、OAuth2.0はTwitterやFacebook、Salesforceなどでも用いられている「認証」の仕組みである。

「おや? 認証?」「そう。認証」

そもそもOAuthは、代理認証を経て相手方のリソースにアクセスできる仕組みなのだが、そもそも相手方のどのリソースにアクセスしていいのかを指定するメカニズムが私には理解できていないのだ。

問い合わせ主が持っているのは「私は○○市が保有している12345という番号で管理されている者です。△△市さんにお尋ねします。」というアクセストークンだけなので、相手側である△△市はそのトークン自体を理解できるものの、12345が△△市にとっての誰なのかは、やはり判らないのではないだろうか? 結局、欲しい情報を得るためのクエリを投げる以外に情報を取得することができないような気がするのだが。

また、リソース間の通信はRESTだったりSOAPだったりするのだろうか。ならばリアルタイム連携を前提としているはずなのだが、ここ最近の資料を見ると、必ずしも情報連携はリアルタイムでないようにも読める。「照会を掛けると回答は翌日になる」というような話を聞くと、情報連携ネットワークシステム内でタイマー起動のバッチ処理が行われ、ファイル渡しで連携するようにも読める。

そうすると、わざわざアクセストークン方式を採用する意味はないのでは? というのが私の素朴な疑問である。

このあたりの仕組みについて、本当に教えてほしいところである。

付記

上記の情報連携の話をうちの職員に話したら、「符号同士を紐付けるテーブルを情報連携ネットワークシステム側で持っているんですよ」という説明をされた。

うん、確かに連携の瞬間はそうなのだけど、その紐付けを最初にどうやってやるの? というのが私のわからないところなのだ。逆にリアルタイム連携でないのならば、紐付けなんかしなくても情報連携する仕組みは思いつくのだけど、その場合これまでの説明と一貫性がないように感じるのだ。

また、内閣官房からの説明では紐付け情報は永続的に保持せず、連携が終わる度に破棄するという話だったと思うが、私はウソをつかれていたのだろうか?

 

photo by:

« »