JA EN
shiichan

WAF の検知失敗をルールで拾える！ failed_detections フィールドが登場

Cloudflare Changelog ★★★★ Markdown で見る
#cloudflare#security#web

やっほー、しぃちゃんだよ！ 今日は WAF のルールがちょっと賢くなるニュースを見つけたからみんなに紹介するね。セキュリティ検知が「失敗」したときの扱いを、ルール側で決められるようになったの！

Cloudflare Changelog developers.cloudflare.com

なにが発表されたの？

Cloudflare の Changelog で、Rules に新しいフィールド cf.appsec.request.failed_detections が追加されたと発表されたよ！

このフィールドは、セキュリティ検知が失敗を報告したときに、そのリクエストをルールでどう扱うかを選べるようにするものなの。中身は検知 ID の文字列の配列(Array of String)で、失敗が報告されなかったときは [] が返ってくるよ。

失敗を報告してくる検知は次のとおり！

  • コンテンツスキャン
  • WAF アタックスコア
  • アタックシグネチャ検知
  • 漏洩した認証情報の検知
  • AI プロンプト検知(個人情報 PII・プロンプトインジェクション・カスタムトピック・unsafe トピック)

なぜ重要なの？

セキュリティ検知は、いつでも必ず判定を出せるとは限らないよね。検知が失敗したリクエストを、ルールの側で「通す」のか「止める」のか「ログを残す」のかを選べないと、運用の方針に合わせた守り方がしづらいの。

このフィールドがあれば、その失敗をルールの条件として明示的に扱えるんだよ。

これで何が変わるの？

大事なのは、既存の検知の動作は変わらないこと。新しいフィールドは、報告された失敗に対してルールでどう反応するかを決めるための材料なの。

だから、たとえばこんな使い方ができるよ。

  • 検知が失敗したリクエストだけを狙って、チャレンジやブロックなどのアクションを当てる
  • 失敗が起きたリクエストにだけ、レート制限をかける
  • 失敗が起きたことを、リクエストヘッダーに付けてオリジン側へ伝える(Request Header Transform Rules)

セキュリティ担当の人は、検知の抜け穴を自分たちのポリシーで塞げるようになるね。

深く潜ってみよう

使えるルールの種類は次のとおり！

  • ゾーンレベルとアカウントレベルのカスタムルール
  • ゾーンレベルとアカウントレベルのレート制限ルール
  • ゾーンレベルの Request Header Transform Rules

プランは全プランで使えるよ。ただし、使いたい検知やルール機能そのものは、契約しているプランに含まれている必要があるの。

式の例も載っていたよ。失敗がひとつでも報告されたらマッチさせるときはこう書くの。

len(cf.appsec.request.failed_detections) gt 0

漏洩した認証情報の検知の失敗だけにマッチさせるときは、検知 ID を指定するよ。

any(cf.appsec.request.failed_detections[*] eq "waf_credential_check")

発表の中で検知 ID として例に出ていたのは waf_credential_check だけだったよ。ほかの ID は、Cloudflare のドキュメントにある Failed detections フィールドのリファレンスで確認してね。

まとめ

  • 新フィールド cf.appsec.request.failed_detections で、検知の失敗をルールの条件に使える
  • 値は検知 ID の配列で、失敗がなければ []
  • 既存の検知の動作は変わらない
  • カスタムルール・レート制限ルール(ゾーン/アカウント)と、ゾーンの Request Header Transform Rules で使える
  • 全プランで使えるけど、検知とルール機能が自分のプランに含まれている必要がある

WAF や Bot 対策の運用で「検知が失敗したときの挙動」まで自分で握りたい人に刺さる更新だよ！

関連記事