WordPressは、Webサイトのコンテンツを管理するCMSとして広く利用されています。しかし、一般的なWordPressサイトでは、コンテンツの管理とWebページの表示を同じシステムが担当するため、WordPress本体やプラグインなどの実行環境がインターネットに公開されています。
これまでの記事では、WordPressを非公開にし、公開サイトを静的化することで、セキュリティリスクを減らせることを紹介してきました。
では、実際にWordPressを非公開にするには、どのような構成が必要なのでしょうか。
今回は、WordPressを非公開で運用するための基本構成と、その仕組みについて解説します。
WordPressを非公開にするとは？
ここでいうWordPressの非公開化とは、Webサイトそのものを非公開にすることではありません。
WordPressをコンテンツ管理専用のシステムとして利用し、一般の訪問者がアクセスするWebサイトとは分離することです。
一般的なWordPressサイトでは、訪問者がページにアクセスすると、WordPressがデータベースから必要な情報を取得し、HTMLを生成して返します。
一方、非公開WordPressでは、WordPressが生成したコンテンツデータを別の仕組みで取得し、公開用のHTMLをあらかじめ作成します。
訪問者がアクセスするのは、作成済みのHTMLや画像などの静的ファイルです。
この構成では、公開サイトにWordPress本体やデータベースを設置する必要がありません。
WordPressの管理機能を維持しながら、公開環境からWordPressの実行処理を切り離せることが大きな特徴です。
基本構成は3つの役割に分かれる
非公開WordPressと静的サイトを組み合わせる場合、システムは大きく3つの役割に分かれます。
① コンテンツを管理するWordPress
WordPressは、記事やお知らせ、画像などのコンテンツを管理するために使用します。
管理者は従来と同じようにWordPressの管理画面から記事を作成・編集できます。
ただし、WordPressは一般の訪問者に公開せず、管理者や必要なシステムだけがアクセスできるように制限します。
例えば、管理用のサブドメインにWordPressを設置し、Basic認証や二要素認証などを組み合わせてアクセスを制御します。
さらに、外部からのアクセス自体を遮断できるローカルサーバーや社内サーバーで運用する方法もあります。
重要なのは、WordPressをどこに設置するかではなく、誰が、どのような経路でアクセスできるかを制御することです。
② 公開用のWebページを生成する仕組み
WordPressで管理しているコンテンツを取得し、公開用のHTMLを生成します。
この処理には、Astroなどの静的サイトジェネレーター（SSG）を利用できます。
Astroは、WordPressのREST APIなどを通じて記事や画像の情報を取得し、Webページを構築します。
一般的なWordPressではページへのアクセス時にHTMLを生成しますが、静的サイトでは公開前にHTMLを生成します。
この処理を「ビルド」と呼びます。
ビルド時に必要なデータを取得するため、公開サイトからWordPressへアクセスする必要はありません。
また、WordPressへの接続に必要な認証情報も、公開サイトではなくビルド環境で管理できます。
③ 静的ファイルを配信する公開サーバー
ビルドによって生成されたHTML、CSS、JavaScript、画像などを公開サーバーに配置します。
公開先には、一般的なレンタルサーバーやCDNを利用できます。
公開サーバーにはWordPress本体やデータベースを設置しないため、WordPressの管理画面やプラグインを直接攻撃される経路をなくせます。
ただし、静的サイトであっても、公開サーバーの設定不備やJavaScriptの脆弱性など、別のセキュリティリスクがなくなるわけではありません。
WordPressに由来する攻撃対象を公開環境から取り除くことが、この構成の目的です。
コンテンツの更新から公開までの流れ
非公開WordPressを利用する場合、コンテンツの更新から公開までは次のような流れになります。
STEP 1：WordPressでコンテンツを更新する
管理者がWordPressの管理画面にログインし、記事やお知らせを作成・編集します。
ここまでは、一般的なWordPressとほとんど変わりません。
STEP 2：ビルド処理を実行する
コンテンツの更新後、AstroなどのSSGでビルドを実行します。
ビルドは管理者が手動で実行するほか、WordPressの更新をきっかけに自動実行する仕組みも構築できます。
STEP 3：WordPressからデータを取得する
ビルド処理がWordPressのREST APIにアクセスし、必要なコンテンツデータを取得します。
取得対象を公開用のコンテンツに限定することで、不要な情報を外部に渡さない設計にできます。
WordPressへのアクセスを制限している場合は、ビルド環境からのアクセスを許可する仕組みも必要です。
STEP 4：静的ファイルを生成する
取得したデータをもとに、公開用のHTMLや関連ファイルを生成します。
この段階で、公開サイトに必要なページが作成されます。
STEP 5：公開サーバーに配置する
生成された静的ファイルをレンタルサーバーやCDNに配置します。
これを「デプロイ」と呼びます。
デプロイが完了すると、訪問者は新しいコンテンツを閲覧できるようになります。
このように、WordPressでの更新と、公開サイトへの反映を別々の処理として管理することが、従来のWordPressとの大きな違いです。
WordPressを非公開にする3つの構成
基本的な仕組みは同じでも、WordPressと公開サイトをどこに配置するかによって、運用方法やセキュリティの考え方が変わります。
代表的な構成は、次の3つです。
① レンタルサーバー内で分離する
1つのレンタルサーバーを利用し、WordPressと公開サイトを別々の領域に配置する方法です。
例えば、管理用サブドメインにWordPressを設置し、本ドメインでは静的ファイルだけを公開します。
既存のレンタルサーバーを活用できるため、比較的導入しやすい構成です。
ただし、WordPressと公開サイトが同じサーバー上にあるため、サーバー自体が侵害された場合には、両方が影響を受ける可能性があります。
また、WordPressへのアクセス制限や、公開ディレクトリとの分離を適切に設定する必要があります。
② WordPressと公開サイトを別のサーバーに配置する
WordPressはレンタルサーバーで管理し、公開サイトはCDNなどから配信する方法です。
WordPressの管理環境と公開環境を、サーバー単位で分離できます。
公開サイトへのアクセスがWordPressのサーバーに集中しないため、表示速度や負荷分散の面でもメリットがあります。
また、公開サイト側で問題が発生しても、WordPressの管理環境への影響を限定しやすくなります。
一方、複数のサービスを利用するため、ビルドやデプロイの設定、サービス間の認証情報の管理が必要です。
③ WordPressをローカル・社内サーバーで運用する
WordPressをインターネットに公開せず、ローカル環境や社内ネットワーク内で運用する方法です。
管理者はローカルネットワークなどからWordPressを操作し、ビルドした静的ファイルだけを公開サーバーへ送ります。
この構成では、WordPressへの外部からの直接アクセスを遮断できます。
公開サイトが攻撃を受けても、そこからWordPressへ直接アクセスできる経路を設けないことで、管理環境への影響を限定しやすくなります。
ただし、ローカルサーバーの保守やバックアップ、停電・機器故障への対応などは必要です。
また、外部のビルドサービスを利用する場合は、非公開ネットワーク内のWordPressからデータを取得する方法も考慮しなければなりません。
非公開化は被害の連鎖を防ぐ障壁にもなる
WordPressを非公開にすることで、公開サイトからWordPressへの直接的な攻撃経路を減らせます。
しかし、非公開化の効果は、攻撃を受ける機会を減らすことだけではありません。
管理環境と公開環境を分離することで、侵害された場合の被害の連鎖を防ぐ障壁にもなります。
例えば、公開サイトが侵害された場合でも、そこからWordPressへアクセスできる経路がなければ、管理環境への被害の拡大を抑えられます。
また、WordPressが侵害された場合でも、公開ファイルを直接変更できない構成であれば、攻撃者が公開サイトを改ざんするには、さらに別の仕組みを突破する必要があります。
ただし、非公開化によって、すべてのセキュリティリスクがなくなるわけではありません。
管理者の認証情報が漏洩した場合や、ビルド・デプロイ環境が侵害された場合には、管理環境と公開環境の両方が影響を受ける可能性があります。
そのため、非公開化に加えて、次のような対策も重要です。
- アクセス制御：管理者や必要なシステム以外からのアクセスを制限する
- 認証の強化：二要素認証などで不正ログインのリスクを減らす
- 公開前の確認：生成されたファイルに不正な変更がないか確認する
- 復旧手段の確保：バックアップや過去の公開ファイルから復旧できるようにする
Webサイトのセキュリティでは、侵入を防ぐことだけでなく、万が一侵入された場合の影響を限定し、早期に発見して復旧できる体制を整えることも重要です。
非公開WordPressと静的サイトの構成は、こうした複数の対策を組み合わせやすいという特徴があります。
更新と公開を分けることで、運用の自由度も高まる
WordPressを非公開にするメリットは、セキュリティだけではありません。
コンテンツの更新と公開を分離することで、公開前に生成結果を確認する仕組みを設けられます。
例えば、ビルドした静的サイトを検証用の環境に配置し、表示やリンク、コンテンツの変更点などを確認してから本番公開できます。
また、生成したファイルをGitなどで管理すれば、変更履歴を記録し、問題が発生した際に以前の状態へ戻す仕組みも構築できます。
これらは静的サイトであれば自動的に実現する機能ではありませんが、ビルドとデプロイを分離することで導入しやすくなります。
WordPressをコンテンツ管理に専念させることは、公開サイトの安全性だけでなく、更新・確認・復旧といった運用全体を見直すことにもつながります。
まとめ｜WordPressの非公開化は、管理と公開を分離すること
WordPressを非公開にするために、必ずしも特殊なサーバーや高額なシステムが必要になるわけではありません。
基本となるのは、次の3つの役割を分離することです。
WordPressでコンテンツを管理し、SSGで静的ファイルを生成し、公開サーバーから配信する。
この仕組みを理解すれば、既存のレンタルサーバーを活用する方法から、CDNやローカルサーバーを組み合わせた構成まで、目的や予算に応じた選択ができます。
ただし、WordPressをどこに配置し、どのようにアクセスを制御するかによって、セキュリティや運用負担は変わります。
重要なのは、非公開化そのものを目的にするのではなく、Webサイトの用途や運用体制に合った構成を選ぶことです。
次回からは、今回紹介した3つの構成について、具体的な構築方法や運用上の注意点を解説していきます。
