PHP問題って、そもそも何？ ／ Cyber Incident Management for PHP Vulnerability

第二話 契約先はどこだ？

第二話　契約先はどこだ？

午後十時四十分。

サイバーナイト株式会社の情報システム部門では、PHPの脆弱性に関する確認作業が続いていた。

最初に行うべきことは、影響を受ける可能性のあるシステムを洗い出すことだった。

ところが、その作業は思ったほど簡単ではなかった。

「社内のシステム一覧を、もう一度確認してください」

最高情報責任者の黒木厳は、担当者に伝えた。

「PHPを使っているシステムだけでなく、管理部署、保守会社、サーバーの管理者、現在のバージョンまで確認したい」

担当者は、画面に表示された一覧を見つめた。

「社内システムについては、ある程度わかります。ただ、外部に制作を依頼したウェブサイトは、一覧に載っていないものがあるかもしれません」

「契約書は？」

「調達部門に確認します」

黒木はうなずいた。

それは、必要な手順だった。

しかし、契約書が見つかれば、すべてがわかるというわけではない。

## 契約書に書かれていること、書かれていないこと

企業が外部の会社にシステムの開発や管理を依頼するとき、通常は契約を結ぶ。

契約書には、依頼する業務、料金、契約期間、保守の範囲などが記載される。

ただし、契約の内容は案件によって異なる。すべての契約書に、サーバーの機種やソフトウェアのバージョンまで書かれているとは限らない。

ここで、二つの言葉を区別する必要がある。

**契約管理**とは、誰と、どのような条件で契約しているかを把握すること。

**システム管理**とは、実際に稼働しているシステムの構成や状態を把握し、更新や保守などを行うことだ。

両者は関係しているが、同じものではない。

契約管理の台帳に会社名が記載されていても、その会社が現在のPHPのバージョンを把握しているかどうかは、別途確認しなければならない。

また、契約先がシステム全体を管理しているとは限らない。

ウェブサイトの制作会社がプログラムを開発し、別の会社がサーバーを提供し、さらに別の会社が保守を担当している場合もある。

つまり、企業が一つのウェブサイトを利用していても、その裏側には複数の会社が関わっている可能性があるのだ。

「調達部門から、契約先の一覧が届きました」

担当者が報告した。

黒木は、一覧を確認した。

会社名はある。契約期間もある。支払金額も記録されている。

しかし、技術的な情報は十分ではなかった。

どのサーバーで動いているのか。

PHPのバージョンは何か。

修正プログラムを適用できるのは誰なのか。

そして、緊急時に連絡すべき担当者は誰なのか。

「契約先はわかった。でも、これだけでは、影響を受けるかどうかを判断できない」

黒木はそう言った。

責める口調ではなかった。

契約管理の台帳は、契約を管理するためのものだ。それが技術的な構成まで記録する仕組みになっていなければ、情報が不足するのは不思議ではない。

問題は、必要な情報を、どこから集めるかだった。

## サーバーとアプリケーションは別のもの

午後十一時。

外部のホスティング事業者、ブロッサムネット株式会社から回答が届いた。

ホスティングとは、ウェブサイトやアプリケーションを動かすためのサーバー環境を、事業者が提供するサービスのことだ。

企業が自社でサーバーを購入し、社内で管理する代わりに、外部の事業者が提供する環境を利用する方法である。

サーバーとは、簡単にいえば、ほかのコンピューターからの要求を受け付け、データやサービスを提供するコンピューター、あるいはその役割を担う仕組みを指す。

ウェブサイトの場合、サーバーは利用者からのアクセスを受け取り、必要な処理を行う。

ただし、サーバーを提供する会社が、ウェブサイトのプログラムまで管理しているとは限らない。

ブロッサムネットは、ホスティング環境について確認を進めていると回答した。

一方、顧客側で管理しているアプリケーションについては、PHPのバージョンやプログラムの構成を別途確認する必要があるという。

黒木は、その回答を読み返した。

アプリケーションとは、特定の目的を果たすためのソフトウェアのことだ。ウェブサイトであれば、会員登録や商品検索、予約受付などの機能を実現するプログラムが該当する。

サーバーの管理と、アプリケーションの管理。

両者は密接に関係しているが、管理する会社が異なることもある。

たとえば、サーバーを管理する会社がPHPの実行環境を提供していても、その環境上で動くウェブサイトのプログラムは、別の制作会社が管理しているかもしれない。

その場合、サーバー側で対応できることと、アプリケーション側で対応しなければならないことを分けて考える必要がある。

「つまり、ブロッサムネットが対応できる範囲と、こちらで確認しなければならない範囲があるわけですね」

担当者が尋ねた。

「そういうことです。ただし、実際の責任範囲は契約と構成を確認してから判断する必要があります」

黒木は答えた。

会社名だけで責任を決めつけることはできない。

必要なのは、どの会社が、どの部分を、どこまで担当しているかを確かめることだった。

## バージョンを調べる

次に問題になったのは、PHPのバージョンだった。

ソフトウェアには、機能の追加や不具合の修正、安全性の改善などを反映した複数のバージョンが存在する。

今回のような脆弱性への対応では、対象となるバージョンを特定することが重要になる。

ただし、単にバージョン番号を調べれば、すべての判断が終わるわけではない。

脆弱性の影響を受ける条件は、それぞれの問題によって異なるからだ。

修正済みのバージョンを使っているのか。

影響を受ける機能を使用しているのか。

開発元が案内している対策を適用できるのか。

そうした情報を、該当する脆弱性の公式な説明と照らし合わせる必要がある。

そして、確認した結果は記録しておかなければならない。

「バージョン確認済み」という記載だけでは不十分な場合がある。

いつ、誰が、何を確認し、どの情報を根拠に判断したのか。

その記録があれば、別の担当者が引き継ぐときにも、同じ調査を最初からやり直さずに済む。

逆に、確認したという報告だけが残り、根拠が記録されていなければ、緊急時にもう一度調べ直すことになりかねない。

黒木は、一覧に確認結果の欄を追加するよう依頼した。

対象システム、管理者、PHPのバージョン、影響の有無、修正の可否、確認日時。

そして、まだわからない項目は、わからないまま記録する。

空欄を、勝手に「問題なし」と読み替えてはいけない。

## 「問題なし」とは、どういう意味か

日付が変わるころ、担当者から報告があった。

一部のシステムについては、管理先と技術的な情報を確認できた。

しかし、まだ確認が終わっていないシステムも残っていた。

「現時点で、明確な攻撃の痕跡は確認されていません」

担当者が報告した。

黒木は、すぐには答えなかった。

「調査は終わっていますか」

「いいえ。ログの確認を続けています」

ログとは、システムがいつ、どのような処理を行ったかを記録した情報だ。アクセスの日時や接続元、処理結果などが記録される場合があり、障害や不正アクセスの調査に使われる。

ただし、ログに記録される内容は、システムの設定や保存期間などによって異なる。ログがあるからといって、すべての出来事が記録されているとは限らない。

だからこそ、調査の途中で「攻撃の痕跡がない」と報告するときには、注意が必要だった。

調査した範囲では、まだ痕跡が見つかっていない。

それは、現時点で確認できる事実だ。

しかし、すべてのシステムについて、すべての期間を調べ終えたわけではないなら、「攻撃はなかった」と断定することはできない。

黒木は、担当者に伝えた。

「報告には、確認できた範囲と、まだ確認できていない範囲を分けて書いてください」

「わかりました」

「不明なものは、不明と記録する。確認が終わったものと、終わっていないものを混ぜないでください」

それは、慎重すぎるほどの要求に見えるかもしれない。

しかし、危機管理では、事実と推測を混同することが、次の判断を誤らせる原因になる。

わからないことを、わかったことにしない。

確認していないことを、確認済みとしない。

黒木が求めていたのは、それだけだった。

## 一覧にないシステム

午前零時十五分。

黒木は、更新された一覧を確認していた。

確認済みの項目は増えていた。

一方で、空欄も残っていた。

社内で管理しているシステムについては、担当部署をたどることができる。

契約先がわかれば、問い合わせ先を確認できる。

しかし、事業部門が独自に依頼したウェブサイトや、過去に制作され、その後ほとんど変更されていないサイトは、すぐには全体像を把握できないことがあった。

契約の記録が見つかっても、現在の運用担当者がわからない。

制作会社に連絡できても、サーバーの管理会社は別だった。

管理会社が判明しても、どのバージョンが稼働しているかは、確認中だった。

一つの情報がわかるたびに、次に確認すべきことが見えてくる。

それでも、すべての項目が一度に埋まるわけではなかった。

黒木は、一覧の空欄を見つめた。

この空欄は、ただの入力漏れではない。

会社が、自分たちの事業を支えるシステムの一部について、十分な情報を持っていないことを示していた。

もちろん、情報が不足しているからといって、直ちに危険だと決まるわけではない。

だが、影響を受けるかどうかを判断できない状態が続けば、対策を始めることも、停止の必要性を評価することも遅れてしまう。

「契約先の一覧と、システムの一覧を照合しましょう」

黒木は言った。

「契約があるのにシステムが登録されていないもの。システムはあるのに管理者がわからないもの。両方を確認してください」

それは、今夜の対応だけのためではなかった。

今後、別の脆弱性が見つかったときにも、同じ問題が起きる可能性がある。

そのたびに、契約先を探し、管理者を探し、システムの構成を一から確認していては、時間がかかりすぎる。

危機が起きる前から、何を使い、誰が管理し、どこへ連絡すればよいのかを把握しておく必要がある。

## 任せることと、把握しないこと

午前零時三十分。

ブロッサムネットから、追加の確認結果が届き始めていた。

すぐに対応できるものもあれば、アプリケーションの管理者に確認しなければならないものもあった。

黒木は、報告を受けながら、次の作業を整理した。

影響を受ける可能性があるシステムを特定する。

管理者と連絡先を確認する。

修正の可否と、必要な作業を確認する。

ログの調査を続ける。

まだ判断できない項目については、何が不足しているのかを明確にする。

それぞれの確認結果は、経営会議が対応方針を判断するための材料にもなる。

黒木自身が、すべての技術的な詳細を知っているわけではない。

だからこそ、担当部署や外部事業者から情報を集め、確認できた事実と不明な点を区別しなければならなかった。

外部の専門会社に仕事を任せること自体は、問題ではない。

専門知識を持つ会社に管理を委託するのは、合理的な選択である。

しかし、委託していることと、何を委託しているのか把握していないことは違う。

どこまでを委託先が管理し、どこからを自社が管理するのか。

緊急時に、誰が連絡を受け、誰が修正し、誰が結果を確認するのか。

それを把握していなければ、いざというときに対応が滞る。

黒木は、一覧に残された空欄をもう一度確認した。

「任せることと、把握しないことは違う」

静かな声だった。

その言葉は、誰かを責めるためのものではない。

これまでの管理の仕組みを見直すための、出発点だった。

午前零時を過ぎても、確認は続いていた。

すべてのシステムが、すぐに特定できるわけではない。

すべてのバージョンが、すぐにわかるわけでもない。

だが、わからないことを放置せず、誰が確認するのかを決め、確認できた事実を記録することはできる。

黒木は、次の報告を待った。

一覧には、まだ一つ、管理担当者の欄が空白のウェブサイトが残っていた。