第三話 サーバーを止めるべきか
第三話 サーバーを止めるべきか
午前零時四十分。
サイバーナイト株式会社の会議室には、最高情報責任者の黒木厳と、関係部署の担当者たちが集まっていた。
画面には、確認作業の進捗が表示されている。
管理先がわかったシステム。
PHPのバージョンを確認できたシステム。
修正の方法を問い合わせているシステム。
そして、まだ管理者すら特定できていないシステム。
一覧は少しずつ埋まり始めていたが、すべての項目が確認できたわけではなかった。
「まず、今回の問題について、技術的な仕組みを整理します」
黒木は会議の参加者を見回した。
「そのうえで、現時点でわかっていることと、まだ確認できていないことを説明します。停止するか、継続するかについては、それぞれの影響を踏まえて、会議で判断していただきたいと思います」
彼は、画面を切り替えた。
【ウェブサイトは、何でできているのか】
表示されたのは、簡単な構成図だった。
・利用者のスマートフォンやパソコンから、インターネットを通じてウェブサイトにアクセスする。
・そのアクセスを受け付けるのが、ウェブサーバーだ。
・ウェブサーバーは、利用者からの要求を受け取り、必要な処理を行い、結果を返す。
・しかし、会員ページや予約画面のように、利用者ごとに異なる情報を表示する場合、ウェブサーバーだけでは仕事が終わらないことがある。
・そこで登場するのが、アプリケーションと呼ばれるソフトウェアだ。
・アプリケーションは、会員情報を確認したり、予約を登録したり、商品の在庫を調べたりする。必要に応じて、データベースと呼ばれる情報の保管場所に問い合わせる。
・データベースには、会員情報や商品情報、予約記録などが保存されている場合がある。
・そして、アプリケーションを動かすための仕組みの一つが、PHPだった。
黒木は、図の上から順に説明した。
「大まかに分けると、利用者からのアクセスを受け付ける部分、ウェブサイトの処理を行う部分、データを保存する部分があります。PHPは、そのうち、ウェブサイトの処理を実行するために使われる言語の一つです」
参加者の一人が尋ねた。
「では、PHPに問題があれば、ウェブサイト全体が危険になるのですか」
「影響の範囲は、問題の内容とシステムの構成によります。PHPの脆弱性が、ウェブサイトのプログラムより手前の段階で悪用される可能性もあります。一方、すべてのサイトが同じ条件で影響を受けるわけではありません」
黒木は、言葉を区切った。
「ですから、PHPを使っているというだけで、すべて危険だと決めつけることもできません。逆に、画面が表示されているから安全だとも言えません」
【システムが動いていることと、安全であることは別なのだ。】
会議室は静かになった。
◾️脆弱性は、どこにあるのか
「もう一つ、区別しておきたいことがあります」
黒木は、構成図の横に三つの項目を表示した。
・ 一つ目は、ウェブサーバーやPHPの実行環境。
・ 二つ目は、PHPを使って作られたウェブサイトのプログラム。
・ 三つ目は、データベースや、ほかのサービスとの接続部分。
「脆弱性という言葉は、ソフトウェアやシステムに存在する弱点を指します。ただし、弱点が見つかった場所によって、修正する担当者も、必要な作業も違います」
ウェブサーバーやPHPの実行環境を管理する会社がある。
ウェブサイトのプログラムを制作・保守する会社がある。
データベースや認証システムを別の部署や事業者が管理している場合もある。
それぞれの担当範囲が分かれていれば、問題が起きたときに、一社だけですべての対応を終えられるとは限らない。
「今回のPHP問題では、まず、影響を受けるバージョンを使っていないかを確認する必要があります。影響を受ける場合には、修正済みのバージョンへ更新することが基本です」
「更新すれば、それで終わりですか」
別の参加者が尋ねた。
「いいえ。更新したあと、正常に動くかを確認する必要があります。それから、更新前に不正なアクセスがなかったかどうかも、別途調査しなければなりません」
黒木は、三つの作業を示した。
* 脆弱性の影響を受けるか確認する。
* 必要な修正を適用し、正常に動作するか確認する。
* 修正前に攻撃を受けていなかったか、ログなどを調査する。
「この三つは関連していますが、同じ作業ではありません。修正が完了しても、過去に侵入されていなかったことまで自動的に証明されるわけではありません」
会議の参加者たちは、画面を見つめていた。
脆弱性への対策は、プログラムを新しくするだけの作業ではない。
影響範囲を特定し、修正し、検証し、必要な調査を続ける。その一連の作業だった。
◾️サーバーを止めれば、安全なのか
「では、修正が終わるまでサーバーを止めてしまえばよいのではありませんか」
参加者の一人が言った。
もっともな質問だった。
黒木は、すぐには答えなかった。
「停止によって、外部からのアクセスを遮断できる場合はあります。修正をすぐに適用できず、危険を十分に減らせない場合には、サービスを一時的に外部から切り離すことも選択肢になります」
「それなら、止めたほうが安全なのでは？」
「停止することにも、影響があります」
黒木は、画面に新しい項目を表示した。
ウェブサイトを停止すれば、利用者はアクセスできなくなる。
通販サイトなら、注文を受け付けられないかもしれない。
予約システムなら、予約や変更ができなくなる可能性がある。
取引先との連携に使われているシステムなら、相手側の業務にも影響が及ぶことがある。
金融サービスであれば、利用者が必要な取引を行えなくなることもある。
もちろん、サービスの継続によって生じる危険が、停止による影響を上回る場合もある。
だから、単純に「止めればよい」「動かしておけばよい」と決めることはできない。
「停止するかどうかを考えるには、少なくとも、脆弱性の影響を受けるか、修正できるか、どのような防御策が取れるか、停止した場合にどのような影響が生じるかを整理する必要があります」
黒木は、ここで強調した。
「技術的に可能なことと、会社として選択すべきことは、分けて考える必要があります」
◾️一時的な防御策とは何か
「修正がすぐにできない場合、ほかに方法はないのでしょうか」
質問を受け、黒木は一時的な防御策について説明した。
たとえば、システムの構成によっては、外部からのアクセスを制限することができる。
特定の通信だけを許可したり、公開範囲を狭めたり、ウェブアプリケーションファイアウォールを利用して、危険な通信を遮断したりする方法もある。
ウェブアプリケーションファイアウォール、略してWAFとは、ウェブサイトに向けられた通信を検査し、設定されたルールなどに基づいて、不審な通信を遮断する仕組みだ。
ただし、WAFを設置すれば、あらゆる脆弱性を防げるわけではない。
問題となっている脆弱性に対応できるルールがあるか。攻撃に使われる通信を適切に識別できるか。正規の利用者まで遮断してしまわないか。確認すべきことがある。
また、アクセス制限によってサービスの一部が使えなくなることもある。
「一時的な防御策は、修正そのものの代わりにはなりません。どのような方法が有効かは、脆弱性とシステムの構成を確認したうえで判断する必要があります」
黒木は、さらに続けた。
「修正できないからといって、何もできないとは限りません。ただし、何らかの対策を実施したという事実だけで、安全が保証されるわけでもありません」
◾️ わからないシステムを、どう扱うか
会議の画面に、前の晩から更新しているシステム一覧が表示された。
確認済みの項目が増えていた。
しかし、管理者がわからないもの、バージョンを確認できていないもの、外部事業者からの回答を待っているものも残っている。
「問題は、こうした未確認のシステムです」
黒木は言った。
「影響を受けると確認できたシステムと、影響を受けるかどうか判断できていないシステムは、同じではありません」
未確認であることは、脆弱性の影響を受けているという証拠ではない。
しかし、影響を受けていないという証拠でもない。
どのサーバーで動いているのか。
どのバージョンを使っているのか。
誰が管理しているのか。
すぐに修正できるのか。
確認できない理由は、それぞれ異なるかもしれない。
「確認できていないシステムについては、まず管理者と構成を特定する必要があります。そのうえで、外部からアクセスできるか、影響を受ける可能性があるか、どのような対策が取れるかを確認します」
「全部止めるわけにはいかないのですか」
「停止することによる影響も、システムごとに異なります。事業への影響を確認せず、すべてを一律に扱うことはできません」
黒木の説明は、慎重だった。
それは、決断を避けているからではない。
情報が不足している部分を、確かな情報であるかのように扱わないためだった。
◾️会議が決めること
午前一時を過ぎたころ、会議は対応方針の検討に入った。
確認済みのシステムについては、影響の有無と修正の可否を整理する。
修正が可能なものは、適用手順と動作確認の方法を確認する。
すぐに修正できないものについては、利用できる一時的な防御策と、その限界を確認する。
停止が必要になる可能性のあるシステムについては、停止による事業への影響も整理する。
ログの調査は継続し、攻撃の痕跡が見つかった場合には、別途、インシデントとしての対応を検討する。
そして、管理者や構成がわからないシステムについては、確認の担当者と期限を明確にする。
黒木は、それぞれの選択肢について、技術的に可能なこと、現時点でわかっているリスク、残された不明点を説明した。
最終的な方針は、会議で決められる。
あるシステムを継続するのか、制限を設けるのか、一時停止するのか。
それぞれの判断には、技術的な安全性だけでなく、事業への影響や利用者への責任も関係していた。
会議は、確認された情報をもとに、システムごとの対応を検討していった。
すべての問題に、同じ答えがあるわけではなかった。
◾️修正と復旧は、同じではない
会議が続くなか、黒木は最後に一つの点を説明した。
「修正プログラムを適用できたとしても、その時点で、すべての確認が終わるわけではありません」
修正後の動作確認が必要だ。
ログの調査も続けなければならない。
不審な動きが見つかれば、影響範囲を調べ、必要な対応を取ることになる。
さらに、システムを再開する場合には、どの機能が正常に動作しているか、残っている制約は何かを確認する必要がある。
「復旧という言葉だけでは、何が確認できたのかがわかりません。修正済みなのか、動作確認済みなのか、調査が継続中なのか。それぞれを分けて報告する必要があります」
会議の参加者は、うなずいた。
一つのシステムが動き始めたとしても、別のシステムの調査が終わっているとは限らない。
ウェブサイトが表示されるようになっても、過去の侵入がなかったことまで確認できたとは限らない。
安全性の確認には、段階がある。
黒木は、画面に残された未確認の項目を見た。
この夜の仕事は、すべてのサーバーを一斉に停止することでも、何事もなかったかのようにサービスを継続することでもない。
何がわかっていて、何がわからないのか。
どの対策が有効で、どこに限界があるのか。
その情報を、組織が判断できる形にすることだった。
会議は続いていた。
そして、まだ確認できていないシステムが、一覧には残っていた。
