Cloudflare導入時のWAF誤遮断を防ぐ：エンドポイント調査とホワイトリスト設計

課題 (Situation / Task)

システムのモダン化に伴いCloudflareを導入した際、最も頭を悩ませたのが「WAF（Web Application Firewall）によって、システムに必要な正当な通信が誤って遮断されてしまう」という現象でした。

決済サービスのWebhookや物流会社のAPI連携など、外部からサーバーへ向かってくるインバウンド通信において、当初設定していたホワイトリストではカバーしきれないケースが発生しました。 さらに厄介なことに、CloudflareのEdge（エッジ）側で通信が遮断されると、オリジンサーバーのアクセスログには記録が一切残らないため、従来の「エラーログを見て対応する」という動的解析が不可能な状態に陥りました。

解決策 (Action)

ログに頼った事後対応ではなく、既存のシステムが持つ外部連携エンドポイント（受け口）を網羅的に洗い出し、通信の性質に応じたWAFのホワイトリストを再構築することにしました。

1. ソースコードの静的解析によるエンドポイントの抽出

アクセスログが利用できないため、ローカルのソースコード群に対して静的解析を実施しました。 具体的には、以下のような条件で外部からのデータ受け取りを処理しているファイルを抽出しました。

  • $_POST、$_GET、php://input などを処理しているWebhook用のコード
  • ファイル名やディレクトリ名に api, webhook, callback, ipn, recv 等のキーワードが含まれるもの

2. 通信の性質によるグループ分けとルール策定

リストアップしたエンドポイントを確認した結果、通信の送信元は大きく2つのパターンに分かれることがわかりました。これを混同してWAFルールを設定すると、正当なユーザーのアクセス（決済画面への遷移など）まで弾いてしまい、カゴ落ちなどのビジネス的な機会損失に直結します。 そのため、性質ごとに以下の2つのグループに分けてルールを検討しました。

グループA：サーバー間通信（IPアドレス制限が可能）

外部決済サービス（SaaS）や物流システムのサーバーから、直接サーバーへリクエストが来る通信です。 これらは、各サービスの公式ドキュメントで公開されている「送信元IPアドレス（CIDR）」が明確であるため、「特定のIPアドレス空間からのリクエスト」を条件にWAFをスキップさせる安全なルールの設計が可能です。

公開されている送信元IPアドレス情報の例

グループB：クライアント通信（IPアドレス制限が不可）

決済完了後のリダイレクトや、フロントエンドのJavaScriptからの非同期呼び出しなど、お客様（購入者）自身のスマートフォンやPCからリクエストが来る通信です。 送信元IPアドレスは無数に存在するため、IP制限をかけるとすべてのお客様がアクセスできなくなってしまいます。したがって、このグループについては 「特定のURLパス」を条件にしてWAFをスキップさせる 必要があります。

3. WAFルールの再構築

洗い出したエンドポイントと、グループAで特定した各外部サービスの送信元IPアドレス（CIDR）を照らし合わせ、Cloudflare上で必要なWAFのスキップルール（ホワイトリスト）を整理・適用しました。

結果と今後の展望 (Result)

上記のアプローチによりエンドポイントを網羅的に特定し、適切なホワイトリストを設定したことで、CloudflareのWAFによる必要な通信の誤遮断トラブルは解消されました。 今回の反省点としては、WAFを有効化する前に、あらかじめソースコードベースでの網羅的な調査とルール策定を済ませておくべきでした。

現状、グループB（クライアント通信）については「特定パスへのアクセスはWAFをスキップする」という広めの回避策をとっています。次のステップとして、Cloudflareのイベントログ（Security Events）を詳細に分析し、「具体的にどのWAFマネージドルール（SQLi検知やXSS検知など）が誤検知を引き起こしているのか」を特定した上で、当該パスに対してはその特定ルールのみをバイパス（例外化）する形へと設定を精緻化し、セキュリティレベルをさらに高めていく予定です。