「お使いのサーバーに脆弱性があります」と通知が来たら｜共用サーバでできること・できないこと

ある日突然、「貴社のサーバーで使われているOS・ソフトウェアがサポート終了（EOL）しており、脆弱性のリスクがあります」という通知が届く——。取引先やセキュリティ調査機関、あるいは行政の管轄部門などから、こうした指摘を受けることがあります。特に官公庁・公的機関やその関連団体のサイトでは、管轄省庁やセキュリティ調査機関から、こうした通知が回ってくるケースがあります。

こういった通知を受け取ると、多くの担当者は「何か重大な問題が起きているのでは」と焦ります。ですが、共用レンタルサーバーを使っている場合、利用者側でできること・できないことははっきり分かれています。慌てて動く前に、まず構造を理解することが大切です。

この記事では、こうした通知が来たときの正しい読み方と、現実的な対応の進め方を解説します。

１．通知の中身（よくあるパターン）

この手の通知は、だいたい次のような内容です。

• サーバーで使われているOSやミドルウェアがEOL（開発元のサポート終了）になっている
• あるいは、5年以上バージョンアップされていない可能性が高い
• 具体例として、FreeBSD 12.3 や OpenSSH 7.9 のような、古いバージョン名が挙げられている

そのうえで、多くの場合、次の3点への確認・対応と報告を求められます。

1. サーバー管理者を特定・選定しているか
2. OS・ソフトウェアのアップデートを検討すること
3. 脆弱性診断の実施履歴を確認すること

一見すると「早くアップデートしなければ」と思わせる内容ですが、ここに落とし穴があります。

２．共用レンタルサーバーでは、利用者はOSを更新できない

さくらインターネットに代表される共用レンタルサーバーでは、OSやミドルウェア（OpenSSHなど）はサーバー事業者が一括して管理しています。そして利用者には、いわゆる root権限（サーバーの最上位の管理権限）が渡されません。

これが何を意味するかというと——利用者側では、OSやOpenSSHのバージョンアップを行うことが技術的に不可能だということです。

つまり、通知が指摘している「古いOSをアップデートしてください」は、共用サーバーの利用者にとっては、そもそも実行できない要求なのです。これは決して「管理を怠って放置している」わけではなく、サービスの構造上そうなっているという点が重要です。ここを理解していないと、「対応していない＝危険」という誤解に振り回されてしまいます。

３．では、どう対応・回答すればいいか

やるべきことは「OSを直す」ことではなく、「構造を正しく説明し、事業者の対応体制を根拠に報告する」ことです。具体的には次の流れになります。

① 管理者は「特定・選定済み」と答える

これはシンプルです。サイトの管理を担う担当者や制作会社が決まっていれば、「特定・選定済みです」と回答すれば足ります。

② サーバー事業者の対応体制を確認し、それを根拠にする

OS層の管理は事業者の領域なので、サーバー事業者に「脆弱性への対応体制」を確認します。

たとえばさくらインターネットの場合、共用サーバーは複数サーバーを一括管理する仕組みで、OSやミドルウェアの個別バージョンアップは提供しておらず、root権限も付与されないという前提が明示されています。そのうえで、各種脆弱性については第三者機関も含めて脅威度を確認し、サーバーの根幹が悪用されないよう個別に対応している、というのが同社のスタンスです。CSIRT（セキュリティ対応の専門体制）の設置など、対応体制も公開されています。

こうした事業者の見解を確認・入手し、それを根拠として「アプリケーションのバージョンだけでなく、運用中のサーバー全体として総合的に判断されている」旨を回答します。

③ 脆弱性診断は、未実施なら正直に

独自の脆弱性診断を実施していないなら、正直にその旨を伝えたうえで、「今後、必要に応じてアプリケーション層の診断実施を検討する」と添えるのが無難です。

中長期の視点も一言添える

「当面は現行サービスを利用しつつ、中長期的にはVPSや専用サーバーへの移行も視野に検討する」と方針を示しておくと、報告として誠実で、先を見据えた印象になります。

４．本当に利用者が守るべきは「アプリケーション層」

ここが一番のポイントです。今回の通知はOS層の話ですが、実際のリスクの主戦場は、その上で動いているアプリケーション層——つまりWordPress本体・テーマ・プラグインです。

OSやミドルウェアの管理は事業者に任せられますが、次の領域は利用者（＝保守を担う側）の責任です。

• WordPress本体・テーマ・プラグインを最新に保つ
• 使っていないプラグイン・テーマを削除する
• ログインまわりのセキュリティ（管理画面の保護、ログイン試行制限など）
• 定期的なバックアップ

「サーバーのOSが古い」という指摘に気を取られてOS層ばかり見ていると、本当に狙われやすいアプリ層の対策がおろそかになる——これが避けたい事態です。通知の指摘に正しく回答しつつ、自分たちの守備範囲であるアプリ層をしっかり固める。この切り分けが何より大切です。

まとめ

• 「サーバーに脆弱性が」という通知の多くは、OSやミドルウェアのEOLに関する指摘
• 共用レンタルサーバーでは、OS・ミドルウェアは事業者管理でroot権限もなく、利用者側では更新できない（＝構造上の話で、放置ではない）
• 対応は「事業者の脆弱性対応体制を確認し、それを根拠に報告する」のが現実的
• 利用者が本当に守るべきは、WordPress本体・プラグイン等のアプリケーション層

こうした通知への対応、まるごとお引き受けします

行政・公的機関をはじめ、こうしたセキュリティ通知への対応には、独特の作法があります。「どこまでが自社の責任で、どこからがサーバー事業者の領域なのか」を切り分け、事業者へ確認を取り、報告文にまとめる——慣れていないと、必要以上に不安になったり、逆に見当違いの対応に時間を取られたりしがちです。

GIVでは、公的機関を含むサイトの保守を通じて、こうした通知への一次対応・サーバー事業者への確認・回答文の作成・中長期の移行検討まで対応してきました。あわせて、本当に守るべきアプリケーション層（WordPress本体・プラグインの更新、バックアップ、ログイン保護）の保守も担います。「通知が来たが、どう対応すればいいか分からない」という方は、まずは、ホームページ保守サービスをご確認＆ご相談ください。落ち着いて対応できるよう、状況の整理からお手伝いします。