ホームページの表示がおかしくなり、知らないサイトへ飛ばされる。そんなとき、書き換えられたページを戻すだけで、運営を再開してよいのでしょうか。
日本将棋連盟が2026年8月に公表した調査結果では、サイト管理システムの既知の脆弱性が悪用され、不正なファイルが設置されました。再発防止を考える際には、「入口をふさぐ」「変更に気付く」「安全な環境へ戻す」の三つを分けて確認する必要があります。［1］
法人サイトやブログの管理担当者は、まず更新担当、異常時の連絡先、復旧用データを確認してください。外注しているサイトでも、誰がどこまで対応するかを把握しておくことが大切です。
2026年11月3日までに確認した公表資料に基づく技術解説です。一般的な対策例は、当該組織の未公表構成を示すものではありません。
公式調査で確認されたことと、まだ分からないこと
連盟は5月21日付で不正アクセス・改ざん被害を告知し、8月7日に調査結果を発表しました。既知の脆弱性を悪用した不正ファイルの設置と、一部ページの外部誘導コードを確認しています。情報漏えいや持ち出しの痕跡は確認されていないと説明しています。［1］
復旧には被害を受けたサーバー基盤を使わず、新たな環境で再構築しています。今回確認した発表には、管理システムの製品名やCVE番号は示されていません。「WordPressのプラグインが原因」「更新を長期間放置した」といった具体的な断定はできません。［1］
改ざんは、見えている文章の書き換えだけではない
Webサイトは、ページを表示するプログラム、画像、設定、データベースなどの組み合わせで動きます。攻撃者がファイルを書き込める状態になると、利用者が見ているページ以外にも、不正な変更が残る可能性があります。
以下は一般的な説明です。今回の事件で、すべての種類の不正プログラムが見つかったという意味ではありません。見えるコードを削除しただけでは、入口になった脆弱性や、別のファイルの状態まで確認したことにはなりません。
また、同じサイト内であっても、URLやアクセス条件によって表示が違う場合があります。担当者がトップページを一度開いて正常だったとしても、サイト全体の安全確認として十分とは言えません。
更新・WAF・改ざん検知は、それぞれ何をする？
| 対策 | 主な役割 | それだけでは済まないこと |
|---|---|---|
| ソフトウェア更新 | 判明した脆弱性を修正する。 | 既存の不正ファイルの有無を調べる作業。 |
| WAF | Webへの通信を検査し、攻撃を遮断する。 | 元のソフトウェア自体の修正。 |
| 改ざん検知 | ファイルなどの変化を検出する。 | 変化を正当か不正か判断し、復旧する作業。 |
| バックアップ | 必要なデータを戻すための備え。 | 戻すデータが安全かどうかの判断。 |
WAFは、不正なリクエストをアプリへ届く前に遮断する防御として使われます。OWASPの資料でも、仮想パッチは元のソースコードを変更するものではないと説明されています。WAFの導入と、脆弱性の修正は別に管理します。［2］
改ざん検知には、正当な更新との区別も必要です。「変更あり」の通知を誰も見ていなければ、検知の仕組みを置いても対応につながりません。制作会社が作業した日時と通知を照合できる運用にします。
外注先へ確認したいのは「保守していますか」より具体的な質問
保守契約があっても、サーバー、CMS、追加機能、独自プログラムの更新範囲は契約によって違います。「ホームページの更新」が記事の追加だけを指す場合もあるため、対象を具体的に確認します。
たとえば、WordPressで運用する自分のサイトなら、本体、テーマ、プラグイン、PHPなどの更新について、担当と対象範囲を整理します。これはWordPress一般の管理例であり、連盟の使用製品を示すものではありません。
| 質問 | 確認したい理由 |
|---|---|
| 何のソフトを、どのバージョンで使っているか。 | 脆弱性情報が出た際に対象を判定するため。 |
| 緊急の脆弱性が出たら、誰がいつ連絡するか。 | 通常の定期更新まで待つ運用になっていないか確認するため。 |
| 不正ファイルや不審なログを調べられるか。 | 表示の修正だけで終わらせないため。 |
| 停止中に告知ページを出せるか。 | 利用者へ別の安全な経路で案内するため。 |
| 安全な環境へ移す場合、何を戻せるか。 | プログラムとコンテンツを分けて復旧するため。 |
改ざんを見つけたときの進め方
最初に、利用者が被害を受ける経路を止める必要があります。同時に、調査に必要な情報を残します。公開停止、ログやファイルの保全、専門家への連絡について、保守会社と役割を決めておくと初動を進めやすくなります。
不正ファイルを先にすべて消してしまうと、侵入経路や影響範囲を調べにくくなる場合があります。バックアップの上書きや初期化も、調査担当との相談前に急いで行わないようにします。
一般的な復旧では、入口の修正、不正な変更の除去、認証情報の見直し、動作と監視の確認を組み合わせます。再構築が必要かは侵害の範囲によるので、一律に「丸ごと戻せば安全」とは判断できません。
バックアップから戻す前に、いつのデータか確認する
昨日のバックアップであっても、攻撃が数日前から始まっていたなら、不正な変更を含んでいる可能性があります。保存日時だけで選ぶのではなく、ログや調査結果をもとに復元点を判断します。
コンテンツを取り出して新しい環境へ移す場合も、設定やプログラムを無条件にコピーしないことが大切です。復旧を委託するときは、どのデータをどう確認して戻すかを、担当者へ説明してもらいます。
公開再開前に、担当者が確認する順番
一つ目は、今回の侵入口へ対処したかです。復元によって古い脆弱なバージョンへ戻っていないか、更新や設定変更が必要な箇所を確認します。過去のバックアップを使うときは、サイトの復元と修正の適用を一つの作業計画で扱います。
二つ目は、権限と接続情報の確認です。CMSの管理者、サーバー管理、ファイル転送、外部連携など、影響した可能性のある資格情報を調査担当と整理します。今回の事件で、これらの情報がすべて盗まれたと確認されたという意味ではありません。
三つ目は、必要なページと機能の確認です。トップページに加え、検索から来訪される記事、問い合わせ、添付資料、管理画面などを確認します。どの範囲を調べたかを記録すれば、制作会社と発注側で認識を合わせられます。
四つ目は、再発に気付ける状態かどうかです。復旧直後は、ログの確認担当と連絡経路を決め、想定していない変更や外部誘導が出た場合にすぐ公開判断を見直せるようにします。
外部サービスへのリンクも、利用者目線で点検する
サイト本体が安全でも、問い合わせフォームや予約、資料配布などを外部サービスへ委託している場合があります。復旧の際には、リンク先が正しいか、使わなくなったフォームが残っていないかも確認してください。これは今回の原因とは別の、一般的なサイト運用の点検項目です。
日常の確認では、担当者だけが知るURLや管理方法を減らし、外注先と共有できる一覧にしておくと便利です。サイトの構成を把握することが、更新漏れと復旧時の確認漏れを減らす土台になります。
よくある疑問
個人情報を置いていないサイトなら、対策の優先度は低い？
閲覧者の誘導先として悪用されたり、サイト停止によって問い合わせや案内ができなくなったりします。自分が保有する情報だけでなく、訪問者と業務への影響も考えてください。
トップページが正常に表示されたら復旧完了？
表示確認に加え、不正な変更、脆弱性、アカウント、ログを確認する必要があります。閲覧、問い合わせ、管理画面などの必要な動作も点検します。
WAFをオンにすれば、更新はしなくてよい？
WAFはソフトウェアの修正を代行するものではありません。使っている機能と設定に応じて防御を確認し、更新も進めます。
次の保守打ち合わせでは、異常時の対応範囲まで決める
「更新しています」という説明から一歩進め、対象ソフト、通知担当、公開停止の判断、調査、復元を一覧にしてください。サイトを任せることと、管理の状況が分からないことは別です。担当者が次の連絡先を迷わない状態にしておくことが、復旧の備えになります。
