自社のサーバーのセキュリティ対策を見直そうとすると、話はすぐに広がります。AIを使った攻撃への備え、ゼロトラスト、監視の強化と、候補はいくらでも出てきます。ところが、実際の侵入でよく入口に使われるのは、何年も前に入れたまま更新していない OS や Web サーバー、サポートが終わったプログラムの部品です。これらが今も本番で動いていないかを、最初に確かめます。
まず、サーバーの中で動いている OS とミドルウェアを一覧にし、提供元のサポートが終わったものと、攻撃に使われたと公表された弱点を抱えたものを探します。見つけたら、更新を年に一度の大仕事にせず、毎月の決まった作業に変えます。コンテナで動かしている場合も、中身は作った時点のまま古くなっていくので、定期的に作り直す仕組みが要ります。
この記事の調べ方
OS とプログラム言語のサポート期限は、Red Hat、Canonical（Ubuntu の提供元）、PHP の公式ページで確かめました。攻撃の傾向は、米国の CISA（サイバーセキュリティ・インフラストラクチャー安全保障庁）が公開している一覧、IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」、警察庁の白書を根拠にしています。コンテナの作り直しについては Docker の公式ドキュメントを参照しました。記事中の金額や期間の例は説明のための仮定で、実際の見積もりや事例ではありません。手順は一般的な進め方として書いており、この記事のために当社で試したものではありません。
この記事は、シリーズ「オープンソースと AI 時代のセキュリティ」の3本目です。シリーズ全体の考え方は、1本目のオープンソースの時代は終わるのかにまとめています。
最初に見るのは、古いまま動いているもの
セキュリティ対策の順番を考えるときは、攻撃する側が何から試すかを基準にすると決めやすくなります。攻撃する側にとって一番手間がかからないのは、すでに弱点が公表され、直し方も配られているのに、まだ直していないサーバーを探すことです。新しい弱点を自分で見つけるより、世の中に出回った情報を使うほうがずっと楽だからです。
IPA が毎年まとめている情報セキュリティ10大脅威 2026でも、組織の側の4位に「システムのを悪用した攻撃」が入っています。1位のランサム攻撃でも、入口には機器の弱点がよく使われています。警察庁の令和7年の警察白書によると、ランサムウェアの被害を受けた企業や団体に警察庁が感染経路を尋ねた調査では、有効な回答があった100件のうち、VPN 機器からの侵入が55件、リモートデスクトップからの侵入が31件でした。白書は、テレワーク用の機器のぜい弱性や弱いパスワードを使った侵入が大半だと分析しています。
派手な新技術への備えより先に、知られた弱点をふさぐ作業が効きます。そして、知られた弱点が一番残りやすいのは、誰も触らなくなった古いサーバーやプログラムです。経営者や情報システムの担当者が最初に聞くべき質問は「うちのサーバーで、何年も更新していないものはどれか」になります。
コンテナの中の OS は、作り直さない限り古いまま残る
最近の Web システムは、で動かすことが増えました。コンテナを使うと、開発者のパソコンでも本番のサーバーでも同じ中身を動かせるので、導入や引っ越しが楽になります。ただし、コンテナは中身の更新が止まりやすい仕組みでもあります。
コンテナは、というひな形から起動します。Docker の公式の手引きには、イメージは変更できず、イメージを作ることはその時点の中身を写し取ることだと書かれています。同じ手引きは、イメージを最新で安全に保つには、更新された部品で定期的に作り直すよう勧めています。2年前に作ったイメージを使い続けていれば、コンテナの中では2年前の OS の部品と Web サーバーが今も動いています。
ここに「動いているから触らない」という判断が重なります。コンテナで動くシステムは、外から見ると問題なく動き続けます。OS の画面にログインして更新の通知を見る人もいません。普通のサーバーなら担当者が更新の作業をすることもありますが、コンテナの場合はイメージを作り直して入れ替えない限り、中身は変わりません。作り直す手順を知っている人が異動や退職でいなくなると、誰も作り直せないまま年月が過ぎていきます。
図の上の段では、システムは3年間止まらずに動いています。その間に、中の OS の部品にはいくつもの弱点が見つかり、提供元は修正を配っています。それでも、イメージを作り直していないので、その修正は一度も入っていません。下の段のように作り直しを決まった作業にしておけば、部品は毎月新しいものに入れ替わります。コンテナを使っているからといって、中身が新しいとは限りません。
提供元のサポートが終わった OS とミドルウェア
更新が止まったソフトの中でも特に危ないのが、提供元のを迎えたものです。サポートが続いている間は、弱点が見つかっても直したものが配られます。サポートが終わると、新しい弱点が見つかっても直したものは出てきません。自社で更新したくても、更新するものがない状態になります。
サーバーでよく使われる OS とについて、公式に発表されているサポートの期限を並べると次のようになります。
表のうち、CentOS 7、Ubuntu 20.04、PHP 7.4、PHP 8.1 の4つは、すでに期限を過ぎています。CentOS 7 は社内のサーバーやコンテナのひな形として長く使われてきた OS なので、期限の後も入れ替えずに動いているものがないか確かめてください。PHP は WordPress をはじめ多くの Web サイトで使われており、7.4 や 8.1 のまま動いているサイトは、この先見つかる弱点が直りません。
PHP 8.2 の行も見ておいてください。この記事を書いている2026年10月の時点で、弱点の修正が届くのは残り2か月あまりです。期限が近づいてから慌てて上げようとすると、次の章で書く「止まる理由」がそのまま出てきます。期限は年単位で先が見えているので、1年前には次の手を決めておくと、準備を進めやすくなります。古い WordPress サイトを引き継いだ場合の点検は、引き継いだWordPressで最初に見る10項目にまとめています。
攻撃は、直し方が分かっている弱点に向かう
「古いと言っても、うちのような会社を狙う人はいない」という声もよく聞きます。ただ、古いソフトを狙う攻撃は、特定の会社を選んで行うものとは限りません。公表された弱点を抱えたサーバーをインターネット全体から機械的に探し、見つかったところから入る、という形が取られます。会社の規模や知名度とは関係なく、古いソフトが動いていることが狙われる理由になります。
米国の CISA は、実際に攻撃に使われたことが確かめられた弱点を既知の悪用された脆弱性カタログ（KEV カタログ）として公開しています。CISA はこの一覧を、攻撃に悪用された弱点の確かな情報源としており、組織が直す順番を決めるときの材料に使うよう勧めています。2026年10月の時点で、一覧には1,700件を超える弱点が載っています。
この一覧の使い方は単純です。自社で動いているソフトの名前とバージョンが分かっていれば、一覧と照らし合わせて、攻撃に使われたことのある弱点を抱えていないかを調べられます。逆に言えば、自社で何が動いているかが分からなければ、この一覧があっても使えません。だから、対策はまず自社で動いているソフトの棚卸しから始めます。AIを使って弱点を探す動きについては、AIに破られやすくなったセキュリティ対策ランキングでも取り上げています。
大きな会社ほど、更新が止まる理由
古いソフトが危ないことは、多くの担当者が分かっています。それでも更新が進まないのには理由があります。特に、売上を生んでいるシステムを抱える大きな会社ほど、更新を進めにくくなります。止まる理由を知っておくと、どこから手を打てばよいかも見えてきます。
止めたときの損失が怖い
通販サイトや予約のシステムのように売上に直結するシステムでは、更新の作業で数時間止まるだけでも損失が出ます。更新の後に不具合が出れば、その損失はさらに大きくなります。動いているシステムを触らないことが、担当者にとって一番責められにくい選択になりやすいのです。結果として、更新は「何か起きてから考える」ことになります。
関わる人が多く、会議で決まらない
1つのシステムに、事業部、情報システム部門、開発を委託している会社、サーバーを運用している会社が関わっていることがあります。OS を上げるには、全員の予定を合わせ、止める時間を決め、問題が出たときの責任の分け方まで話し合う必要があります。誰も決める権限を持っていないと、会議を重ねても結論が出ません。
見積もりが大きく見える
何年も更新していないシステムを一度に新しくしようとすると、作業は大きくなります。OS、Web サーバー、プログラム言語、アプリが使う部品がまとめて古くなっているので、どれか1つを上げると他も上げないと動かない、という連鎖が起きるからです。例えば、委託先から「数千万円・半年」といった規模の見積もりが出てくれば、予算の承認が通らず、さらに先送りになることもあります。先送りした分だけ次の見積もりは大きくなり、ますます手を付けにくくなります。
3つの理由に共通するのは、更新を「たまにやる大きな工事」として扱っていることです。毎月少しずつ上げていれば、1回の変更は小さく、止める時間も短く、見積もりも膨らみません。更新を止めないためには、小さな更新を毎月続ける仕組みを作ります。
更新を止めない進め方
更新を毎月の決まった作業に変えるために、次の5つを順番に見ていきます。何が動いているかを知ること、作り直しを自動にすること、本番の前に試す場所を持つこと、問題が出たら戻せること、誰が承認するかを先に決めておくことです。
図の左から右へ、毎月同じ順で進めます。下の帯にあるとおり、承認する人と判断の基準を先に決めておくのがこの流れの前提です。
1. 何が動いているかの一覧を作る
最初に、サーバーとコンテナの中で動いている OS、Web サーバー、データベース、プログラム言語と、それぞれのバージョンを一覧にします。コンテナの場合は、イメージの中身から部品の一覧を自動で書き出せるツールがあります。こうして書き出した部品の表をと呼びます。CISA はSBOMを、ソフトを構成する部品と、その中に含まれる部品を並べた一覧だと説明しています。一覧があれば、先ほどのサポート期限の表や KEV カタログと照らし合わせられます。
2. イメージを定期的に作り直す
コンテナのイメージは、毎月など決まった間隔で、最新の部品を取り込んで作り直します。Docker の手引きにも、元になるイメージの新しいものを取りに行く設定と、前回作ったときの途中の結果（キャッシュ）を使わずに一から作り直す設定が紹介されています。作り直しは人の手でやると忘れるので、日程を決めて自動で動くようにします。作り直したイメージで自動のテストが通るところまでを、毎月の作業に入れておきます。
3. 本番の前に試す場所を持つ
作り直したイメージは、いきなり本番に入れずにで動かします。本番と同じ構成で画面を操作し、注文や問い合わせなど売上に関わる動きが変わらないことを確かめます。確かめる項目を決めておけば、毎月同じ点検を短い時間で終えられます。
4. 一部から本番に入れ、戻す手順を用意する
本番に入れるときは、全部を一度に切り替えず、サーバーの一部や利用者の一部から入れていきます。問題が出たときは、すぐに前の状態に戻します。コンテナで動いていれば、前のイメージを残しておくことで、アプリと部品は短い時間で元に戻せます。データベースの形を変える更新は、イメージを戻すだけでは元に戻らないので、戻し方を別に決めておきます。戻す手順を書いておき、実際に一度試しておくと、更新の作業への怖さはかなり減ります。
5. 誰が承認するかを先に決める
毎月の更新を、そのたびに会議にかけていては続きません。検証環境の点検が通れば誰の承認で本番に入れてよいか、どんな問題が出たら止めるかを、最初に決めておきます。事業部の責任者と情報システムの担当者が合意した基準があれば、毎月の更新は担当者の判断で進められます。売上に関わるシステムほど、この取り決めが更新を続けられるかどうかを左右します。
ここまでの5つは、どれも特別な技術を要するものではありません。それでも、古くなったシステムを一度新しくしないと、この流れに乗せることができません。古いシステムを一度新しくする作業は外部に頼み、その後の毎月の更新は自社で行う方法もあります。
古いものを減らした次に考えること
更新を毎月回せるようになっても、弱点がゼロになるわけではありません。提供元が直したものを配る前に攻撃が始まることもあります。そのため、更新とあわせて、そもそも動かすソフトを減らすことと、侵入されても被害を小さくすることを考えておく必要があります。
動かすソフトが少なければ、一覧に載る部品も、追いかける弱点も少なくなります。Web サーバーの中に使っていない機能を残さない考え方は、シリーズ4本目のWeb サーバーに機能は要らないで取り上げます。侵入されたときにすべてを取られないようにする権限の分け方は、5本目の乗っ取られても全部は取られない設計で書きます。
守りを固めるには、古いものの更新に加えて、動かすソフトを減らし、権限も分けておく必要があります。それでも、最初に手を付けるのは古いものの洗い出しです。何が動いているかが分からないままでは、減らすことも、権限を分けることも始められないからです。WordPress で作ったサイトの場合は、AI時代のWordPressセキュリティも参考にしてください。
今日から使える点検の一覧
最後に、自社のサーバーを見直すときの点検項目を並べます。情報システムの担当者や、システムを委託している会社に、この一覧をそのまま聞いてみてください。答えが返ってこない項目から手を付けてください。
- 本番で動いているサーバーとコンテナの一覧があり、それぞれの OS と Web サーバー、プログラム言語のバージョンが書かれているか
- その中に、提供元のサポートが終わったもの（CentOS 7、PHP 8.1 以前など）が含まれていないか
- サポートの期限が1年以内に来るもの（PHP 8.2 など）について、次に上げる先と時期が決まっているか
- 動いているソフトを KEV カタログと照らし合わせ、攻撃に使われた弱点が残っていないか確かめたか
- コンテナのイメージを最後に作り直したのはいつか、作り直しが決まった日程で動いているか
- 本番と同じ構成の検証環境があり、更新の前に確かめる項目が決まっているか
- 更新して問題が出たときに、前の状態に戻す手順が書かれ、一度試してあるか
- 毎月の更新を誰の承認で本番に入れるか、止める基準とあわせて決まっているか
一覧の8つの項目のうち、1つ目の一覧が無ければ、他の項目は確かめようがありません。まずは一覧を作るところから始めてください。サーバーの台数が少なければ、担当者や委託先への聞き取りで下書きを作れます。
2つ目と4つ目で古いものや攻撃に使われた弱点が見つかった場合は、すぐに上げられるものから手を付けます。上げると他の部品も動かなくなるものは、検証環境で試す計画を立ててから進めます。古くなったシステムを一度新しくしたい、作り直すかどうかを含めて相談したいという場合は、はてなベースでもお手伝いしています。
古いまま動いているシステムの更新と作り直しをお手伝いします
サポートが終わった OS やプログラム言語のまま動いている Web サイトやシステムについて、現状の確認から、更新するか作り直すかの判断、更新した後の運用の決め方までご相談いただけます。