PHPの脆弱性から学ぶ運用保守のIT統制｜ただちに対応できた会社の4つの条件

公開日： ／更新日：

2026年10月21日の夜、PHPの重大な脆弱性があると公表され、多くの会社が23時の緊急アップデートに伴う対応を余儀なくされました。この影響はIT業界だけにとどまらず、高市首相がXなどで呼びかけるなどの騒ぎに発展しました。結果的に、このトラブルの影響で多くの会社で運用保守の体制が試されました。PHPは、サーバー側の言語が分かっているWebサイトの約7割で使われているプログラミング言語（W3Techs調べ）であるため、影響は計り知れないものになったでしょう。

https://x.com/takaichi_sanae/status/2112890642590564386

では、当日に対応できた会社とそうでない会社の違いはどこにあるのでしょうか？この差は、技術力の差というより、運用保守の仕組みの差だと私は考えています。そして運用保守は、IT統制では「システムの運用・管理」「システムの開発、保守に係る管理」として評価の対象になる領域です。この記事では、今回の出来事を題材に、運用保守のIT統制で何を見直せばよいかを整理します。

この記事を読んでわかること

  • PHP2shell（2026年10月）で、いつ何が起きたか
  • IT統制でいう「運用保守」が、内部統制の実施基準や経済産業省のガイダンスのどこに当たるか
  • パッチを「今夜」当てられる会社に共通する4つの条件
  • 保守が終わったシステムを抱えている場合のリスクと、明日からの見直し方

PHPの脆弱性と影響範囲についての警報

10/21の日中に、PHPの脆弱性について、IPAなどの多くの機関からアラートがでました。

10月21日修正版の公開予定を受けて、IPAが「事前準備のお願い」を掲載 → 10月21日 午後10時前首相がXで「大至急のお願い」を投稿 → 10月21日 深夜修正版（8.5.12／8.4.27／8.3.36／8.2.35）が公開 → 10月22日IPA・JPCERT/CCが注意喚起を公開

IPAの注意喚起によると、PHPの脆弱性の影響によって遠隔の第三者が、任意のコードを実行できるおそれがあると記載がありました。

その影響がとても大きいことから、高市総理自ら「今夜に対応して頂きたい大至急のお願いです」「今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします」とアラートを出しています。

https://x.com/takaichi_sanae/status/2112890642590564386

また、早急にアップデート出来ない場合は「ウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つ」とも書かれていました。

国のトップがこのようにアラートをかけることも相当珍しいですが、それだけ大きな影響があるということの表れなのでしょう。

IT統制でいう「運用保守」とは

「運用」はシステムを日々動かし続けること、「保守」は不具合の修正や更新でシステムの機能を保つことを指します。

内部統制の実施基準は、ITに係る全般統制（IT全般統制）の具体例として、次の4つを挙げています。

  • システムの開発、保守に係る管理
  • システムの運用・管理
  • 内外からのアクセス管理などシステムの安全性の確保
  • 外部委託に関する契約の管理

運用保守は、このうち前の2つにまたがります。監査基準報告書315も、IT全般統制を「ＩＴ環境の継続的かつ適切な運用を支援する企業のＩＴプロセスに係る内部統制」と定義しています。つまり、システムを「動かし続ける」こと自体が、統制の対象になっているということです。

経済産業省の「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（令和6年12月）は、保守を「情報システムの能力・機能の維持・更新」と説明しています。そして、運用・管理の中に「変更管理（ソフトウェアとIT基盤の保守）」を位置づけています。今回のようなパッチの適用は、保守作業であると同時に、IT統制上は「変更」でもあるわけです。

今回のPHPの脆弱性対応においては、ある意味、IT統制の運用保守体制について試される場になっていたかもしれません。具体的には、それぞれの対応がIT統制上において以下の意味を持っていたと考えられます。

今回の対応 IT統制での位置づけ 追補版の統制目標の例
脆弱性情報を集める システムの安全性の確保 「利用するITの脆弱性情報を適時に把握し、セキュリティパッチを適用する」
パッチを当てる 保守・変更管理 「最新の承認されたパッチが導入されていることを確認すること」
委託先に更新を頼む 外部委託の管理・変更管理 「本番への移行は、自社で行うにせよ外部に委託するにせよ、適切なモニタリングのもとで実施すること」
夜間に判断して動く 運用・管理 「緊急時を含む障害対応があること」
古い製品を使い続ける 運用・管理 「調達先とのサポート体制を維持すること」

もし、今回の対応で自社で不十分だと思える対応があった場合は、これを機に見直す良い機会になるかもしれないですね。

変更管理の考え方そのものは、IT全般統制の変更管理｜GitHubのプルリクエストが監査証跡になる仕組みで詳しく扱っています。

パッチを当てられるかどうかは、普段の仕組みで決まります

月次決算・IPO準備・IT統制の実務知見を、月1回メールでお届けします

無料でメルマガを受け取る

当日に対応ができた会社の4つの条件

では、当日に動けた会社と、動けなかった会社では何が違ったのでしょうか。私自身の経験と、相談の現場で見てきたことから、4つの条件に分けて考えてみます。

1. 脆弱性情報を、誰が・いつ受け取るか

まず、脆弱性に関する情報を受け取れる体制をどのように構築するかです。
こうしたセキュリティインシデントに関するニュースは何かしらの方法で入手しないといけないのですが、情報源をちゃんと持っていないと手に入れようがありません。

  • セキュリティに関するコミュニティで情報を仕入れる
  • セキュリティに詳しい知人と情報交換を行う
  • そうしたチャットコミュニティ等に参加していく
  • ニュース番組等で情報を入手する

弊社にPHPに関するアップデートの第一報が届いたのは、たまたまクライアントにセキュリティエンジニアの方がいて、その方がSlackで知らせてくれたからでした。たまたま詳しい人が近くにいた、というのが実態です。

もう一つ、以前関わっていた会社のメンバーが集まるチャットグループでも話題になっていました。そのため早めに警戒でき、当日より前にPHPを更新できました。

ただ、これは運が良かっただけとも言えます。第一報が「たまたま詳しい人」に頼っていると、その人がいない会社、その人が休んでいる日には、情報が届きません。追補版が「利用するITの脆弱性情報を適時に把握し」と書いているのは、まさにこの入口を仕組みにすることを求めているのだと思います。
そのためには、IPAやJPCERT/CCの注意喚起、ベンダーやレンタルサーバー会社の告知を、誰が見るのかを決めておく必要があります。

2. エスカレーションの体制が整っているか

こうしたインシデント対応のためには、きちんとHPやサービスを止めるためのエスカレーションフローが整備されていないといけません。

サービスを止めるというのは相当重いことになるため、当然経営陣に判断を伺わないといけないですが、経営陣がITに明るくないと止めることすら叶わないことになります。

そこで、今回のエスカレーションで役に立ったのは、高市総理の投稿が一つになります。

私が見聞きした範囲では、ITに詳しくない経営陣が「首相が言っているなら危ないんだ」と受け止め、ホームページの点検に動いた例がありました。報道でも、エンジニアから「経営層に伝わる」という評価が出ていました。そのことから、首相の投稿には一定の効果があったと思います。

裏を返すと、首相の投稿がなければ、経営陣まで話が届かなかった会社もあったということです。相談の現場では、情シスの担当者が危険に気づいても、「サイトを止める」判断を誰がするのかが決まっていない会社もあります。サイトを止めれば、問い合わせや売上に影響します。だから、IT部門の担当者一人では決めにくいのです。

追補版は「緊急時を含む障害対応があること」を統制目標に挙げています。夜に誰へ連絡し、誰が止めると決めるのか。この順番が1枚の紙になっていないと、判断を待つ間に時間が過ぎていきます。インシデントの記録の残し方は、インシデント対応で「やってはいけないこと」で扱っています。

3. 更新の手を、自社で持っているか

また、HPの更新を自社で出来るのかも重要です。現に、HPの保守業者などのアップデートのリソースがパンクして、それまでHPの更新ができないという話も聞いております。

例えば、弊社のホームページはWordPressで作っています。以前は、制作会社に任せている部分がありました。その後、AIを使って自分でメンテナンスするようになり、セキュリティの確認や動作確認も自前で行うようになっていました。今回は、その体制のおかげで、たまたまPHPのアップデートを事前に実施していたため助かりました。

外部に任せきりだと、緊急時には「委託先が動いてくれるまで待つ」しかありません。委託契約の対応時間が平日の日中だけであれば、夜の呼びかけには間に合わないこともあります。外部委託そのものが悪いわけではありません。追補版も「自社で行うにせよ外部に委託するにせよ、適切なモニタリングのもとで実施すること」と、どちらもあり得る前提で書いています。問題は、緊急時の対応が契約で決まっているか、そして自社で確認できる範囲があるかです。

4. 普段から、定期的に更新しているか

普段からサーバーやアプリのバージョンを定期的に更新している環境なら、当日の作業は「いつもの更新を前倒しする」だけで済みます。手順も、動作確認のやり方も分かっているからです。

一方で、何年も更新していない環境は事情が違います。修正版に上げる前に、互換性の確認が必要になるかもしれません。プラグインや周辺のソフトウェアも、合わせて上げる必要が出てくるかもしれません。そうなると、「今夜」には間に合いません。追補版の「最新の承認されたパッチが導入されていることを確認すること」は、緊急時だけでなく、普段の状態を問う統制目標だと私は読んでいます。

保守が終わったシステムだったら

今回のアップデートにおいて、PHP 8.1以前は公式の更新対象外でした。
IPAは、8.1以前はサポート終了を迎えているとしたうえで、更新や移行が完了するまでは、脆弱な状態での運用を放置せず、暫定対策やアクセス制限を検討するよう求めています。
つまり、サポートが切れたものを使っている会社には、「修正版を当てて終わり」という選択肢がありません。

これがホームページではなく、会計や販売管理の基幹システムだったらどうでしょうか。サポートが切れたOSやミドルウェアの上で基幹システムが動いていると、同じような脆弱性が見つかったときに、更新できません。
システムを止めれば、請求も記帳も止まります。止めなければ、データが改ざんされるリスクを抱えたまま動かすことになります。どちらを選んでも、財務報告の信頼性に影響が及びます。想像すると、かなり怖い状況です。

追補版は「調達先とのサポート体制を維持すること」を統制目標に挙げています。サポートの期限は、切れてから気づいても遅いものです。システム管理台帳に、システムごとのバージョンとサポート期限を書いておけば、更新の計画を前もって立てられます。委託先のシステムであれば、SOC1レポートなどで、委託先側の保守の体制を確認しておくことも必要です。

IT統制の構築を見直すきっかけにする

今回の件は、運用保守の仕組みを見直すよい機会だと思います。大がかりな規程づくりから始める必要はありません。4つの条件に対応させて、次の4つから手をつけてみてください。

条件 明日からやること
1. 情報の入口 脆弱性情報を見る担当者と、その代理を決める
2. エスカレーション 「サイトを止めるか」を誰が決めるか、連絡の順番を1枚にまとめる
3. 更新の手 委託契約で、緊急時の対応時間・連絡先を確認する。自社で確認できる範囲を決める
4. 定期更新・保守期限 システム管理台帳に、バージョンとサポート期限の列を足す

システム管理台帳テンプレート（Excel・無料）

4つ目の「保守期限」は、台帳があれば列を足すだけで始められます。システム管理台帳（17項目）と資料一覧のテンプレートをお使いください。

資料をダウンロードする

IT全般統制の全体像は、IT全般統制（ITGC）とはでまとめています。運用保守は、その中でも目立ちにくい一方で、止まると業務に直接響く部分です。

運用保守・インシデント対応を含めたIT統制の構築をご検討の方へ

脆弱性情報の受け取りから、緊急時の判断の経路、委託先の管理、保守期限の把握まで、IT統制に詳しい公認会計士が現状を整理し、運用できる形に整えます。

無料相談・お問い合わせ

まとめ

PHPの修正を当日に対応できたかどうかは、技術力よりも、運用保守の仕組みで決まりました。情報が誰に届くのか、誰が止めると決めるのか、更新の手を誰が持っているのか、普段から更新しているのか。この4つは、IT統制の「システムの運用・管理」「システムの開発、保守に係る管理」をどう作るか、という問いそのものです。

弊社も、たまたま詳しい人が近くにいたから間に合った面があり、他人事ではありません。今回の出来事を、自社の運用保守を見直すきっかけにしていただければと思います。運用保守やインシデント対応を含めたIT統制の構築について相談したい方は、お問い合わせからお気軽にご連絡ください。

参考資料

執筆者

稲垣大輔

合同会社オントロジー　代表

合同会社オントロジー代表。大手監査法人・税理士法人・事業会社等を経て独立開業。会計とITの双方のノウハウを用いて、IT全般統制の構築・評価、上場準備支援、決算早期化やDXコンサルなどを実施している。

公認会計士・税理士・システム監査技術者

2023年度・2024年度　日本公認会計士協会東京会テクノロジー委員会委員長

おすすめ記事

一覧へ