Cloudflare WAFの設定方法｜Managed Rules・Custom Rules・Rate Limitingを安全に導入する
Cloudflare WAFは、WebサイトやAPIへ届くリクエストを検査し、攻撃パターンや自社条件に応じて許可、ブロック、チャレンジなどを実行します。防御を強くするだけなら簡単に見えますが、正常な問い合わせ、決済通知、検索クローラー、社内利用者を止めると事業影響が出ます。
安全な導入では、Managed Rules、Custom Rules、Rate Limitingの役割を分け、Security Eventsで実際の通信を確認しながら適用範囲を広げます。例外も恒久的な全許可ではなく、対象・理由・期限を記録します。
Cloudflare WAFは、まずSecurity Eventsと重要URLの正常通信を把握し、Managed Rulesを段階有効化し、自社固有条件をCustom Rules、連続アクセスをRate Limitingで扱うのが基本です。誤検知時は該当ルールだけを限定調整します。
本記事のポイント
- Managed Rulesは対象範囲と変更影響を確認し、重要経路をテストしてから段階的に有効化します。
- Custom RulesとRate Limitingは、攻撃条件だけでなく正常利用・検索クローラー・Webhookへの影響を確認します。
- 誤検知ではWAF全体を停止せず、ルールID、パス、送信元、期間を特定して最小限の例外を設定します。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| Managed Rules | 既知の脆弱性・攻撃パターン | ベンダー更新を受けながら広く防御 |
| Custom Rules | IP、国、パス、ヘッダーなど自社条件 | 固有の公開範囲や禁止条件を制御 |
| Rate Limiting | 一定時間内の過剰アクセス | ログイン、検索、API、フォーム乱用を抑制 |
| Security Events | 実際に一致した通信 | 誤検知と攻撃傾向を確認 |
| 例外 | 正常通信への影響 | 条件・理由・期限を限定して調整 |
重要経路と正常通信を先に定義する
トップページだけでなく、ログイン、管理画面、問い合わせ、検索、ファイルアップロード、Webhook、API、決済、モバイルアプリなど、止められない経路を一覧化します。各経路で正常な送信元、HTTPメソッド、パス、ヘッダー、頻度を確認します。
WAF変更のたびに同じ確認ができるよう、テスト手順と期待結果を残します。外部サービスからのWebhookは固定IPとは限らないため、公式署名検証や専用パスなど複数条件で保護します。
Managed Rulesを段階的に有効化する
Managed Rulesは広範な攻撃を検知できますが、アプリケーションの実装や古いCMS、特殊なリクエストによって正常通信も一致する場合があります。対象ゾーン全体へ一度に強制せず、イベント観測と重要経路のテストを挟みます。
検知したルールID、リクエストパス、送信元、アクションを記録し、ブロックが必要な攻撃か、正常な業務かを判断します。ルール更新で挙動が変わる可能性もあるため、変更履歴と定期レビューを用意します。
Custom Rulesは狭い条件から作る
Custom Rulesでは、管理画面を特定ネットワークやAccess経由に限定する、不要な国・AS番号・User-Agentをチャレンジする、特定パスへの不正メソッドを止めるなどの条件を作れます。
広いIP範囲や国単位の一括ブロックは、出張者、モバイル回線、クラウドサービス、検索エンジンへ影響する場合があります。最初はLogやManaged Challengeなど影響の小さいアクションも検討し、確信を得てからBlockへ進めます。
Rate Limitingは業務上の最大値から設計する
ログイン試行、検索、パスワードリセット、フォーム送信、API呼び出しなど、乱用されやすい経路に適用します。閾値は平均値ではなく、キャンペーン、バッチ、再送、NAT配下の多数利用者など、正当なピークを考慮します。
IPだけで数えると、企業ネットワークや通信事業者の共有IPをまとめて止めることがあります。利用可能な識別条件、セッション、認証状態、パスを組み合わせ、制限時の画面やAPI応答も確認します。
誤検知は証拠を残して最小限に除外する
利用者から『送信できない』と連絡があったら、発生時刻、Ray ID、URL、操作、送信元、WAFイベントを照合します。WAF全体を無効化すると別の攻撃まで通すため、該当ルールと経路を特定します。
例外には対象ルール、パス、送信元、理由、所有者、期限を持たせます。アプリ側の不適切なリクエストや脆弱な実装をWAF例外で隠していないかも確認し、恒久対応後に例外を削除します。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 止められないURLと外部連携を一覧化した
- 正常通信のテストケースを用意した
- Managed Rulesを段階適用した
- Custom Rulesの条件を狭く始めた
- Rate Limitingで正当なピークを確認した
- Security EventsとRay IDの調査手順を決めた
- 例外に理由・所有者・期限を設定した
よくある質問
WAFを有効にするとサイトが遅くなりますか？
通常はCloudflareのネットワーク上で処理されますが、複雑なルールやチャレンジは利用体験へ影響します。性能だけでなく正常完了率を監視します。
Managed ChallengeとBlockはどう使い分けますか？
確実に不要な通信はBlockを検討し、正常利用の可能性が残る条件ではManaged Challengeで追加確認する方法があります。
検索クローラーを許可リストに入れるべきですか？
User-Agentだけでは偽装できます。Cloudflareの検証済みボット情報や公式IP確認など、信頼できる判定を使います。
誤検知が多い場合はWAFを停止しますか？
停止せず、該当ルール・パス・条件を特定して限定的に調整します。アプリ側の修正が必要かも同時に確認します。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
Cloudflare WAFを観測から段階導入し、攻撃を減らしながら正常利用を止めないための設定・検証・例外管理ガイドです。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
