WordPressの改ざん被害の多くは、公開時の設定と、その後の運用体制に原因があります。制作段階で決まってしまうことも多く、後から直すのは手間がかかります。

また、被害が出てから「制作会社が悪い」「いや運用の問題だ」という話になっても、エンドクライアントには関係ありません。事前に線引きしておくことは、双方を守ることにもなります。

1. 使用プラグインの選定基準

プラグインは脆弱性の主要な侵入口です。最終更新日と有効インストール数を基準に選んでいるか確認してください。更新が1年以上止まっているプラグインが入っていれば、その時点でリスクです。

「便利だから」だけで選ばれていないか、代替の検討がされているかを聞くと、選定の考え方が分かります。

2. 不要なプラグイン・テーマの削除

停止中でもファイルが残っていれば攻撃対象になります。「停止」ではなく「削除」されているかを確認してください。既定テーマも、使わないものは1つだけ残して削除するのが安全です。

3. 管理画面のアクセス制限

ログインURLの変更、試行回数の制限、IP制限のいずれかが入っているかです。標準のままだと、公開直後から総当たり攻撃を受け続けます。

4. 管理者アカウントの設計

ユーザー名が「admin」になっていないか、投稿者名から推測できないか。権限が必要以上に高いアカウントが作られていないか。

制作時のテスト用アカウントが残ったまま納品される例もあります。納品時のアカウント一覧を確認してください。

5. 納品時の認証情報

制作中の共有パスワードのまま納品されていないかです。納品時に必ず変更してください。制作会社のPCが侵害された場合の被害範囲を限定できます。

FTP、データベース、管理画面のすべてが対象です。

6. バックアップの初期設定

公開時点でバックアップが動いているか。ファイルとデータベースの両方か。保存先はサーバーと別か。公開してから設定しようと思っていて、そのまま忘れられるのが典型的なパターンです。

更新の担当者は誰か

制作会社なのか、エンドクライアントなのか、外部の保守業者なのか。ここが曖昧なまま公開されるサイトは非常に多く、結果として誰も更新しない状態になります。

「クライアント側で更新してください」と伝えただけでは、実際には行われないことがほとんどです。誰が、どの頻度で行うかまで決めてください。

脆弱性公表時に誰が動くか

本体の重大な脆弱性は予告なく公表されます。そのとき「対象バージョンかどうかを誰が確認するのか」を決めておいてください。決まっていなければ、実際には誰も確認しません。

復元できる状態か

バックアップを取っているかではなく、復元を試したことがあるかです。ここが確認できていない現場は多く、いざ戻そうとして失敗する例は珍しくありません。

• 納品後の脆弱性対応が、契約に含まれるか／別途か
• 改ざん被害が発生した場合の責任範囲
• 使用プラグインの一覧と、ライセンスの帰属
• サーバー・ドメインの管理権限をどちらが持つか

最後の項目は、後から乗り換えるときに問題になります。管理権限を渡してもらえず身動きが取れない、という相談は実際にあります。

3番目のライセンスも見落とされがちです。有料プラグインが制作会社の名義で購入されている場合、契約終了後に更新できなくなります。

過去に納品したサイトが気になる場合、次の順で確認すれば大枠は掴めます。

1. WordPress本体のバージョン（重大な脆弱性の対象か）
2. 更新が止まっているプラグインの有無
3. 管理者アカウントの棚卸し
4. バックアップが動いているか

管理サイトが多い場合は、バージョンの一覧化から始めてください。1件ずつ確認していては終わりません。一覧さえあれば、優先順位をつけて対処できます。

点検の頻度

年1回程度でも、放置よりは大きく違います。特に、担当者が変わったタイミング、サーバーを移転したタイミングでは、設定が引き継がれていないことがあるため確認をおすすめします。

• 被害の原因は制作時の設定と公開後の運用体制に集中する
• 制作時はプラグイン選定・不要ファイルの削除・認証情報の変更を確認
• 公開後は「誰が更新するか」「誰が脆弱性を確認するか」を決める
• 管理権限とライセンスの帰属を契約書に入れる
• 既存案件は、バージョンの一覧化から点検を始める