WordPressのセキュリティ対策には、「侵入を防ぐ」「被害を広げない」「異常を早期に発見する」「迅速に復旧する」という4つの考え方があります。
今回紹介するのは、このうち「侵入を防ぐ」ことを重点的に強化する構築方法です。
既存のレンタルサーバーを活用し、WordPressを非公開にしたうえで、公開サイトを静的ファイルで運用します。
比較的シンプルな構成で、WordPressへの攻撃機会を減らすことを目的としています。
どのようなWebサイトに適している？
この構成は、次のようなWebサイトに適しています。
- 会社案内やサービス紹介が中心のコーポレートサイト
- お知らせやブログなど、WordPressでの更新を継続したいサイト
- 会員機能や決済機能など、複雑な動的処理を必要としないサイト
- 既存のレンタルサーバーを活用し、運用コストを抑えたいサイト
一方、会員サイトやECサイト、リアルタイムでデータが変化するサービスなどは、別の構成が適している場合があります。
また、サーバー自体が侵害された場合の被害の拡大防止については、管理環境と公開環境の分離など、別途対策を検討する必要があります。
基本構成｜1台のレンタルサーバーで管理と公開を分ける
WordPressと公開サイトを、同じレンタルサーバー内の異なるサブドメインに配置します。
| 役割 | 配置・使用技術 |
|---|---|
| コンテンツ管理 | cms.example.com（WordPress） |
| 公開サイト | www.example.com（静的HTML・CSS・JS） |
| 静的サイト生成 | Astro（SSG） |
| コード管理 | GitHub |
| ビルド・デプロイ | GitHub Actions |
| 認証情報の管理 | GitHub Actions Secrets |
WordPressはコンテンツ管理専用とし、サブドメイン全体にBasic認証を設定します。これにより、管理画面だけでなくREST APIなども含めて、外部からのアクセスを制限します。
さらに、WordPressのログインには二要素認証を導入し、管理者アカウントへの不正ログインを防ぎます。Basic認証によるアクセス制限と二要素認証によるログイン保護を組み合わせ、二重の防御を設けます。
一方、公開サイトにはAstroで生成した静的ファイルだけを配置します。訪問者がアクセスしても、WordPressやデータベースが動作することはありません。
更新から公開までの仕組み
コンテンツの更新は、これまでと同じWordPressの管理画面から行います。
公開までの流れは次のとおりです。
- WordPressで更新：記事や固定ページ、画像などを編集する
- GitHub Actionsを実行：手動または設定した方法でビルドを開始する
- データを取得：Basic認証を通過し、REST APIからコンテンツを取得する
- 静的ファイルを生成：AstroでHTMLなどを生成する
- 公開サーバーへ配置：生成したファイルをSFTPなどでデプロイする
Basic認証やAPI、デプロイに使用する認証情報は、GitHub ActionsのSecretsで管理します。
これらはビルド・デプロイ時に必要な処理だけで参照し、公開用ファイルには含めません。認証情報をHTMLやJavaScriptへ書き出さない設計も必要です。
ソースコードはGitで管理するため、変更履歴を確認しながら開発できます。
この構成のメリット
WordPressへの攻撃機会を減らせる
WordPress全体にBasic認証を設定し、一般の訪問者からアクセスできないようにします。
さらに、公開サイトではPHPやデータベースを使用しないため、WordPressの脆弱性を直接狙った攻撃経路を減らせます。
既存のレンタルサーバーを活用できる
WordPressと公開サイトを同じサーバーに配置するため、新たな公開サーバーの契約は原則として不要です。
表示速度と安定性を向上させやすい
公開サイトは生成済みの静的ファイルを配信するため、アクセスのたびにデータベースへ問い合わせる必要がありません。
WordPressの更新方法を維持できる
コンテンツ管理には引き続きWordPressを利用します。管理担当者が新しいCMSの操作を覚える必要はありません。
注意点とデメリット
被害の伝搬を十分に防げるわけではない
WordPressと公開サイトは同じサーバー上にあります。
サブドメインを分けても、ファイルへのアクセス権限などが共通であれば、一方の侵害がもう一方へ影響する可能性があります。
今回の構成は、あくまで侵入の機会を減らすことを主目的とした対策です。
WordPressの保守は引き続き必要
非公開化しても、WordPress本体やプラグイン、PHPなどの更新は必要です。
ただし、一般公開されているWordPressとは攻撃への露出が異なるため、リスクに応じた保守計画を立てられます。
動的機能には別途対応が必要
お問い合わせフォームやサイト内検索などは、外部サービスやJavaScriptなどを利用して再構築する場合があります。
また、WordPressテーマの表示機能をそのまま移せるわけではなく、公開側のテンプレートを作成する必要があります。
構築前に確認したいこと
導入を検討する際には、次の点を確認します。
- レンタルサーバーでサブドメインとBasic認証を設定できるか
- WordPressのREST APIから必要なコンテンツを取得できるか
- GitHub ActionsからWordPressへアクセスし、公開先へデプロイできるか
- フォームや検索など、静的化に伴って再構築する機能があるか
これらを確認することで、既存サイトを活用できる範囲や、必要な改修内容を判断できます。
まとめ｜必要なセキュリティ対策をシンプルに実現する
レンタルサーバーだけでWordPressを非公開にする方法は、既存の環境を活用しながら、WordPressへの侵入リスクを減らす構成です。
一方、被害の拡大防止や異常検知、ロールバックなどは、この基本構成の対象としていません。
すべてのWebサイトに高度な対策が必要なわけではありません。サイトの用途や重要性に応じて、必要な対策を選ぶことが大切です。
次の記事では、WordPressと公開サイトを別の環境に配置し、被害の伝搬防止も強化する「レンタルサーバー＋CDN」の構成について紹介します。
