Google Cloud Armor のセキュリティ ポリシーの問題をトラブルシューティングするには、こちらの手順を使用してください。
一般的な問題
セキュリティ ポリシーのデバッグ
特定のイベントによって事前構成済みのルールがトリガーされる原因に関する追加情報が必要な場合は、リクエスト ロギングの使用を参照し、詳細ログを有効にします。Cloud Logging によってログに詳細が記録されます。このログを使用して、ポリシーとルールを分析し、デバッグできます。
Cloud Armor セキュリティ ポリシーで拒否ルールを構成しているにもかかわらずトラフィックが許可される
この問題を解決する手順は次のとおりです。
Cloud Armor セキュリティ ポリシーがターゲットのバックエンド サービスに接続されていることを確認します。たとえば、次のコマンドを実行すると、バックエンド サービス
BACKENDに関連付けられているすべてのデータが表示されます。返される結果に、このバックエンド サービスに関連付けられている Cloud Armor セキュリティ ポリシーの名前が含まれています。gcloud compute backend-services describe BACKEND
HTTP(S) ログを確認して、トラフィックに一致したポリシーとルール、および関連するアクションを特定します。ログを表示するには、Cloud Logging を使用します。
許可されたリクエストのログの例を以下に示します。注意が必要なフィールドはハイライト表示されています。次のフィールドを確認して、トラフィックを拒否するように構成したルールと一致することを確認します。
configuredActionは、ルールで構成されたアクションと一致する必要があります。nameは、このバックエンド サービスに接続された Cloud Armor セキュリティ ポリシーの名前と一致する必要があります。outcomeはconfiguredActionと一致する必要があります。priorityは、ルールの優先度の数字と一致する必要があります。
httpRequest: remoteIp: 104.133.0.95 requestMethod: GET requestSize: '801' requestUrl: http://74.125.67.38/ responseSize: '246' serverIp: 10.132.0.4 status: 200 userAgent: curl/7.35.0 insertId: ajvis5ev4i60 internalId: projectNumber: '895280006100' jsonPayload: '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry enforcedSecurityPolicy: configuredAction: ACCEPT name: mydev-policy-log-test1 outcome: ACCEPT priority: 2147483647 statusDetails: response_sent_by_backend logName: projects/mydev-staging/logs/requests resource: labels: backend_service_name: BACKEND_SERVICE_NAME forwarding_rule_name: FORWARDING_RULE_NAME project_id: PROJECT_ID target_proxy_name: TARGET_HTTP_PROXY_NAME url_map_name: URL_MAP_NAME zone: global type: http_load_balancer severity: INFO timestamp: '2017-04-18T18:57:05.845960288Z'ルールの階層を確認して、確実に正しいルールが一致するようにします。allow アクションを含むより優先度の高いルールがトラフィックと一致している可能性があります。Google Cloud CLI で
security-policiesのdescribeコマンドを使用して、Cloud Armor セキュリティ ポリシーの内容を表示します。たとえば、次の例では、より優先度の高い許可ルール（優先度 100）が IP アドレス 1.2.3.4 からのトラフィックに一致します。そのため、優先度の低い拒否ルール（優先度 200）はトリガーされず、このトラフィックはブロックされません。
gcloud compute security-policies describe POLICY_NAME
出力:
creationTimestamp: '2017-04-18T14:47:58.045-07:00 description: '' fingerprint: Yu5spBjdoC0= id: '2560355463394441057' kind: compute#securityPolicy name: POLICY_NAME rules: -action: allow description: allow high priority rule kind: compute#securityPolicyRule match: srcIpRanges: -'1.2.3.4/32' preview: false priority: 100 -action: deny description: deny lower priority rule kind: compute#securityPolicyRule match: srcIpRanges: -'1.2.3.0/24 preview: false priority: 200 -action: deny description: default rule kind: compute#securityPolicyRule match: srcIpRanges: -'*' preview: false priority: 2147483647 selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp
事前構成済みのルールが偽陽性を返す
XSS と SQLi の検出は、HTTP リクエスト ヘッダーと他の L7 パラメータの静的なシグネチャ マッチングに基づいています。これらの正規表現パターンでは、偽陽性となる可能性が高くなります。XSS や SQLi の検出用の事前構成済みルールをプレビュー モードで使用した後、ログに偽陽性がないかを確認できます。
偽陽性が見つかった場合は、トラフィックの内容を OWASP CRS のルールと比較できます。ルールが無効または不適切な場合は、evaluatePreconfiguredWaf 式を使用してルールを無効にし、exclude ID list 引数でルールの ID を指定します。
ログを確認してすべての偽陽性を削除した後、プレビュー モードを無効にします。
事前構成済みのルールをプレビュー モードで追加するには:
プレビュー モードで事前構成済みの式セットとともにセキュリティ ポリシーを作成します。
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredWaf('xss-stable')" --action deny-403 --previewHTTP(S) ログで
urlやcookieなどの HTTP リクエスト フィールドを確認します。この例では、requestUrlが OWASP CRS ルール ID 941180 に対して陽性となっています。httpRequest: remoteIp: 104.133.0.95 requestMethod: GET requestSize: '801' requestUrl: http://74.125.67.38/foo?document.cookie=1010" responseSize: '246' serverIp: 10.132.0.4 status: 200 userAgent: curl/7.35.0 insertId: ajvis5ev4i60 internalId: projectNumber: '895280006100' jsonPayload: '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry enforcedSecurityPolicy: configuredAction: ACCEPT name: POLICY_NAME outcome: ACCEPT priority: 2147483647 preconfiguredExprIds: [ 'owasp-crs-v030001-id941180-xss' ] statusDetails: response_sent_by_backend logName: projects/mydev-staging/logs/requests resource: labels: backend_service_name: BACKEND_SERVICE forwarding_rule_name: mydev-forwarding-rule project_id: mydev-staging target_proxy_name: mydev-target-http-proxy url_map_name: mydev-url-map zone: global type: http_load_balancer severity: INFO timestamp: '2017-04-18T18:57:05.845960288Z'Cloud Armor セキュリティ ポリシーのルールを更新して、OWASP CRS ルール ID 941180 を除外します。
gcloud compute security-policies rules update 1000 \ --security-policy POLICY_NAME \ --expression "evaluatePreconfiguredWaf('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \ --action deny-403 \ --previewログをもう一度確認してから、プレビュー モードを無効にしてルールを実装します。
拒否されたシグネチャを持つクライアントがブロックまたは拒否されない
Cloud Armor と Cloud CDN を併用している場合、セキュリティ ポリシーが適用されるのは、動的コンテンツやキャッシュミスに関するリクエスト、または CDN オリジン サーバーが宛先であるその他のリクエストに限られます。そのリクエストが CDN オリジン サーバーに到達するのを防ぐ Cloud Armor セキュリティ ポリシーがダウンストリームにある場合でも、キャッシュ ヒットは処理されます。
レート制限に関する問題
トラフィックが適切に制限されない
クライアント IP アドレスが、設定したしきい値を超えるレートでアプリケーションに大量のトラフィックを送信していても、予期したとおり制限されない場合があります。次の手順に沿って問題を調査してください。
まず、優先度の高いルールにより、その IP アドレスからのトラフィックが許可されているかどうかを確認します。ログを調べて、IP アドレスに対して ALLOW ルールがトリガーされたかどうかを確認します。ALLOW ルール単独の場合もあれば、別の THROTTLE ルールや RATE_BASED_BAN ルールで使用されている場合もあります。
優先度の高いルールが見つかった場合は、次のいずれかを行います。
- 優先度を変更し、優先度に小さい数値を割り当てて、レート制限ルールに高い優先順位が設定されるようにします。
- 優先度の高いルールに一致する式から IP アドレスを除外します。
しきい値が正しく設定されていない可能性もあります。その場合、リクエストは正確に照合されますが、確認アクションがトリガーされます。ログを調べてこれに該当していることを確認したら、ルールのしきい値を下げます。
さらに、IP アドレスがスロットルまたはレートベースの禁止ルールと一致しない場合があります。この問題を解決するには、一致条件に誤りがないことを確認してから、ルールの一致条件を正しい値に変更します。