すべてのプロダクト
Search

このプロダクト

    Web Application Firewall:カスタムルール

    ドキュメントセンター

    Web Application Firewall:カスタムルール

    最終更新日:Sep 16, 2026

    悪意のある API コール、不審なリクエスト、高頻度スキャンといった特定の攻撃に対して精密な保護が必要な場合は、カスタムルールを使用し、柔軟な一致条件とルールアクションを組み合わせて、カスタマイズされた保護戦略を構築します。

    基本概念

    • カスタムルール：Core Web Protection 内の保護モジュールです。このモジュールを有効にするには、保護テンプレートを作成する必要があります。複数の保護テンプレートを作成できます。

    • 保護テンプレート：保護ルールの内容と適用範囲を定義する、ルールのセットです。保護テンプレートは、テンプレートタイプ、保護ルール、適用対象オブジェクトで構成されます。

      • テンプレートタイプ：保護テンプレートの作成時にタイプを指定する必要があります。作成後にタイプを変更することはできません。使用できるテンプレートタイプは 2 種類です。

        テンプレートタイプ

        説明

        ユースケース

        デフォルトの保護テンプレート

        • デフォルトでは、このテンプレートは既存および新規のすべての保護対象と保護対象グループに適用されます。

        • ステータスを [Not Applied] に設定することで、特定のオブジェクトを手動で除外できます。

        • カスタムルールモジュール内では、デフォルトの保護テンプレートは 1 つしか作成できません。

        グローバルかつ汎用的な保護ルールのデプロイ

        カスタム保護テンプレート

        テンプレートを適用する保護対象または保護対象グループを手動で指定する必要があります。

        ログイン API や決済 API など、特定のサービス向けのきめ細かな保護ルールのデプロイ

      • 保護ルール：具体的な検知ロジックと応答アクションを定義します。保護テンプレートには複数の保護ルールを含めることができます。各ルールは、次のコンポーネントで構成されます。

        • 一致条件：リクエストパスやクライアント IP アドレスなど、検査対象となるリクエストの特性を定義します。

        • 保護タイプ：[Access Control]、[Rate Limiting]、[プラグイン実行]の 3 つの検知ディメンションをサポートします。

        • ルールアクション：リクエストがルールに一致した場合に実行するアクションを定義します。アクションは優先度の高い順に、ブロック、厳格な CAPTCHA、CAPTCHA、JavaScript 検証、ログです。

          説明

          同一の保護モジュール内で、同じルールアクションを持つ複数のルールにリクエストが一致した場合、WAF はいずれか 1 つの一致したルールをランダムに適用します。

      • 適用対象オブジェクト：保護テンプレートの適用先を指定します。この設定を使用して、特定の保護対象または保護対象グループに保護ルールを適用できます。1 つの保護対象または保護対象グループを複数の保護テンプレートに関連付けることができます。

        • 保護対象：WAF に追加した各ドメインまたはクラウドサービスインスタンスに対して、システムが保護対象を自動的に作成します。

        • 保護対象グループ：複数の保護対象をグループに追加して、一元的に管理できます。

    手順

    説明

    開始する前に、Web サービスが Web Application Firewall (WAF) に追加され、保護対象が設定されていることを確認してください。サービスをまだ追加していない場合は、「WAF へのドメインの追加」をご参照ください。

    Web アプリケーションファイアウォール (WAF) コンソールにログインします。上部のナビゲーションバーで、お使いの WAF インスタンスのリソースグループとリージョン (中国本土 または 中国本土以外) を選択します。左側のナビゲーションウィンドウで、保護設定 > Web コア保護を選択します。

    ステップ 1: テンプレートタイプの設定

    Web コア保護 ページで、カスタムルール セクションを見つけ、テンプレートの作成 をクリックします。テンプレートの作成 パネルで、次のパラメーターを設定します。

    • [テンプレート名]: テンプレートの名前を入力します。

    • [デフォルトテンプレート]: カスタムルールモジュールで設定できるデフォルトテンプレートは 1 つだけで、新しいテンプレートの作成時にのみ設定できます。

      • はい: 有効対象 を設定する必要はありません。テンプレートが作成されると、デフォルトですべての保護オブジェクトとオブジェクトグループに適用されます。また、後で追加された新しいオブジェクトにも自動的に適用されます。特定のオブジェクトのステータスを「無効」に設定することで、手動で除外できます。

      • いいえ: 保護対象オブジェクトまたはオブジェクトグループを手動で指定するには、有効対象 を設定する必要があります。

    ステップ 2: 保護ルールの追加

    ルールの設定 エリアで、ルールの作成 をクリックして、次のパラメーターを設定します。

    • [Rule Name]：ルール名を入力します。

    • [一致条件]：ルールが検査するリクエストの特性を定義します。条件の追加 をクリックして条件を追加します。各条件は、マッチフィールド、論理記号、および マッチコンテンツ で構成されます。次の表に設定例を示します。

      説明

      ルールに複数の条件が含まれている場合、リクエストは、すべての条件 (論理 AND 関係) に一致する必要があります。条件間に論理 OR 関係を設定することはできません。複数のキーワードまたは特性のいずれか 1 つに一致するリクエストをブロックする場合 (例：キーワード A またはキーワード B)、各条件に対して個別の保護ルールを作成します。一致フィールドと論理演算子の詳細については、「一致条件」をご参照ください。

      [マッチフィールド]

      [論理記号]

      [マッチコンテンツ]

      説明

      URI パス

      次を含む

      /login.php

      リクエストパスに /login.php が含まれている場合、ルールが一致します。

      IP

      次に属する

      192.1.0.0/16

      クライアント IP アドレスが 192.1.0.0/16 の範囲に属する場合、ルールが一致します。

      説明

      複雑な一致ルール

      1. 複数値のマッチングロジックと制限
      複数の API エンドポイントに同じルールを適用するには、Contains One of Multiple Values、Equals One of Multiple Values、Does Not Contain Any Value、または Does Not Equal Any Value などの複数値をサポートする論理演算子を使用できます。設定要件は次のとおりです。

      • 区切り文字：複数の一致値を区切るには、カンマ (,) を使用する必要があります。システムは値をカンマで分割し、個別に処理します。

      • 数量と重複排除：最大 50 個の値を入力できます。重複する値は許可されません。

      2. 特殊文字の処理
      一致コンテンツにカンマが含まれている場合 (例：一部の User-Agent 文字列)、システムが複数値の区切り文字と誤って解釈し、一致が失敗する可能性があります。この場合は、複数値の論理演算子を使用しないでください。次の代替方法を推奨します。

      • 正規表現マッチング：正規表現を使用してコンテンツを照合し、カンマをリテラル文字として扱います。

      • 単一ルール：特定の文字列に対して個別のルールを作成し、単一値の論理演算子を使用します。

      3. 正規表現の適用例

      • 特定のバージョン番号の範囲に一致させる：Chrome ブラウザのバージョン 100 から 200 に一致させるには、一致フィールドを User-Agent に、論理演算子を Regex Match に、一致内容を Chrome/(1[0-9]{2}|200)\. に設定します。

      • 複数の URL エンコーディングのブロック: 複数回 URL エンコードされたリクエスト (たとえば、% が \x25 としてエンコードされている場合) をブロックするには、論理演算子を [正規表現の一致] に設定し、一致内容を \x25.*\x25 に設定します。

      4. 本番環境に関する推奨事項
      本番環境で正規表現などの複雑な一致条件を設定する場合、まず 監視 アクションまたはカナリアテストを使用してルールの動作を検証することを推奨します。問題がないことを確認した後、ルールをすべてのトラフィックに適用できます。

    • [Protection Rule Type]：Access Control、Rate Limiting、およびプラグイン実行 の 3 種類がサポートされています。

      • [Access Control]: 特定のタイプのリクエストに対する厳密な制御を必要とするシナリオに最適です。

      • [Rate Limiting]: アクセス頻度に基づく保護を必要とするシナリオ (クレデンシャルスタッフィングやブルートフォース攻撃の防止など) に最適です。この機能は、サブスクリプション (エンタープライズ版またはアルティメット版) および従量課金の WAF インスタンスでのみ利用できます。

      • [プラグイン実行]: カスタム Lua スクリプトを使用して複雑なビジネスロジックを実装する必要がある、個別のセキュリティシナリオに最適です。まず 拡張機能 を設定することをお勧めします。

      アクセスコントロール

      アクセスコントロールルールを設定して、特定の条件を満たす個々のリクエストに対して指定されたアクションを実行します。

      レート制限

      レート制限ルールを設定して、クライアントからの過度なアクセスを制限します。

      • レート検出条件: 指定された統計期間 (秒)内に、単一のStatistical Objectがルールに一致する回数が、設定されたしきい値 (回)を超えた場合、WAF はブラックリストアクションをトリガーします。

        パラメータ

        説明

        [Statistical Object]

        リクエスト頻度を測定するオブジェクトを選択します。オプションには次のものがあります。

        • [IP]: 単一の IP アドレスからのリクエスト頻度を測定します。 WAF の前面に CDN や Anti-DDoS などのレイヤー 7 プロキシをデプロイする場合は、アセットを WAF に追加する際に 「WAF の前にレイヤー 7 プロキシ (Anti-DDoS/CDN など) はデプロイされていますか?」 パラメーターを [はい] に設定してください。 設定が正しくないと、WAF は実際のクライアント IP アドレスを取得できなくなり、IP ベースのルールは失敗します。

        • [Custom Header]: カスタムリクエストヘッダー (例: Referer) の値でリクエストをグループ化し、指定された期間内に同じヘッダー値を持つ各グループのリクエスト頻度を測定します。

        • [Custom Parameter]: URL に特定のパラメーターを含むリクエストの頻度を測定します。 たとえば、パラメーターが user_id の場合、WAF は同じ user_id 値を持つリクエストの頻度を測定します。

        • [Custom Cookie]: 指定された期間内に特定の Cookie を含む HTTP リクエストの頻度を測定します。 たとえば、カスタム Cookie 名が User の場合、WAF は期間内に各 User 値の出現回数をカウントします。

        • [Session]： WAF は、レスポンスに acw_tc という名前の Cookie を設定することでセッション ID を確立し、この Cookie の値に基づいてクライアントのリクエスト頻度を測定します。

        • [アカウント]: 同一アカウントからのリクエスト頻度を計測します。このオプションを使用する前に、保護対象 ページで アカウント抽出設定 を設定する必要があります。詳細については、「保護対象オブジェクトと保護対象オブジェクトグループを設定する」をご参照ください。

        [統計期間 (秒)]

        統計期間を秒単位で設定します。

        [しきい値 (回)]

        統計期間 (秒)内で、Statistical Objectが一致条件に一致する最大回数を設定します。

      • ステータスコード検出条件: Quantity または Percentage (%) が、特定の Status Code を持つレスポンスにおいて設定されたしきい値を超えると、WAF はブラックリストアクションをトリガーします。 ステータスコード検出を有効にした場合、統計オブジェクトは、アクションをトリガーするためにレート検出とステータスコードの両方の条件を満たす必要があります。

        パラメータ

        説明

        [Status Code]

        カウントするステータスコードを設定します。

        [Quantity]

        統計期間内のレスポンスで、指定されたStatus Codeが出現する最大回数を設定します。

        [Percentage (%)]

        統計期間内に、指定されたStatus Codeのレスポンスの最大割合を設定します。

      • ブラックリストのアクション条件: 先行する検出条件に一致する統計オブジェクトをブラックリストに追加します。Timeout Period の期間中、WAF は Apply To の範囲に含まれる、ブラックリストに登録されたオブジェクトからのリクエストに対し、設定された Rule Action を適用します。

        パラメータ

        説明

        [Apply To]

        ブラックリストアクションの範囲を設定します。オプションには次のものがあります。

        • [Current Match Condition]: アクションは、現在のルールの 一致条件 を満たすリクエストにのみ適用されます。

        • [Protected Object]: アクションは、IP アドレスなどの統計オブジェクトから現在の保護対象へのすべてのリクエストに適用されます。

        [Timeout Period]

        ブラックリストアクションの期間を設定します。単位：秒。値の範囲：60～86400。

      拡張機能の実行

      設定済みの拡張機能ルールから選択して、パーソナライズされたセキュリティコントロールを実装します。

      説明

      拡張実行ルールは、ブロックとモニターの 2 つのルールアクションのみをサポートします。

    • [Rule Action]：リクエストがルールに一致した場合のアクションを選択します。

      パラメータ

      説明

      [JS 検証]

      WAF は検証用の JavaScript スニペットをクライアントに返します。標準的なブラウザはこのコードを自動的に実行します。クライアントのブラウザがコードを正常に実行した場合、WAF はそのクライアントからのすべてのリクエストを一定期間 (デフォルトでは 30 分間) 許可します。それ以外の場合、WAF はリクエストをブロックします。

      [ブロック]

      ルールに一致するリクエストをブロックし、ブロックレスポンスページをクライアントに返します。

      説明

      WAF はデフォルトのブロックページを使用します。「カスタムレスポンス」機能を使用して、ブロックページをカスタマイズすることもできます。

      [モニター]

      ルールに一致するリクエストを許可しますが、その一致をログに記録します。 新しいルールをテストする場合、まず モニター モードを使用して WAF ログを分析し、ルールが正当なリクエストをブロックしないことを確認してから、別のルールアクションに切り替えることができます。

      [スライダー]

      WAF は CAPTCHA ページをクライアントに返します。クライアントが CAPTCHA を正常に完了した場合、WAF はそのクライアントからのすべてのリクエストを一定期間 (デフォルトでは 30 分間) 許可します。それ以外の場合、WAF はリクエストをブロックします。

      説明

      従量課金の課金方法を使用する WAF インスタンスの場合、このルールアクションには追加料金が発生します。詳細については、「従量課金の詳細」をご参照ください。

      [厳密なスライダー]

      WAF は CAPTCHA ページをクライアントに返します。クライアントが CAPTCHA を正常に完了した場合、WAF はリクエストを許可します。それ以外の場合、WAF はブロックします。このモードでは、このルールに一致するクライアントからのすべてのリクエストに CAPTCHA 検証が必要です。

      説明

      従量課金の課金方法を使用する WAF インスタンスの場合、このルールアクションには追加料金が発生します。詳細については、「従量課金の詳細」をご参照ください。

      説明

      • スライダー アクションは、サブスクリプション (エンタープライズ版またはアルティメット版) および従量課金の WAF インスタンスでのみ利用可能です。

      • JS 検証 および スライダー アクションは、同期リクエストにのみ適用されます。 XMLHttpRequest または Fetch API などで行われる非同期リクエストの場合、Web SDK を注入する必要があります。 そうしないと、これらの機能は正しく機能しません。 詳細については、「ボット管理」の JavaScript 検証および CAPTCHA セクションをご参照ください。

      • JS 検証 または スライダー を有効にし、クライアントが検証に合格すると、WAF は Set-Cookie を使用して、レスポンスヘッダーに acw_sc__v2 (JavaScript 検証の場合) または acw_sc__v3 (CAPTCHA の場合) という名前の Cookie を設定します。その後、クライアントは後続のリクエストの Cookie ヘッダーにこの識別子を含めます。

    • [詳細設定] (オプション): 以下の高度な機能は、サブスクリプション課金のエンタープライズ版またはアルティメット版の WAF インスタンス、および従量課金の WAF インスタンスでのみ利用できます。

      パラメータ

      説明

      [規則的グレースケール]

      指定されたディメンションに基づいて、ルールを適用するトラフィックの割合を設定します。

      カナリアルールを有効にした後、ディメンション と グレースケール も設定する必要があります。ディメンション の有効な値は、IP、カスタムヘッダ、カスタムパラメーター、カスタム Cookie、および Session です。

      説明

      カナリアルールは、すべてのリクエストの一定の割合にランダムに適用されるのではなく、設定されたディメンションに基づいて有効になります。たとえば、ディメンションをIPに、グレースケールを 10% に設定した場合、WAF はすべての IP アドレスの約 10% を選択します。WAF は、すべてのリクエストのランダムな 10% にではなく、選択された IP アドレスからのすべてのリクエストにルールを適用します。

      [有効化されるモード]

      • [Permanently Effective] (デフォルト)：保護テンプレートが有効になっている場合、ルールは常に有効です。

      • [期間ごとに有効化する]：ルールは指定された期間のみ有効です。

      • [周期ごとに有効化する]: ルールは、指定された繰り返し期間のみ有効です。

    ステップ 3: 適用先オブジェクトの設定

    有効対象 エリアで、テンプレートを適用する 保護対象オブジェクトと保護対象オブジェクトグループ を選択します。

    テンプレートの適用方法は、「ステップ 1」で行った設定によって異なります。

    • テンプレートをデフォルトの保護テンプレートとして設定した場合：適用先オブジェクトを設定する必要はありません。テンプレートは、デフォルトですべての既存および新規の保護対象と保護対象グループに適用されます。特定のオブジェクトのステータスを「未適用」に設定することで、手動で除外できます。

    • テンプレートをデフォルトの保護テンプレートとして設定していない場合: テンプレートが適用される保護対象オブジェクトおよび保護対象オブジェクトグループを手動で指定する必要があります。

    説明

    テンプレートの作成中および作成後に、保護対象または保護対象グループの適用ステータスを手動で調整できます。

    保護ルールの設定例

    重要

    以下の設定例は参考用です。本番環境にルールを展開する前に、実際のビジネストラフィックと攻撃パターンに基づいて調整する必要があります。これらの例を直接コピーして適用すると、ビジネスの中断や保護の無効化を引き起こす可能性があります。

    管理パネルへのアクセスを特定の IP アドレスに制限

    /wp-admin パスへのすべてのアクセスリクエストをブロックし、管理者の IP アドレスである 192.1.XX.XX からのリクエストのみを許可します。

    • 一致条件：

      • マッチフィールド を IP に、論理記号 を Not Belong To に、マッチコンテンツ を管理者のホワイトリスト IP アドレス 192.1.XX.XX に設定します。

      • マッチフィールド を URI Path に、論理記号 を Contains に、マッチコンテンツ をアクセスを制限するパス (/wp-admin) に設定します。

    • Protection Rule Type： Access Control。

    • Rule Action： ブロック。

    ドメインをテストするための IP アドレスのホワイトリスト登録

    WAF に追加されたテストドメインへのアクセスを、特定のホワイトリスト IP アドレスのみに許可し、その他のすべての公開トラフィックをブロックします。

    • 一致条件：

      • マッチフィールド を IP に、論理記号 を Not Belong To に、マッチコンテンツ を 203.xx.xx.200/32 などの許可リストに登録された IP アドレス範囲に設定します。

      • マッチフィールド を Host に、論理記号 を Equals に、マッチコンテンツ を test.example.com などのテストドメインに設定します。

    • Protection Rule Type： Access Control。

    • Rule Action： ブロック。

    Host ヘッダーが一致しないリクエストのブロック

    リクエストの Host ヘッダーが正規のビジネスドメインと一致しない場合、次のルールを使用してブロックできます。これにより、CC 攻撃や悪意のあるプロービングのリスクを軽減できます。

    • 一致条件：

      • [マッチフィールド]： Host。

      • [論理記号]: 等しくない。

      • マッチコンテンツ： ビジネスで使用している正規のドメイン名を入力します。

    • Protection Rule Type： Access Control。

    • Rule Action： ブロック。

    悪意のあるクローラーとスキャナーのブロック

    カスタムルールを設定する際、次の一般的な User-Agent (UA) パターンを使用して、さまざまなタイプのトラフィックを識別できます。

    • セキュリティスキャンツール: sqlmap、nmap、nikto など、脆弱性スキャンに一般的に使用されるツールです。

    • 自動化されたスクリプトとライブラリ: python-requests、Python-urllib、curl/、Wget/ などがあり、これらはスクリプトによる呼び出しやブラウザ以外からのアクセスによく使用されます。

    • データスクレイピングクローラー: MJ12bot、AhrefsBot、SemrushBot など、SEO 分析やコンテンツのスクレイピングに使用されます。

    • 主要な検索エンジン：Googlebot、Baiduspider、bingbot など。

    • モバイル識別子： Mobile、Android、iPhone、iPad など。

    説明

    UA フィールドのみに依存することは、悪意のあるトラフィックを識別する信頼性の高い方法ではありません。攻撃者は通常のブラウザを模倣するために UA を偽装することがよくあるためです。カスタムルールを設定する際は、正規のビジネスリクエストのブロックを避けるため、IP 評価、アクセス頻度、WAF ログ も考慮して総合的に評価することを推奨します。

    次の例では、UA フィールドに bot という文字列を含む HTTP リクエストをブロックします。

    • [一致条件]: マッチフィールド を User-Agent に、論理記号 を Contains に、マッチコンテンツ を UA パターン bot に設定します。

    • Protection Rule Type： Access Control。

    • Rule Action： ブロック。

    人間による検証を使用したボットのブロック

    /index.php などの悪意のある攻撃を受けているリクエストパスに対して JavaScript 検証を有効にすることで、通常のブラウザアクセスに影響を与えることなく、自動化された攻撃ツールをブロックできます。

    説明

    • 静的ページの場合、JavaScript 検証または CAPTCHA ルールを設定して、リクエストが JavaScript を実行できる標準ブラウザから発信されていることを確認できます。これらの検証方法は同期リクエストにのみ適用され、XMLHttpRequest や Fetch API で行われる非同期リクエストには適していません。

    • サービス間通信に使用されるバックエンド専用 API エンドポイントの場合、JavaScript 検証 を設定することは推奨しません。JavaScript 検証 は、実行するためにブラウザ環境に依存します。API クライアントは通常、JavaScript を解析して実行できないサーバー側プログラムまたは自動化スクリプトであり、正規のリクエストが継続的にブロックされる原因となります。一致条件を設定する際は、JavaScript 検証 の範囲から API エンドポイントを除外することを推奨します。

    • [一致条件]：マッチフィールド を URI Path に、論理記号 を Contains に、マッチコンテンツ を /index.php に設定します。

    • Protection Rule Type： Access Control。

    • Rule Action： JavaScript 検証 または CAPTCHA。

    すべてのリクエストパスで JavaScript 検証を有効にするには、一致条件を / に設定できます。この設定はすべてのリクエストに適用されるため、最小権限の原則に従い、ルールの範囲を正確に定義し、グローバルマッチングは慎重に使用することを推奨します。

    API エンドポイントのレート制限

    example.com/api/pay を除くすべての API エンドポイントに対してレート制限を有効にします。この例では、すべての API エンドポイントの URI に文字列 /api が含まれていることを前提とします。

    • 一致条件：

      • マッチフィールド を URI Path に、論理記号 を Not Equal To に、マッチコンテンツ を /api/pay に設定します。

      • マッチフィールド を URI Path に、論理記号 を Contains に、マッチコンテンツ を /api に設定します。

    • Protection Rule Type： Rate Limiting。

    • Statistical Object： IP。

    • 統計期間 (秒)： 10。

    • しきい値 (回)： 5。

    • Apply To： Current Match Condition。

    • Timeout Period： 1800。

    • Rule Action： ブロック。

    本番デプロイ

    ビジネスの中断を避けるため、ブロック アクションを使用する保護ルールを本番環境で直接作成して有効にしないでください。このデプロイプロセスに従うことを推奨します。

    1. リクエスト特性の分析： WAF の セキュリティレポート と ログ を使用して、IP アドレス、ユーザーエージェント、ヘッダー、URI などの正当なビジネスリクエストと悪意のある攻撃の特性を特定します。レート制限ルールを設定する予定の場合は、通常のビジネストラフィックのベースラインとなるリクエスト頻度も決定する必要があります。

    2. 許可リストの設定： カスタムルールを作成する前に、許可リストルール を作成して信頼できる IP アドレスを許可リストに追加することを推奨します。これにより、信頼できるリクエストが新しいルールによってブロックされるのを防ぎます。

    3. カナリアテストの実行： カスタムルールを作成した後、本番環境にデプロイする前に、次のいずれかの方法を使用してテストします。

      • テストのために非本番環境にルールを適用します。

      • [Rule Action] を [モニター] に設定します。

      • [詳細設定] で [規則的グレースケール] を有効にします。

    4. テスト結果の分析： ルールを一定期間実行した後、セキュリティレポートとログで、一致したリクエストの中に誤検知がないか確認します。

    5. 本番環境への適用： 誤検知率が許容範囲であることを確認した後、ルールアクションを意図したアクションに変更し、ルールを本番環境に適用します。

    6. 継続的な監視と最適化： セキュリティレポートとログを監視します。ビジネストラフィックの変更とルールの有効性に基づいて、ルールを動的に調整および最適化します。

    日常の運用

    保護テンプレートの管理

    新しい保護テンプレートはデフォルトで有効です。保護テンプレートのリストでは、次の操作を実行できます。

    • テンプレートに関連付けられている [保護対象 / グループ] のエントリ数を表示します。

    • ステータス スイッチを使用して、テンプレートを有効または無効にします。

    • テンプレートの Create Rule をクリックします。

    • 保護テンプレートを 編集、削除、または 複製 します。

    • 保護テンプレート名の左側にある 展开图标 アイコンをクリックして、テンプレート内のルールを表示します。

    保護ルールの管理

    新しいルールはデフォルトで有効です。ルールのリストでは、次の操作を実行できます。

    • [ルールID] や [ルール条件] などの情報を表示します。

    • ステータス スイッチを使用して、ルールを有効または無効にします。

    • ルールを 編集 または 削除 します。

    クォータと制限

    • サブスクリプション課金方式のエンタープライズ版またはアルティメット版の WAF インスタンス、および従量課金方式の WAF インスタンスのみが、スライダー、Rate Limiting、および詳細設定 機能をサポートします。

    • 単一の保護ルールには、一致条件 を最大 5 つ設定できます。

    • Equals One of Multiple Values や Contains One of Multiple Values などの論理演算子を使用する場合、最大 50 個の一致コンテンツの値を入力できます。50 個を超える値を照合するには、複数のルールに分割するか、次を含む や Regex Match などの演算子を使用することをお勧めします。

    • ルールが次のいずれかの条件を満たす場合、「高度なルール」となります。サブスクリプション WAF インスタンスの場合、高度なルールは Enterprise Edition 以上でのみサポートされます。従量課金 WAF インスタンスの場合、WAF は高度なルールと基本ルールで異なる課金を行います。料金の詳細については、「従量課金の料金詳細」をご参照ください。

      • ルールタイプがレート制限である場合。

      • 一致フィールドとして Cookie、Content-Type、Content-Length、X-Forwarded-For、Body、Http-Method、File Extension、Filename、Server-Port、Header、Cookie Name、または Body Parameter を使用する場合。

      • 論理演算子として Regex Match または Regex Not Match を使用する場合。

      • 高度な設定として、ルールグレースケールまたは有効時間パターンを使用する場合。

    よくある質問

    ルールが機能しないのはなぜですか？

    設定した WAF カスタムルールが期待どおりに機能しない場合、またはブロックされたリクエストの数が予想よりも大幅に少ない場合は、以下の項目について体系的にトラブルシューティングすることを推奨します。

    基本的な設定とステータスの確認

    1. 保護オブジェクトの関連付けの確認：カスタムルールテンプレートが正しく作成され、ターゲットの 保護対象 / グループ (ALB インスタンスやドメイン名など) に関連付けられていること、およびそのステータスが 有効 であることを確認します。有効でない場合、WAF はルールを配信して実行できません。

    2. テンプレートとルールのステータスの確認：保護テンプレートの [ステータス] スイッチと特定のルールの [ステータス] スイッチの両方がオンになっていることを確認してください。いずれかのスイッチがオフの場合、対応するルールは非アクティブになります。

    3. ルールアクションの確認: ルールの Rule Action が モニター 以外に設定されていることを確認します。モニター アクションは、イベントを記録するだけで、リクエストをブロックしません。

    一致条件とロジックの検証

    1. 一致条件の精度: ルールの マッチフィールド、論理記号、および マッチコンテンツ が対象のリクエストに正しく一致するかどうかを十分に確認してください。 正規表現を使用する場合、エスケープ文字が正しく記述されていることを厳密に検証してください。

    2. 動的パスに対する戦略: 対象パスに動的に生成されるランダムなセグメント (ランダムなパラメーターや ID など) が含まれている場合、一致フィールドを URI Path に設定し、論理演算子 次を含む を使用してパス内の固定された不変の文字列のみを照合することを推奨します。動的な変更によってルールが機能しなくなる可能性があるため、完全なパスを照合することは避けてください。

    3. 欠落しているヘッダーの処理：Referer や User-Agent など、欠落する可能性のあるリクエストヘッダーフィールドについては、「フィールドの値が空である」ことと「フィールドがリクエストヘッダーに存在しない」ことは、2 つの異なる論理状態であることに注意してください。未処理の状態が原因でルールが失敗するのを防ぐため、両方の論理状態に対して条件を設定することを推奨します。

    ルール優先度とトリガー条件の確認

    1. 他のルールが優先される可能性：設定されている他の保護ルールやモジュールを確認してください。たとえば、許可リスト ルールが設定されている場合、ブロックルールによって評価される前にリクエストが通過する可能性があります。

    2. ステータスコード条件によるレート制限: Rate Limiting ルールを設定し、ステータスコード検出を有効にした場合、WAF は、統計期間内に統計対象が「アクセス頻度のしきい値」と「ステータスコードの特性」の両方の条件を満たした場合にのみルールをトリガーします。関連するリクエストに対して、オリジンサーバーが実際に指定されたステータスコード (404 など) を返すことを確認する必要があります。そうでない場合、アクセス頻度がしきい値に達しても、WAF はルールをトリガーしません。

    共有インスタンス上のドメインのレート制限

    レート制限ルールは、保護対象に基づいて単一の統計オブジェクトのリクエスト頻度を制限します。単一のクラウドサービスインスタンスが複数のドメインのトラフィックを処理する場合、WAF は統計目的ですべてのドメインのアクセス頻度を集計します。特定のドメインのみのアクセス頻度を制限する必要がある場合は、次のいずれかの方法を使用できます。

    • ドメインを WAF の保護対象として追加し、その対象にレート制限ルールを適用します。詳細については、「保護対象と保護対象グループの設定」をご参照ください。

    • アクセス頻度制限ルールの一致条件で、[ホスト] フィールドを使用して、アクセス頻度を制限するドメインを指定します。

    ボディパラメーターのマッチフィールドのトラブルシューティング

    マッチコンテンツが短すぎることが原因と考えられます。ボディパラメーターフィールドを使用する場合、マッチコンテンツが 5 文字以上であることを確認してください。そうでない場合、WAF はトラフィックを検出できません。

    夜間の攻撃からの保護方法

    夜間に正規のトラフィックが少ないサービスでは、より厳格な保護ルールを設定して攻撃から防御できます。これを行うには、ルールの有効化されるモードを周期ごとに有効化するに設定し、正しいタイムゾーンを選択することで、夜間の時間帯に正確な保護を適用できます。

    サービスが特定の地域のユーザーに対応していない場合 (たとえば、国内ユーザーのみにサービスを提供している場合)、地域ブロックルール を設定して、これらの地域からのアクセスリクエストを直接ブロックし、それによって異常なトラフィックをブロックすることもできます。

    特定のリクエストを許可し、その他をブロックする方法

    特定のリクエストを許可し、その他すべてをブロックするための設定ロジック

    WAF カスタムルールは「一致してトリガーする」ロジックを使用しており、「指定されたリクエストのみを許可し、その他すべてをブロックする」という許可リストモデルを直接サポートしていません。このセキュリティポリシーを実装するには、逆のロジックを使用する必要があります：「許可基準に一致しないすべてのリクエストをブロックする」。具体的な設定方法については、「特定の IP アドレスへの管理パネルアクセスの制限」をご参照ください。

    WAF と Cloud Firewall の ACL の違い

    WAF は、防御モデルにおいて Cloud Firewall の ACL や ECS のセキュリティグループとは根本的に異なります。

    • Cloud Firewall ACL：固定的で列挙可能な「ビジネスインテント」に基づいて設定されます。たとえば、内部データベースへのアクセスを特定のアプリケーションサーバーの IP アドレスのみに制限できます。「デフォルトですべて拒否、例外で許可」戦略を使用し、ネットワーク攻撃対象領域を正確に削減します。

    • WAF：主に HTTP/HTTPS リクエストに対して、シグネチャと振る舞いに基づいて防御を提供します。Web アプリケーションのトラフィックは非常に複雑で、多数の動的リクエストとユーザーインタラクションが含まれます。WAF で「すべて拒否、例外で許可」戦略を採用した場合、すべての正当なリクエストの特性 (URL、パラメーター、ヘッダーなど) を列挙する必要があります。この戦略は実装が難しいだけでなく、維持コストも非常に高くなります。

    推奨される WAF のきめ細かい戦略

    これらの違いを考慮して、WAF でグローバルな「すべてブロック、特定を許可」ルールを設定することは推奨しません。代わりに、次のきめ細かい設定戦略を採用することをお勧めします。

    1. 精密なアクセス制御：管理パネルやコア API エンドポイントなどの機密性の高いパスに対して、IP アドレス、User-Agent、または特定のヘッダーに基づいて精密なアクセス制御ルールを設定し、厳格なアクセス制御を実施します。

    2. ベースライン保護：一般からの通常のトラフィックに対しては、包括的なブロックを使用するのではなく、WAF のコア Web 保護ルールと CC 保護モジュールを利用して、既知の攻撃パターンと異常な振る舞いを識別してブロックします。

    3. 継続的なチューニング：WAF のイベントログを定期的に分析します。ビジネストラフィックの変化と脅威の状況に基づいてアクセス制御ルールを継続的に繰り返し、改良し、セキュリティとビジネスの可用性のバランスを確保します。

    contains 演算子を使用した重複ルールの回避

    マッチフィールドを [URI パス] に、論理演算子を [含む] に設定すると、指定された文字列がリクエストパスのどこかに現れると、リクエストは一致します。

    例：マッチコンテンツとして /resources/author/ を入力すると、/cn/resources/author/ や /en/resources/author/ などの多言語パスに一致させることができます。

    ユースケース：共通の固定パスセグメントを共有する多階層ディレクトリや多言語サイトの場合、この方法は、重複ルールの必要性を効果的に削減できます。