常時オン検知：WAFの「ログ対ブロック」トレードオフの解消

2026-03-04 Daniele Molteni 10分で読める

従来のWebアプリケーションファイアウォールは、悪意のあるトラフィックを安全にブロックする前に、ルールの広範囲にわたる手動調整が必要でした。新しいアプリケーションがデプロイされると、セキュリティチームは通常ログオンリーモードから開始し、ログを精査してどのルールがブロックモードで安全かを段階的に評価します。このプロセスは、正当なトラフィックに影響を与えることなく偽陽性を最小化するように設計されています。これは手動で、遅く、エラーが発生しやすいものです。

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

今日、私たちはマネージドルールの次の進化であるAttack Signature Detectionを導入することで、この問題を解決しています。有効にすると、この検知は悪意のあるペイロードについてすべてのリクエストを検査し、アクションが実行される前にリッチな検知メタデータを付加します。保護やパフォーマンスを犠牲にすることなく、すべてのシグネチャマッチの完全な可視性を得られます。

オンボーディングがシンプルになります：トラフィックが分析され、データが蓄積され、どのシグネチャが発火し、その理由を正確に確認できます。その後、過去のトラフィックに基づいて精密な緩和ポリシーを構築し、偽陽性のリスクを軽減できます。

しかし、私たちはさらに一歩進んでいます。リクエストのみの分析を超えて、はるかに強力なFull-Transaction Detectionに移行しています。受信リクエストのみを見るのではなく、この新しい検知はHTTPトランザクション全体（リクエストとレスポンス）を関連付けます。完全なコンテキストを分析することで、従来のリクエストのみのシグネチャエンジンと比較して偽陽性を劇的に削減します。さらに重要なことに、反射型SQLインジェクション、微妙なデータ流出パターン、レスポンスでのみ明らかになる危険な設定ミスなど、他が見逃す脅威を発見します。

Attack Signature Detectionは現在Early Accessで利用可能です — こちらで関心を表明してください。Full-Transaction Detectionは開発中です；準備ができたときに最初に試すためにこちらで登録してください。

常時オンフレームワーク

インターネットを遅くすることなくトラフィックの完全な可視性を提供するために、リクエストライフサイクルについての考え方を変える必要がありました。

オプトインした顧客に対して、Attack Signature検知は現在「常時オン」です。これは、トラフィックがプロキシされるとすぐに、すべての検知シグネチャがすべてのリクエストで実行され、結果がSecurity Analyticsですぐに表示されることを意味します。

この「常時オン」フレームワークは、検知と緩和を分離します。検知は継続的に実行され、トリガーされた検知に関するメタデータでアナリティクスを充実させます。このメタデータは新しいフィールドとしてリクエストにも追加され、顧客はセキュリティルール内でカスタムポリシーを作成するために使用できます。

悪意のあるペイロードの検知をセキュリティルールによって実行されるアクションから分離することが、常時オンフレームワークの核心です。このアプローチはアナリティクス体験を向上させ、新しい保護をデプロイする際の信頼性を高めます。

既存のBot ScoreとAttack Score検知は、すでにこの方法に従っています。Attack Signature Detectionは、Managed Rules製品と同じカバレッジを提供しますが、この新しいフレームワーク内で動作します。

これによりリクエストに追加のレイテンシが発生しますか？

いいえ — このモデルは効率性のために設計されています。顧客が検知に基づくブロッキングルールを作成していない場合、検知はリクエストがオリジンサーバーに送信された後に実行できるため、検知自体がトラフィックに追加のレイテンシを導入することはありません。

したがって、オンボーディング時には、検知はデフォルトで有効になりますが、トラフィックパフォーマンスに影響しません。ルールが作成されると、検知は追加のレイテンシを経験する可能性があるリクエストとインラインで移動されます。正確な値は、アプリケーションのトラフィックプロファイルによって異なります。

Attack Signature Detection

Cloudflare Managed Rulesetなどの従来のルールベースシステムと比較して、新しい検知はWebアプリケーションセキュリティにおいて大幅な進歩を提供します。このアプローチにより、悪意のあるWebペイロードの特定とセキュリティルールのデプロイが大幅にユーザーフレンドリーになります。

Cloudflare Managed Rulesetは、アナリストチームがSQL injection (SQLi)、Cross Site Scripting (XSS)、Remote Code Execution (RCE)、特定のCommon Vulnerabilities and Exposures (CVEs)を含む一般的な攻撃ベクターの検知を開発する場所です。アナリストは通常、週次で新しいルールをリリースし、注目度の高い脆弱性（最近のReact2Shellリリースなど）に対して緊急リリースをデプロイします。現在、700以上のマネージドルールがManaged Rulesetでアクティブです。

新しい検知はシグネチャルールまたは単にシグネチャとも呼ばれます。これらはManaged Rulesと同じヒューリスティックを使用しますが、トラフィックに直接アクションを適用しません。

各シグネチャは、Ref ID（Managed RulesetのRule IDに類似）によって一意に識別され、categoryとconfidenceの両方でタグ付けされます。categoryはシグネチャが対象とする攻撃ベクターを指定し、confidenceレベルは偽陽性（正当なトラフィックでのトリガー）の可能性を示します。ルールは1つのconfidenceレベルのみを持つことができますが、複数のcategoryを持つ場合があります。

Category

ルールが参照する攻撃ベクターを示します。categoryのリストは長いですが、SQLi、XSS、RCE、または番号付きの特定のCVEなどのタグが含まれます。

Confidence

confidenceフィールドは、対応するグループから少なくとも1つのシグネチャがトラフィックにマッチするかどうかに基づいて、2つの値に分かれています。

Confidence	Description
High	これらのシグネチャは高い真陽性と低い偽陽性を目指し、正当なトラフィックをブロックすることなくペイロードが識別可能なCVEに典型的です。Managed Rulesetのデフォルト設定のように機能します。
Medium	これらのシグネチャは、Managed Rulesetでデフォルトでオフになっており、トラフィックに基づいて偽陽性を引き起こす可能性があります。これらのルールにマッチするトラフィックをブロックする前に、潜在的なアプリケーションへの影響を評価してください。

検知のリクエスト分析は3つのフィールドを設定します。これらのフィールドは、Security AnalyticsとSecurity RulesのコアエンジンであるEdge Rules Engineでアクセス可能です。

Field	Description	Where can be used
cf.waf.signature.request.confidence	Array. マッチしたシグネチャに関連するconfidenceスコアを集約	Analytics and Security Rules
cf.waf.signature.request.categories	Array. マッチしたシグネチャに関連するcategoryを集約	Analytics and Security Rules
cf.waf.signature.request.ref	Array. マッチしたシグネチャのRef IDを最大10個まで集約	Analytics and Security Rules

Security Analyticsでのデータ分析

Security Analyticsは、Cloudflare Application Securityツールボックスの中核であり、シグネチャがWebトラフィックとどのように相互作用するかの包括的でデータ駆動型のビューを提供します。Web保護を理解、測定、最適化するために必要なツールを提供します。

Analyticsとシグネチャを組み合わせる一般的な使用例には以下が含まれます：

• オンボーディングプロセス中のセキュリティ体制の設計
• 最も頻繁な攻撃試行の検証
• 偽陽性を処理するための例外の作成

新しいアプリケーションがCloudflareを通じてプロキシされると、Attack Signature Detectionがダッシュボードにデータを入力し始めます。最初のステップは、タイプとシグネチャ別に分類された集約マッチを調べて、すべての潜在的な攻撃がブロックされていることを確認することです。

アナリストは、リクエストがブロックされたか、キャッシュから提供されたか、オリジンサーバーに到達することが許可されたかを示すようにデータをフィルタリングして、シグネチャの上位統計を確認することでこれを行うことができます。悪意のあるリクエストがオリジンに到達したことが判明した場合、アナリストは迅速にセキュリティルールを実装できます。

対応するCategoryまたはSignatureによって分類された、攻撃シグネチャにマッチする総リクエスト量の内訳。

Analyticsは、時間の経過に伴うトラフィック量に基づく最も頻繁なCVEなど、攻撃パターンに関する洞察を提供します。この機能は、アプリケーションを標的とする支配的な攻撃ペイロードを迅速に特定し、関連するCVEに対する現在の保護の有効性を検証するために設計されています。

例えば、アナリストは/api/などのアプリケーションの特定の部分を標的とする攻撃頻度を監視したり、React2Shellなどの既知の悪意のあるペイロードがPOST /_next/ Node.jsパスなどの特定のエンドポイントに到達しているかを確認したりできます。

AnalyticsフィルターとAttack Analysis toolの両方を使用して、このタイプの調査を実行できます。

Security Analytics内の視覚化は、/api/エンドポイントを標的とする悪意のあるペイロードの時系列ビューを提供します。このビューは、ボリューム別の上位5つのCVEをハイライトするようにデータをグループ化します。

Analyticsは例外の作成と偽陽性の特定にも役立ちます。特定のルールのマッチの増加は、例えば、アクティブな悪用ではなく偽陽性を示唆する場合があります。例えば、ユーザーがリッチHTMLコンテンツを送信できるアプリケーション（Content Management Systemsやサポートチケットシステムなど）は、より一般的なXSSシグネチャにマッチするマークアップを正当に含む場合があります。

これらの場合、影響を受けるエンドポイントにスコープ付き例外を適用し、アプリケーションの残りの部分で保護を有効に保つことができます。このアプローチは、積極的なブロッキングと偽陽性リスクのバランスを取る中程度の信頼度シグネチャを評価する際に特に有用です。

ツールは、過去のトラフィックに対する「what-if」シナリオを可能にし、本番パフォーマンスを経験的に決定します。このプロセスは、中程度の信頼度シグネチャが全体的なトラフィックプロファイルに適しているか、または高い偽陽性率により特定のURLやリクエストタイプへのデプロイメントを制限する必要があるかを判断するのに役立ちます。

一般的に、過去のトラフィックで非常に低いマッチ率を持つシグネチャは、正当なトラフィックに大きな混乱を与えることなく、ブロックモードでより安全にデプロイできます。

このレベルの信頼性を達成するために、Security Analyticsは詳細なフォレンジック調査のためのツールを提供します。

即座の検知を超えて、防御管理の重要な側面は、セキュリティ体制をカスタマイズする能力です。ユーザーインターフェースは、すべてのセキュリティシグネチャの検索可能なカタログを提供し、完全なリストを閲覧し、それぞれが対処するように設計された特定の脅威を理解できます。

検索可能なシグネチャカタログが利用可能で、重要な検知に関するより詳細な情報を提供し、顧客が脅威と修復アクションを理解するのに役立ちます。

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

データを分析し、過去のトラフィックに対するシグネチャのパフォーマンスに信頼を確立した後、検知に基づいてトラフィックを処理するカスタムルールを簡単に作成できます。

例えば、高信頼度シグネチャにマッチするリクエストをブロックするポリシーを作成したい場合、次のルールを作成できます：

高信頼度シグネチャにマッチするリクエストをブロックするルールの作成。これは、Cloudflare Managed Rulesetのデフォルトデプロイメントと同等です。

少なくとも1つのルールにマッチするすべてのリクエストをブロックしたい場合は、Mediumの信頼度タグを追加します。これは、Cloudflare Managed Rulesetのすべてのルールを有効にすることと同等です。

または、複数のルールを設定し、高信頼度の検知に対してより厳格なアクション（「Block」など）を適用し、中信頼度の検知に対してより緩いアクション（「Challenge」など）を適用することもできます。

HighとMediumの両方の信頼度を選択することで、任意のシグネチャがマッチした場合にルールをトリガーできます。

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

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