<前の日記(2004年08月21日) 次の日記(2004年08月23日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 956   昨日: 3759

2004年08月22日

植物状態のITゼネコンが国家をデザインする

総務省:「住民のプライバシー保護に関する新しい考え方」

あまり報道されることがなかったようだが、5月19日に総務省の「住民のプライバシーの保護に関する新しい考え方と電子自治体におけるそのシステム的な担保の仕組みについての研究会」の報告書が公表されている。これは大変すばらしい内容になっている。

いろいろ書かれているが、パッと見で肝を理解するには、参考資料III「電子政府・電子自治体におけるセキュリティーの構築とプライバシー保護」の、p.17にある「カナダ・アルバータ州政府のプライバシー・アーキテクチャーの例」の図などを見るとよい。図の直前部分には次のように書かれている。

このような種々の策を適切に配置するのは、難しいことではない。一般的なアーキテクチャーのなかにも、こうした事項に対処できるものがある。例えば、カナダ・アルバータ州政府により設計されたプライバシー・アーキテクチャーでは、データベース所有者は、外部アクセスと内部アクセスや関連業務からのアクセスなどのように、複数のレイヤー及びアクセスのためのフィルターを通してデータを交換する構成になっており、情報の詳細度を低下させることで危険性を下げ、プライバシーを保護するように考えられている。以下のURL から資料が入手できる。
http://www.sharp.gov.ab.ca/ppa/documents.htm
http://www.sharp.gov.ab.ca/ppa/documents/AlbertaPrivacyArchitectureOverview.pdf

例えば、カナダ・アルバータ州政府により設計されたPrivacy Architecture(プライバシー・アーキテクチャー)では、データベース所有者は、複数のレイヤーまたはフィルターを通してデータを送信し、情報の精度及び危険性を低下させることで、プライバシーを保護できる。

(注: このアルバータ州政府の例では、システムには、外部からのアクセスのための公開された「パブリックID = PID」と、それぞれのシステム内部のみで使われる「内部ID = IID」、そして複数の政府部門のシステム間で使われる「フェデレーテッド(連携)ID = FID」の3 種類が使われる。これらのID の関連性は、極めて安全な領域に置かれた相互の連携情報を与えるサーバーにより、毎回の条件ごとに組み合わせが与えられる。以下の図を参照。)

総務省, 住民のプライバシーの保護に関する新しい考え方と電子自治体におけるそのシステム的な担保の仕組みについての研究会報告書, 参考資料III, p.17

サービスごとに番号を切り分けるICカード

同様の効果を目的とした技術開発は、国内でも既に行われている。九大安浦研で研究開発が進められてきた「PID」と名づけられた方式のICカードだ。

詳細は掲載されている論文を読むとして、おおまかにこれがどういうものであるかは、朝日新聞西部版の2004年6月22日夕刊1面に掲載された以下の記事が参考になるであろう。

報! サービスごと番号切り分け
1枚のカードに1000〜1万ケタ 九大が開発
情報漏れのリスク減る

1枚で様々なサービスが利用できるカードに潜むプライバシー漏洩の危険を減らす技術を九州大システムLSI研究センターが開発した。あらゆるサービスを同じ会員番号で利用するのではなく、割り振られた長大な番号の一部をサービス別に切り取って使う仕組み。同大は福岡市西区に来秋完成する新キャンパスで、学生や教職員のIDカードに新技術を試験導入する。

クレジットカードのほか、定期券と電子マネーを組み合わせるなど、多機能のカードが相次いで登場しているが、多くは番号が固定されている。

例えば1枚のカードが電車の定期券や金融機関のキャッシュカード、店での買い物に使えるとする。すべて同じ会員番号で取引すると、番号を通じて個人の行動や預金残高、購買履歴といったサービスの使用記録が結合され、一度に個人情報が漏れる危険性が高い。 11桁の番号で管理する住民基本台帳ネットワーク(住基ネット)も同じ仕組みで、市民団体などが個人データ漏洩の可能性を理由に、導入に反対してきた経緯がある。 サービスごとに異なる番号のカードを使えばリスクは分散するが、枚数が増えて不便になる。

そこで同センターでは、カードに会員番号として1千〜1万ケタの大きな番号を与え、各サービスの提供者にはうち30ケタ程度の部分数列(サブID)を抜き出して知らせる方式を提案。サービスの提供者は、利用者が提示したカードのサブIDと照合する。万一、サブIDの一部が漏れても、他の情報は保護される。

(略)

サービスの提供者にとっても、効率的な個人情報の管理が可能になる。例えば、販売する商品が安価な鉛筆と高価な自動車では扱う個人情報の量も異なるため、商品やサービスに合わせたコスト管理ができる。

(略)

安全かつ実用的

産業技術総合研究所グリッド研究センターの高木浩光チーム長の話

大変重要な技術だ。サービスごとに違うカードを持つのは究極の安全策だが非現実的だ。この技術なら、1枚のカードで非常に多くのカードを使い分けるのと同じ効果があり、実用性がある。共通の番号を使うリスクを避ける考え方はこれまでにもあったが、対処されていないカードが普及しつつある。行政や民間のサービスには今後、こうした配慮が求められる。

朝日新聞2004年6月22日夕刊1面 西部版

記事中の「扱う個人情報の量も異なるため」という文章はちょっと変だが、IDに紐付けられる情報の重みが異なるということだろう。どの店でも同じIDで買い物する方式では、どの店も最大限にそのIDを丁重に扱わなくてはならなくなる。それに対して、このPID方式であれば、鉛筆しか売らない店ならば、ID漏洩にかける対策コストは小さめで済むことになる。

また、住民基本台帳のことが比較に挙げられているが、住基カードでも、複数のアプリケーションを入れられるのだから、店ごとに異なるアプリケーションを付けば、店ごとに異なる番号ということを当然、実現できる。しかし、アプリケーションは数個〜十数個程度しか入らないだろう。

それに対し、このPIDでは、記事によれば「番号は将来、10万〜100万ケタに増やすことも考えている」とされており、100万桁 / 30桁 ≒ 3.3万であるから、3万か所で別々のIDを使うことができる。

つまり、現状のICカードではせいぜい、銀行と電車と電子マネーを別々にする程度のことしかできないところ、このPIDならば、電子マネーの取り扱い系列店ごとに、さらには、その店舗ごとに別々のIDを使うようにすることができるということだ。

植物状態のITゼネコン

さて、これらを踏まえて、次の記事を読んでみる。

  • 日本ユニシス最高技術責任者兼先端技術企画部長 保科 剛, 「住基カードは本当に危険なのか,その可能性を改めて問う」, 日経BP, RFIDテクノロジ, 2004年8月6日

    RFIDの普及・浸透に対する今後の課題を聞くと,プライバシに関する意見が多く挙がってくる。しかし前回述べたように,それは利便性の説明が足りないからではないかと私は常々思っている。(略)

    住民基本台帳カード,いわゆる住基カードは,“国民背番号制”というネガティブな言葉で語られることが多い。(略)エキセントリックに言う人たちが,“国民背番号”という非常に嫌な印象を受けるような言葉を付けて,「そんなものを付けさせてはいけない!」という流れにしてしまった。

    (略)

    住基はそもそも,国民一人ひとりにIDを付けることによって,さまざまな官の手続きを一本化してスムーズにし,さらに同じIDを使って,民の色々なプロセスもスムーズにできるというものだったはずだ。(略)官・民ともにそのようなIDがあれば,色々面倒なことを考える必要がなくなり便利になるだろう。住基とプライバシに関する議論がこれほど偏った方向に白熱していなければ,官民協同による新しい基盤が,一意の識別子によって作られていたのではないだろうか。

    (略)

    メディアにも責任の一端がある。確かに「住基カードとプライバシ問題」をテーマにすると面白い記事が書けるだろう。しかし彼らが本当の意味をわかって書いていたのかは疑問だ。

    (略)

    前回の記事で触れたが,日本人は本来,利便性やメリットをしっかり理解できれば,フレキシブルにチャレンジする国民であると思う。プライバシが保護された上で便利であるとわかれば浸透するのは早いのではないだろうか。住基については何らかの形での仕切り直しを切望してやまない。

前回はそれとなくにしたが)今回ははっきり言うことにする。これほどまでに無能ぶりを堂々と曝け出して大丈夫ですかと心配だ。

まず、一部の電波系市民運動を敵として位置づけることで自己の主張の正当性を印象付けようというのが拙い。

住基について仕切り直しをするのは結構であるが、当然ながら、指摘されてきた問題点を解消した上で、本当の意味での「仕切り直し」をすればよいのだから、まず問題点の解消方法を検討するのが技術者の役目だろう。

しかし、保科氏の議論はすべて一意の固有IDありきで始まっており、「民の色々なプロセスをスムーズに」することに、なぜ「同じIDを使う」ことが必須なのか、その理由さえ何ら説明されていない。これでは単なる思い込みでしかない。

総務省の報告書にあるカナダ・アルバータ州政府の事例を知らないのか? 九州大学が研究開発した事例の報道を知らないのか?

営業職の人や体育会系出身のコンサルタントが言うのならまだわかる。情報技術の基礎を知らない人からすれば、複数のIDを関連付ける方式や暗号を使った方法に想像が及ばないのはしかたのないことかもしれない。

しかし、この記事の著者は、日本国を背負って立つ代表的ITゼネコンの最高技術責任者である。経歴を拝見すれば、「数理計画・人工知能分野の研究,アプリケーション開発を担当」「オブジェクト指向開発環境」などに携わってこられたそうだ。どうしてわからないのだろう?

たとえば、擬似固有PICC識別子が裏住民票コードとして働いてしまう問題を回避する*1ため奔走するなどは、本来あなた方の役目でしょう? 非接触型ICカードである住基カードのPICC識別子が、何メートル以内からしか電波読み取りできないといった安全確認実験をしましたか?

そもそも、ICカードのプライバシー問題は、RFIDタグ(ICタグ)のそれより解決はずっと容易である。なぜなら、ICタグほどに低コスト性が求められないため、暗号機能等を搭載し、様々な工夫を凝らせられる余地があるからだ。RFIDタグの推進記事で苦悩するのはしかたないにしても、ICカードの話題で同じように開き直って見せるのには、呆れるほかない。

日本の政府の役人さん達が、ITゼネコンの技術力を正しく評価する術を持っていないのが、この種の問題の根源ではなかろうか。本来ならば、今回の総務省の研究会のような報告書は、電子政府を設計する前の段階で調査しておくべきものだったと思うが、おそらく、ITゼネコン各社に任せておけば大丈夫だろうということだったのではないか。

たしかに、富士通にせよ、日立、NEC、NTTデータ、日本IBMにせよ、それぞれに中央研究所(ないし子会社や関連会社の研究所)があり、そこにはこの種の問題を解決し得る要素技術の研究を追いかけている研究者達がいる。しかし、去年の8月1日の日記にも書いたように、そうした人材が「研究のための研究」だけに費やされていて、電子政府のような重要な仕事に関与させられていないのではないか。

納税者フェデレーテッドID方式の可能性

こういう事例もある。日経BP社が、昨年12月に「新雑誌の試作版モニターを募集します」という告知を出していた。新雑誌の創刊を準備中とのことで、記事の見本を数本収録した試作版をモニターに提供するという。その記事の一つのタイトルが「納税者番号なくして税制改革なし」というものだった。

これを入手して読んだ。冒頭には次のように書かれており、期待に胸が膨らむ。

国家のデザイン

制度と情報システムを議論する時

島田 直貴, 納税者番号なくして税制改革なし, 日経BP 経営+技術 特別編集版

著者は、日本IBMで金融業界担当の営業・営業企画・コンサルティング部門に勤務され、退職して独立された方だそうだ。

さて、内容を読むと、冒頭はこう書かれている。

わが国には幾つかのタブーが存在する。その一つが「納税者番号制度」である。(略)タブーになってしまったのは「納税者番号は、国民総背番号の導入につながり、国民のプライバシーが侵害される」と指摘する声があるからだ。 しかし、強い反対意見があるからといって、納税者番号制度の議論すらできないという状況はいかがなものか。

島田 直貴, 納税者番号なくして税制改革なし, 日経BP 経営+技術 特別編集版

まったくである。ざっと目を通すと、次の見出しがある。

  • なぜ番号が必要か
  • 長期的な視点でコード体系を設計する
  • 最新のコンピューター技術の活用を検討すべき
  • 情報システムの課題と解決方法
  • プライバシーの保護
  • 他の公的番号との並存

これは期待できそうだ。

……だがしかし、期待したような内容のことは書かれていないのである。

それを端的に示しているのは次の部分だ。

1. プライバシーの保護

納税者番号を他人に知られる程度ではプライバシー侵害の恐れはあるまい。問題は、当該者の氏名・住所・電話番号などの基本情報や、取引内容や財産情報などの納税情報が漏れることである。

島田 直貴, 納税者番号なくして税制改革なし, 日経BP 経営+技術 特別編集版

やれやれ、まったくおわかりでない。

では、「長期的な視点でコード体系」とか「最新のコンピューター技術の活用」というのは何のことを言っているのかというと、どうでもいいことが書いてある。

コード体系の話は、ようするに、

単純に対象者数(例えば十億人分でケタすうと文字種類で決めてしまうと、将来に課題を残すことになる。番号に様々な意味を持たせすぎると後々困る。

(略)

コンピューターの技術は進歩してきており、コード体系の利便性と後々の修正のしやすさを両立させることが可能になってきた。具体的には、コンピューターハードウェアの高速化・低価格化と、大容量のデータを超高速処理できる「データベースエンジン」と呼ばれるソフトウェアの出現である。(略)

こうした最新技術の動向を勘案すると、納税者番号のコード体系は、順次自動採番方式が簡便であろう。これらはコード自体にあまり意味を持たせず、主として対象者の識別のためだけにコードを使う考え方である。(略)

何らかのデータを分析する場合、ハードウェアとデータベースエンジンの高速処理を活用して、別々に保管してある属性情報を呼び出して集計すればよい。実は、国産のデータベースエンジンは優秀であり、これらを複数使えば数億件程度のデータを即座に処理できる。

島田 直貴, 納税者番号なくして税制改革なし, 日経BP 経営+技術 特別編集版

ということなのだが、そんなのは当たり前だ。いったい何十年前の話をしているのか?

結局、この記事のIDのあり方に関する主張はこれだけなのである。

では、どうすればよいのか。

もし納税者番号制度が導入されれば、人々は自分の納税者番号を暗記するか、カードに記されている番号を見て、あらゆる場面でそれを手書き記入することになるだろう。

住民基本台帳法で住民票コードの民間利用を禁止したのは、ひとたび許可してしまうと、ささいな民間サービス(信用性の高くないサービス)にまでその番号が使われるようになり、やがてプライバシーやセキュリティの問題が生じてくるであろうことは、米国のSSN(ソーシャルセキュリティ番号)の実情を見れば明らかであり、同じ轍を踏まないようにしたものだ。

そもそも、納税者番号を書けば本人確認とするなどという番号の使い方が誤りなのであるが、民間はそれをやってしまうだろう。米国では、コンピュータ技術の進歩とともに、他人のSSNを使った詐欺が増え、昨年からはフィッシング詐欺によるID窃盗(SSNを含む)が大流行して、深刻な問題になっている。

  • MYCOM PCWEB, ブッシュ大統領がID窃盗罰則強化法に署名, 2004年7月16日

    Gartner Researchの調査によると、2003年4月から2004年4月の間にID窃盗件数は3倍に増加。インターネットユーザーをおとりサイトに誘い込んで、個人情報を盗み取るいわゆるフィッシング詐欺の被害は12億ドルになるという。ソーシャルセキュリティ管理局によると、98年に1万1,000件だったソーシャルセキュリティ番号を使った詐欺は、前回調査の2001年には6万5,000件に増加。今年の調査ではさらに飛躍的な増加になることが予想される。

こうした問題を避けるために、複数の番号を使うという方法が考えられる。しかし、複数の番号を人が暗記することは難しいだろうし、カード上に読めるように書ける番号の数は限られてしまう。

もし、国民全員にICカードを発行し、税に係る業務を行う事業者のすべてがICカード読み取り機を導入できるなら、解決方法はあるかもしれない。

例えば、すべての事業者・金融機関に固有番号を発行しておき、国民がICカードを事業者に提示すると、カード内の固有番号と事業者・金融機関の固有番号とから、何らかの暗号演算等により、別の番号を生成して、これを事業者・金融機関に渡す。事業者・金融機関はその番号でその人を識別して記録し、税務処理をするのだが、税務を担当する行政機関のセンターでは、暗号の復号演算等により、元の人を識別するID番号を得て、それを元に集計できるようにする――という方法が考えられる。

行政機関側でも、必要最小限の突合せしかできないように、行政サービスを細かく区分けして、区分ごとに異なる番号を用いるようにすることもできるだろう。

暗号を使う方法の他にも、PIDのように、事前に登録された長大な数字列の一部分を使用して、センター側では、検索により集計するという方法も考えられそうだ。

「最新のコンピューター技術の活用を検討すべき」とは、こういうことについて言ってもらいたいものだ。どうしてこうも不勉強な、十年遅れの人達ばかりが、「国家のITデザイン」を口にするのだろうか。

読み直してみて追記

ごめんなさい、言葉が過ぎました。謝っておきます。でも、黙っているわけにもいかない。誰もブレーキをかけないので。

*1 これは回避しようと思えば回避できる。

検索

<前の日記(2004年08月21日) 次の日記(2004年08月23日)> 最新 編集

最近のタイトル

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|
<前の日記(2004年08月21日) 次の日記(2004年08月23日)> 最新 編集