マイナンバーカード管理システム障害の原因が判明

マイナンバーカードの交付に使うカード管理システムの障害原因が判明したようです。4月27日に原因を特定したうえで、対応済みとのこと。

マイナンバーカード(個人番号カード)の交付に使う「カード管理システム」の障害について、システムを運営している地方公共団体情報システム機構(J-LIS)は2016年4月27日、障害原因を特定したと公表した。

公表内容によると、2016年1月にカード管理システム内の「住基ネット中継サーバー」内の障害によって、市区町村の統合端末から接続できない状態が起きた原因は2つある

情報源:ITPro http://itpro.nikkeibp.co.jp/atcl/news/16/042801270/?rt=nocnt

J-LISからの報告
https://www.j-lis.go.jp/data/open/cnt/3/2064/1/j-lispress160427_1.pdf
全文引用

地方公共団体情報システム機構

カード管理システムの中継サーバに生じた障害原因の特定と対応について

本年1月中旬以降に当機構のカード管理システムに障害が生じたことにより、各市区町村におけ るマイナンバーカードの交付事務に影響を与える事象が発生しました。本事象により、住民の皆様 及び地方公共団体の皆様に、多大なるご迷惑をおかけしましたことを、改めて深くお詫び申し上げ ます。 この度、発生以降調査を進めてきたカード管理システム内の中継サーバの障害の根本原因を特定 し、その対応策を講じましたので下記のとおりお知らせいたします。

事象

中継サーバ内の障害により、市区町村の統合端末からカード管理システムに接続できない状態 となった。

(障害発生日時)

・平成28 年1 月13日(水) 11:40 13:10

・平成28 年1 月18日(月) 15:40 19:00

・平成28 年1 月19日(火) 8:30 8:50

・平成28 年1 月21日(木) 18:40 19:00

・平成28 年1 月22日(金) 9:40 9:50

・平成28 年1 月25日(月) 10:45 11:25

原因

原因1 (説明)

CPUが耐タンパ装置からのデータを各コアで処理している最中に、ハードウェア監視ツ ールから CPU への状態確認が行われ、同一コアで処理されると、CPU ではハードウェア 監視ツールへの対応のみが行われ、CPU での処理結果が耐タンパ装置へ返答されず、そ の結果、業務アプリケーション側から見て、耐タンパ装置が無応答になってしまう。

原因2 (説明)

通常、業務アプリケーションがデータ処理を開始する際に、メモリ内に作業領域を確 保してから処理を行う。ところが、業務アプリケーションがデータ処理を開始する前に Windows からタイムアウトの通知を受け取った場合、終了処理が実行され、メモリ内に 作業領域を確保していないにも関わらず存在しない作業領域を解放しようとして、業務 アプリケーションが異常終了する。

対応策

原因1への対応

・CPUがデータ処理中にハードウェア監視ツールからの状態確認が行われても、正しく処理(CPU でのデータ処理結果を耐タンパ装置へ返答)するように修正。 ・中継サーバに対し4/15(1台)、4/22(残り3台)に修正を実施。

原因2への対応

・メモリの確保状況を確認した上で、終了処理が実行されるよう、中継サーバの業務アプリケ ーションを修正。 ・中継サーバに対し4/15(1台)、4/22(残り3台)に修正を実施。

耐タンパー性というのは聞き慣れない言葉だったのですが、住民基本台帳カードの説明の資料がありました。
http://juki-card.com/security/security.pdf

tamper1 tamper2

しかし、こういうニュースが発表されました。

マイナンバーカード管理システムの遅延、5月2日も再び続出
2016/05/02

地方公共団体情報システム機構(J-LIS)が運営するマイナンバーカード管理システムが2016年5月2日、自治体にある統合端末から接続しにくくなったり、動作が遅い状態が再び続出していることが分かった。

カード管理システムについては、J-LISが16年4月27日に障害原因を公表して事実上の問題解消を宣言していた。しかし複数の自治体関係者によると、「午前中にJ-LISのサーバーにつながらずにタイムアウトと返ってくる」「複数台ある統合端末で、動きが鈍かったりエラーが返ってきて交付作業が滞る状態」という。

J-LISによると、「連休の谷間で自治体の窓口が混雑していると聞いている。カードの受け取りなどでシステムへのアクセスが急増したようだ」(情報化支援戦略部)という。システムの遅延が起きた自治体に地域差はなく、システムから弾かれたり、作業ができない状態が特に午前中に頻発したという。

カード管理システムは住民基本台帳ネット(住基ネット)と同じ通信回線を利用しているため、転居などに伴う自治体からの転入・転出の手続きで通信が急増したことや、JーLISによる問題解消の公表を受けてカードの交付を控えていた自治体からのアクセスやデータ量が増えた可能性を指摘する自治体関係者もいる。

一部の自治体では、4月末まで窓口での即日交付をやめて本人限定郵便で郵送したり、J-LISから自治体にカードが届いても実際にカード交付が可能になったことを伝える通知を小出しにして、窓口で市民を長時間待たせないように対応してきたという。しかし「起きている事象は変わらないので対応を変えられない」(関東の自治体関係者)といった不安の声も上がっている。

情報源:ITPro http://itpro.nikkeibp.co.jp/atcl/news/16/050201292/

マイナンバーをめぐる障害は、まだまだ続きそうです。

いくつかの記事を読んだ上で、2つ、指摘したい。

原因1については、連続したカードの書き込みや読み込みとハードウェア監視装置の連動なんていうのは、リリース前に必ずテストが行われる内容だと思う(本番と同じ環境によるカードの発行のテストを行うにあたって、ハードウェア監視だけは作動させないで行うとか、それは本番と同環境ではない)。ハードウェアの監視タイミングが11回しかないなんていうことはもちろんありえない。高速処理中だとしても、例えば何秒かに1枚のカードに対する処理が実行される際に、1回位テストでぶち当たりそうなものだ。しかしこれが行われていないようだ。どうやらシステム開発チームは、マイナンバーカードを数枚から数十枚くらいしか連続発行テストを行っていないのではないだろうか。

1時間あたりに何枚実際に発行できるのかテストしてから交付に対する備えをするにあたって、きっと10分間テストした結果とかを24時間(もしくは9時から18時の9時間)で算出した枚数を「発行可能枚数」としたのではないかと思うくらいだ。

なのでテスト不足。原因2は単なるプログラムのテストケースの不足だろう。

もう1つは、これを発見、報告、対応するのにあたって、1月に発見されてから(たぶん発生日時は不当に減らされている可能性を推察する)、4月になって修正対応が「終わった」ことを報告してくるなんて、なんて馬鹿にしているのか。

私はしがないアプリケーションエンジニアなので、こういうハード寄りの作業はしたことがない。しかし、テストの重要性を無視したスケジュール優先のシステム開発は絶対に成功しない。

しかも今回はテスト不足による失敗が、日本全体を巻き込んでいる。開発担当者はいったい何を思って作業を行っていたのか。はたまた「しかたない」「命令に逆らえない」と、こうなることは予期していたのか。

もし自分がこういうシステムをリリースした(してしまった)場合、どれだけ胃がキリキリすることか。ちょっと経験があるので開発担当者、現場の担当者には同情すると同時に、システムエンジニアが持っていてしかるべき情熱や倫理観、善良な管理者としての注意義務を思い出すタイミングなのではないだろうかと思った。

スポンサーリンク
hige1
hige1

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
hige1