第一話 PHP問題―緊急警報
【登場人物紹介】
◾️黒木 厳
サイバーナイト株式会社・最高情報責任者（CIO）。46歳。
社内の情報システムと情報セキュリティを統括する責任者。サッカーではセンターフォワードを務めていた。危機的な状況でも、確認できた事実と、まだわかっていないことを区別して考える。
自らの判断だけで会社の方針を決めるのではなく、技術的な状況、リスク、事業への影響を整理し、経営会議が判断できる材料を提示する。
今回のPHP問題では、脆弱性への対応だけでなく、社内システムの管理状況や外部委託先との責任分担という課題にも直面する。
◾️サイバーナイト株式会社の経営陣・関係部署
従業員約1,100人の企業を支える人々。
サイバーインシデントへの対応には、情報システム部門だけでなく、経営陣、事業部門、契約担当者など、さまざまな立場からの判断と協力が必要になる。
サービスを停止するのか、継続するのか。どのリスクを許容し、何を優先するのか。最終的な方針は、技術担当者の説明を踏まえ、組織として決定される。
◾️外部のシステム管理会社・開発委託先
企業のウェブサイトやシステムを支える外部の事業者。
サーバーの管理、プログラムの開発、保守、脆弱性への対応など、担当する範囲は契約やシステム構成によって異なる。
複数の会社が関わる環境では、誰がどの部分を管理しているのか、誰が修正を担当するのかを確認すること自体が、緊急対応の重要な仕事となる。
◾️利用者と取引先
企業のサービスを日常的に利用する人々、そして業務を支える取引先。
システムの停止は、単なる画面の不具合では済まないことがある。予約、注文、会員サービスなどが利用できなくなれば、利用者や取引先にも影響が及ぶ。
安全性を確保することと、サービスを継続すること。その両方を考えなければならないのが、サイバー危機管理の難しさである。
第一話 PHP問題―緊急警報
【そもそも、PHP問題とは何なのか】
インターネットのウェブサイトは、画面に文字や写真を表示するだけの仕組みではない。
利用者がログインする。商品を検索する。買い物かごに商品を入れる。予約を申し込む。会員情報を確認する。
こうした動きの多くは、画面の裏側で動いているプログラムによって支えられている。
そのプログラムを作るための言語の一つが、PHPである。
PHPは、ウェブサイトの開発で広く利用されてきたプログラミング言語だ。たとえば、利用者が会員ページを開いたとき、サーバー側でPHPのプログラムが動き、必要な情報をデータベースから取り出して、画面に表示するための処理を行う。
もちろん、すべてのウェブサイトがPHPで作られているわけではない。ウェブサイトの仕組みはさまざまであり、PHPを使っていても、その使い方や構成はサイトごとに異なる。
問題は、PHPそのものが悪いということではなかった。
ソフトウェアには、開発者が想定していなかった条件で、誤った動作をしたり、本来許されていない処理を実行してしまったりする欠陥が見つかることがある。
これが、いわゆる「脆弱性」だ。
脆弱性が発見されると、開発元は原因を調べ、必要に応じて修正版を公開する。システムを管理する側は、自分たちが影響を受ける環境を使っているか確認し、修正プログラムを適用するなどの対策を取らなければならない。
ここで、話は単純ではなくなる。
PHPを使っていることがわかっても、それだけでは、影響を受けるかどうかは判断できない。PHPのバージョン、問題となった機能の使用状況、サーバーの設定、公開されているプログラムの構成など、確認すべき条件があるからだ。
そして、脆弱性が見つかったという事実は、すでに攻撃されたという証拠でもない。
危険な欠陥が見つかったことと、その欠陥を利用して侵入されたことは、別の問題なのである。
しかし、だからといって、攻撃された証拠が出るまで何もしなくてよいわけではない。
攻撃を受ける前に修正できるなら、修正する。それが基本だ。
ただし、修正プログラムを適用すれば、すべてが即座に解決するとは限らない。システムによっては、更新に伴う動作確認が必要になる。複数のプログラムが連携している場合、ある部分を変更した結果、別の部分に不具合が生じる可能性もある。
さらに、修正前に攻撃を受けていなかったかどうかは、別途、ログなどを調べて確認しなければならない。
**修正すること。正常に動くか確認すること。過去に侵入されていないか調べること。**
この三つは、互いに関係しているが、同じ作業ではない。
では、ウェブサイトを一時的に停止すれば、安全になるのだろうか。
停止すれば、外部からのアクセスを減らせる場合はある。しかし、停止しただけで脆弱性が修正されるわけではない。すでに侵入されていた場合、その痕跡が消えるわけでもない。
また、ウェブサイトを止めるということは、利用者がサービスを使えなくなるということでもある。
一般の企業サイトなら、情報を閲覧できない不便が中心かもしれない。だが、予約、通販、会員サービス、決済、金融機関のシステムであれば、停止の影響はさらに大きくなる。
だから、脆弱性への対応では、単に「直すか、止めるか」の二択だけで考えることはできない。
どのシステムが影響を受けるのか。
修正プログラムは利用できるのか。
すぐに修正できない場合、危険を一時的に減らす手段はあるのか。
攻撃の痕跡は見つかっているのか。
サービスを停止した場合、利用者や取引先にどのような影響が生じるのか。
それらを確認し、技術的な状況と事業への影響を整理したうえで、組織として対応を決める必要がある。
そして、ここにもう一つ、見落とされがちな問題があった。
自社のシステムが、どこで、誰によって管理されているのか。
社内のサーバーなら、担当部署が把握しているかもしれない。しかし、外部の会社に制作を依頼したウェブサイトや、別の会社が管理するサーバーを利用しているサービスでは、話が違ってくる。
契約書に会社名が書かれていても、PHPのバージョンまで記録されているとは限らない。
サーバーを管理する会社と、ウェブサイトのプログラムを開発する会社が異なる場合もある。
そのとき、サーバーの環境を修正するのは誰なのか。ウェブサイトのプログラムを確認するのは誰なのか。緊急時に、誰に連絡すればよいのか。
問題が起きてから調べ始めれば、それだけ対応に時間がかかる。
PHPの脆弱性は、プログラムの欠陥に関する問題だ。
だが、企業が直面する危機は、プログラムの修正だけでは終わらない。
技術の問題と、管理の問題と、組織の判断が、同時に押し寄せてくるのである。
## 午後十時十二分
サイバーナイト株式会社の本社は、泉ガーデンタワーにあった。
従業員、およそ千百人。
社内では、グループウェアをMicrosoft 365からGoogle Workspaceへ移行する作業が進められていた。業務の仕組みを新しくする一方で、緊急時の連絡手段としてSlackも残されていた。
「もしもの時のSlack」。
平時には、少し冗談めいた呼び名だった。
だが、その夜は違った。
午後十時十二分。
最高情報責任者、黒木厳のもとに、緊急の警報が届いた。
PHPに関する重大な脆弱性が問題となり、影響を受けるシステムの確認と、必要な対策を急ぐよう求められていた。
黒木は、通知を読み終えると、まず一つのことを確認した。
「現時点で、攻撃を受けたことを示す情報はあるのか」
返答は、明確ではなかった。
確認できる情報は限られている。関連するログの調査も、まだ終わっていなかった。
攻撃されたと断定できる証拠はない。
しかし、攻撃されていないと断定できるだけの確認も、済んでいない。
黒木は画面を見つめた。
この二つは、似ているようで、まったく違う。
「まず、影響を受けるシステムを洗い出してください。PHPを使っているかどうかだけでなく、バージョンと管理者、修正の可否を確認する必要があります」
彼は、対応に必要な情報を整理し始めた。
社内のシステム一覧を開く。
だが、一覧にあるものが、会社のすべてのウェブサイトとは限らなかった。
外部に制作を委託したサイト。事業部門が独自に契約したサービス。別の会社が管理するサーバー。
契約が存在することと、技術的な構成を把握していることは同じではない。
黒木は、次の連絡を待ちながら、もう一度、画面を見た。
これは、単にPHPを更新すれば終わる仕事ではない。
何が影響を受けるのか。
誰が管理しているのか。
どこまで確認できていて、何がまだわかっていないのか。
そして、どの情報をもとに、会社として判断するのか。
その夜、サイバーナイト株式会社の危機管理は、まだ入口に立ったばかりだった。
