常時検知：WAFの「ログ記録とブロック」のトレードオフを解消

従来の Web アプリケーションファイアウォール（WAF）は、悪意のあるトラフィックを安全にブロックするために、ルールを徹底的に手動で調整する必要があります。新しいアプリケーションがデプロイされると、セキュリティチームは通常、ログ記録モードから始め、どのルールがブロックモードに適しているかをログを精査しながら徐々に評価します。このプロセスは、正当なトラフィックに影響を与えずに誤検知（false positives）を最小限に抑えるために設計されています。しかし、これは手作業であり、時間がかかり、エラーが発生しやすいものです。 チームは、ログモードでの可視性とブロックモードでの保護のどちらかを選択せざるを得ません。ルールがリクエストをブロックすると評価が停止し、他のシグネチャ（signature）がそのリクエストをどのように評価したかという可視性が失われます。これは、防御体制の調整や強化に役立つ貴重な洞察です。 今日、私たちは管理されたルールの次の進化である「攻撃シグネチャ検出（Attack Signature Detection）」を導入することで、この課題を解決します。 これを有効化すると、アクションが実行される前に、すべてのリクエストが悪意のあるペイロードに対して検査され、豊富な検出メタデータが付与されます。保護やパフォーマンスを犠牲にすることなく、すべてのシグネチャマッチに対する完全な可視性が得られます。オンボーディングはシンプルになります：トラフィックが分析され、データが蓄積され、どのシグネチャが発火し、なぜ発火したのかを正確に把握できます。その後、過去のトラフィックに基づいて精密な緩和ポリシーを構築できるため、誤検知のリスクを低減できます。 しかし、私たちはさらに一歩を進めます。リクエスト単体の分析を超え、はるかに強力な「トランザクション全体検出（Full-Transaction Detection）」へと移行します。 単なる着信リクエストのみに注目するのではなく、この新しい検出機能は HTTP トランザクション全体（リクエストとレスポンス）を相関分析します。文脈全体を分析することで、従来のリクエストのみを対象とするシグネチャエンジンと比較して、誤検知を劇的に削減できます。さらに重要なのは、他の手法では見逃される脅威を発見できる点です。具体的には、反射型 SQL インジェクション、微妙なデータ漏洩のパターン、レスポンスにおいて初めて明らかになる危険な設定ミスなどが挙げられます。 攻撃シグネチャ検出機能は現在、早期アクセスプログラムで利用可能です。興味がある場合はこちらから登録してください。フルトランザクション検出（Full-Transaction Detection）は開発中です。準備ができ次第、いち早く試せるよう、こちらから登録してください。 常時稼働フレームワーク インターネットの速度を低下させることなくトラフィックに対する完全な可視性を提供するためには、リクエストライフサイクルに関する考え方を根本的に変える必要がありました。オプトインした顧客向けに、攻撃シグネチャ検出機能は現在「常時稼働（always on）」となっています。これは、トラフィックがプロキシされた瞬間から、すべての検出シグネチャがあらゆるリクエストに対して実行され、その結果が即座にセキュリティ分析（Security Analytics）で確認できることを意味します。 この「常時稼働」フレームワークは、検出と緩和（mitigation）を分離しています。検出プロセスは継続的に実行され、トリガーされた検出に関するメタデータによって分析を強化します。このメタデータはリクエストに新しいフィールドとして追加され、顧客はこれをセキュリティルール内でカスタムポリシーを作成するために利用できます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/Vx8m4KODWR1lqusEdBtUj/8339eea7b73eb79bae416ef7fe01b60b/image9.png) 悪意のあるペイロードの検出とセキュリティルールによる対応措置を分離することが、常時オンフレームワークの中核です。このアプローチは分析体験を向上させ、新しい保護機能の導入時の信頼性を高めます。 既存の Bot Score および Attack Score の検出機能もすでにこの手法に従っています。Attack Signature Detection（攻撃シグネチャ検出）は、Managed Rules 製品と同じカバレッジを提供しますが、この新しいフレームワーク内で動作します。 これによりリクエストに追加のレイテンシが発生するのでしょうか？いいえ — このモデルは効率性を重視して設計されています。顧客が検出結果に基づいてブロックルールを作成していない場合、検出処理はリクエストがオリジンサーバーへ送信された後に実行されるため、検出自体がトラフィックに追加のレイテンシをもたらすことはありません。したがって、オンボーディング時には検出機能がデフォルトで有効化されますが、トラフィックパフォーマンスには影響しません。ルールが作成されると、検出処理はリクエストと並列（インライン）に移動し、これにより追加のレイテンシが発生する可能性があります。具体的な値はアプリケーションのトラフィックプロファイルによって異なります。 Attack Signature Detection 従来のルールベースシステムである Cloudflare Managed Ruleset と比較すると、新しい検知機能は Web アプリケーションセキュリティにおいて大幅な進歩をもたらします。このアプローチにより、悪意のある Web ペイロードの特定やセキュリティルールの展開が、これまでよりもはるかにユーザーフレンドリーになりました。 Cloudflare Managed Ruleset は、当社のアナリストチームが SQL インジェクション（SQLi）、クロスサイトスクリプティング（XSS）、リモートコード実行（RCE）、および特定の共通脆弱性・脅威（CVE）を含む一般的な攻撃ベクトルに対する検知を開発する場所です。アナリストは通常、毎週新しいルールをリリースしており、高プロファイルな脆弱性（例えば直近の React2Shell のリリースなど）に対しては緊急リリースが展開されます。現在、Managed Ruleset には 700 を超える管理ルールがアクティブに稼働しています。新しい検知機能は、シグネチャルールまたは単にシグネチャとも呼ばれます。これらは Managed Rules と同じヒューリスティック（推論手法）を採用していますが、トラフィックに対して直接アクションを適用するわけではありません。 各シグネチャは、Managed Ruleset の Rule ID に類似した Ref ID によって一意に識別され、カテゴリと信頼度レベルの両方でタグ付けされます。カテゴリはシグネチャが対象とする攻撃ベクトルを指定し、信頼度レベルは誤検知（正当なトラフィックでのトリガー）の可能性を示します。ルールには信頼度レベルは 1 つのみ設定できますが、複数のカテゴリを持つことができます。 カテゴリは、そのルールが参照する攻撃ベクトルを示します。カテゴリのリストは長く存在しますが、SQLi、XSS、RCE、または番号付きの特定の CVE などのタグが含まれます。 信頼度フィールドは、対応するグループからのシグネチャのうち少なくとも一つがトラフィックに一致するかどうかに基づいて、2 つの値に分割されます。 信頼度 説明 高 これらのシグネチャは、ペイロードを識別可能でありながら正当なトラフィックをブロックしない CVE において典型的であるように、高い真陽性率と低い偽陽性率を目指しています。これは Managed Ruleset のデフォルト設定と同様の機能を果たします。 中 Managed Ruleset ではデフォルトで無効になっているこれらのシグネチャは、お客様のトラフィックに基づいて偽陽性を引き起こす可能性があります。これらのルールに一致するトラフィックをブロックする前に、その潜在的なアプリケーションへの影響を評価してください。 リクエストの分析により、検出機能は 3 つのフィールドに情報を埋め込みます。これらのフィールドは、Security Rules のコアエンジンである Security Analytics および Edge Rules Engine で利用可能です。 フィールド 説明 使用箇所 cf.waf.signature.request.confidence 配列。一致するシグネチャに関連付けられた信頼度スコアを集計します。 Analytics および Security Rules cf.waf.signature.request.categories 配列。一致するシグネチャに関連付けられるカテゴリを集計します。 Analytics および Security Rules cf.waf.signature.request.ref 配列。一致するシグネチャの Ref ID を最大 10 件まで集計します。 Analytics および Security Rules Security Analytics でデータを分析する セキュリティ分析は、Cloudflare アプリケーションセキュリティツールボックスの中核を成し、シグネチャがウェブトラフィックとどのように相互作用するかについての包括的でデータ駆動型のビューを提供します。これにより、ウェブ保護を理解・測定・最適化するために必要なツールが提供されます。Analytics とシグネチャを組み合わせて使用するための一般的なユースケースには、オンボーディングプロセス中にセキュリティ姿勢を設計する、最も頻繁な攻撃試行を確認し、誤検知（false positives）を処理するための例外を作成することが含まれます。 新しいアプリケーションが Cloudflare を経由してプロキシ化されると、攻撃シグネチャ検出機能によりダッシュボードへのデータ入力が開始されます。最初のステップは、タイプとシグネチャ別に分類された集約された一致を確認し、すべての潜在的な攻撃がブロックされていることを確認することです。アナリストは、シグネチャの上位統計をレビューし、リクエストがブロックされたか、キャッシュから提供されたか、オリジンサーバーへの到達が許可されたかをフィルタリングして表示することでこれを行うことができます。悪意のあるリクエストがオリジンに到達していることが判明した場合、アナリストは迅速にセキュリティルールを実装できます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/Flwiq3kVd2vHnIT7w30Op/2c9564f636b5e1169228711cd7ff5c15/image6.png) 攻撃シグネチャに一致する総リクエストボリュームの breakdown（内訳）は、対応するカテゴリまたはシグネチャ別に分類されています。 分析機能は、時間経過に伴うトラフィック量に基づく最も頻繁な CVE などの攻撃パターンに関する洞察を提供します。この機能は、アプリケーションを標的とする支配的な攻撃ペイロードを迅速に特定し、関連する CVE に対する現在の保護の有効性を検証するために設計されています。例えば、アナリストは /api/ といったアプリケーションの特定の部分を標的とした攻撃頻度を監視したり、React2Shell などの既知の悪意のあるペイロードが POST /_next/ Node.js パスのような特定のエンドポイントに到達しているかどうかを確認したりできます。この種の調査には、分析フィルターと攻撃分析ツールの両方を使用することができます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/PswhIBA7AXI5y6BaH4Rq6/aafe3e2f272d8077ed1454066600da51/image5.png) セキュリティ分析内の可視化機能は、/api/ エンドポイントを標的とする悪意のあるペイロードの時系列ビューを提供します。このビューではデータをグループ化し、ボリューム上位の 5 つの CVE を強調表示しています。 分析機能は、例外の作成や誤検知（false positive）の特定にも役立ちます。例えば、特定のルールに対する一致件数が増加した場合、それはアクティブな悪用ではなく誤検知を示唆している可能性があります。具体的には、ユーザーがリッチ HTML コンテンツ（コンテンツ管理システムやサポートチケットシステムなど）を提出できるアプリケーションでは、より一般的な XSS 署名に一致するマークアップが正当に含まれる場合があります。このようなケースでは、影響を受けるエンドポイントに対してスコープ付きの例外を適用しつつ、アプリケーション全体に対する保護機能は有効なまま維持できます。 このアプローチは、積極的なブロックと誤検知リスクのバランスを取る中程度の信頼度を持つ署名の評価において特に有用です。本ツールを使用すれば、過去のトラフィックに対して「もしも」シナリオを検証し、実環境でのパフォーマンスを実証的に決定することが可能です。このプロセスにより、中程度の信頼度を持つ署名が全体的なトラフィックプロファイルに適しているか、あるいは誤検知率が高すぎるために特定の URL やリクエストタイプへの展開に制限が必要かを判断できます。 一般的に、過去のトラフィックで一致率が非常に低い署名は、正当なトラフィックに大きな支障をきたすことなく、ブロックモードでより安全に展開できます。このレベルの信頼性を確保するために、セキュリティ分析機能は詳細なフォレンジック調査のためのツールを提供しています。 即時検知に加え、防御管理の重要な側面は、セキュリティ姿勢をカスタマイズする能力です。ユーザーインターフェースには、すべてのセキュリティシグネチャを検索可能なカタログとして提供しており、一覧を確認して各シグネチャが対象とする特定の脅威を理解することができます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6enXCjehRa8ibfhOoUfnRv/8a65fa9975e7582a07c08a99c693aa8b/Untitled-1.png) シグネチャの検索可能なカタログが利用可能で、重要な検知に関する詳細を提供し、顧客が脅威と修復アクションを理解するのを支援します。 セキュリティルールの作成 データ分析を行い、過去のトラフィックに対するシグネチャのパフォーマンスに確信を持った後、検知に基づいてトラフィックを処理するためのカスタムルールを簡単に作成できます。例えば、高信頼度のシグネチャに一致するリクエストをブロックするポリシーを作成したい場合、以下のルールを作成できます: ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/55sYmYsoMh9effxtmxG65j/2ca91e74188ad69a908b5ae69571225c/image1.png) 高信頼度のシグネチャに一致するリクエストをブロックするためのルール作成。 これは、Cloudflare Managed Ruleset のデフォルト展開と同等です。 少なくとも 1 つのルールに一致するすべてのリクエストをブロックしたい場合は、Medium confidence タグを追加します。これは Cloudflare Managed Ruleset のすべてのルールを有効化することと同等です。あるいは、複数のルールを設定し、High confidence の検出に対してはより厳格なアクション（"Block" など）を、Medium confidence の検出に対してはより緩やかなアクション（"Challenge" など）を適用することもできます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3JhVPtrx2ZRhsNgRQHCaLc/ca3f597d8b794fd5a2eb1ddfc1362288/image8.png) High と Medium の両方の信頼度レベルを選択することで、いずれかのシグネチャが一致した場合にルールをトリガーできます。 特定の CVE や攻撃ベクトルをブロックするルールを作成するには、Categories を使用します。ルールビルダーを使用すると、攻撃ベクトルのカテゴリタグと既存のすべての HTTP リクエストデータを組み合わせることができます。これにより、細粒度のルール（または例外）を作成し、アプリケーションの異なる部分に合わせてセキュリティ体制を調整することが可能になります。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/wEf21sGlDdKkO7Mgt1pVn/01bd915ae33d931ca33bd0b2d04fc9e8/image7.png) 顧客は、特定の CVE や攻撃カテゴリに一致するリクエストをブロック（または許可）するためのルールを作成できます。 特定の Signature に基づいてルールを作成するには、Ref ID を使用します。利用可能な Attack Signature ルールを検索することで、ルールビルダー内で適切な Ref ID を見つけることができます。これは、偽陽性を管理するための例外を作成したい場合に特に有用です。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1LQ93vHMecuHS8xNbL0RTz/b805072b739f1ded6f4383c13f2cfb5a/image3.png) お客様は、ルールビルダーから直接シグネチャルールを閲覧できます。 Cloudflare Managed Ruleset では何が起きるのでしょうか？ すべてのお客様は引き続き、従来の Managed Ruleset にアクセスできます。Attack Signature Detection が広く利用可能になった際、お客様はご自身のニーズに最も適したデプロイモデルを選択できるようになります。それは Attack Signature Detection であっても、Managed Rules であっても構いません。当社のアナリストチームは、新しい検知機能を Managed Ruleset と Attack Signature Detection の両方で同時にリリースするように保証しています。 フルトランザクション検知 従来の Web 攻撃検知は主に「問い」である HTTP リクエストに焦点を当てています。しかし、リクエストだけでは物語の半分しか語られません。攻撃が実際に成功したかどうかを知るには、「答え」である HTTP レスポンスを確認する必要があります。 リクエストとレスポンスのメタデータを単一の検知イベントに組み合わせることで、偽陽性を劇的に削減し、従来のリクエストのみを対象とするシステムでは見逃してしまう成功したエクスプロイトを特定することが可能になります。 例えば、クエリパラメータ内に一般的な SQL インジェクション文字列を含むリクエストを考えてみましょう。 GET /user?id=1' UNION SELECT username, password FROM users-- 従来の WAF は UNION SELECT パターンを検知してブロックします。しかし、アプリケーションに実際的な脆弱性が存在しない場合、これは誤検知（false positive）となる可能性があります。例えば、セキュリティ研究者が自社のサイトをテストしているケースなどが該当します。 フルトランザクション検出（Full-Transaction Detection）では、システムはリクエスト内の SQLi 署名を検知しますが、応答を待機します。オリジンサーバーが 500 Internal Server Error または標準的な 404 を返す場合、「成功したエクスプロイト」の確信度は低くなります。一方、オリジンサーバーが 200 OK を返し、かつ「機密データ」署名（ユーザー名のリストなど）に一致する文字列を含むボディを返した場合、システムは「成功したエクスプロイトの確認」としてフラグを立てます。 まず、いくつかの検出カテゴリを展開し、将来的にはこのリストを拡大する予定です。現在注力している 3 つの領域と、表示される一部のフラグは以下の通りです。 エクスプロイト試行。本検出機能は、HTTP リクエストからレスポンスまでの一連のサイクル全体を検査することで、Web アタックを検知します。重点を置くのは 3 つの主要領域です：悪意のある署名を通じて XSS や SQLi などの入力エクスプロイトを特定すること、脆弱性プロービングなど自動化された濫用行為を阻止すること、そして不審なリクエストと異常なサーバー応答を相関させることで成功したエクスプロイトを確認することです。 データ露出および不正転送の兆候。このフレームワークは、入力経路において正当なトラフィックに見えるデータ不正転送も検知することを可能にします。/api/v1/export へのリクエストは標準的な管理操作ですが、その特定のリクエストが応答として 5,000 件のクレジットカード番号（例：ルーンアルゴリズム署名によって識別される）を含む場合、その取引は「データ露出」としてフラグ付けされます。 設定ミス。公開された管理インターフェースはしばしば攻撃のベクトルとなります。従来のセキュリティチェックでは、トラフィック自体が有効に見えるため（実際のエンドポイントや管理ページであるため）、この設定ミスを検知できません。問題となるのはトラフィックそのものではなく、それが公衆にアクセス可能である点です。私たちは、顧客データで確認される一般的な実世界の設定ミスに基づいて検知の優先順位を決定します。具体的には、認証なしで公開されている Elasticsearch クラスター、インターネットから到達可能な管理パネル、および露出した Apache の機密エンドポイントなどが挙げられます。 この検知は「攻撃シグネチャ」と同様、2 つの特定フィールドに結果を保存します。これらのフィールドはダッシュボードでアクセス可能であり、セキュリティ分析（Security Analytics）内でログとして記録されます。 フィールド | 説明 | 使用箇所 ---|---|--- cf.waf.signature.response.categories | 配列。一致するシグネチャに関連付けられたカテゴリを集約します。 | セキュリティ分析 (Security Analytics) cf.waf.signature.response.ref | 配列。一致するシグネチャの Ref ID を最大 10 件まで集約します。 | セキュリティ分析 (Security Analytics) 当初は、分析を通じて一致するリクエストの可視化を提供することに注力しています。潜在的な攻撃に関するイベントを表面化することで、顧客がインフラストラクチャやソフトウェアスタック全体にわたる標的型対策を通じてインシデント対応に活用できる情報を提供します。今後の計画には、セキュリティルールを応答フェーズへ拡張し、ポリシー作成を可能にすることで、これらの検出に基づいて応答をブロックできるようにする顧客への機能強化が含まれています。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3uUoiHlxC6qEjBNU1AA5Rg/1402f5be8f412443cf3b9ff39e8d0700/image4.png) 攻撃シグネチャ検出とフルトランザクション検出の双方における実行場所と対応して埋められるフィールドを示す図。 アクセス権を取得するにはサインアップしてください。 攻撃シグネチャ検出は早期アクセス版として提供されており、フルトランザクション検出（Full-Transaction Detection）は開発中です。Attack Signature へのアクセス権を取得するにはこちらから、Full-Transaction への関心を表明するにはこちらからサインアップしてください。これらの機能を一般公開（General Availability）に向けて準備する数ヶ月間にわたり、フィードバックを収集していきます。

常時検知：WAFの「ログ記録とブロック」のトレードオフを解消

背景や根拠まで確認しますか？

調べる

選ぶ

サイト