<前の日記(2007年07月07日) 次の日記(2007年07月10日)> 最新 編集

高木浩光@自宅の日記

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

2007年07月08日

厚生労働省の脆弱性放置は何が問題とされているのか

目次

  • 今回の報道
  • 過去の経緯
  • 何が問題なのか
  • 本当に動かなくなるのか
  • 内閣官房に期待すること
  • 新たな問題(Sun Microsystemsの愚行)

今回の報道

先週、NHKが、厚生労働省の電子申請システムのセキュリティ上の問題点を取り上げていた。

  • NHKニュース「厚労省 欠陥ソフトを放置」, 2007年7月5日 ニュース7

    厚生労働省はホームページ上で特定のコンピューターソフトを提供していますが、このソフトには重大な欠陥があり、利用者がパソコンの情報を盗まれるおそれのあることがわかりました。(略)

    厚生労働省は、こうした情報を把握できず、5か月以上にわたって、欠陥が修正された最新のソフトに切り替えたり、利用者に注意を呼びかけたりするなどの対策をとっていませんでした。

  • NHKニュース「厚労省 欠陥ソフト提供中止」, 2007年7月6日 おはよう日本

    厚生労働省は6日未明になって安全性が確保できないとしてソフトの提供を中止する措置をとりました。また、ホームページに注意を呼びかけるコメントを載せるとともに、ソフトを削除する手順などもあわせて掲載しました。

  • NHKニュース「欠陥ソフト問題 厚労相が謝罪」, 2007年7月6日 正午のニュース

    これについて柳沢厚生労働大臣は、閣議のあとの記者会見で、「去年12月にソフトのメーカーがみずから欠陥について情報を出したというところからいくばくもなく、アクションを取られるべきであった。少なくとも内閣府から連絡を受けた6月26日の段階で、即日、同じことをホームページ上で明らかにすべきだった」と述べました。そのうえで、「そういった手続きの遅れについてほんとうにおわび申し上げます。今後は、緊張感を持って反省の上に立ってしっかりとやっていきたい」と述べました。

  • NHKニュース「欠陥ソフト 厚労省が改修作業」, 2007年7月7日 おはよう日本

    厚生労働省はソフトの提供を中止し、対策を検討していました。その結果、提供するソフトを欠陥のない最新のものに入れ替えることを決め、7日未明からシステムを停止させて改修作業を進めています。改修されたシステムの運用は、7日午前9時から始める予定です。

  • NHKニュース「欠陥ソフト 省庁の実態調査へ」, 2007年7月7日 正午のニュース

    厚生労働省が重大な欠陥の見つかったコンピューターソフトを5か月以上にわたってインターネット上で提供していた問題で、省庁の情報セキュリティー対策に取り組んでいる内閣官房情報セキュリティセンターは、ほかの省庁でも欠陥のあるソフトを提供しているおそれがあるとして、すべての省庁のソフトの利用の実態を調べることになりました。(略)

    内閣官房情報セキュリティセンターの伊藤毅志参事官は「本来は省庁それぞれが自主的に取り組むべきだが、調査を行い、各省庁にあらためて対策を促すことが必要と判断した」と話しています。

この件では私も5日のニュースでコメントをした(勤務先に取材があったため)わけだが、この話題はもう5年も前から繰り返し繰り返し言われてきたことで、「いまさらその話題を?」と思った。実際、正直飽き飽きしていたので、ここしばらく各省庁の電子申請システムを見てまわることをしておらず、厚生労働省にこの問題があることは把握していなかった。

他の報道を見てみるに、どうやら今回の新しさは、NISC(内閣官房情報セキュリティセンター)の勧告を無視したという点にあるようだ。

  • 厚労省の電子申請欠陥、10日間放置…個人情報流出の恐れ, 読売新聞, 2007年7月5日

    ソフト会社は昨年12月の時点で欠陥を公表していたが、同省は気づいていなかった。

    同省は先月26日、内閣官房情報セキュリティセンターからの指摘で初めて問題を認識したが、利用者に注意喚起せず、システムを稼働させていた。

  • 厚労省のソフトに欠陥 利用者情報流出のおそれ, 朝日新聞, 2007年7月6日

    昨年度のシステムの利用件数は約9万5000件。(略)

    ソフト開発会社は昨年12月以降、自社のホームページ(HP)上で注意喚起したが、同省は内閣官房から連絡を受ける6月26日まで欠陥を把握できず、その後も「利用者に迷惑をかける」との理由で利用中止や注意喚起などをしていなかった。

  • 厚労省の電子申請、欠陥ソフトを放置・情報流出の恐れ, 日経新聞, 2007年7月6日

    同省は6月下旬に内閣官房情報セキュリティセンターから指摘を受けたが、利用者に注意喚起しないまま放置していた。

  • 厚労省の電子申請ソフト欠陥、原因はパッチ更新の慢性的な滞り, 日経IT Pro, 2007年7月6日

    サン・マイクロシステムズは昨年の12月と今年5月の2度に渡ってパッチを公開していたが、厚労省はこのときも更新していなかった。6月にはサン・マイクロシステムズが、今回の問題の原因となった新たな脆弱性が見つかったと発表している。それを受けて6月26日に内閣官房情報セキュリティセンターがJREを導入している各省庁に注意を促した。しかし、厚労省では対策を講じず欠陥のあるソフトがそのままダウンロードできる状態だった。

    7月2日には内閣官房情報セキュリティセンターが各省庁に対してサン・マイクロシステムズからパッチが出たことを通告。それでも厚労省は7月5日まで対応をとっていない状態だったという。

  • 厚労省、欠陥ソフト放置 公表後5カ月 年金申請など利用, 東京新聞, 2007年7月6日

    厚労省HPでは、今年一月から五月までに約四万二千件の利用があった。利用者のパソコンが外部から操作され、入力した情報を盗まれる恐れがあることが分かり、開発会社が今年一月に事実を公表、欠陥を改善したソフトを公開した。他省庁はこれに更新していたが、厚労省は先月二十六日まで気付かず、それ以降も対応していなかったという。

これが見過ごされなかったもうひとつの要因は、システムがちゃんと利用されていて、利用者がけっこう多いということなのだろう。たとえば、最高裁判所のオンライン申立てシステムは、最低最悪の糞野郎なのだが*1、正直、誰も利用していない(札幌地裁しか受け付けていない)のでもう放置でもいいやという諦めムードだったのに比べると、厚生労働省のシステムは昨年度に9万5千件、今年も既に4万2千件もの利用があるというのだから、無視できない問題と言えるのだろう。

過去の経緯

ここで過去の経緯を振り返っておこう。2002年3月末に最初の電子申請システムが総務省と経済産業省と国土交通省で始まった。このとき、CD-ROMで専用ソフトが配布されたのだが、同梱されたJREがその時点で脆弱性の知られたバージョンであったため、次の展開となった。

  • 経済産業省の電子申請ソフトに問題発覚, 日経IT Pro, 2002年4月8日

    ITEM2000は、本体の「ITEM2000」のバージョン1.02と、Javaの実行環境「Java 2 Runtime Environment」(JRE)のバージョン 1.3.1_01の2種類のソフトで構成されている。問題はJREの方にあった。(略)

    既にこのJREの問題について、米サン・マイクロシステムズ社は3月18日に同社のWebページで告知していた。しかし、経済産業省とITEM2000の開発元であるニューメディア開発協会は、この告知に気付かなかった。両者がこの問題に気付いたのは4月4日の夕方で、しかも産業技術総合研究所の研究員の指摘で分かった。

これにより各省庁は注意喚起を出すようになったのだが、時が経つにつれ、内容を理解しないで見よう見まねで注意喚起文を書くところが現れるようになり、誤った告知がされるようになっていった。

また、JREが自動アップデート機能を搭載するようになると、自動アップデートを止めるよう指示するところが現れるようになっていった。

昨年には、そもそも脆弱性以前の問題として、指定されているバージョンが異なるために複数の省庁を1台のパソコンで使えないという不満も利用者の間から顕になってきていた。

  • 電子政府、縦割り弊害 同一パソコンで申請不可, 朝日新聞, 2006年3月26日

    インターネットによる国への電子申請で、一つの申請ができるようにパソコンを設定すると、同じパソコンからは別の省庁などに申請できなくなる不具合があることがわかった。多くの省庁がシステムを発注する際、ソフトのバージョンアップへの対応を考慮していなかったことが背景にあるという。不具合解消を目指し、総務省は4月3日、電子政府のホームページ(http://www.e-Gov.go.jp/)に総合受付コーナーを設ける。

    (略)日本行政書士会連合会などによると、昨年末から東京や大阪などで始まった新車のオンライン登録ができるように設定したパソコンからは、不動産・商業登記の申請や国交省の電子入札の利用者登録ができない。

    また、多くの申請では個人認証が必要だが、公的個人認証カードが有効であるかどうかを確認するシステムを使用するパソコンでは、不動産登記ができない。

  • 電子政府が使えない理由、縦割りの弊害?JREの弊害?, スラッシュドットジャパン, 2006年3月26日

しかし、上の朝日新聞の記事にあるように、いくつかの省庁が、昨年度から e-Gov のサイトへ電子申請システムを移行させており、この問題は、e-Gov への一本化によって解決されていくのだろうと思っていた。(そのため関心を失っていた。)

何が問題なのか

今回の大々的な報道に対し、何が問題なのかわからないという声を耳にした。後から追従したCNET Japanの記事を見ても、注意喚起を行っていなかったことが問題であるかのように誤解している様子が見られるし、厚生労働省電子申請システムのヘルプデスクに電話すると、「サンの問題であるが(我々の問題ではないが)注意喚起することにした」というようなことを言う。

というわけで、何が問題なのかを改めてここに書こうと思った……のだが、調べてみると、言いたいことは2年前の日記に既に書いていた。

要点を抜き出しておく。

インストールさせる者による脆弱性告知

JREをインストールさせている官庁(中央省庁および地方自治体)にとって、 JREに脆弱性が見つかるたびに対応策を告知することは義務であるという考え方は、概ね普及したようである。(Acrobat Readerのインストールを要求している官庁も、Acrobatの脆弱性発覚時に告知するべきだと思うが、それは行われていない。)まことに適切なことである。しかし、告知には2種類のものがある。Javaのアップデートをしないで対処せよと呼びかけるものと、アップデートせよと呼びかけるものだ。

追いつかない対応

一方、現時点で脆弱なバージョンを使わせているにもかかわらず危険性を伝えていないところもあり、警察庁、防衛庁、外務省、厚生労働省などがあった。

このところ 1.4.2系列のJREに頻繁に脆弱性が発覚しており、各官庁の対応も追いつかない様子が見られる。しかし、そもそも「_XX」の「アップデートリリース」が出るたびに、「対応」が必要となること自体がおかしいのではないか。

たとえば、総務省の対応はスマートなものになっている。

5.Java実行環境

次に示すいずれかのJava実行環境が必須です。(注3)

・Microsoft社 Java Virtual Machine(以下、『MSJVM』)(注4)

・Sun Microsystems社 Java 2 Runtime Environment v1.3.1、v1.4.1、 v1.4.2(以下、『JRE』)(注5)

(注5) システムの動作確認はv1.3.1_10、v1.4.1_07、v1.4.2_03の各バージョンで行っています。セキュリティーの観点からは、最新バージョンの導入を推奨します。 JREはSun Microsystems社のページからダウンロードできます。

「_XX」のバージョンをとくに指定していない。つまり、「どのバージョンでも動きます」ということを言っていて、だからこそ、どのバージョンを使うかはユーザの責任だ(常に最新バージョンを使うことを推奨)と言えてしまっている。

総務省のアプレットは規模が小さくて、他省庁のアプレットは大きいといった事情の違いがあるのかもしれないが、本来目指すべきところは、このように実行系のバージョンに依存しないアプレット作りであろう。

それが簡単なことではないことは知っている。1.4.1 が 1.4.2 になると動かなくなるということはよくあることだ。だが、「_XX」という「アップデートリリース」で動かなくなるというのは、どういう作りをしているのか? JREのバージョンを上げると動かなくなるというのは、枯れていない最新ライブラリを使っている場合を除けば、やはり下手糞なプログラムの書き方をしている(誤ったライブラリの使い方をしているなど)からではないか。

「_XX」をセキュリティアップデートだと位置づけるのであれば、それによってアプリケーションが動かなくなるということは、ほとんど起きないものでなくてはならない。Windows Updateと同様にだ。

本当に動かなくなるのか

そもそも、電子申請のアプレットにおいて、「_XX」のバージョンを上げると動かなくなるという事態が、本当に起きているのだろうかという疑問がある。実際、「_XXにアップデートすると○○の機能が正常動作しなくなる現象が報告されています」といった注意を呼びかけている役所をこれまでに見たことがない*2。単に、「動作確認ができていません」というだけのことではないだろうか。なぜそこまで動作確認に拘るのか?

もしかするとこれは、まさにいわゆる役所仕事の弊害にすぎないのではないだろうか。つまり、発注時に、「JRE 1.4.2_04 での完動を保証すること」といった要件を無思慮に入れているために、こういうことになっているのではないか。新たなアップデートリリースが出ると、役所は「動作を保証できない」という思考に短絡し、正常に動くかもしれない可能性と脆弱性回避のトレードオフという発想に思考が及びもしない。そして、「アップデートを止める」という発想に陥るか、でなければ、新バージョンでの動作検証と動作保証のための改修という新たな開発事業を発注するということをやっているのではないか。

新たな「_XX」バージョンのリリースに対して、動作検証に何か月〜半年以上もかかっているというのがおかしい。予算を確保するところから始めているのではないか?

ここは、「JRE 1.4.2 の任意のアップデートリリースでの動作を保証すること」という発注要件にするべきだろう。もちろん、そのための費用を上乗せしてだ。

JRE 5.0で事態は改善されるか

経済産業省の場合は JRE 5.0(別名 JRE 1.5)へ移行したようだ。JRE 5.0では、「_XX」というバージョン表記は廃止され、「Update 4」といった名前が付けられるようになった。

これにより、これが「アップデートリリース」であることが名前からして明確となったわけで、もはや官庁が国民に対して、「Update 1での動作しか保証していません」だとか、「Update 2にしないでください」などと呼びかけることは許されなくなると期待できる。Windows XPで「Service Pack 2の適用をさせない」などということが許されないのと同様にだ。

経済産業省は、次のように、JRE 1.4.X_XX を捨てて、JRE 5.0 系を使うように指示している。(略)しかし、先ごろ発覚した Update 1の脆弱性については触れられていない。これは次のように考えることが可能かもしれない。 JRE 5.0では自動アップデートの機能が Windows Update同様に、タスクバーに現れるようになった(図1)。これによって、JREのアップデートはユーザの責任ということになったと言うことが可能かもしれない*3。

しかしそれでよいのだろうか? Windowsをインストールさせている(というか、インストールして販売している)パソコンメーカの何社かは、Windowsの脆弱性パッチがリリースされるたびに、そのパソコンのポータルサイト等で Windows Updateの適用をうながす告知をしているくらいなのだから、最初から入っているわけではないJREを自身の提供サービスの都合で消費者に入れさせる事業者および官庁は、JREの脆弱性情報を告知するべきではないだろうか。せめて政府機関くらいはそうしてほしい。Acrobat Readerの脆弱性についても

つまり、

  1. そもそもJREの「_XX」というバージョンが変わっても動くようにアプリケーションを作るべきであるところ、それをしていない省庁があり、
  2. そうなっていないならば、JREのセキュリティアップデートが出たら直ちにアプリケーションも対応バージョンにアップデートしなければならないところ、それをやっていない省庁があり、
  3. そのような場合には、直ちに回避策を利用者に周知する責任があるところ、それを怠る省庁があって、

今回は厚生労働省が上記 1. 2. 3. の全てに該当したところ、さらに内閣官房の勧告を無視して、大臣が陳謝する事態にまで至った。*2

2年前の日記では、発注者側が「1.4.2_04 での完動を保証すること」といった指定をしているのではないかという説を唱えたが、昨年のスラッシュドットジャパンのストーリでは、役所の方が業者にカモにされているのではないかと揶揄されていた。

Re:仕様書の書き方がわるいのか? (スコア:0)
Anonymous Coward のコメント: 2006年03月26日 18時31分 (#909216)

JREがバージョンアップしたら
また金蔓になるとか業者が思ってたりして。
「仕様変更は有料です。」とかね。

電子政府が使えない理由、縦割りの弊害?JREの弊害?

2005年の時点では、警察庁、防衛庁、外務省でも今回の厚生労働省と同様に何か月も放置していた状況があったわけだが、おそらく、上記 2. の対応をするには無視できない額の費用(テスト料金と、プログラム改修料金)が要求されていて、それが確保できないという状況があったのではないか。

しかし今回はどうか。5日夜に報道され、7日朝には新バージョンを提供したのだから、1日で対応できたわけだ。これはいったいどういうことか?

本当に動かなくなるのか

上記 1.の「「_XX」というバージョンが変わっても動くようにアプリケーションを作るべきであるところ」について、厚生労働省のシステムが本当にそうなっていないのかどうか、今回提供された改修バージョン(3.0.6)がどう変更されたのかを逆コンパイルして*3調べてみた。

「jp.go.mhlw.hanyou.apr.APRShinseiDataIchiran」というクラス(extends JFrame)があり、mainメソッドに次のコードがある。

    boolean result = checkJavaVersion();
    if (!result) {
        String param[] = errDialog.getDialogMessage("ErrAPR01-129-375");
        JOptionPane.showMessageDialog((Frame)null, param[1], param[0], 0);
        System.exit(1);
    }

「checkJavaVersion」メソッドは次のようになっている。

private static boolean checkJavaVersion() {
    ...
    String javaVersion = System.getProperty("java.version");
    boolean result = false;
    for (int i = 0; i < APRShinseiConst.JAVA_VERSION.length; i++) {
        String version = APRShinseiConst.JAVA_VERSION[i];
        ....
        if (!javaVersion.equals(version)) continue;
        result = true;
        break;
    }
    ...
    return result;
}

そして、5日まで配布されていた 3.0.5 と、7日から配布され始めた 3.0.6 を比較すると、「APRShinseiConst」クラスの以下の違いだけであった。(「, "1.4.2_15"」の12バイトが追加されただけ。)

3.0.5 のコード

public static final String JAVA_VERSION[] = {
    "1.3.1_06", "1.3.1_07", "1.3.1_08", "1.3.1_09", "1.3.1_10", "1.3.1_11", "1.4.1", "1.4.1_01", "1.4.1_02", "1.4.1_03", 
    "1.4.1_04", "1.4.1_05", "1.4.1_06", "1.4.1_07", "1.4.2", "1.4.2_01", "1.4.2_02", "1.4.2_03", "1.4.2_04", "1.4.2_05", 
    "1.4.2_06", "1.4.2_07", "1.4.2_08", "1.4.2_09", "1.4.2_10"
};

3.0.6 のコード

public static final String JAVA_VERSION[] = {
    "1.3.1_06", "1.3.1_07", "1.3.1_08", "1.3.1_09", "1.3.1_10", "1.3.1_11", "1.4.1", "1.4.1_01", "1.4.1_02", "1.4.1_03", 
    "1.4.1_04", "1.4.1_05", "1.4.1_06", "1.4.1_07", "1.4.2", "1.4.2_01", "1.4.2_02", "1.4.2_03", "1.4.2_04", "1.4.2_05", 
    "1.4.2_06", "1.4.2_07", "1.4.2_08", "1.4.2_09", "1.4.2_10", "1.4.2_15"
};

実際、このシステムを使おうとすると(JRE 1.4.2_15 の環境で 3.0.5のソフトウェアを起動すると)図1のダイアログウィンドウが出て、終了するようになっている。

画面キャプチャ
図1: 厚生労働省のソフトウェアを起動するとエラーが出て終了する様子

つまり、わざわざ動かないように作られているわけで、今後新たに JRE 1.4.2の「_16」がリリースされたとき、利用者がそれにアップデートすると、このチェックにかかってシステムは動かなくなるという事態が再び繰り返されるのは目に見えている。もし、この「checkJavaVersion()」を取り除いておいたなら、「_16」がリリースされてもそのまま動作するだろう。

1.5での動作が不安なのでバージョンチェックをするというのならまだ話はわかるが、それなら、「1.4.2_15」というバージョン文字列全体の一致ではなく、「1.4.2_」という先頭部分文字列の一致でバージョンを制限するようにしたらいい。

もう一つの方法は、JRE組み込みのアプリケーションを開発して提供することだ。これにより、JREの別途インストールを不要とし、Java Plug-inにそのJREの脆弱性が影響しないようにできる。(これについては後日。)

内閣官房に期待すること

2年前の日記に書いていたように、総務省や経済産業省は2年前の時点で、JREのアップデートリリースに依存しない形でプログラムを作っていた。現在の状況を確認してみると、一本化されつつある e-Gov のシステムでは、図2のように案内されており、1.4.2 または 5.0 というバージョン指定で、最新のリリースのものを使えばよいとされている。

画面キャプチャ
図2: 現在の e-Gov における「動作環境」の案内

次に示すいずれかのJava実行環境が必要です(最新のものを推奨)。

* Windows2000 SP4 および WindowsXP SP2
Sun Microsystems社 J2SE 1.4.2 Java Runtime Environment
Sun Microsystems社 J2SE 5.0 Java Runtime Environment

すべての省庁がこのような適切な案内をするべきところ、それができていないのは、省庁によって担当者のIT理解力が異なっているためではないだろうか。だからこそ、e-Gov に一本化して、IT理解力のある担当者をそこに集中させるという方策は正しい。

しかし、未だ e-Gov へ移行できない省庁があること、また、いくつかの省庁には部分的に e-Gov へ移行していないシステムもあるようであるし、地方公共団体のシステムは e-Gov に移行しないであろうから、単に e-Gov 一本化で万事解決する話でもないように思われる。

そうすると、IT理解力に斑があるのが現実である各官公庁の全部を正しく対処させるためには、どこかの機関が命令するなり、指導するなり、何らかの統括的な管理が不可欠であろう。

その点で、7日正午のNHKニュースにあった、NISC(内閣官房情報セキュリティセンター)が対応に乗り出すという話は良いニュースだと思う。

内閣官房情報セキュリティセンターは、ほかの省庁でも欠陥のあるソフトを提供しているおそれがあるとして、すべての省庁のソフトの利用の実態を調べることになりました。(略)

内閣官房情報セキュリティセンターの伊藤毅志参事官は「本来は省庁それぞれが自主的に取り組むべきだが、調査を行い、各省庁にあらためて対策を促すことが必要と判断した」と話しています。

NHKニュース「欠陥ソフト 省庁の実態調査へ」, 2007年7月7日 正午のニュース

実態を調べることはまずはの一歩だとして、さらに進めて、政府統一基準に盛り込むべきだ。NISCはこれまでに、「政府機関の情報セキュリティ対策のための統一基準」なるものを提供しており、この中に、「政府機関統一基準適用個別マニュアル群」というものがあり、そこに「ソフトウェア開発における情報セキュリティ対策実施規程 策定手引書」という文書がある。

こうした基準文書に、次のことを盛り込むべきである。


国民に導入させて使用させるソフトウェアを開発する際には、次の各要件を満たさなければならない。

  1. 当該ソフトウェア(以下甲とする)の動作環境として、サポート期限切れのソフトウェアの別途導入を利用者に求めてはならない。
  2. 甲の動作環境として他のソフトウェア(以下乙とする)の別途導入を利用者に求める場合には、前項の要件を満たすため、開発立案者は、甲の利用年限を計画し、以下の措置をとる。
    • 乙のサポート期限を確認(または予測)し、甲の利用年限より長いものであることを確認すること。
    • 乙のサポート期限が甲の利用年限より短い場合は、乙のサポートが終了する前に甲の更新バージョンを開発し提供するよう、計画すること。
    • 乙のメンテナンスリリースのバージョン更新(セキュリティアップデート等)の適用によって甲が動作しなくなる事態を、可能な限り排除すること。
    • 前項の要件を満たすため、乙のメンテナンスリリースのバージョン番号の判定によって故意に甲の動作を停止させることのないよう、甲の開発仕様書に明記すること。
  3. 前項の場合で、乙が自動アップデート機能を備えている場合、その機能を無効に設定するよう利用者に促すことをしてはならない。
  4. 同、乙が自動アップデート機能を備えていない場合、甲の配布者は、乙にセキュリティ脆弱性が発覚して修正バージョンがリリースされた際に、随時、乙のアップデートが必要である旨を利用者に告知しなければならない。

また、内閣官房は「すべての省庁のソフトの利用の実態を調べる」とのことだが、調査にあたっては次のことについて調べるのがよいと思う。

  1. 電子申請システムのために国民に導入を求めているソフトウェアの一覧
  2. 前項各ソフトウェアについて、導入すべきバージョンをどのように指定しているか
  3. そのバージョンはサポート期限切れのものでないか
  4. 前項が期限切れのものとなった際に利用者に回避策を告知するようにしているか
  5. 各ソフトウェアについて、最新バージョンを導入すると電子申請システムが動作しなくなるという事実が現在までに存在しているか
  6. 今後、最新バージョンの導入によって電子申請システムが動作しなくなる事態が発生した際に、どのように対応するかを計画しているか
  7. 各ソフトウェアは自動アップデート機能を備えているか
  8. 自動アップデート機能を備えているソフトウェアを導入させている場合、各ソフトウェアについて、自動アップデート機能を無効に設定するよう国民を促していないか
  9. 自動アップデート機能を備えていないソフトウェアを導入させている場合、脆弱性発覚時に利用者に注意喚起の告知を行っているか

7月5日の時点での厚生労働省の場合、回答例は以下のようになる。

  1. JRE
  2. JREについて 1.4.2_10 のバージョンを指定している
  3. 期限切れ
  4. 告知していない
  5. 動作しない事実がある
  6. 計画していない
  7. 備えている
  8. 無効にするよう促している
  9. 該当しない

7月8日の時点での厚生労働省の場合では、回答例は以下のようになる。

  1. JRE
  2. JREについて 1.4.2_15 のバージョンを指定している
  3. 現時点では期限切れではないが、いつ期限切れになるか不明であり、これまでの経緯からすれば半年前後が経過した後に期限切れとなる可能性が高い
  4. これまでは告知を怠っていたが、今後は告知していく予定
  5. 指定しているバージョンが最新版であるが、1.5を導入すると動作しなくなる事実がある
  6. 計画していない
  7. 備えている
  8. 無効にするよう促している
  9. 該当しない

理想的な対処をしているところの回答は以下のようになる。

  1. JRE
  2. JREについて 1.4.2 または 1.5 系列の任意のバージョンを指定している
  3. 1.5系列については、20XX年までは期限切れにならないと予測している
  4. 期限切れとなったことがない
  5. 現在のところそのような報告はない
  6. 計画している
  7. 備えている
  8. 促していない
  9. 該当しない

新たな問題(Sun Microsystemsの愚行)

この2年の間に、新しい不都合が生じるようになっていた。Sunはこの間にJRE 6.0をリリースしたのだが、その結果、Javaの自動アップデート機能は、JRE 5.0をインストールしている人に対しても、JRE 6.0のインストールを促すようになってしまった(図3)。

画面キャプチャ
図3: JRE 5.0最新版利用中に現れる「Java Update」の画面

これは喩えて言えば、Windows 2000 SP4 ユーザに Windows XP SP2 への自動アップデートを促すようなもの(XPが有料であるのは別として)で、そんなメジャーバージョンのアップデートをしてしまったら、それこそ何が動かなくなるかわからない。

Sunはいまだに開発者のお遊びのノリで作っているのか? 1.4.2ユーザには 1.4.2系列の最新メンテナンスリリース(現時点で 1.4.2_15)を案内し、1.5.0ユーザには 1.5.0系列の最新(JRE 5.0 Update 12)を案内するべきだろう。少しは Microsoftのやり方*4を見習ったらどうか。

JREがこんな糞設計になっていることも、厚生労働省などが、「自動更新機能を無効にしてください」と言わざるを得なくなってしまっているもう一つの原因だ。

画面キャプチャ
図4: 厚生労働省が自動アップデートを無効にするよう指示している様子*5

Q. JRE(Java Runtime Environment)の最新バージョンへの更新のお知らせが表示されるのですが、どのようにすればいいですか?

A. 最新バージョンへの更新は行なわないでください。

JREのバージョン1.4.2をインストールすると、自動更新機能が働き、JREのバージョンが上がってしまう場合があります。

自動更新機能を無効にする手順をご案内しますので、設定のご確認と変更をお願いいたします。

(略)「自動的にアップデートする」のチェックボックスに印がついていたら、印を外してください。 (略)

厚生労働省電子申請・届出システム よくあるご質問

これは Sunが悪い。2年前にも書いていたように、Sunの大口顧客であるところの政府やITゼネコン会社たちが設計変更を要望するべきだ。このような重要な要望に対して耳を傾ける様子がないのなら、そのようなベンダの製品はこのようなソフトウェア開発で使わないよう避けるべきだろう。

*1 一昨年2月の日記「サポート中止ソフトをこれからも入れさせる最高な裁判所」で書いたように、開発者向けのダウンロードサイトから期限切れのJREをインストールさせており、2度にわたって電話で抗議したのに、いまだにそのままにしている。

*2 1.に該当しないところ、つまり、「_XX」というバージョンが変わっても動くようにアプリケーションを作っているところについては、今回のような意味での告知の義務はないだろう。私としては、そのような場合であっても、せめて政府くらいは、インストールさせているソフトウェアの脆弱性情報の提供をした方がよいと思うのだが、それは、Acrobat Readerに脆弱性が見つかったときにもそうするべきだというのと同じ程度の要望であって、厚生労働省がしなかった告知とはレベルが違う。

*3 「厚生労働省電子申請・届出システム利用規約」で「エンドユーザは、次の各号に掲げる行為を行うことはできません」として、「本ソフトウェアに改変を加えること並びに逆コンパイルまたは逆アセンブルを行うこと」とされているが、今回のような事実の確認をする行為が妨げられるのは正義に反するので、公然と無視する。

*4 Windows XP SP1がサポート期限内だったときは、SP2が出ている時点でも、MicrosoftはSP1用のセキュリティアップデートを出していた。

*5 7月5日のNHKニュースウオッチ9で、この画面を映し出して「最新バージョンへの更新は行なわないでください」とは何事か!と批判されていたのに、厚生労働省は現在もこの指示を出したままにしている。

本日のTrackBacks(全100件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20070708]
検索

<前の日記(2007年07月07日) 次の日記(2007年07月10日)> 最新 編集

最近のタイトル

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|
<前の日記(2007年07月07日) 次の日記(2007年07月10日)> 最新 編集