WordPress サイトのセキュリティ対策は、プラグインを入れて終わりではありません。「誰が管理者アカウントを持つか」「更新をいつまでに当てるか」「乗っ取られたら誰に連絡するか」が決まっていないと、担当者が替わったときや事故のときに対策が続きません。この記事では、WordPress サイトの運用ルールをセキュリティポリシーとして文書にする手順と、書く項目、ひな形を紹介します。内容は2026年10月時点の WordPress 公式ドキュメントと公的なガイドラインに基づいています。
セキュリティポリシーの位置づけ
組織全体の情報セキュリティには、通常、次の2段階の文書があります。
| 文書 | 内容 | WordPress サイトとの関係 |
|---|---|---|
| 基本方針 | 経営者が示す、情報セキュリティに取り組む姿勢と原則 | 組織にすでにあれば、それに従う |
| 対策基準・運用規程 | 具体的なルール（アカウント、更新、バックアップなど） | この記事で作るのは、WordPress サイトに関するこの部分 |
組織としての文書をこれから作る場合は、IPA（情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン」が参考になります。2026年3月に公開された第4.0版には、付録として「情報セキュリティ基本方針（サンプル）」や「情報セキュリティ関連規程（サンプル）」が含まれています（IPA のガイドラインのページ）。
手順1: 対象範囲と資産を書き出す
最初に、ポリシーが対象とするサイトと、守る対象（資産）を一覧にします。ここに載っていないものは管理されないため、外部サービスやドメインも含めます。
| 資産 | 記録すること |
|---|---|
| ドメイン・DNS | 登録事業者、契約者、更新期限、ログインできる人 |
| サーバー | 事業者・プラン、OS・PHP の版、SSH や管理パネルにログインできる人 |
| WordPress | 本番・ステージングの URL、本体の版 |
| プラグイン・テーマ | 名前、版、入手元、有料ならライセンスの管理者 |
| アカウント | 管理画面の管理者、FTP / SFTP、データベース |
| バックアップ | 取得方法、保存先、保存期間 |
| 外部サービス | CDN、メール配信、フォーム、アクセス解析など |
WordPress の部分は、WP-CLI を使うと一覧を書き出せます。
# WordPress 本体の版
wp core version
# プラグインとテーマの一覧（状態・版・更新の有無）
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update
# 管理者アカウントの一覧
wp user list --role=administrator --fields=user_login,user_email,user_registered手順2: 役割と責任を決める
小さなサイトでは1人が兼任することもありますが、役割ごとに担当者と代理を書いておきます。
| 役割 | 主な責任 |
|---|---|
| サイト責任者 | ポリシーの承認、事故時の公表や判断 |
| 運用担当 | 更新の適用、アカウント管理、バックアップと復元テスト、ログの確認 |
| 制作・開発の委託先 | テーマ・プラグインの改修、脆弱性の修正。作業時に使うアカウントの範囲 |
| サーバー事業者 | 契約で定められた範囲（OS の更新、障害対応など）。どこからがサイト側の責任かを確認しておく |
手順3: 項目ごとのルールを決める
ポリシーには、守るべきルールと、それを WordPress でどう実現するかを書きます。数値（日数・回数）はサイトの重要度に合わせて決めます。以下の数値は例です。
アカウントと権限
- 管理画面のアカウントは1人1つとし、共有しない。
- 権限は業務に必要な最小限にする。記事を書くだけの人は「投稿者」や「編集者」にし、「管理者」は限られた人だけにする。
- 管理者には二段階認証を必須にする。
- 退職・契約終了時は、その日のうちにアカウントを削除または権限を外す。
- 委託先には作業期間だけアカウントを発行する。
権限グループの違いは WordPressのユーザー権限一覧と設定方法、設定方法は WordPressで二段階認証（2FA）を設定する方法 と WordPressのパスワードポリシーを設定する方法 を参照してください。
更新
- WordPress 本体のマイナーリリース（セキュリティ修正を含む）は、WordPress の既定の自動更新で適用する。
- プラグイン・テーマの更新は週1回確認する。脆弱性が公表された更新は、公表から例えば3日以内に適用する。
- メジャーアップデートや大きな更新は、ステージングで確認してから本番に適用する。
プラグイン・テーマの導入基準
- 入手元は WordPress.org の公式ディレクトリか、提供元が明確な配布元に限る。
- 長期間更新されていないもの、公式ディレクトリから公開停止になったものは使わない。
- 使っていないプラグイン・テーマは、無効化だけでなく削除する。
管理画面とファイル
管理画面からテーマやプラグインのファイルを編集できる機能は、乗っ取られたときにコードを書き換えられる経路になります。WordPress 公式のセキュリティ強化のドキュメントでも紹介されているとおり、wp-config.php に次の1行を加えると無効にできます。
define( 'DISALLOW_FILE_EDIT', true );ファイルの権限やその他の設定は WordPress 公式の Hardening WordPress を基準にします。
バックアップ
- ファイルとデータベースを毎日取得し、サーバーとは別の場所に保存する（3-2-1 ルール）。
- 少なくとも四半期に1回、別環境で復元できるかを試す。
手順は WordPressの3-2-1バックアップルールを実践する方法 と WordPressのバックアップテストと復元確認の方法 を参照してください。
ログと監視
- 管理画面のログイン、ユーザーの追加・権限変更、プラグインの導入を記録する。
- 記録を月1回確認し、心当たりのない操作がないかを見る。
記録の方法は WordPressのセキュリティ監査ログを設定する方法、毎月の確認項目は WordPressのセキュリティ監査を毎月実施するためのチェックリスト にまとめています。
インシデント対応
- 改ざんや乗っ取りに気付いた人の連絡先（担当者・代理・夜間）を決める。
- 初動（サイトの停止、パスワード変更、ログの保全）を誰が判断するかを決める。
- 個人情報の漏えいの可能性がある場合の、報告と公表の判断者を決める。
初動の順番は サーバーがハッキングされた時の初動対応手順 を参考にしてください。
脆弱性の受付窓口
外部の人がサイトの脆弱性に気付いたときの連絡先を公開しておくと、報告を受け取りやすくなります。RFC 9116 で定められた security.txt を、サイトの /.well-known/security.txt に置く方法があります。Contact（連絡先）と Expires（有効期限）は必須の項目です。
Contact: mailto:security@example.com
Expires: 2027-10-31T23:59:59+09:00
Preferred-Languages: ja, en
Policy: https://example.com/vulnerability-policy/Expires は1年より先にしないことが推奨されているため、期限が切れる前に更新する作業もポリシーに入れておきます。詳しくは WordPressサイトの脆弱性開示ポリシーの作り方とsecurity.txtの設定 を参照してください。
手順4: 文書にまとめる
手順1〜3の内容を1つの文書にします。次のひな形の「例」の部分を自社の内容に置き換えて使ってください。
# ○○サイト セキュリティ運用規程
版: 1.0 / 承認者: サイト責任者 / 承認日: 2026-10-01 / 次回見直し: 2027-10-01
## 1. 目的と対象範囲
- 目的: 本規程は、○○サイトの情報と利用者の個人情報を守るための運用ルールを定める。
- 対象: 本番サイト https://example.com/ とステージング環境、関連するドメイン・サーバー・外部サービス。
## 2. 役割
- サイト責任者: 山田（代理: 佐藤）
- 運用担当: 鈴木（代理: 田中）
- 制作委託先: 株式会社○○（作業時のみアカウントを発行）
## 3. 資産台帳
- 別紙「資産台帳」に記録し、変更時に更新する。
## 4. アカウント
- 1人1アカウント、共有禁止。管理者は2名まで。
- 管理者は二段階認証を必須とする。
- 退職・契約終了日に削除する。
## 5. 更新
- 本体のマイナーリリースは自動更新で適用する。
- プラグイン・テーマは毎週月曜に確認し、脆弱性の修正は公表から3日以内に適用する。
## 6. プラグイン・テーマ
- WordPress.org 公式ディレクトリまたは提供元が明確なものに限る。
- 不要なものは削除する。
## 7. バックアップ
- 毎日、ファイルとデータベースを別の場所に保存し、30日分保持する。
- 四半期ごとに復元テストを行い、結果を記録する。
## 8. ログと監視
- 操作ログを記録し、毎月第1営業日に確認する。
## 9. インシデント対応
- 発見者は運用担当に連絡する（夜間は代理）。
- 初動の判断はサイト責任者が行う。
## 10. 脆弱性の受付
- 連絡先は security@example.com。security.txt を年1回更新する。
## 11. 見直し
- 年1回、および重大な事故・体制変更の後に見直す。
## 改訂履歴
- 1.0（2026-10-01）初版パスワード、API キー、サーバーの IP アドレスなどの秘密情報はポリシー本文に書きません。必要なら、アクセスを限ったパスワード管理ツールで管理し、ポリシーには「どこで管理するか」だけを書きます。
手順5: 周知し、運用の記録を残す
- 作成した規程は、関係者全員（委託先を含む）に共有し、読んだことを確認する。
- 更新の適用、復元テスト、ログの確認を行ったら、日付と結果を記録する。記録があると、ルールが守られているかを見直しのときに確かめられる。
- 規程は、年1回と、事故や担当者の交代、サーバーの移転などがあったときに見直し、改訂履歴に残す。
まとめ
- セキュリティポリシーは、WordPress サイトの運用ルール（誰が・何を・いつまでに）を文書にしたもの。組織の基本方針があればそれに従い、IPA のガイドラインの付録も参考になる。
- 対象範囲と資産を洗い出し、役割分担を決める。
- アカウント・更新・プラグイン導入・ファイル編集・バックアップ・ログ・インシデント対応・脆弱性の受付について、具体的な数値と実現方法を書く。
- 秘密情報は書かず、周知・記録・定期的な見直しまでを規程に含める。
関連記事: