高木浩光＠自宅の日記

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

目次

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

今回の報道

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  昨年度のシステムの利用件数は約９万５０００件。（略）

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

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

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

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

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

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

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

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

これが見過ごされなかったもうひとつの要因は、システムがちゃんと利用されていて、利用者がけっこう多いということなのだろう。たとえば、最高裁判所のオンライン申立てシステムは、最低最悪の糞野郎なのだが*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日の夕方で、しかも産業技術総合研究所の研究員の指摘で分かった。

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

• 官公庁の担当者は署名なしアプレットの存在を知らないのか, 2005年2月19日の日記

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

• 宮城県がセキュリティアップデートの中止を推奨中, 2005年7月11日の日記
• Winny利用教唆本のセキュリティ対策指南、その仰天内容, 国土交通省電子申請システムにも英知出版みたいな記述が, 2006年4月12日の日記

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

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

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

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

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

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

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

何が問題なのか

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

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

• 官庁はJavaの脆弱性にどう対処すればいいのか, 2005年7月17日の日記

要点を抜き出しておく。

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

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

追いつかない対応

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

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

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

５．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ゼネコン会社たちが設計変更を要望するべきだ。このような重要な要望に対して耳を傾ける様子がないのなら、そのようなベンダの製品はこのようなソフトウェア開発で使わないよう避けるべきだろう。