概要

従来のWebアプリケーションファイアウォール（WAF）は、悪意あるトラフィックを安全にブロックする前にルールを手動で大幅にチューニングする必要がありました。新しいアプリケーションがデプロイされると、セキュリティチームは通常ログのみ（logging-only）モードで開始し、ログを解析してどのルールがブロックモードに切り替えても安全かを徐々に評価します。このプロセスは誤検知を最小化するために設計されていますが、手動で遅く、エラーが発生しやすく、チームは可視性（ログモード）か保護（ブロックモード）かを選ばざるを得ないトレードオフに陥ります。

ルールがリクエストをブロックすると評価はそこで停止し、他のシグネチャがどのように評価したかという貴重な洞察を失います。これらの洞察は調整や防御強化に役立つ可能性があります。

今回、我々はマネージドルールの次の進化として「Attack Signature Detection（攻撃シグネチャ検出）」を導入し、この問題を解決します。これを有効にすると、検出はすべてのリクエストをスキャンし、アクションが実行される前にリッチな検出メタデータを付与します。これにより、保護やパフォーマンスを犠牲にすることなく、すべてのシグネチャ一致に対する完全な可視性が得られます。

オンボーディングは簡単になります：トラフィックが解析され、データが蓄積され、どのシグネチャがいつなぜ発火したかを正確に確認できます。その情報をもとに過去のトラフィックに基づいて正確な緩和ポリシーを構築し、誤検知のリスクを低減できます。

さらに一歩進めて、リクエストのみの解析を超えるより強力な機能：Full-Transaction Detection を提供します。これは受信リクエストだけでなくHTTPトランザクション全体（リクエストとレスポンス）を相関させます。フルコンテキストで解析することで、従来のリクエストオンリーのシグネチャエンジンと比べて誤検知を大幅に削減します。加えて、反射型SQLインジェクション、微妙なデータ流出パターン、レスポンスでしか露呈しない危険なミスコンフィグレーションなど、他が見逃す脅威を発見できます。

• Attack Signature Detection は現在 Early Access で利用可能です — 興味のある方はサインアップしてください。
• Full-Transaction Detection は開発中です；準備が整い次第最初に試せるよう登録してください。

---

常時有効（always-on）フレームワーク

トラフィックの完全な可視化を提供しつつインターネットの速度を落とさないために、リクエストのライフサイクルに対する考え方を変える必要がありました。オプトインした顧客向けに、Attack Signature 検出は「常時有効（always on）」になります。つまり、トラフィックがプロキシされるとすぐに、すべての検出シグネチャが各リクエストで実行され、その結果は即座に Security Analytics に表示されます。

この「常時有効」フレームワークは検出と緩和（mitigation）を分離します。検出は継続的に実行され、トリガーされた検出に関するメタデータで分析を拡張します。このメタデータはリクエストに新しいフィールドとして追加され、顧客はこれを使ってセキュリティルール内でカスタムポリシーを作成できます。

攻撃ペイロードの検出をセキュリティルールで実行されるアクションから分離することが、常時有効フレームワークの核心です。このアプローチは分析体験を向上させ、新しい防御をデプロイする際の信頼性を高めます。既存の Bot Score や Attack Score 検出は既にこの方法に従っています。Attack Signature Detection は Managed Rules 製品と同等のカバレッジを提供しますが、新しいフレームワーク内で動作します。

レイテンシへの影響

追加のレイテンシを発生させますか？いいえ — このモデルは効率性を重視して設計されています。顧客が検出に基づくブロッキングルールを作成していない場合、検出はリクエストをオリジンサーバーへ送信した後に実行され得るため、検出自体がトラフィックに追加レイテンシをもたらすことはありません。したがって、オンボーディング時には検出はデフォルトで有効ですが、トラフィック性能には影響しません。ルールが作成されると、その検出は該当リクエストのパスにインラインで移動し、追加レイテンシが発生する可能性があります。具体的な値はアプリケーションのトラフィックプロファイルによります。

---

Attack Signature Detection の特徴

従来のルールベースシステム（例：Cloudflare Managed Ruleset）と比べて、この新しい検出はウェブアプリケーションセキュリティにおける大きな前進です。攻撃ペイロードの識別とセキュリティルールの展開が格段に使いやすくなります。

Cloudflare Managed Ruleset は、SQL injection（SQLi）、Cross Site Scripting（XSS）、Remote Code Execution（RCE）、および特定の Common Vulnerabilities and Exposures（CVEs）など、一般的な攻撃ベクター向けの検出をアナリストチームが開発する場所です。アナリストは通常毎週新しいルールをリリースし、React2Shell のような高プロファイル脆弱性には緊急リリースが行われます。現在、Managed Ruleset には 700 を超えるマネージドルールがアクティブです。

新しい検出はシグネチャルール（もしくは単にシグネチャ）とも呼ばれ、Managed Rules と同じヒューリスティクスを用いますが、トラフィックに直接アクションを適用しません。各シグネチャは一意の Ref ID（Managed Ruleset の Rule ID に類似）で識別され、category と confidence のタグが付与されます。

• category：シグネチャが対象とする攻撃ベクター（例：SQLi、XSS、RCE、特定の CVE 番号など）
• confidence：誤検知（正当なトラフィックでのトリガー）の可能性を示す信頼度

ルールは1つの confidence レベルのみ持てますが、複数のカテゴリを持つことができます。

Confidence の説明

Confidence	説明
High	これらのシグネチャは高い真陽性率と低い誤検知率を目指します。ペイロードが特定可能で正当なトラフィックをブロックしない典型的な CVE に適しており、Managed Ruleset のデフォルト構成と同様に機能します。
Medium	Managed Ruleset ではデフォルトでオフになっていることが多く、あなたのトラフィックに応じて誤検知を起こす可能性があります。これらをブロックする前に、適用による影響を評価してください。

検出が出力するフィールド

検出の解析は3つのフィールドを埋めます。これらのフィールドは Security Analytics と Edge Rules Engine（Security Rules のコアエンジン）で利用可能です。

• cf.waf.signature.request.confidence — 配列。マッチしたシグネチャに関連する confidence スコアを集約
• cf.waf.signature.request.categories — 配列。マッチしたシグネチャに関連するカテゴリを集約
• cf.waf.signature.request.ref — 配列。マッチしたシグネチャの Ref ID を最大 10 個まで集約

これらは Analytics と Security Rules の両方で使用できます。

---

Security Analytics でのデータ解析

Security Analytics は Cloudflare Application Security の中核であり、シグネチャがあなたのウェブトラフィックとどのように相互作用しているかをデータ駆動で包括的に把握できます。これにより、ウェブ保護を理解、測定、最適化するためのツールが提供されます。

Analytics とシグネチャを組み合わせた一般的なユースケース：

• オンボーディング時のセキュリティ姿勢の設計
• 最も頻度の高い攻撃試行の検証
• 誤検知を処理するための例外（exceptions）の作成

アプリケーションが Cloudflare 経由でプロキシされると、Attack Signature Detection はダッシュボードにデータを蓄積し始めます。最初のステップは、型やシグネチャごとに集計されたマッチを確認し、潜在的な攻撃が適切にブロックされているかを確認することです。アナリストは上位のシグネチャ統計をレビューし、リクエストがブロックされたのか、キャッシュから配信されたのか、オリジンに到達したのかをフィルタリングして確認できます。

もし悪意あるリクエストがオリジンに到達していた場合、アナリストは迅速にセキュリティルールを実装できます。

Analytics は次のような分析を提供します：

• 総リクエスト量のうち攻撃シグネチャにマッチしたものをカテゴリやシグネチャごとに内訳表示
• 時系列での CVE ごとのトラフィックボリュームに基づく上位攻撃の把握
• 特定のアプリケーション領域（例：/api/）を狙う攻撃頻度の監視や、POST /_next/ のような特定エンドポイントで React2Shell のような既知の悪性ペイロードが到達しているかの確認

Analytics のフィルタと Attack Analysis ツールの両方を使ってこれらの調査を実行できます。

また、Analytics は例外の作成や誤検知の特定にも役立ちます。特定のルールのマッチ数が増加している場合、それは悪用ではなく誤検知である可能性があります。たとえば、ユーザーがリッチなHTML（CMSやサポートチケッティングシステムなど）を送信できるアプリケーションでは、正当なマークアップが一般的な XSS シグネチャに一致することがあります。このような場合、影響を受けるエンドポイントにスコープを限定した例外を適用し、アプリケーションの残りには保護を継続したままにできます。

これは、誤検知リスクと積極的なブロックのバランスを取る Medium confidence シグネチャを評価する際に特に有用です。ツールは過去のトラフィックに対する「what-if」シナリオを実行でき、本番環境でのパフォーマンスを経験的に判断できます。このプロセスにより、Medium confidence シグネチャが全体トラフィックに対して適切か、あるいは誤検知率が高いため特定の URL やリクエストタイプに限定すべきかを判断できます。

一般に、履歴トラフィックで非常に低いマッチ率しか示さないシグネチャは、正当なトラフィックに重大な影響を与えずにブロックモードでより安全に展開できます。これを達成するため、Security Analytics は詳細なフォレンジック調査のためのツールを提供します。

さらに、防御管理で重要なのはセキュリティ姿勢をカスタマイズする能力です。UI はすべてのセキュリティシグネチャの検索可能なカタログを提供し、各シグネチャが対処する具体的な脅威を理解するための詳細情報を参照できます。

---

セキュリティルールの作成

データを解析し、過去のトラフィックに対するシグネチャの挙動に自信が持てたら、検出に基づいてトラフィックを扱うカスタムルールを簡単に作成できます。

• たとえば、High confidence シグネチャに一致するリクエストをブロックするポリシーを作成することで、Cloudflare Managed Ruleset のデフォルト展開と同等の動作を得られます。
• High と Medium の両方を選択すると、どちらか一方のシグネチャがマッチした場合にルールを発動できます。Medium を含めると Managed Ruleset のすべてのルールを有効にしたのと同等です。
• また、High confidence に対してはより厳格なアクション（例：Block）、Medium confidence に対してはやや緩いアクション（例：Challenge）を適用するように複数のルールを構成することもできます。

特定の CVE や攻撃ベクターをブロックするルールを作成するには、Categories を使用します。ルールビルダーは攻撃ベクトルのカテゴリタグを既存のすべての HTTP リクエストデータと組み合わせることを許可するため、アプリケーションの異なる部分に対して粒度の高いルール（または例外）を作成してセキュリティ姿勢を調整できます。

顧客は特定の CVE や攻撃カテゴリにマッチするリクエストをブロック（または許可）するルールを作成できます。