個人情報保護委員会から年次報告が上がりました。

これによると、マイナンバーの漏洩件数は

６３機関から８３件となっています。

また、１００件以上のマイナンバー漏洩の重大事案は２件あったとのこと。

これだけでも多いと思う方がいるかも知れません。

ですが、氷山の一角ですね。

なぜなら、この数字。

３月末までの数字でしかありません。

年度末にマイナンバーの必要な帳票は限られますから、

年度内の収集を見送った企業も多いことでしょう。

また、個人情報保護委員会に報告するという

適切な対応を行った組織の数字です。

ですから、実際にはもっと多いでしょうし、

今はさらに増えているでしょう。

・・・マスコミは追及しませんね。

いまだに「個人情報に毛が生えたモノ」くらいに

考えているんでしょうか。

マイナンバーの話題が下火になって来てますが。

まだまだ、問題山積み（というか、積んだ山が崩れてるレベル）

の状態のようなんですけども。

マイナンバーカード発行システム、連休前に

原因特定して解消したって報道ありましたが

本当なんでしょうか？

「直った感じがしない」報道とか

「土日もカード発行をする」仙台市の報道とか

全然システム直った感じがしないのですけども。

そもそも、前回説明したトランザクション保護の問題。

アレ、本当に２件だけだったのでしょうか？

オンラインシステムの基本中の基本が

出来てない設計・開発部隊に見えるので

テストが疎かになっていて他にも同様のバグが

潜んでいるような気がしてなりません。

。。。まあ、それ以前のプライマリＩＤの話があるんだけども。

さて、ところで、三鷹市長のインタビュー記事を読みました。

マイナンバー制度の有効性とマイナンバーカードの普及は

別のモノとして、やれる行政サービスから始めて行く

と至極真っ当なことをおっしゃっています。

こういう地方行政のＴＯＰもおられます。

マイナンバーカードは棚上げして

“本来の”マイナンバー制度の有効活用から始める。

国がそう宣言してくれれば、

行政サービスへの有効性が認められて

マイナンバー制度への信頼も

少しづつ回復すると思うのですが。

国の余計な思惑が、

マイナンバー制度の足を引っ張りまくってます。

マイナンバーカード発行システムの障害原因の特定報告が

地方公共団体情報システム機構から発表されました。

原因は２つあって、こう説明されています。

【原因１】

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

【原因２】

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

ふむふむ。

て、これ読んで原因を理解できる方が省庁筋にどれだけいるんでしょう、

という話ですな。

わざとわかりにくく書いてるでしょう。ｗ

これ、結局ですね。

データのやりとりしてる時に応答が無くなったらどうするか、

ってプログラムがなくてじーっと待ってることになっちゃった

てことなのですよ。

ありえねぇ。

オンラインシステムでは、物理的に回線が切れるとか、

マシンが落ちるとか、停電が起こるとか

応答が無くなることは当然に発生します。

だから、応答が無くなったときに、それまでのやりとりを

成立させるのか、無かったことにするのかってロジックを

必ず入れるしテストでも確認するのですね。

じゃないと危なくてしょうがない。

これを「トランザクション」と言います。

オンラインシステムの基礎中の基礎ですな。

それに対し、

設計者も能力不足、

プログラマーも能力不足、

テスト担当も能力不足、

という「ありえねぇ」状態だったのです。

ちなみにISMSでは

管理策の要求事項に

「トランザクションの保護」と、そのものズバリなものが

あったりします。

関係した会社がISMS取得してたら、

完全に不適合ですな。

構築期間が短かったことを考慮しても

原因内容があまりに低レベルです。

困ったもんだ。

。。。。で、最も問題なハズの

プライマリＩＤのダブリの話が出てないんだけど。。。