マイナンバーカード管理システム障害の原因が判明 93
ストーリー by hylom
いまいち詳細が見えない発表 部門より
いまいち詳細が見えない発表 部門より
マイナンバーカード管理システムで不具合が発生していたことはすでに報じられているが、これら障害の原因が明らかになったという( 日経ITpro)。
原因は2つあり、1つは「暗号化・復号化を行うデバイスとの連携処理」と「ハードウェア監視ツールからCPUへの状態確認処理」が同一コアで行われると、暗号化・復号化デバイスとの連携処理が止まるというもの。もう1つは業務アプリケーションにおけるタイムアウト処理のタイミングによっては確保していないメモリを解放しようとし、アプリケーションが異常終了されるというものとのこと。
また、処理実行時のスレッド名が極端に長くなり、ログファイルへの出力処理に時間を要するという問題もあったという。すでにこれら問題は対処されており、またカード管理業務サーバーのメモリ割当量についても512MBから2GBに拡張したとのこと。
ややオフトピながら、マイナンバーの「仕様上の問題点」のひとつ (スコア:2, 参考になる)
デジタル・フォレンジック研究会 第404号コラム「マイナンバーのチェックデジットについて」
https://digitalforensic.jp/2016/03/14/column404/ [digitalforensic.jp]
末尾の数字がチェックサムになっていて、入力間違いを一定以上の確率で見つけ出せるようになっているが、末尾の数字がゼロだった場合、間違いを入力機器が検出する可能性が大幅に下がってしまう、という意味...でいいですかね?
そこでちょっとモンテカルロ法で調べてみたところ、個人番号の検査用数字は1桁誤りの約1.66%を見逃してしまうことが分かりました。この見逃しは検査用数字が0の時のみ発生しますので、この場合に限ると実に1桁誤りの約9.1%を検出することが出来ません。これではチェックデジットとしては失格と言っていいでしょう。
なんかよくわかんないけど (スコア:0)
ずいぶんと複雑なシステムなんですね。
Re:なんかよくわかんないけど (スコア:2, 興味深い)
複雑というよりは、「今どきのOSや開発環境では考えられない」問題のような。
前者は「デッドロック」に類されるトラブルでしょうが、お互いに同じ資源を奪い合っているのであればともかく、外部デバイスとのインターフェイス処理と内部的な処理でそれが発生するとは考えにくいですし、もしそうであるとしたら、「お前らテストしてないだろ」って言われても仕方のないくらい、根本部分のバグのような気がします。よく言われる「枯れていない」(=十分にフィールドテストされていない)環境で発生するトラブルと思われます。
後者は「不正ポインタ参照」に類されるトラブルと思われますが、こちらも十分にテストされた高水準言語を使用していれば、最初から避けられたトラブルのような気がします。
Re:なんかよくわかんないけど (スコア:2, 興味深い)
日経BPの絵をちょっと見たけど、確かにあまり普通のWebエンジニアにはお目にかからないものかも
中継サーバのレイヤー構成の中に耐タンパ層ってのがある。で、その中にドライバーという箱の絵もある。
つまり、暗号化・複合化処理っていうのはICカードの耐タンパ処理の(理論処理の)ことらしい。
なんでこれがデバイスドライバーなのかというと、それはつまりICカードメーカがソフトウェアライブラリは(リバースエンジニアリングされるから)出してくれないからだろう。
自分はIAサーバの物理ハードのデバイスドライバは書いたことないのでどれくらいの難易度なのかわからんが、すくなくともコピペすれば出来上がるものではなさそうだ。
ま、実際やれば色々苦労はあるんじゃないか。
この辺からどんどん想像になっていくけど、
そのデバイスドライバの割り込み処理が変で、割り込み入るとうまく動かないらしいね。
じゃぁ、CPU監視の割り込みを止めりゃいいんじゃないのか?毎日使えないよりましだろ?とは思うが。
なにより問題なのは時間がかかってることだよなぁ。そしてその原因が問題解決以外のところに時間使ったのが原因じゃねえのかよ?
ってところがなぁ。日本の技術力は落ちたなぁ。
Re:なんかよくわかんないけど (スコア:1)
日本の技術力は落ちたなぁ。
ネットワークサービス、特に公的機関の提供物に関しては元々高い技術力のイメージはないなあ。
洗練されたものを一発で作るよりも、泥臭く工数を掛けて実用に耐えうるように作っていく感じ。
Re: (スコア:0)
レイヤーの図は何かおかしいし、CPU監視は、ただのウォッチドッグタイマーじゃないかなぁ?
Windows Serverのwatchdogの挙動は良く知りませんが、メモリディスクの退避などのためにカーネルパニックしない設定もできるはず。
でも、ウォッチドッグタイマーとなると、因果関係が逆になるので、CPUを弄っても意味無いはず…。
Re: (スコア:0)
後者はマルチスレッド間のリソース共有という、超基本ができてなかったという問題に見える。
高水準言語でもロック機構使わずに回避は無理。
前者はわからないな。encrypt/decrypt deviceがDisable Interruptかけずに割り込まれて固まったようにも聞こえるけど、やっぱ記事からだけじゃわからん。
Re:なんかよくわかんないけど (スコア:1)
報道資料「カード管理システムの中継サーバに生じた障害原因の特定と対応について」 [j-lis.go.jp](PDF)から抜粋
原因2
(説明)通常、業務アプリケーションがデータ処理を開始する際に、メモリ内に作業領域を確保してから処理を行う。ところが、業務アプリケーションがデータ処理を開始する前にWindowsからタイムアウトの通知を受け取った場合、終了処理が実行され、メモリ内に作業領域を確保していないにも関わらず存在しない作業領域を解放しようとして、業務アプリケーションが異常終了する
#3006932 [it.srad.jp]が指摘するように不正ポインタ参照でしょうね。
ただ、終了時に開放リソースのnullチェックしてなかったってだけと思えるような説明だけども。
Re:なんかよくわかんないけど (スコア:2)
タイムアウトの通知を受けるよりも過去に、作業領域を確保するだけで済みそうな。
ケチるような場面でもないだろうし。
それと、常識的に考えて、データ処理とタイムアウト通知受けが別のスレッドで動く事は無い。
Re:なんかよくわかんないけど (スコア:1)
バッドノウハウを指摘されただけのようにも見える。
タイムアウトが来たらアプリは使用不能になる→どうせアプリ止めなきゃならないなら、不正処理例外で殺せば良いんじゃ?
ってパターンもあるかも?
一見トンでもないやり方に見えるが、リソース節減には有効だったりするし。
-- Buy It When You Found It --
Re:なんかよくわかんないけど (スコア:1)
アゴがっくん。
そんな方法があるなんて、思いもしなかった。
目にウロコがはまった。
Re: (スコア:0)
ぬるぽっ!
今時スレッドセーフ意識しないで組むとか有り得ないw
「数(人月)だけ間に合わせ」てシステム組んだんだろうなぁ。
そして、個々のスキルは考慮外と。
炎上するフラグしか見えない…
Re: (スコア:0)
ガッ
#「ぬるぽっ!」って題名のマンガないのかねぇ
Re: (スコア:0)
そのPDFによると、コーナーケースのようですね。
>①タイムアウト通知とタイマリセットが同時に発生した場合、Windowsの仕様上、タイマリセットが行われない場合がある。
>②この場合、タイムアウト通知が保持されたままとなり、アプリケーションがデータ処理開始前にタイムアウト通知を受け取る。
nullチェックだけで防げたかというと、どうでしょう。終了処理とタイムアウト通知が運悪く重なると、タイミングによってはnullチェックも突破しそうなような…。いや、でも、図のように終了処理の後までタイムアウト通知を保持するのかなぁ?
処理完了の前にビジーになると「同時」でなくてもメッセージが溜まる (スコア:2)
ソースコード実物を見ないと分かりませんが、この説明はおそらく図のほうが正しく(実挙動に近く)、文章の方が不正確です。
「タイマリセット」に使っているのは、多分このAPIでしょう。
https://msdn.microsoft.com/ja-jp/library/cc410876.aspx [microsoft.com]
とあります。これはWindows罠仕様の一つです。
「タイマリセットが行われない場合がある」ではなく、KillTimer関数が呼ばれるまでの間にタイムアウトすると、タイムアウトのメッセージが削除されない事による現象です。
これ、もう一つ罠があって、『中継処理の完了』メッセージを受け取る前のタイミングで何か別の処理が走りだしてビジーになっていて、『中継処理の完了』メッセージが保留されていると、その間にタイムアウトする可能性があるって事なんですね。
ですので、この問題が発生するタイミングは「同時に発生」どころか、数秒(数分)に渡る可能性があります。
(遅延がひどいと2度も3度もタイムアウトを受け取ります。タイマはリピートするので)
レアなケースではなく、運用環境では頻繁に起きるものと考える必要があります。(そして実際起きた)
Re: (スコア:0)
# 複数雑なところがあるシステムだって皮肉なのでは。。。
Re: (スコア:0)
複雑というよりは、「今どきのOSや開発環境では考えられない」問題のような。
うん、単純に組んでいればこんなこと起きないかなと。なので随分と複雑だと思いました。
Re:なんかよくわかんないけど (スコア:1)
マイナンバー中枢システムはNTTコムなど「大手5社連合」が異例の落札、114億円で
http://itpro.nikkeibp.co.jp/article/NEWS/20140331/547394/ [nikkeibp.co.jp]
> NTTコミュニケーションズを代表とし、ほかにNTTデータと富士通、NEC、日立製作所が参加するコンソーシアムが落札した。
開発も複雑そう。
Re:なんかよくわかんないけど (スコア:1)
政府が日本企業のレベルを正しく認識するのはいつの話だろうか。
Re: (スコア:0)
騒がしくなってきたので素人が反論できそうにないそれらしい理由を挙げてみただけ。
判明したとは言うけどー (スコア:0)
ニュース - マイナンバーカード管理システムの遅延、5月2日も再び続出:ITpro [nikkeibp.co.jp]
なんて状況みたいだけど。
Re: (スコア:0)
「よしわかった! 犯人は◆■▲だ!」
よくある事だけど、障害対応する時は落ち着いて検証しましょうね。
BIOSとは (スコア:0)
BIOSがCPUに処理通知をし、CPUが返した処理結果を受け取るとなっていますが、このBIOSは何者なんです?
普通のPC/ATならBIOSが勝手に処理を行うということはないと思うのですが。
Re: (スコア:0)
担当した技術者は原因を的確に絞り込むほどの技術はもたず、説明を受けた広報担当は勝手な解釈で超高度な技術用語(と自分が感じた単語)を並べて外野を煙に巻いたつもりとか。
でなきゃここまで論理性の欠如した発表文にはならないんじゃないかと。
Re: (スコア:0)
今どきのPCやそこから派生したシステムの場合、BIOSはOSが起動するまでの手続きを実施するだけの仕組みですが、その昔はBIOSが提供する様々な機能を直接利用してシステムを構成していました。 PC/AT互換機 [wikipedia.org] の場合はMS(PC)-DOSがその代表例で、これによってMS-DOSの時代でもある程度のハードウェア抽象化を実現できていたわけです。
おそらくは今回の「サーバー」と呼ばれるものも、一般的なPCサーバーではなくて、昔ながらの汎用機やオフコンに属するものだったのではないでしょうか。
Re:BIOSとは (スコア:2)
「今回のシステムはセキュリティが重要だ。信頼できる国産品を使うんだ」とか仕様書にあって、98シリーズを使い、N88Basicでサーバー組んでたりして(メモリのサイズであり得ないよね、ねっ)。
>昔ながらの汎用機やオフコンに属するものだったのではないでしょうか。
汎用機にしても、オフコンにしても、よほど古い考えで無ければ、現代的になってそうな気が・・。
Re: (スコア:0)
> >昔ながらの汎用機やオフコンに属するものだったのではないでしょうか。
> 汎用機にしても、オフコンにしても、よほど古い考えで無ければ、現代的になってそうな気が・・。
国内系の汎用機やオフコンって、旧世代で時間が止まっちゃってますよ。
海外勢とは違って保守で儲かる構造になっていることから、
古いシステムを後生大事に使いがちで、新しい技術者も入ってこないので
昭和の時代で時が止まっているところが多いです。
それでも中途半端にTCP/IPを喋ったりするので、
「信頼できる国内メーカーを」「実績と信頼が第一」など、営業に騙されて
買っちゃって痛い目を見ている企業や官庁が後をたちませんが・・
国内メーカーで生き残ってる汎用機/ミニコンって何がある? (スコア:1)
富士通とか日立でIBM互換機って、まだ作ってるっけ?
(ミニコンとなると、思いつかない。)
/*
ACOSは、うちの組織では現役です。運用担当にデータ出力をお願いをするたび、内容からN88Basicのマニュアルを連想してしまう。
Re: (スコア:0)
BIOSのないコンピュータというと、それこそENIACぐらい
しかないぞ。
Re: (スコア:0)
Basic Input/Output System
基本的な入出力をやっていれば、何を指していても
まあ間違いではない。
Re: (スコア:0)
今ならUEFI BIOSですが、起動時の各デバイス設定以外にも、OS走行中にちょっとしたアレだのコレだのの裏処理に刈り出されることがあります。
CPUの設定を修正することで対策とは (スコア:0)
CPUの何の設定でしょうか? 特権レベルなど何らかのモード切替的な機能が影響している?
単純にソフトウェアの不良のような感じがするんだけど、図や説明を見ると明らかにハードウェア的な部分の設定が問題だったようです。
単にソフトウェア不良なんだけど、CPUが原因だったように見せているだけ?
Re: (スコア:0)
PCのBIOS設定でマルチコアを無効化したんですよ!
※今時そんな設定は無いだろうな
Re: (スコア:0)
HyperThreadingをOFFで対策とかいかが?
Re: (スコア:0)
プログラム毎に実行するコアを指定することで同じCPU内でプログラムが実行されないようにする。
確かにWindowsの標準機能で出来ますね・・・・・
#いやまさか
Re: (スコア:0)
SetThreadAffinityMask, SetProcessAffinityMaskかな?
RDTSC使う時とか必要になりますね
Re: (スコア:0)
メモリを変更した量(512MB→2GB)からみて、VM なんじゃないですかね。
という訳で CPU を 1コアにするのも簡単でしょうが、
「同一コアで行われると、暗号化・復号化デバイスとの連携処理が止まる」のだから
対策が反対ですね。
原因が分からないからロック用のコードを除去してシングルスレッドでしか動かなくした
という「対策」か?
Re: (スコア:0)
CPUが1つのチップだけで構成されていると誰が定義した?
Re: (スコア:0)
割り込みマスクを変更して、その場しのぎしていないことを祈る…
つまり (スコア:0)
マイナンバーカード管理システムがまーなんだ、ガタガタ管理システムだったって事ですね?
まだカードの申請してない (スコア:0)
連休中にやろうかと思ってたけど、まだやってないな
Re:まだカードの申請してない (スコア:1)
同じく。惨事が収束するのを待つ。
Re: (スコア:0)
うち申請出したのはいつだっけかな。
1月だったような。
まだ届いてませんが。
Re:まだカードの申請してない (スコア:1)
Re: (スコア:0)
12月中頃に出して4月頭だったから、年明け組は相当先になると思うぞ
Re:まだカードの申請してない (スコア:1)
カード管理業務サーバーのメモリ割当量についても512MBから2GBに拡張 (スコア:0)
いかにもjvm起動オプションの値を変えましたって感じだけど
ここって官公庁ウォーターフォール工程的にだれが責任とるところなんだ?
Re:カード管理業務サーバーのメモリ割当量についても512MBから2GBに拡張 (スコア:1)
責任もウォーターフォール行程的に元請けから子請け、孫請けに丸投げされて雲散霧消します。
Re:カード管理業務サーバーのメモリ割当量についても512MBから2GBに拡張 (スコア:3, すばらしい洞察)
責任が雲の上Re:カード管理業務サーバーのメモリ割当量についても512MBから2GBに拡張 (スコア:1)