2024年7月21日

BSoD (2)

世界的に発生したBSoDの障害原因が特定されて、修正された当該ファイルの配布も始まり徐々に修復されているようですが、なんと言っても対象デバイスの数が膨大で完全に修復されるまでは更に数日は必要という話も。どうも"NULL"チェックをせずに、NULLが含まれる可能性のある変数で演算処理をして問題が発生するらしいけれど、何だかなぁ。普通は初期化処理で全ての変数に初期値を何か設定しないか? 途中で一時的に生成するローカル変数だって、先ずは何か(1とか)値設定するだろうし。往々にして、大きな問題を引き起こす時の原因って、本当に些細なと言っては怒られるかもしれないけれど案外単純なミスの見逃しだったりするんですよね。 

引き起こされる問題の原因が単純だからといって、その問題修復の作業も単純なわけでは無くかえって難しく面倒になるもの。今回もWindows起動時に読み込まれるファイルだけに、修復するにはWindowsの起動が必要で起動したらエラーに成るしで、あるいみデッドロック状態。だから修復するには、何らかの方法で内部のOSを起動せずに外部から起動する方法が必要で、その一番手っ取り早いのが前回も書いたブータブルUSBを準備して、そこから対象機器を起動して問題のあるファイルを差し替えるというもの。ただその為にはその物理的USBメディアを対象機に挿入して電源操作をしないといけないので、1台2台なら兎も角、何十何百万台となるとちょっと目眩がします。当然その機会が目の前にあって、ベルトコンベアーで流れ作業で出来る分けでも無く、人海戦術でその場所へ出かけて一つ一つ処理しないといけない。一人の作業員がもしかしたら一日に一台程度しか対応出来ないかもしれない。

それでも少しだけ救いがあるかなと思うのは、今回の問題はサーバー機器での発生も多いと思うのですが、最近のサーバー機器にはインストールされたOSとは別に、本体だけで電源のON/OFFからHDD/SSDへアクセスしてソフトウェアのインストールも出来る仕組みが入っています。極端な例では、離れた場所に設置されたOSも何も入っていないサーバーを、最初に起動してBIOS設定画面に入り、そのサーバーのBIOS用の固定IPアドレスを設定してアクセス用にID/PWを登録しておき、且つネットワーク設定と接続も設定しておけば、後はリモートからそのサーバーにアクセスして本体の電源ON/OFFからソフトのインストール、その他機器の設定変更やソフトの更新等も自由に実行すること事が出来ます。そこまでで無くても、Linux OS等をインストールしたUSBを早着して、そこから起動する仕組みが有るものも有りますよね。そういう仕組みを利用すれば、わざわざ現地へ出向かなくても、リモートで対応出来るデバイスもそれなりに存在しそう。

ただ、今回影響を受けているPOS端末とかIoTデバイス等は、セキュリティポリシーからそういうバックドアになりそうなリモートアクセス機能は利用していないだろうから、やはり一台一台手作業での対応が必要になるんじゃないかな。仮に可能であっても、悪用されないように公開されないかもしれないし。その分、コストも掛かるので可能であってもその機能を削除するとか使用不可にしているケースも多いだろうし。この辺り、私も昔保守関係の仕事をしていたことがあるので良く分かるんですが、結局はお客様側の要求内容と、保守する側の要求内容のぶつかり合いみたいなところもあるんですよね。それにお客様としては「壊れないことが前提なのに、何で壊れた時の話をするのか。しかもそれなりのお金が必要とは何故?」みたいな気持ち何ですよね。いゃ、そうなんですけどね、そうなんですけれど、想定と現実は大きく違う物として対策して置かないと、結果的に一番被害を被るのはお客様ですよと言いたいのだけれど、言ったら最後「責任転嫁」と怒られそうだし。知らない間に社会基盤化しているこの手の「見えないサービス」の安全性だったり可用性だったりと言う事を、もっと真剣に考えないといけませんね。まぁ、結果的にメーカーが頑張るしか無いのだけれど、エンドユーザー側としてはユースケースなりテストケースなりを充実させるしか無いのかなぁ。やっぱり、昔から有る話の一つだよなぁ、規模が違うだけで。

0 件のコメント:

コメントを投稿