さて、昨日は緊急の寄稿でした。とてつもないセキュリティ事故が起こったものです。このテンションの中で平常運転に戻るのも何なんですが、既に下書きは出来ていまして。引き続き「2018年のセキュリティ事件ランキング」です。

前記事はこちら。というか、10位まで用意しないつもりなんですけど、途中でランクインするネタが増えてきたら困るなぁ。

差し込み1位：PayPayはクレジットカードのセキュリティコード問合せシステムだった
https://newspicks.com/news/3539004
1位改め2位：HUAWEIが「安全保障上の脅威」だと言うけれども
https://newspicks.com/news/3534364
2位改め3位：統制不能な外部委託先リスク
https://newspicks.com/news/3535521
3位改め4位：仮想通貨じゃなくてブロックチェーンが危ない
https://newspicks.com/news/3537064

そして今日の話。僕ソフバンユーザなのでここのグループばかり挙げるのは本意ではないのですが。。。

5位：大規模ネットワーク障害（ソフトバンク、ANA）
ソフトバンクがつい最近、大きな通信障害が起きたことは記憶に新しいですね。また、ANAも丸一日、予約関係のシステムが動かなくなったという話もありました。どちらもネットワーク機器に問題が発生したことで問題が起きたそうです。

あれ？あれってサイバー攻撃だったの？

違います。どちらもネットワーク機器のバグなんだそうです。しかし、セキュリティというのは個人情報や仮想通貨が盗まれるといった被害だけではなく、サービスが止まらないようにする「可用性」を確保する活動も含まれています。それが担保できなかったわけなので、やはりセキュリティ障害なんです。

実際、セキュリティの現場でよく話題になり、そしてなかなかうまくやれていないのが「パッチマネジメント」という活動。ネットワーク機器、というのは要するに皆さんの家にあるルータだと考えてもらえばいいのですが、これらにもPCと同じくハードウェアとソフトウェアの両方が備わっています。

で、ハードウェアが古くなったり故障したりしたら機器の交換をするのですが、ソフトウェア側は時折脆弱性が発見されます。これを閉じるため、または新しい技術に対応したりするためにソフトウェアを更新します。更新はものによっては製造元に送って行う場合もありますが、今では多くがネットからソフトウェアをダウンロードして自分でインストールできたり、インストール自体も勝手に行ってくれたりします。

で、この更新プログラムをパッチと呼ぶのですが、パッチをインストールすることで予期しない不具合が起きてしまう場合もあることから、特に安定的な運行が必要なシステムに関するパッチについては、慎重に検証を実施してから適用しています。

システム部の人たちは、リリースされたパッチが何を直すものなのかを確認して、関係が無いものは適用を除外したり、優先度が低いものは適用を延期したりします。重要度が特に高いパッチは大急ぎで検証して適用を行ったりしています。パッチマネジメントというのは、そのパッチ適用に関するサイクルを管理する活動のことを言います。

パッチマネジメントの対象は、OSだけではなくネットワーク機器、Officeソフト、Webブラウザ等々、システムに係るすべてに及びますから、それを本来あるべきレベルで管理するというのはとても大変なことなんです。

これが大変すぎるから、まるっとこの辺をアウトソースすることが出来るクラウドは良い仕組みなんですよねって話は今回の主題からそれますので省略します。

で、ネットワーク機器のパッチマネジメントは特に大変なんですよ。理由は「完全な検証環境が作れないから」です。

一般的に、PCやその中にインストールされているシステム、さらにはERPや基幹システムなどの業務用ソフトについては、本番環境とテスト環境、時にはステージング環境というものが用意されます。新規機能や修正版が盛り込まれた更新ソフトウェアは、テスト環境で様々なテストを実施し、ステージング環境で本番とほぼ同じセッティングとデータでの最終確認や、ソフトウェア適用作業のチェックを行います。こうして、問題なく稼働することを確認してから、利用者が直接使う本番環境に適用します。いきなり本番一発、みたいな危ないマネはしないのです。普通。

Facebookはやってるっていうシンジラレナイ話も聞きますが。。。

で、話は戻ってネットワーク機器。これ、ステージング環境を作るのが無理なんですよ。詳しくは説明しませんが仮想化という技術もあるので、それなりには検証用の環境を用意できなくも無いです。が、世界中に張り巡らされたネットワークを、本番とは別に１セット用意することなんて、とんでもないコストがかかってしまうので事実上不可能です。したがって、どうしても業務系ソフトウェアのように本番環境とほぼ同じセッティングの環境（＝ステージング環境）でテストを行うことはできないまま本番リリースを行うことになります。

で、そうなると「不具合の無い完璧なソフトウェア更新」などというものは不可能なのですが、それでも障害が発生すると今回のように影響の甚大なものが起き得るので、出来るだけ障害を最小化しなければいけません。

これには通常「冗長化」というアプローチが取られています。一部のパーツに障害が起きても、代わりとなるパーツが機能すれば問題ないようにすることです。ネットワークを登山道だとすれば、ルート１でがけ崩れが発生しても、ルート２で頂上を目指せればいいのです。そのために、あえて”余り”の道をもう１つ作っておくのです。これが冗長化です。

ところが、ルート１と２の分岐前の登山道でがけ崩れがあったら、頂上には行けませんね。なので通信事業者のような大規模ネットワークを組む事業者は、このような場所を作らないようにネットワーク構成を組んでいくわけです。

ところが、ネットワーク機器に不具合があった場合、以下のような理由によって障害の影響を大きくする可能性があります。
①　その機器がメジャーな機器であり過ぎて、あまりにもあちこちに導入されているので障害も同時多発的に起きる
②　障害を回避した先（ルート２）に対して、許容量を超えた通信が来ることで大幅に速度が劣化する
③　ユーザが「あれ、遅い！」と、ボタンを連打したりしてパケット量がいつもより増えてしまう

ソフトバンクの件はエリクソン社、ANAの件はCisco社の機器だったそうで、どちらも大変メジャーな機器ですね。①が起きていた可能性があります。②③は小さなネットワーク障害でも起きているのですが、大規模障害になってしまう時は①も発生している可能性があります。

ちなみにルート２は待機系と言われ、要するに緊急時しか使わないのでルート１よりもスペックを落としている、つまり”道が狭い”のが普通です。早くルート１を復旧させることが前提です。

そして、対サイバー攻撃の観点では、この①の部分が存在するシステムは非常に危険なんですね。もし、①のような機器に脆弱性があったら、一斉に世界中の機器が攻撃されて大規模ネットワーク障害が起きてしまう可能性があるのです。なので、この２つの大きな事故は、たとえサイバー攻撃を受けて一部の機器が止まったとしても、その被害を最小化するために足りない箇所があることを明らかにしたということでもあります。

で、このシリーズの1位（改め2位）をなぜHUAWEIの話にしたのかというと、この危惧もあるからなんです。メジャーな調達先を1つ減らすということは、まさにこの①の問題が起きる可能性を高めることになりかねない。得体のしれないものが怖いのはわかりますが、排除したらしたで、別の巨大なリスクを背負うことになるってことです。

本日はここまで。まだ続きます。