Cloudflare WAFの初期設定とルール調整の手順・注意点

Cloudflare WAFの設定では、どのルールを有効にするかだけでなく、正規の利用者の操作を妨げないかも検討する必要があります。保護を強めようとして設定を一括変更すると、フォーム送信やAPI連携に影響する場合があります。

初期設定は、既定設定を確認し、正常な操作への影響を検証しながら調整することが基本です。ここでは、設定前の準備から本番適用までの流れと、運用支援会社へ依頼する際の確認点を紹介します。

Cloudflare WAFの初期設定前に確認すること

プランで使えるマネージドルールと設定範囲を確認する

Cloudflare WAFは、契約プランによって利用できるマネージドルールや調整機能が異なります。FreeにはCloudflare Free Managed Rulesetがあり、Pro以上ではCloudflare Managed RulesetやOWASP Core Rulesetも利用できます。

設定前に、契約プランと対象ドメインで使えるルールセット、変更できる項目を照合します。別のプラン向けの手順をそのまま適用せず、自社の管理画面と公式ドキュメントを照らし合わせて進めると、設定の行き違いを防げます。

保護する画面・APIと正常な操作を洗い出す

まず、ログイン、問い合わせフォーム、ファイルアップロード、購入手続きなど、保護する画面と正常に通す必要がある操作を整理します。APIや外部サービスから届くWebhookも含め、通信先のURLや送信内容、利用者への影響を把握しておきます。

管理画面を開けるだけでは、動作確認として不十分です。入力から送信完了までの流れや、連携先からの通知を受信できるかまでをテスト項目に含めると、設定後の誤検知を見つけやすくなります。

Cloudflare WAFの初期設定とルール調整の手順

1. マネージドルールの既定設定と適用範囲を確認する

対象ドメインのセキュリティ設定から、利用するマネージドルールセットの有効・無効と適用範囲を確認します。ルールには既定のアクションがあり、誤検知とのバランスを考慮して無効になっているものもあります。

すべてのルールを一括で有効化したり、処理を一律にBlockへ変更したりせず、既定設定を起点に検討します。WordPressなど利用技術に対応するルールも確認し、変更する場合は目的と対象を明確にしてから保存します。

Web通信がプロキシ済みで、対象のマネージドルールセットがデプロイされていることも確認します。DNSのみの通信や、適用対象から除外された通信は、そのWAFルールで検査されません。

2. Logアクションの利用可否に応じて動作を検証する

一致したリクエストを記録するLogアクションは、Enterpriseで利用できます。そのルールでは遮断せずに一致状況を調べられますが、別のセキュリティルールによって通信が遮断される可能性は残ります。

Logを使えない場合も、検証環境や影響を限定できる条件で正常な操作を試し、小さな単位で変更を進められます。検証環境と本番環境の差も整理し、本番で確認する際は対応担当者と変更前の設定へ戻す手順を用意しておきます。

3. Security Eventsで検知したルールと処理内容を確認する

Security Eventsでは、セキュリティ機能が検知・処理した通信を調べられます。テストした日時やURLなどで絞り込み、どの機能・ルールが、どのアクションを実行したかを確かめます。遮断されたという結果だけで、マネージドルールが原因とは判断できません。

Security Eventsの閲覧と、Logアクションの利用条件は別です。また、表示内容にはサンプリングや保存期間の制約があるため、イベントが見つからない場合も、配信元のログや実際の操作結果と照合して原因を追います。

4. 必要なルール調整と限定的な例外設定を行う

正常な操作にルールが一致した場合は、送信内容と検知条件を確認し、対象ルールのアクション変更や例外設定を検討します。例外は、必要なリクエスト条件と該当ルールに絞り、管理画面やAPI全体をまとめて保護対象から外さないようにします。

マネージドルールの例外は、Bot対策やレート制限なども一括で無効にする設定ではありません。調整後は正常な操作が通るかに加え、想定外の通信まで許可していないかを確認し、例外を設けた理由と見直し時期を記録します。

5. 調整後の設定を本番へ適用し、動作を再確認する

検証で決めた設定を本番へ適用し、主要な画面操作とAPI連携を再確認します。少量のテストでは問題がなくても、実際の入力内容や利用環境によって結果が変わるため、適用直後は問い合わせとSecurity Eventsの両方を確認します。

利用者への影響が出た場合は、原因となった変更を特定し、必要に応じて変更前の設定へ戻します。WAF全体を停止する対応を前提にせず、変更日時、対象ルール、適用条件、元の値を残しておくと、影響を絞った修正につなげやすくなります。

本番で正常な通信が遮断された際は、Cloudflareの誤検知の原因と対処法から、WAF以外の機能や配信元の障害も含めて切り分けます。

WAF設定後の見直しと運用支援会社へ依頼する際の確認点

マネージドルールはCloudflareによって更新されます。また、自社サイトの機能追加やAPIの仕様変更によって、以前は問題のなかった通信が検知される場合もあります。初期設定で完了とせず、ルールやサイトの変更に合わせて動作を見直す運用が必要です。

運用支援会社へ依頼する場合は、初期設定に加え、テスト項目の作成、誤検知の調査、例外設定、公開後の見直しまで含まれるかを確認します。対応時間と追加料金の条件も把握しておくと、依頼後の認識のずれを減らせます。

継続的な調整を依頼する場合は、Cloudflare保守・月額サポートの作業範囲を確認し、初期設定だけの費用と月額費用を分けます。

あわせて、正常な操作かどうかを判断する自社・開発会社側の担当者と、ルールを調整する担当者を決めておくと連携が円滑です。設定内容と変更理由、元に戻す手順は自社でも参照できる形で共有してもらうとよいでしょう。

WAFの検証経験と障害時の対応体制は、Cloudflare代理店・運用支援会社の選定基準を使い、対象プランと作業内容をそろえて比較しましょう。