はじめに
前回の記事では、WordPressサイトをCloudflare経由で公開するためのネームサーバー切り替え手順とその際の確認/注意すべき事項を整理しました。
ネームサーバーの切り替えが完了すれば、Cloudflare経由でサイトを公開すること自体は可能になります。
ただし、Cloudflareを導入した直後は、SSLやキャッシュ、WAFなどの初期設定が適切でないことがあります。設定によっては、サイト管理者用の管理画面が正常に動作しなかったり、意図しないキャッシュが発生したりすることもあります。
本記事では、Cloudflare導入後に最低限確認しておきたい初期設定を紹介します。
Cloudflareとアプリケーション側の役割分担を整理する
Cloudflareを導入すると、WAFやキャッシュ、Bot対策などを前段で利用できるようになります。
ただし、それだけでサイト運用に必要な保護をすべて置き換えられるとは限りません。アプリケーション側で行うべき監視や制御もあるため、役割分担を整理しておくと運用しやすくなります。
Cloudflareが担いやすい役割
Cloudflareは、サイトの前段でリクエストを受ける構成になるため、入口での制御を担当しやすいのが特徴です。
たとえば、以下のような役割はCloudflareと相性が良いと言えます。
- WAFによる一般的な攻撃の検知・遮断
- ログイン画面や特定URLへのアクセス制御
- Bot対策やレート制御
- 公開ページのキャッシュ最適化
アプリケーション側が担いやすい役割
一方で、アプリケーション内部の状態やCMS（Content Management System）固有の挙動に関わる部分は、アプリケーション側の機能で補うほうが分かりやすいことがあります。
たとえば、以下のような役割です。
- 管理ユーザーのログイン通知
- ファイル改ざん検知
- アプリケーション内部の設定変更監視
- CMS固有のセキュリティチェック
どちらか一方に寄せすぎない
Cloudflareは前段で広くリクエストを制御できますが、アプリケーション内部の状態まで詳細に把握できるわけではありません。
逆に、アプリケーション側の機能だけに頼ると、不要なトラフィックを入口で減らすという観点は弱くなります。
そのため、前段の制御はCloudflare、アプリケーション内部の監視や補助はアプリケーション側、というように役割を分けて考えると整理しやすくなります。
前提条件
本記事は、以下のような前提でCloudflare導入後の初期設定を確認するケースを想定しています。
- Cloudflareの Full setup（ネームサーバー切り替え） が完了している
- Cloudflare経由でサイト表示できる状態になっている
- 本記事では、公開直後に最低限確認しておきたい初期設定を扱う
Cloudflare Accessを用いた追加の認証保護については次の記事で扱います。
1. SSL/TLSのモードを確認する
Cloudflare導入後に最初に確認したいのが、SSL/TLSの暗号化モードです。
この設定は、ブラウザ ⇔ Cloudflare 間だけでなく、Cloudflare ⇔ オリジンサーバー 間をどのように暗号化するかにも関わります。
設定が適切でない場合、サイトが正常に表示できなかったり、HTTPSに関するエラーが発生したりすることがあります。
Cloudflareダッシュボードの SSL/TLS → 概要 から、現在の暗号化モードを確認します。
1-1. Full (strict) に設定する
Cloudflare公式では、可能であれば Full (strict) を選ぶことが推奨されています。
Full (strict) では、Cloudflareからオリジンサーバーへ接続する際にもHTTPSを使用し、さらにオリジンサーバー側の証明書が有効であることを検証します。
そのため、Cloudflare ⇔ オリジンサーバー間も含めて、より安全に暗号化通信を行いたい場合に適した設定です。
先ほどの画面の「設定」からフル（厳密）を選択します。もし フル (厳密) でオリジンへ正常に接続できない場合は、まず フル に変更して表示確認を行います。
補足：フル と フル (厳密) の違い
フル も Cloudflare とオリジンサーバーの間を暗号化しますが、オリジンサーバー証明書の厳密な検証までは行いません。
一方、フル (厳密) では、オリジンサーバー側が以下の条件を満たす証明書を提示している必要があります。
- 有効期限内であること
- パブリックに信頼されたCA（Let's Encryptなど）または Cloudflare Origin CA によって発行されていること
- 証明書のホスト名がアクセス先と一致していること
この条件を満たしていない状態で フル (厳密) を有効にすると、526 エラー が発生することがあります。
オリジンサーバー側の証明書状態に自信がない場合は、まず フル で表示確認を行い、その後 フル (厳密) へ引き上げる進め方でも問題ありません。
フル は暫定的な切り分け用として、本番運用では フル (厳密) に引き上げることを目標にしてください。フル のまま運用を続けると、オリジンサーバーの証明書が検証されないため、中間者攻撃のリスクが残ります。
すでにオリジンサーバー側で有効な証明書を利用しており、ホスト名も一致していることが分かっている場合は、最初から フル (厳密) を選んで問題ありません。
1-2. あわせて確認したいポイント
SSL/TLSモードを変更した後は、少なくとも以下を確認しておきます。
https://example.com/に問題なくアクセスできるかhttps://www.example.com/にも問題なくアクセスできるか- ブラウザ上で警告が出ていないか
- リダイレクトループが発生していないか
Cloudflare公式でも、環境によっては Mixed Content や redirect loops の調整が必要になることが案内されています。
補足：Always Use HTTPS について
HTTPアクセスを常にHTTPSへリダイレクトしたい場合は、SSL/TLS → Edge Certificates → Always Use HTTPS の有効化も検討できます。
ただし、まずはSSL/TLSの暗号化モードとサイト表示が安定していることを確認してから有効化するほうが、問題の切り分けはしやすくなります。
2. 管理画面やログイン関連をキャッシュ対象から外す
Cloudflare導入後は、公開ページだけでなく、管理画面やログイン関連のURLが意図せずキャッシュ対象になっていないかも確認しておきます。
管理画面や認証関連のページは、ログイン状態や操作内容によって表示やレスポンスが変化することが多く、静的ページと同じようにキャッシュすると不具合の原因になりやすいためです。
この考え方はWordPressに限らず、管理画面や認証を持つWebアプリ全般に共通します。Cloudflareでは、キャッシュルールで特定URLをBypassすることで、キャッシュ対象から除外できます。
アクセス制御は4章やCloudflare Accessに関する記事で別途行います。
2-1. WordPressで除外しておきたい代表例
WordPressでは、少なくとも以下のようなURLをキャッシュ対象から外しておくと安全です。
/wp-admin/*/wp-login.php*
Cloudflareの Caching → Cache Rules からルールを作成し、これらのパスに対してキャッシュをバイパスする設定をします。
設定例
- フィールド：URI パス
- オペレーター：次で始まる
- 値：/wp-admin/
- 「キャッシュをバイパスする」にチェック
補足：なぜ除外が必要か
管理画面やログインページをキャッシュすると、ログイン後の表示が意図どおり更新されなかったり、セッションや認証まわりの挙動に影響したりすることがあります。
特に、管理画面はユーザーごとに表示内容が変わるため、公開ページと同じ考え方でキャッシュしないほうが安全です。
2-2. まずは最小限の除外から始める
最初から細かく除外条件を増やしすぎると、かえって設定の意図が分かりにくくなります。
まずは、管理画面とログイン画面のように、明らかに動的なURLをキャッシュ対象から外し、公開ページにはCloudflareのキャッシュを活かす構成がシンプルです。
2-3. 設定後に確認したいポイント
キャッシュ除外ルールを追加した後は、少なくとも以下を確認しておきます。
- 管理画面、ログイン画面が正常に表示されるか
- ログイン状態の変化に応じてページ表示が正しく切り替わるか
必要に応じて、ブラウザの開発者ツール（F12）で cf-cache-status を確認し、管理系ページが意図どおりキャッシュされていないこともあわせて見ておくと切り分けしやすくなります。
画像の例では、cf-cache-status: DYNAMIC となっていることが分かります。これは期待通りの動きとなります。
補足：
DYNAMICは、「Cloudflareを経由しているものの、キャッシュ対象としては扱われていない」状態を示します。環境によっては「BYPASS」等、同様にキャッシュされていないことを示す別の値になる場合もあります。
3. Cloudflare WAFを確認する
Cloudflare導入後は、WAFが有効な状態になっているかも確認しておきます。
CloudflareのWAFでは、あらかじめ定義された Managed Rules（Cloudflare 管理ルールセット） を利用することで、一般的な攻撃手法や既知の脆弱性に対する保護を比較的簡単に導入できます。
3-1. Cloudflare 管理ルールセットが有効かを確認する
Cloudflareダッシュボードの セキュリティ → 概要 → 検出ツール →Web アプリの脆弱性 から、Cloudflare 管理ルールセット の状態を確認します。
初期状態でも Cloudflare 管理ルールセット が有効になっている構成であれば、基本的な保護はすでに働いています。
基本的にはデフォルト有効、かつ常にアクティブで固定されています。
WAFは設定項目が多いため、導入直後から細かいチューニングまで行おうとすると、かえって運用が複雑になりやすくなります。
補足：Managed Rules は何をしているのか
Managed Rules は、Cloudflareが用意している事前定義ルール群です。
Cloudflare公式では、主に以下のような脅威への保護を継続的に更新することが案内されています。
- ゼロデイ脆弱性
- 一般的なWeb攻撃手法
- 漏えいした認証情報の悪用
- 機微データの抽出
また、ルールにはタグが付与されており、wordpress のようなタグで関連ルールを探しやすくなっています。
3-2. 設定後に確認したいポイント
WAFの確認後は、少なくとも以下を確認しておきます。
- Managed Rules が有効になっているか
- Security Events にイベントが記録されているか
- 通常のサイト表示や管理画面操作に支障が出ていないか
Cloudflareダッシュボードの セキュリティ → Analytics → イベント でイベントを確認すると、どのルールが検知したかを把握できます。
このように管理ルールや、必要に応じて、有効化したボットファイトモード由来のイベントが確認できれば、Cloudflare側で検知が行われている状態です。
もし管理画面や特定機能で意図しないブロックが発生する場合は、いきなりWAF全体を緩めるのではなく、まずは該当イベントを確認し、必要最小限の例外設定を検討する流れが安全です。
補足：Bot Fight Mode について
Freeプランでも、Cloudflareの Bot Fight Mode を利用することができます。
Bot Fight Mode は、既知のボットパターンに対して計算コストの高いチャレンジを返すシンプルな機能で、小規模サイトの簡単なボット対策としては導入しやすい選択肢です。
一方で、Bot Fight Mode はドメイン全体に適用され、特定のパスやIPだけを例外にすることができません。
そのため、まずは Managed Rules やログイン画面保護などの基本設定を確認したうえで、必要に応じて追加で有効化を検討すると良いです。
有効にする場合は、 セキュリティ → 概要 → 検出ツール →ボットトラフィック から有効にできます。
4. ログイン画面の保護
Cloudflare導入後は、ログイン画面に対する不要なアクセスを減らすための保護も検討しておきます。
ログイン画面は、公開ページと比べてブルートフォース攻撃や不要なスキャンの対象になりやすいためです。
Cloudflareでは、セキュリティ → セキュリティ ルール から、特定URLに対して Managed Challenge や Block を適用できます。
4-1. まずはログイン画面に条件付きでチャレンジをかける
最初から完全にブロックするのではなく、まずは Managed Challenge を利用して、不要なアクセスだけに追加確認を求める形から始めると運用しやすくなります。
たとえば、WordPressでは /wp-login.php へのリクエストを条件にし、自分のIPアドレス以外に Managed Challenge を適用する形が分かりやすい例です。Cloudflare公式にも、特定条件に一致したリクエストへ challenge を返すカスタムルールのユースケースがあります。
補足：Challenge と Block の使い分け
Managed Challenge は、正規ユーザーの操作を完全には遮断せず、不審なアクセスに追加確認を求める（Cloudflareが自動でJSチャレンジやCAPTCHAを出す）方法です。
一方、Block は条件に一致したアクセスをそのまま拒否します。
まずは誤検知時の影響を抑えやすい Managed Challenge から始め、必要に応じて Block を検討するほうが安全です。Cloudflareの custom rules では、アクションとして challenge や block を選択できます。
4-2. ルール例（WordPress の場合）
例えばWordPressのログイン画面を保護する例としては、次のような条件が考えられます。
- URI Path が
/wp-login.phpと一致する - 送信元IPアドレスが、自身の固定IPや許可IPと一致しない
この条件に一致した場合のアクションとして、まずは Managed Challenge を選択します。
画像の例では許可IPのリストを条件に含めています。リストの作成方法は後程説明します。
Cloudflare公式でも、許可したいIPを条件に分ける考え方や、不要トラフィックへ challenge を返すユースケースが案内されています。
4-3. 許可IPリストの作成方法
画像の例では許可IPリストを作成し、それを条件文に組み込んでいました。許可IPリストの作成方法について説明します。
ダッシュボードから、アカウントの管理 → 構成 → リスト → カスタムリスト から「リストを作成」をクリックします。
以下を入力し、まずは許可IPを入れる「箱」となるリストを作成します。
- 識別子：リストの名前を入力
- タイプ：IP を選択
先ほどの画面に戻り、作成したリストの右にある「編集」→「項目を追加」をクリックし、許可IPを追加します。
補足：固定IPがない場合の考え方
自宅回線やモバイル回線などで固定IPを前提にできない場合は、単純なIP許可方式だけでは運用しづらいことがあります。
その場合も、まずはログイン画面全体に Managed Challenge を適用し、通常利用に支障がないかを確認する進め方が現実的です。
より強い保護を行いたい場合は、次回の記事で扱う Cloudflare Access のような追加認証も選択肢になります。
4-4. 設定後に確認したいポイント
ログイン画面保護のルールを追加した後は、少なくとも以下を確認しておきます。
/wp-login.phpへ通常どおりアクセスできるか- 許可したいIPからのアクセスが過剰に遮断されていないか
- 想定外のアクセスに対して Challenge が動作しているか
- Cloudflareの Security → Events にイベントが記録されているか
もし正規の操作まで影響を受ける場合は、いきなりルールを削除するのではなく、まずイベント内容を確認し、条件の見直しや許可IPの調整を行うのが安全です。
おわりに
ここまでで、Cloudflare導入後にWordPressサイトで最低限確認しておきたい初期設定を一通り済ませることができました。
Cloudflare経由でサイトを公開できる状態になっていても、SSL/TLSのモードやキャッシュ設定、WAF、ログイン画面保護などが未確認のままだと、表示不良や意図しないアクセスの見落としにつながることがあります。
そのため、まずは今回扱ったような基本設定を押さえたうえで、公開ページにはCloudflareのメリットを活かしつつ、管理画面や認証関連は慎重に扱う構成にしておくと運用しやすくなります。
また、Cloudflareは前段でのリクエスト制御に強みがありますが、アプリケーション内部の監視や通知などは、アプリケーション側の機能と役割分担して考えるのが現実的です。
次回の記事では、さらに管理画面の保護を強める方法として、Cloudflare Access を利用した追加認証の設定をします。
参考情報
- Cloudflare Docs: Full (strict)
- Cloudflare Docs: Full
- Cloudflare Docs: Always Use HTTPS
- Cloudflare Docs: Cache Rules
- Cloudflare Docs: Cloudflare cache responses
- Cloudflare Docs: WAF Overview
- Cloudflare Docs: Managed Rules
- Cloudflare Docs: Bot Fight Mode
- Cloudflare Docs: Custom rules
- Cloudflare Docs: Create a custom rule in the dashboard
- Cloudflare Docs: Allow traffic from IP addresses in allowlist only
- Cloudflare Docs: Challenge bad bots
