第三話 見えないシステム
第三話 見えないシステム
午前九時。
佐伯が出社すると、調査チームの会議室には、すでに何枚もの資料が並べられていた。
中央のモニターには、影響を受けているサービスの一覧が表示されている。
ポイントサービス。
クーポン配信サービス。
企業の公式ウェブサイト。
会員向けの情報提供ページ。
それぞれ運営する会社も、利用者も、システムの構成も違う。
しかし、どこも利用者に対して、明確な復旧時刻を示せていなかった。
「昨日からの調査結果を報告します」
佐伯は、手元の資料を開いた。
「公開されているプログラムと、こちらで確認したアクセス記録には、調査を続ける価値のある共通点があります。ただし、現時点で、すべての障害が同じ攻撃によるものだとは断定できません」
「原因が共通しているかどうかも、まだわからないということか」
上司が確認した。
「はい。個別に調べる必要があります。ただ、もうひとつ、気になる問題が出てきました」
佐伯は画面を切り替えた。
そこには、調査対象となったシステムの管理状況が一覧になっていた。
「資産管理の情報が、不十分なんです」
「資産管理？」
若手の調査担当者が聞き返した。
「サーバーやソフトウェア、外部サービス、それぞれの管理責任者。どこで何が動いているのか、誰が管理しているのか。その情報です」
「そんなものは、会社にあるんじゃないですか」
「あるはずです」
佐伯は、静かに答えた。
「ただし、あることと、現在の実態に合っていることは別です」
＊
調査チームは、関係するシステムの管理資料を集め始めた。
最初に問題になったのは、古いウェブサイトだった。
会社の公式サイトは、数年前に外部の制作会社へ委託していた。制作した当時の担当者は、すでに退職している。運用を引き継いだ部署は、日々の更新を行っていたが、サーバー内部の構成までは把握していなかった。
「ウェブサイトが表示されているなら、問題ないと思っていたんでしょうね」
若手が資料を見ながら言った。
「表示できることと、安全であることは同じじゃない」
佐伯は答えた。
「普段は何事もなく動いていても、使っているソフトウェアが古いままかもしれない。更新が止まっているかもしれない。管理者が変わったあと、誰も確認していない設定が残っている可能性もある」
「でも、外部に委託しているなら、委託先が管理しているんじゃないですか？」
「どこまでを委託しているか、契約を確認しないとわからない」
佐伯は、資料の一行を指さした。
「サイトの文章や画像の更新だけなのか。サーバーの管理までなのか。ソフトウェアの更新も含まれるのか。それぞれ違います」
別の資料には、さらに古いシステムの記録があった。
担当部署の名称は、組織改編前のものだった。
問い合わせ先の担当者は、すでに異動している。
管理台帳には、システム名だけが記載され、使用しているソフトウェアのバージョンは空欄だった。
「これでは、脆弱性の影響を受けるかどうかも、すぐには判断できませんね」
若手が言った。
「そういうことだ」
佐伯はうなずいた。
「使っているソフトウェアがわからなければ、影響の有無を確認できない。影響の有無がわからなければ、どの対策が必要なのかも決められない」
上司が腕を組んだ。
「攻撃を受けてから、管理台帳を作り直しているようなものか」
「残念ですが、そういう状態の組織は、ひとつではないかもしれません」
＊
昼過ぎ、佐伯たちは、外部事業者が管理するシステムについて、追加の確認を依頼した。
返ってきた回答は、すぐには役に立たなかった。
ある事業者は、対象となるソフトウェアを確認中だと答えた。
別の事業者は、現在の契約範囲では、サーバー内部の詳細な調査に時間が必要だと説明した。
また別のシステムでは、ウェブサイト本体とは別に、問い合わせフォームや会員向けページが異なる環境で稼働していることがわかった。
「同じ会社のサイトなのに、別々なんですか」
若手が驚いた。
「見た目がひとつでも、裏側までひとつとは限らない」
佐伯は説明した。
「本体は自社で管理していても、フォームは外部サービス。会員ページは別のシステム。画像だけ別の配信サービスを使っていることもある。利用者には見えない部分で、複数の事業者やシステムがつながっているんだ」
「それじゃあ、どこかひとつに問題があっても、全体を止めることになるんですか？」
「必ずそうなるわけじゃない。ただ、安全を確認できない部分があれば、その部分を切り離すか、機能を制限するか、サービス全体を止めるか。影響を考えて判断する必要がある」
佐伯は、モニターに表示されたサービス一覧を見つめた。
利用者にとっては、ただのウェブサイトだ。
ボタンを押せば、ポイントが確認できる。
クーポンを表示すれば、店で割引を受けられる。
会社名を検索すれば、公式サイトが開く。
それだけのことだった。
しかし、その簡単な操作の向こう側には、複数のサーバー、ソフトウェア、外部事業者、管理契約、更新作業が存在している。
そして、その全体像を、誰も一度に把握できているとは限らなかった。
＊
午後四時。
上司が会議室のホワイトボードに、三つの項目を書き出した。
**第一に、何が動いているのか。**
**第二に、何が影響を受けているのか。**
**第三に、どこまで安全を確認できたのか。**
「この三つを整理しないまま、復旧の話はできない」
上司は言った。
「攻撃を受けた可能性があるからといって、すべてを一律に止め続ければいいわけではない。一方で、動かせるように見えるからといって、確認せずに再開するわけにもいかない」
「わかっています」
佐伯は答えた。
「ただ、確認作業を進めている間にも、攻撃が続く可能性があります」
「だから、調査と防御を並行して進める」
上司は、ホワイトボードの三項目を見た。
「そして、確認できていないことを、確認できたことにしない」
その言葉に、若手も黙ってうなずいた。
調査は、少しずつ進んでいた。
だが、進展があったからといって、すぐにサービスを再開できるわけではない。
影響の範囲を確認し、必要な対策を実施し、その対策が有効に働いているかを確かめる。
それでも、攻撃が再び行われる可能性は残る。
ひとつの問題に対処しても、別のシステムに同じ弱点が残っていれば、そこが新たな入口になるかもしれない。
佐伯の端末に、新しい通知が届いた。
追加で確認を依頼していたシステムについて、外部事業者から回答があったのだ。
対象のソフトウェアは、現在調査中。
利用環境の詳細については、確認に時間を要する。
安全性を判断できる段階には至っていない。
佐伯は、その文面を上司に見せた。
「まだ、確認できないのか」
「はい」
佐伯は短く答えた。
「調べる対象そのものが、まだ見えていない部分があります」
＊
その夜。
仕事帰りの会社員が、スマートフォンでポイントサービスを開いた。
画面には、昨日と同じ表示が出ていた。
『ただいまメンテナンス中です』
復旧時刻の案内はない。
会社員は、画面を閉じた。
明日になれば使えるだろうか。
そう考えたが、確かな根拠はなかった。
その頃、佐伯の端末には、調査対象のシステムに関する新しい記録が届き続けていた。
攻撃の痕跡なのか。
通常のアクセスなのか。
あるいは、別の問題なのか。
ひとつずつ確認しなければ、判断できない。
守るべきシステムがどこにあり、何を使い、誰が管理しているのか。
その全体像さえ、まだ完全には見えていなかった。
復旧への道筋を描くために必要な地図は、最初から、ところどころ欠けていたのである。
