この回で判断できること
気づく・止める・戻す・再公開する各段階の担当と、準備が足りない部分を整理できます。社内で判断・記録することと、専門家へ依頼することを分けて考えます。
A社に、取引先から連絡が来たら
従業員20名のA社は、お知らせと問い合わせフォームのある企業サイトを運営し、制作会社と保守契約を結んでいます。
A社ができているのは、バックアップが定期保存され、その結果を保守先が確認していることです。
もし取引先から「いつもと違うページが表示された」と連絡が来たら、どうするでしょうか。兼任の担当者が保守先に連絡しても、サイトを止める判断や事故調査が契約のどこまでに含まれるか、すぐには分からないかもしれません。
制作会社に悪意や怠慢がある設定ではありません。通常の保守と事故時の対応範囲について、認識が十分に共有されていなかったという想定です。
※A社は説明用の想定事例であり、実在の顧客・被害事例ではありません。取引先からの連絡も、もし起きた場合を考えるための場面です。
1．気づく：WordPressの改ざんや異常を、どう発見するか
異常の発見は、セキュリティの警告だけがきっかけではありません。サイトが開けない、問い合わせが届かない、取引先から表示について指摘された、といった変化も確認の入口です。
ただし、メール不達や表示の乱れは、障害や設定不備でも起こります。兆候だけで攻撃と断定せず、いつ、どこで、何が起きたかを記録します。
確認の手段には、ファイルの改ざん検知、操作・アクセスのログ、稼働監視、Search Consoleのセキュリティ通知、フォームやメールの動作確認があります。
ログとは、通信や操作などの記録です。WordPressのHardeningは、IPアドレス・時刻・操作を調査の手がかりとして挙げ、ファイルの変更・追加を監視する方法も説明しています。Hardening「Logging」「Monitoring」
どの情報が残るかは、ログの種類・設定・保存期間で異なります。利用者名を含めて何を追えるかは、保守先に確認しておきましょう。記録があっても、すべての行為や被害を特定できるとは限りません。
Googleがセキュリティ上の問題を検出した場合は、検索結果やブラウザーに警告が出ることがあります。Google「セキュリティの問題レポート」
通知が来ていないことを、安全の証明にしないでください。 運用上は、通知を受ける人、不在時の代替者、保守先へ連絡する条件を決めます。通知先が有効か、実際に読まれているかも確認します。
第3回で扱った防御機能の検知範囲も、この確認につながります。
2．止める：一時停止の判断と、被害を広げない初動
異常が分かったら、「とにかく消して元に戻す」と急ぎたくなります。しかし、削除や上書きによって、原因や影響を調べる手がかりが失われる場合があります。
以下は、事故時の役割を分けるための運用上の提案です。
一時停止については、判断する権限者、実施する技術者、連絡経路、事前手順を決めます。権限者が不在のとき、誰がどの条件で判断を代わるかも用意します。責任者への連絡がつくまで、何も判断できない状態を避けるためです。
メンテナンス表示にしただけで、不正アクセスが止まるとは限りません。 表示を隠すことと、不正な操作や通信の経路を抑える「封じ込め」は別です。止める範囲と方法は、ホストや事故対応の専門事業者と判断します。
不審な管理者アカウントがある、不正な転送が続く、情報流出が疑われる、影響範囲が分からない場合は、自力でファイルを削除したり再インストールしたりして調査を進めず、専門事業者へ依頼する目安とします。
担当者は、発見日時、見えた兆候、誰に連絡したか、その後に何をしたかを記録します。ログや状態の保全方法は専門家に相談し、被害を抑える措置と並行して進めます。証拠を残すために、危険な状態を放置するという意味ではありません。
告知文のひな形と承認者、サイトが止まっても使える電話などの代替連絡手段も、平時に準備しておきましょう。
確認表A：気づく・止める
「分からない」は「未確認」と記録して構いません。役割は目安です。経：経営者が決める／担：社内担当者が行う／専：専門家に依頼する。 必要な知識を持つ社内技術者が「専」を担う場合もあります。
| 確認すること | 役割 | 確認できる人・聞く先 | 注意が必要な目安 |
|---|---|---|---|
| 監視通知を受けて対応を始める人がいるか | 担 | 保守先・社内担当 | 通知先が退職者、未読のまま |
| 一時停止の権限者と緊急時の委任を決めたか | 経 | 経営者・業務責任者 | 承認待ちで誰も判断できない |
| 停止・封じ込めの事前手順があるか | 専 | ホスト・事故対応事業者 | 表示を隠せば止まると思っている |
| 自力調査を止めて依頼する目安と窓口があるか | 担 | 事故対応事業者 | 影響不明のまま削除・上書きする |
| 告知文と代替連絡手段を準備したか | 担 | 広報・業務責任者 | サイト停止で連絡手段も失われる |
| 告知の承認者を決めたか | 経 | 経営者・法務等 | 原因や被害を未確認のまま断定する |
3．並行して判断する：報告・連絡
復旧完了を待たず、次を並行して確認します。
法令上の報告・本人通知： 個人データの漏えい等は、「おそれ」の段階も含め、条件により報告・本人通知が必要です。速報・確報には期限があります。個人情報保護委員会の対応案内と本人通知の案内で要否を確認します。
犯罪被害の相談： 改ざんなどは、警察庁の相談案内を参照します。
技術的な相談・対応依頼： IPAの安心相談窓口は主に個人向けで、企業向け窓口を別途案内しています。企業・組織向け窓口では初動の助言や専門業者一覧の紹介を案内していますが、相談案件の調査・解析には対応していません。JPCERT/CCは対応依頼と相談・情報提供を案内しています。いずれも復旧代行を約束する窓口とは扱いません。
契約上の連絡： ホスト・保守先・委託先・保険等の連絡条件を確認します。
告知は確認済みの事実に限り、根拠なく「漏えいなし」とせず続報を出します。
4．戻す：バックアップからの復旧と、原因への対応
バックアップの設定を確認する前に、経営側と利用部署で「どこまでデータを失ってよいか」「何時間まで止まってよいか」を考えます。これらは業務上の目標であり、決めれば実現できる保証ではありません。
例えば、問い合わせの記録が前の保存時点まで戻った場合、その後の連絡を別の記録で確認できるでしょうか。バックアップの間隔だけでなく、失われた情報を業務として補えるかも考えます。
保存期間・世代・別保存先を確認する
「世代」は、異なる時点で保存したバックアップです。Hardeningは、定期的な取得と信頼できる場所での保管を説明しています。また、侵害から発見まで時間が空く例を挙げ、侵害前の保存分は再構築に、侵害後の保存分は原因調査に役立つ可能性を示しています。Hardening「Data Backups」
ここからは運用上の提案です。最新の一つだけでなく、どの期間まで、いくつの時点を残せるかを確認します。複数世代があっても、すべて侵害後の状態なら、それだけで侵害前へ戻れるとはいえません。
別保存先についても、場所が違うだけで十分とは考えません。同じ認証情報でサイトとバックアップをまとめて削除できないか、同じ障害や侵害で失われないかを、保守先に確認してもらいます。
保存できていることと、必要な状態へ戻せることは分けて確認します。 A社が行っている保存結果の確認に加え、復元の検証まで誰が担うかを明らかにします。
復元と、原因への対応を組み合わせる
専門家には、復元に使うファイルとデータベースの組み合わせに食い違いがないかを確認してもらいます。データベースは、記事や設定などを保存する仕組みです。
さらに、原因となった弱点、残っている不正なアクセス、不審なアカウント、不要な連携を調べ、対応範囲を決めます。本体・プラグイン・テーマを信頼できる配布元から再構成するかどうかも、専門家の判断事項です。
「全パスワードを直ちに変えれば完了」とは考えません。影響を受けた認証情報の失効・再発行は、証拠保全や封じ込めを踏まえ、範囲と順序を専門家と判断します。
端末側の安全も確認が必要です。Hardeningは、利用するパソコンにキー入力を盗むソフトがある場合、WordPressやサーバー側の対策だけでは守れないと説明しています。Hardening「Vulnerabilities on Your Computer」
この点を踏まえ、認証情報を変更するときは、変更後の情報が再び盗まれないよう、安全な端末・環境から行うことを運用上の確認事項とします。
原因が不明なままなら、その不明点も記録します。見た目が戻ったことだけで対応を終えないためです。
5．再公開する：機能と安全性を確認して再開する
再公開は、専門家の技術確認、社内の業務確認、権限者の承認を分けて進めることを提案します。
技術者は、原因への対応、残存アクセス、復元状態などについて、確認できた範囲と未確認の点を伝えます。社内担当者や利用部署は、フォーム送信、メール受信、主要ページなど、実際の業務に必要な動作を確かめます。
その結果を受け、経営側などの権限者が再公開を判断します。「問題は見つからなかった」と「完全に安全である」は同じではありません。判断の根拠と、再開後に確認することを残します。
再開後の監視と、検索サービスの警告
再公開後も、通知、フォームやメールの動作、不審な変化を確認する担当を引き継ぎます。異常が再び見つかった場合の連絡と停止判断も、同じ手順につなげます。
Googleの「セキュリティの問題レポート」に問題がある場合は、表示された例のページだけでなく、サイト全体で問題を修正してから審査をリクエストします。公式案内では、多くの再審査に数日から数週間かかり、結果が通知されるまでは再送信しないよう説明されています。Google「問題を修正する」「再審査にかかる期間」
「手動による対策」は別のレポートです。どのレポートに何が表示されているかを確認し、手続きを混同しないようにします。サイトの再公開、警告の解除、検索評価の回復も、それぞれ別の確認事項です。解除や回復の時期・結果は保証できません。
確認表B：戻す・再公開する
役割の凡例は確認表Aと同じです。未確認の項目は、聞く先と確認担当を決めて残します。
| 確認すること | 役割 | 確認できる人・聞く先 | 注意が必要な目安 |
|---|---|---|---|
| 許容する停止時間とデータ損失を決めたか | 経 | 各業務責任者 | バックアップ間隔と業務要件が不一致 |
| 感染前の時点まで戻れる可能性のある保存期間・世代と、別保存先があるか | 専 | ホスト・保守先・事故対応事業者 | 最新1世代だけ、短期間で上書きされる、本体と同じ障害や侵害で失われる保存先しかない |
| 正常な状態へ復元できると確認してもらったか | 専 | 保守先・事故対応事業者 | 保存成功の通知しかない |
| 原因・残存アクセス・認証情報を確認してもらったか | 専 | 事故対応事業者 | 復元だけで対応を終える |
| フォーム・メール等の主要機能を確認したか | 担 | 利用部署・保守先 | トップページだけ見て再開する |
| 技術確認の結果を受け、再公開を承認する人がいるか | 経 | 技術者・業務責任者 | 判断根拠と承認記録がない |
| 再開後の監視と警告対応を引き継いだか | 担 | 保守先・Search Console管理者 | 再発や警告を放置する |
次回は、構成の選び方と総費用を考える
事故への備えは、バックアップを契約するだけでは完成しません。通知を受ける人、停止を判断する人、復旧を担う人、再公開を承認する人までをつなげておきます。
A社なら、確認できている定期保存を出発点に、「異常が起きたとき、最初に誰へ連絡し、どこまで依頼できるか」を保守先と確認できます。まずは、その連絡先と契約範囲を社内で共有してみてください。
第5回では、WordPressの継続、管理サービスの利用、別の構成への変更を、運用体制と総費用から考えます。
関連記事
- 第1回：WordPressは危険なのか？ 仕組みと責任分担から考える企業サイトの安全
- 第2回：プラグインとテーマ、追加した後まで管理できていますか
- 第3回：誰がどこまで操作できるか。アカウントと権限を見直す
- 第5回：WordPressを続けるか、構成を変えるか。運用と総費用で選ぶ（2026-10-22公開予定）
出典と情報確認日
情報確認日：2026年10月10日。公開日・更新日とは別に、以下の公式資料を確認した日を示しています。
- WordPress Developer Resources：Hardening — ログ、監視、バックアップ、端末側のリスク。
- Google：セキュリティの問題レポート — 警告表示と、修正後の審査手順。
- 個人情報保護委員会：漏えい等の対応とお役立ち資料 — 報告対象と期限の確認。
- 個人情報保護委員会：漏えい等報告・本人への通知の義務化について — 本人通知の案内。
- 警察庁：サイバー事案に関する相談窓口 — 改ざん等の犯罪被害に関する相談。
- IPA：情報セキュリティに関する技術的なご相談 — 主に個人向けの相談窓口と相談範囲。
- IPA：サイバーセキュリティ 相談・届出窓口一覧 — 企業・組織向け窓口の初動の助言と対応範囲。
- JPCERT/CC：依頼・相談する — 対応依頼と相談・情報提供の区分。
