あるSaaS開発者が、アカウント内のすべてのドメインでCloudflareのBot Fight Modeを有効にしたところ、APIトラフィックが丸一ヶ月間停止してしまい、有料顧客が製品のコア機能を利用できなくなるという事態に陥りました。
問題が表面化したのは、開発者が利用メトリクスの急激な横ばいに気づいた時でした。新規登録は続いていましたが、アクティブなセッションが増えなくなっていたのです。数週間にわたるコードの書き換えとデバッグの末、たった一つのセキュリティ設定が原因であることが判明しました。CloudflareのBot Fight Modeが、そのSaaS自身のAWS Lambdaエンドポイントを悪意のあるボットと判定し、ブロックしていたのです。
たった一つの設定がサービス全体を壊した理由
開発者のスタックはサーバー間通信に依存していました。内部のLambda関数が定期的にSaaSの公開ドメインにデータをポストするという、現代のマイクロサービスアーキテクチャでは一般的なパターンです。Bot Fight Modeは、自動化されたスクレイパーのように見えるリクエストにチャレンジを課したり、ブロックしたりすることで、コンテンツ主体のサイトをデータ収集から保護します。
すべてのゾーンでこのモードを有効にしたところ、CloudflareはLambdaのアウトバウンドリクエストを別の自動化されたクライアントとして扱いました。リクエストはアプリケーションに到達せず、ブロックがエッジで発生したため、SaaSのモニタリングツールにはエラーが表示されませんでした。トラフィックが単に消失しただけだったのです。開発者はCloudflare WorkersのCPU使用率のスパイクを見て、自身のバックエンドではなく外部のスクレイパーを疑ってしまいました。
Cloudflareのログを詳しく調査した結果、LambdaのIP範囲に一致する「Bot Fight Mode」によるブロックエントリを発見しました。影響を受けているゾーンでこの機能をオフにしたところ、APIトラフィックが再開し、利用メトリクスは正常に戻りました。
なぜこのミスがSaaS運営者にとって重要なのか
- API中心の製品には、開かれたサーバー間通信チャネルが必要である。 Bot Fight Modeは、主要なトラフィックがHTML、画像、または静的アセットを求める人間によるブラウザのリクエストであることを前提としています。API、Webhook、または内部コールバックを公開しているSaaSプラットフォームは、アプリケーション層に可視化できるエラーコードが届かないまま、スロットリング（流量制限）されたりブロックされたりする可能性があります。
- グローバルなセキュリティ設定が、あらゆるワークロードに適合することは稀である。 すべてのドメインに単一のCloudflare設定を適用することは、すべてのサイトが同じ脅威モデルを共有しているかのように扱うことになります。コンテンツサイト、フォーラム、そしてSaaSのバックエンドでは、セキュリティ要件が大きく異なります。
- サイレントな失敗は収益を蝕む。 ブロックされたリクエストはアプリケーションに到達しないため、開発者のアラートシステムは作動しませんでした。ユーザーエンゲージメントメトリクスの低下だけが、問題の兆候を示していました。エッジレベルでの積極的なログレビューがなければ、同様の問題は気づかれないまま放置される可能性があります。
同じ運命を避けるために開発者ができること
- 各ゾーンのトラフィックプロファイルを監査する。 Bot Fight Modeを有効にする前に、ドメインが想定しているリクエストタイプ（人間のブラウザ、APIコール、Webhookコールバック、または内部サービス間通信など）をリストアップしてください。それらがコア機能に不可欠な場合は、そのゾーンを「APIファースト」として扱い、ボット緩和設定を最小限に抑えます。
- ステージング環境で変更をテストする。 Cloudflareでは、単一のサブドメインやステージングゾーンに設定を適用できます。変更をグローバルに展開する前に、正当な自動化が引き続き機能することを確認してください。
- オブザーバビリティ・スタックの一部としてエッジレベルのログを監視する。 Cloudflareのファイアウォールおよびボット緩和ログを、SIEM、Loki、またはその他の集約サービスにストリーミングしてください。ブロックされたリクエストのスパイクとアプリケーションメトリクスの低下を相関分析することで、サイレントな失敗を早期に発見できます。
- セキュリティ設定を元に戻せるようにしておく。 ドキュメント化されたロールバックプランを用意しておきましょう。新しいルールが予期しない動作を引き起こした場合は、コードによる回避策に時間を費やす前に、まずそのルールを無効化して変更を確認してください。
- 正しい問いを立てる。 「どうすればスクレイパーを止められるか？」と問うのではなく、「このツールは、今直面している特定の問題を解決するか？」と問いかけてください。スクレイパーをブロックするセキュリティ機能が、オープンなAPIアクセスを必要とするSaaSにとって適切な回答とは限りません。
より広い視点
Bot Fight Modeは、アグレッシブなクローラーから静的コンテンツを保護する必要があるサイトにとっては、依然として価値のあるものです。その欠点は、悪意のあるスクレイパーと、同じHTTPパターンに従う正当な自動化クライアントを区別できない点にあります。
まとめ
単一のCloudflareアカウントで複数のドメインを管理する場合、それぞれを個別のセキュリティゾーンとして扱ってください。Bot Fight Modeは、トラフィックが純粋に人間によるものに限定されている場合にのみ有効にします。API主体のSaaSワークロードについては、設定をオフにするか、カスタムファイアウォールルールを使用して微調整を行ってください。たった一度のクリックが、スクレイパーを止めるのと同じくらい効果的に、正当なトラフィックを沈黙させてしまう可能性があるのです。