Google Cloud Armor の事前構成 WAF ルールを調整する

Google Cloud Armor では、事前構成 WAF ルールが用意されています。各ルールは、ModSecurity Core Rule Set（CRS）の複数のシグネチャから構成されています。各シグネチャは、ルールセット内の攻撃検出ルールに対応しています。受信リクエストは、事前構成 WAF ルールに対して評価されます。事前構成 WAF ルールに関連付けられているシグネチャのいずれかとリクエストが一致する場合、そのリクエストは事前構成 WAF ルールと一致します。evaluatePreconfiguredWaf() または evaluatePreconfiguredExpr() 式が値 true を返すと、マッチングが行われます。

感度を選択する

各シグネチャの感度レベルは、ModSecurity のパラノアレベルに対応します。感度は 0～4 の間で選択できます。感度レベル 0 は、デフォルトでルールが有効にならないことを意味します。

感度レベルが低いほど、信頼度の高いシグネチャとなり、偽陽性が生じる可能性は低くなります。感度レベルが高いほど、セキュリティは強化されますが、誤検出が生じるリスクが高まります。WAF ルールの感度レベルを選択すると、選択したレベル以下の感度レベルでシグネチャを有効にします。次の例では、1 の感度レベルを選択して、事前構成 WAF ルールを調整します。

evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1})

ルールのシグネチャを無効にする

事前構成 WAF ルールが必要以上のリクエストと一致すると判断した場合、または許可する必要があるトラフィックをルールがブロックしている場合は、ルールを調整して、ノイズの多いまたは不要なシグネチャを無効にできます。特定の事前構成 WAF ルールでシグネチャを無効にするには、不要なシグネチャの ID のリストを evaluatePreconfiguredWaf() 式で指定します。

次の例では、事前構成の sqli-v33-stable（CRS 3.3）WAF ルールから 2 つの CRS ルール ID を除外しています。

evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 4, 'opt_out_rule_ids': ['owasp-crs-v030301-id942350-sqli', 'owasp-crs-v030301-id942360-sqli']})

事前構成の CRS ルールセットのシグネチャ ID を無効にする場合は、構成エラーを避けるために、シグネチャ ID のバージョンとルールセットのバージョン（CRS 3.0 または 3.3）を一致させる必要があります。

シグネチャ ID は、従来の式 evaluatePreconfigureExpr() を使用して無効にすることもできます。事前構成 WAF ルール式の詳細については、カスタムルールの言語リファレンスをご覧ください。

ルールのシグネチャを有効にする

ルールのシグネチャを無効にせずに、特定の感度レベルでルールのシグネチャを有効にできます。特定の感度レベルで使用するシグネチャの数が少ない場合、ルール シグネチャを有効にすることをおすすめします。ルールのシグネチャを有効にするには、感度レベルを 0 にする必要があります。次の例では、すべての感度レベルですべての cve-canary シグネチャを無効にし、owasp-crs-v030001-id044228-cve と owasp-crs-v030001-id144228-cve を明示的に有効にしています。

evaluatePreconfiguredWaf('cve-canary', {'sensitivity': 0, 'opt_in_rule_ids': ['owasp-crs-v030001-id044228-cve', 'owasp-crs-v030001-id144228-cve']})

リクエスト フィールドを検査対象から除外する

カスタム アプリケーションには、事前構成 WAF ルールのシグネチャに一致するコンテンツ（ヘッダー、Cookie、クエリ パラメータ、URI など）が含まれている場合がありますが、これらは正規のものであることは明らかです。この場合、リクエスト フィールドの除外リストをセキュリティ ポリシー ルールに関連付けることで、これらのリクエスト フィールドを検査対象から除外し、誤検出を減らすことができます。

リクエスト フィールドの除外を構成する場合は、フィールドをターゲットに関連付けます。ターゲットは、事前構成 WAF ルール全体か、事前構成 WAF ルールのシグネチャのリストになります。フィールド演算子とフィールド値を使用して、完全一致または部分一致を指定できます。使用できるフィールド演算子は次のとおりです。

• EQUALS: 指定された値とフィールド値が等しい場合に、演算子が処理されます。
• STARTS_WITH: 指定された値でフィールド値が始まる場合に、演算子が処理されます。
• ENDS_WITH: 指定された値でフィールド値が終わる場合、演算子が処理されます。
• CONTAINS: 指定された値がフィールド値に含まれている場合、演算子が処理されます。
• EQUALS_ANY: フィールド値がなんらかの値と一致する場合、演算子が処理されます。

以降のセクションでは、検査から除外できるリクエスト フィールドの詳細と例について説明します。

リクエスト ヘッダー

事前構成 WAF ルールの評価中に値が検査から除外されるリクエスト ヘッダー名のリスト。

除外は、リクエスト ヘッダーの値を検査するターゲットのシグネチャにのみ適用されます。これには、ModSecurity Core Rule Set の次のリクエスト フラグに関連付けられたシグネチャが含まれます。

• REQUEST_HEADERS

指定したリクエスト ヘッダーの値のみが検査から除外されます。名前は検査されます。

リクエスト Cookie

事前構成 WAF ルールの評価中に値が検査から除外されるリクエスト Cookie 名のリスト。

除外は、リクエスト Cookie の値を検査するターゲットのシグネチャにのみ適用されます。これには、ModSecurity Core Rule Set の次のリクエスト フラグに関連付けられたシグネチャが含まれます。

• REQUEST_COOKIES

指定したリクエスト Cookie の値のみが検査から除外されます。名前は検査されます。

リクエスト クエリ パラメータ

事前構成 WAF ルールの評価中に値が検査から除外されるリクエスト クエリ パラメータ名のリスト。

除外は、リクエスト パラメータを検査するターゲットのシグネチャにのみ適用されます。これには、ModSecurity Core Rule Set の次のリクエスト フラグに関連付けられたシグネチャが含まれます。

• ARGS
• ARGS_GET
• REQUEST_URI
• REQUEST_URI_RAW
• REQUEST_LINE

検査から除外されるのは、指定したクエリ パラメータの値のみです。これは、クエリ文字列または POST 本文に含めることができます。名前は検査されます。

クエリ パラメータは URI とリクエスト行の一部であるため、これらのフィールドは、指定されたクエリ パラメータを除外した後で検査のために再構成されます。ただし、リクエスト本文全体を検査するシグネチャ（リクエスト フラグ REQUEST_BODY に関連付けられたシグネチャなど）の場合、クエリ パラメータの除外は適用されません。

たとえば、args という名前のクエリ パラメータを除外した場合、リクエストの POST 本文に args パラメータがあり、args の値が一致すると、リクエスト本文全体を検査するシグネチャが一致することがあります。

リクエスト URI

事前構成 WAF ルールの評価中に検査から除外するクエリ文字列データを除く、リクエスト行の URI のリスト。

除外は、リクエストの URI を検査するターゲットのシグネチャにのみ適用されます。これには、ModSecurity Core Rule Set の次のリクエスト フラグに関連付けられたシグネチャが含まれます。

• REQUEST_URI
• REQUEST_URI_RAW
• REQUEST_LINE
• REQUEST_FILENAME
• REQUEST_BASENAME

前述のフィールドのいずれかを除外する場合、そのフィールドは検査から完全に除外され、再構成は行われません。

フィールド値

EQUALS_ANY 以外のフィールド演算子を使用する場合は、フィールド値を指定する必要があります。

リクエスト ヘッダー、リクエスト Cookie、リクエスト クエリ パラメータのフィールド値に使用できる文字セットは、次のとおりです。

• !、#、$、%、&、*、+、-、.、^、_、`、|、~
• A～Z の英数字（小文字と大文字の両方）
• 0～9 の数字

これらのリクエスト フィールドの除外を適用すると、構成フィールドの値とリクエスト内の値（変換後は大文字と小文字が区別されない）が比較されます。許可された文字セットに含まれていない特定の文字を除外する場合、追加のエンコードを実行する必要はありません。

リクエスト URI の場合、フィールド値は次のような URI 形式で指定する必要があります。

• スキームを使用できますが、http または https のみに制限されます。
• ホストを使用できるほかに、IP アドレスを指定することもできます。
• ポートを使用できます。
• パスを使用できます。
• クエリは使用できません。
• フラグメントは使用できません。

リクエスト URI の除外を適用すると、構成フィールドの値とリクエスト行の URI（変換後は大文字と小文字が区別されない）が比較されます（クエリ文字列は除きます）。リクエスト行の URI には、相対 URI または絶対 URI を指定できます。リクエスト URI の除外を構成する場合は、この点に注意してください。

例

最初の例では、PRIORITY のセキュリティ ポリシー POLICY_1 のルールを更新し、sqli-v33-stable WAF ルールのすべてのシグネチャの除外構成を追加して、すべてのリクエスト Cookie を検査から除外します。

gcloud compute security-policies rules add-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_1 \
    --target-rule-set "sqli-v33-stable" \
    --request-cookie-to-exclude "op=EQUALS_ANY"

2 番目の例では、PRIORITY のセキュリティ ポリシー POLICY_2 のルールを更新し、xss-v33-stable WAF ルールにあるシグネチャ owasp-crs-v030301-id941140-xss と owasp-crs-v030301-id941270-xss の除外構成を追加します。abc で始まるリクエスト ヘッダーまたは xyz で終わるリクエスト ヘッダーが検査から除外されます。

gcloud compute security-policies rules add-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_2 \
    --target-rule-set "xss-v33-stable" \
    --target-rule-ids "owasp-crs-v030301-id941140-xss" "owasp-crs-v030301-id941270-xss" \
    --request-header-to-exclude "op=STARTS_WITH,val=abc" \
    --request-header-to-exclude "op=ENDS_WITH,val=xyz"

3 番目の例では、PRIORITY のセキュリティ ポリシー POLICY_3 のルールを更新し、sqli-v33-stable にあるルール ID owasp-crs-v030301-id942110-sqli と owasp-crs-v030301-id942120-sqli のすべてのリクエスト フィールドの除外を削除します。

gcloud compute security-policies rules remove-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_3 \
    --target-rule-set "sqli-v33-stable" \
    --target-rule-ids "owasp-crs-v030301-id942110-sqli,owasp-crs-v030301-id942120-sqli"

カスタムの Content-Type ヘッダー値に JSON 解析を適用する

Google Cloud Armor が事前構成された WAF ルールに対して POST 本文を評価する場合、Content-Type ヘッダーはリクエスト本文のデータ形式を示します。デフォルトでは、Google Cloud Armor は POST 本文の内容を 1 つの文字列として扱います。これらはすべて、事前構成されている WAF ルールによる検査と照合の対象になります。ただし、受信リクエストに別のエンコードがある場合は、より正確な解析を構成できます。Google Cloud Armor は、次のエンコード タイプをサポートしています。

• JSON
• GraphQL

代替解析が適用されるカスタム Content-Type ヘッダー値のリストを構成するには、次の例を使用します。次の例では、セキュリティ ポリシー POLICY_NAME を更新して JSON 解析を有効にし、コンテンツ タイプ application/json、application/vnd.api+json、application/vnd.collection+json、application/vnd.hyper+json を指定します。

gcloud compute security-policies update POLICY_NAME \
    --json-parsing STANDARD \
    --json-custom-content-types "application/json,application/vnd.api+json,application/vnd.collection+json,application/vnd.hyper+json"

または、セキュリティ ポリシーで GraphQL を使用するアプリケーション、または GraphQL でエンコードされたコンテンツを保護する場合は、引数 STANDARD_WITH_GRAPHQL を使用して、次のように POSTQ 本文のコンテンツを GraphQL コンテンツとして解析できます。次に例を示します。

gcloud compute security-policies update POLICY_NAME \
    --json-parsing STANDARD_WITH_GRAPHQL

POST 本文の検査は、引き続き最初の 8 KB に制限されます。詳細については、セキュリティ ポリシーの制限をご覧ください。

• JSON コンテンツが 8 KB より大きい場合、Google Cloud Armor は、事前構成 WAF ルールで検査される最初の 8 KB のコンテンツに JSON 解析を適用します。

• JSON パーサーが結果を返さない場合は、URI 解析が試行される可能性があります。URI パーサーが name-value パラメータを返さないか、部分的な name-value パラメータのみを返す場合、文字列全体または部分的な文字列が検査のパラメータ名として使用されます。

次のステップ

• セキュリティ ポリシーの構成の詳細を確認する。
• 事前構成 WAF ルールで使用可能なルール シグネチャについて学習する。
• カスタムルールの言語リファレンスで、事前構成 WAF ルールについて学習する。