同じ脆弱性で、1時間で終わる会社と徹夜する会社は何が違うのか
株式会社グルーヴサイン代表取締役の米沢です。
先日、PHPに認証不要のリモートコード実行という深刻な脆弱性が公表されました。その対応と、そこで見つかった別の問題については別の記事に書きました。
今回書きたいのは、その周辺で感じたことです。同じ日に公表された、同じ脆弱性です。 それなのに、1時間ほどで点検まで終えた現場があり、一方でサービスを止めて一晩を費やした現場があります。
この差は何なのか。技術力の差ではありません。 それだけは、はっきり言えます。
まず、修正作業そのものは数分で終わる
誤解されやすいので先に書いておきます。今回の脆弱性に対する技術的な対応は、ほとんどの環境でこれだけです。
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
徹夜している現場も、この部分に何時間もかけているわけではありません。夜が溶けているのは、その前後の工程です。
夜を溶かす4つの工程
① 棚卸し ── 何がどこで動いているか分からない
最大の時間泥棒はこれです。「うちはどのバージョンのPHPを、どのサーバで、いくつ動かしているか」に即答できない。
サーバが300台あれば、まず300台を調べるところから始まります。しかも脆弱性が公表された直後、つまり攻撃者が動き始めている最中にです。本来は平時にやっておける作業を、最も時間に追われている瞬間にやることになります。
これは技術力の問題ではなく、記録があるかどうかの問題です。
② コンテナ ── 自動更新という安全網が無い
今回とくに影響が大きかったのが、これだと思います。
OSに直接インストールしていれば、多くの環境では自動更新が働きます。公表の翌朝には、人が寝ている間に修正が当たっている。実際、今回それで済んだ環境は少なくないはずです。
ところがコンテナの中には、その仕組みがありません。 php:8.3-fpm のようなイメージを使っていると、
- ベースイメージの更新を待つ
- 自分のイメージを再ビルドする
- 全環境に再デプロイする
- 動作を確認する
これを、イメージの数だけ繰り返します。50個あれば50回です。
コンテナは「環境が固定されるので安全」と言われます。それは本当ですが、固定されるということは、脆弱性も固定されるということでもあります。OSの自動更新という安全網を外している自覚は、あまり共有されていないように思います。
③ 変更管理 ── 技術的には2分、手続きとしては12時間
大きな組織では、現場の判断で apt upgrade を打てません。
申請を上げ、承認を取り、試験環境で検証し、影響範囲を文書化し、深夜の作業枠を確保する。作業そのものは2分でも、そこに辿り着くまでに12時間かかる。
これは官僚的だから悪い、という話ではありません。止まると大勢が困るシステムを預かっていれば、そうした手続きには理由があります。ただ、緊急時にその手続きが時間を食うことは事実で、だからこそ「緊急時はこの手順を飛ばす」という例外規定を平時に決めてあるかどうかが効いてきます。
④ そもそも修正が存在しない
最も重いのがこれです。
今回、修正が提供されたのは PHP 8.2 以降です。8.1 以前には、上流からの修正がありません。 つまり「当てる」という選択肢が最初から無い。
この場合にやることは、修正の適用ではなく回避策の設計になります。攻撃経路を潰す、外部からの入力を制限する、構成を変える。どれも一晩で終わる作業ではありませんし、終わっても「完全に塞いだ」とは言い切れません。
弊社がお預かりしている案件にも、PHP 5系のまま動いているシステムがあります。こちら側の現実は、私もよく知っています。
正直に書いておきます
ここまで読むと、準備の良い会社とそうでない会社の話に見えるかもしれません。ですが、自社の対応が速かったのは、能力より構成の幸運によるところが大きかったというのが、点検を終えた実感です。
今回うまくいったのは、次の4つがたまたま揃っていたからです。
- ディストリビューションのパッケージを使っていた → 修正がバックポートされ、自動で当たった
- 自前ビルドでもコンテナ同梱でもなかった → 再ビルドが不要だった
- mod_php ではなく PHP-FPM だった → 今回もっとも危険とされた構成に該当しなかった
- サポート期間内のバージョンだった → そもそも修正が提供された
このうち1つでも違っていたら、同じように夜を溶かしていたはずです。
さらに言えば、この機会にサーバ全体を点検したところ、自動更新の対象から漏れていたものが複数見つかりました。 OSの更新は自動で当たっていたのに、別経路で入れていたソフトウェアは長期間放置されていた。カーネルの更新も、入れただけで有効になっていませんでした（いずれも対応済みです）。
「自動更新を入れてあるから大丈夫」が成立していたのは、たまたま今回がPHPだったからです。別の場所に穴が開いていたら、気づくことすらできませんでした。これは胸を張れる話ではありません。
それでも、本質的な差はある
幸運を差し引いてもなお、はっきりした差がひとつあります。
判断を、事前に済ませてあったかどうかです。
自動更新を有効にする。セキュリティ更新のみを対象にする。PHP-FPM で運用する。どのバージョンを使うか決める。これらはすべて、平時に、落ち着いて決めたことでした。
一方、徹夜している現場では、同じ判断を事故の夜にやっています。
- いま全台を更新して大丈夫か
- 止めていいサービスはどれか
- 誰の承認が要るのか
- 古いあのシステムはどうするのか
どれも本来、平時に決められたはずの問いです。障害対応が長引く原因は、たいてい技術の難しさではなく、先送りされた意思決定が一度に押し寄せることにあります。
17年にわたってシステムをお預かりしてきて、慌てる案件と慌てない案件の差も、結局はここでした。事故そのものの大きさより、事前にどれだけ決めてあるかで、夜の長さが決まります。
平時に決めておくこと
技術的に難しいことは何もありません。決めて、書いておくだけです。
- 何がどこで動いているか ── サーバ、バージョン、用途の一覧。年1回でも更新されていれば、緊急時の数時間が浮きます
- 自動更新をどうするか ── 入れるか入れないか。入れるなら何を対象にするか（ここが漏れがちです）
- コンテナの更新手順 ── ベースイメージの更新から再デプロイまで、誰が何分でできるか。一度やっておけば、本番で初見にならずに済みます
- 緊急時の例外手順 ── 通常の変更管理を飛ばしてよい条件と、その承認者
- サポート期限の把握 ── 使っている言語やミドルウェアの、サポートが切れる日。切れた瞬間、修正という選択肢が消えます
- サポート切れ環境の守り方 ── 上げられないなら、上げるまでの間どう守るか
最後の2つが、とくに後回しにされがちです。そして実際に事故が起きたとき、いちばん効いてきます。
経営の判断として
この話は、技術部門だけのものではないと思っています。
「システムを止めない」ための費用は、どこかで必ず払うことになります。平時に少しずつ払うか、事故の夜にまとめて払うかの違いしかありません。後者のほうが、金額も、人の消耗も、信用の損失も、はるかに大きくつきます。
徹夜している現場のエンジニアが怠けていたわけではありません。払うタイミングを、組織として選んでこなかったという話です。
ご相談について
「うちは何が動いているのか、正直よく分からない」「古いシステムがあるが、手を入れるのが怖い」。こうした状態は、決して珍しくありません。むしろ、長く事業を続けている会社ほど自然にそうなります。
棚卸しだけなら、止めずにできます。まず現状を知ることと、動いているものに手を入れることは、別の作業です。 前者を済ませておけば、次に何かが起きたとき、夜を溶かさずに済みます。
状況をお聞かせいただければ、どこから手をつけるべきかの整理からお手伝いします。
レガシーPHPシステムの保守・引き継ぎのご相談を受け付けています。
初回のご相談・ヒアリングは無料です。