Google Cloud Armor に関する問題のトラブルシューティング

Google Cloud Armor セキュリティ ポリシーの問題をトラブルシューティングするには、こちらの手順を使用してください。

一般的な問題

セキュリティ ポリシーのデバッグ

特定のイベントによって事前構成済みのルールがトリガーされる原因に関する追加情報が必要な場合は、リクエスト ロギングの使用を参照し、詳細ログを有効にします。Cloud Logging によってログに詳細が記録されます。このログを使用して、ポリシーとルールを分析し、デバッグできます。

Google Cloud Armor セキュリティ ポリシーで構成された拒否ルールにもかかわらずトラフィックが許可される

この問題を解決する手順は次のとおりです。

  1. Google Cloud Armor セキュリティ ポリシーがターゲット バックエンド サービスに接続されていることを確認してください。たとえば、次のコマンドは、バックエンド サービス BACKEND に関連付けられているすべてのデータを示しています。返される結果には、このバックエンド サービスに関連付けられている Google Cloud Armor セキュリティ ポリシーの名前が含まれているはずです。

    gcloud compute backend-services describe BACKEND
    
  2. HTTP(S) ログを確認して、トラフィックに一致したポリシーとルール、および関連するアクションを特定します。ログを表示するには、Cloud Logging を使用します。

    許可されたリクエストのログの例を以下に示します。注意が必要なフィールドはハイライト表示されています。次のフィールドを確認して、トラフィックを拒否するように構成したルールと一致することを確認します。

    • configuredAction は、ルールで構成されたアクションと一致する必要があります。
    • name は、このバックエンド サービスに接続された Google Cloud Armor セキュリティ ポリシーの名前と一致する必要があります。
    • outcomeconfiguredAction と一致する必要があります。
    • 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'
    
  3. ルールの階層を確認して、確実に正しいルールが一致するようにします。allow アクションのある優先度の高いルールがトラフィックと一致している可能性があります。Google Cloud CLI の security-policiesdescribe コマンドを使用して、Google 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 の検出用に事前構成済みのルールを使用して、ログに偽陽性がないか確認できます。

偽陽性が見つかった場合は、トラフィックの内容を ModSecurity CRS のルールと比較できます。ルールが無効または不適切な場合は、evaluatePreconfiguredExpr 式を使用してルールを無効にし、exclude ID list 引数でルールの ID を指定します。

ログを確認してすべての偽陽性を削除した後、プレビュー モードを無効にします。

事前構成済みのルールをプレビュー モードで追加するには:

  1. プレビュー モードで事前構成済みの式セットとともにセキュリティ ポリシーを作成します。

    gcloud compute security-policies rules create 1000
       --security-policy POLICY_NAME
       --expression "evaluatePreconfiguredExpr('xss-stable')"
       --action deny-403
       --preview
    
  2. urlcookie などの HTTP リクエスト フィールドの HTTP(S) ログを確認します。たとえば、requestUrl は ModSecurity 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'
    
  3. Google Cloud Armor セキュリティ ポリシーのルールを更新して、ModSecurity CRS ルール ID 941180 を除外します。

    gcloud compute security-policies rules update 1000 \
        --security-policy POLICY_NAME \
        --expression "evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
        --action deny-403 \
        --preview
    
  4. ログをもう一度確認してから、プレビュー モードを無効にしてルールを実装します。

シグネチャが拒否されたクライアントがブロックまたは拒否されない

Google Cloud Armor と Cloud CDN を併用している場合、セキュリティ ポリシーが適用されるのは、動的コンテンツやキャッシュ ミスに関するリクエスト、または CDN オリジン サーバーが宛先であるその他のリクエストに限られます。そのリクエストが CDN オリジン サーバーに到達することをダウンストリーム Google Cloud Armor セキュリティ ポリシーが禁止している場合でも、キャッシュ ヒットが発生します。

事前構成された WAF ルールを使用する場合に 8 KB を超える POST 本文のリスクを軽減する

事前構成された WAF ルールが Google Cloud Armor セキュリティ ポリシーで評価されると、WAF ルールを使用して最大 8 KB の POST 本文が検査され、署名の一致が確認されます。これにより、他の Google ユーザーの可用性を維持しながら、低レイテンシでレイヤ 7 の検査と保護を実現できます。

検査されていないコンテンツがバックエンドに到達しないように、セキュリティ ポリシーにルールを作成すると、POST リクエストが大量に発生するリスクを軽減できます。POST 本文のサイズが 8 KB(8,192 バイト)を超えるトラフィックを拒否するルールを作成します。次のコードサンプルに、このルールの作成方法を示します。

gcloud compute security-policies rules create 10 \
    --security-policy my-policy \
    --expression "int(request.headers['content-length']) > 8192" \
    --action deny-403 \
    --description "Block requests great than 8KB"

名前付き IP アドレスリストに関する問題

このセクションでは、名前付き IP アドレスリストに関する問題の解決について説明します。

名前付き IP アドレスリストに含まれる IP アドレス

リスト内の IP アドレスは、Google Cloud Armor の名前付き IP アドレスリスト ガイドに記載されているプロバイダ ウェブサイトの IP アドレスと常に一致します。リストについてご不明な点がある場合は、Cloud サポートチームにお問い合わせください。

名前付き IP アドレスリスト内の IP アドレスが、Google Cloud Armor で最新でない

Google Cloud Armor は、IP アドレスリストを IP アドレスリスト プロバイダと毎日同期します。プロバイダのデータよりも数時間または 1 日遅れている古いデータが存在する可能性があります。ただし、古いデータが想定よりも長く残っていると思われる場合(1 週間を超える場合など)は、Cloud サポートチームにお問い合わせください。

名前付き IP アドレスリストを参照するセキュリティ ポリシーの作成が難しい

次のようなコマンドを使用して、名前付き IP アドレスリストを参照するセキュリティ ポリシーを作成できます。

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
    --action "allow"

コマンドが失敗した場合、次のようなエラーが表示されます。

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.

特定のプロバイダがサポートされていることと、IP アドレスリストの名前が正しく指定されていることを確認します。これを行うには、次の gcloud コマンドを使用して、現在の事前構成済みの式セットを一覧表示します。

gcloud compute security-policies list-preconfigured-expression-sets

名前付き IP アドレスの許可リストに事前構成済みのルールがあるにもかかわらず、トラフィックがブロックされている

名前付き IP アドレスリストにある IP アドレスからのトラフィックがブロックされている場合があります。

  1. トラフィックが名前付き IP アドレスの許可リスト上の IP アドレスから発信されていることを確認します。

  2. トラフィックをブロックする可能性のある他のセキュリティ ルールがあるかどうかを確認します。問題が解決しない場合は、Cloud サポートチームにお問い合わせください

  3. セキュリティ ポリシーが正しいバックエンド サービスに接続されていることを確認します。

    gcloud compute backend-services describe BACKEND_SERVICE
    
  4. セキュリティ ポリシーにあるルールを確認します。次に例を示します。

     gcloud compute security-policies describe POLICY_NAME
    

    コマンドから次のような情報が返されます。

    ---
    …
    name: POLICY_NAME
    rules:
    -action: allow
     description: allow fastly ip addresses
     kind: compute#securityPolicyRule
     match:
        expr:
          expression: evaluatePreconfiguredExpr('sourceiplist-fastly')
     preview: false
     priority: 100
    -action: deny(403)
     description: Default rule, higher priority overrides it
     kind: compute#securityPolicyRule
     match:
        config:
          srcIpRanges:
          -'*'
        versionedExpr: SRC_IPS_V1
     preview: false
     priority: 2147483647
    -action: deny(404)
     description: deny altostrat referer
     kind: compute#securityPolicyRule
     match:
        expr:
          expression: request.headers['Referer'].contains('altostrat')
     preview: false
     priority: 50
    …
    

    上記のセキュリティ ポリシーには、3 つのルールがあります。デフォルトの拒否ルール、Fastly の IP アドレスの許可ルール、altostrat を含むリファラーの拒否ルールです。また、それぞれの優先度も表示されます。

  5. ログを調べて、トラフィックに一致するルールと、関連するアクションを決定します。ロギングの詳細については、ログ エクスプローラの使用をご覧ください。

    ログの例を次に示します。

     httpRequest: {
        referer: "http://www.altostrat.com/"
        remoteIp: "23.230.32.10"
        requestMethod: "HEAD"
        requestSize: "79"
        requestUrl: "http://www.example.com/"
        responseSize: "258"
        status: 404
        userAgent: "Mozilla/5.0"
      }
      …
      jsonPayload: {
        @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
        enforcedSecurityPolicy: {
          configuredAction: "DENY"
          name: "POLICY_NAME"
          outcome: "DENY"
          priority: 50
        }
        statusDetails: "denied_by_security_policy"
      }
      …
    

    上記のログからのリクエストは 23.230.32.10 からのもので、Fastly のパブリック IP アドレスリストから取得されます。ただし、リクエストは、優先度 50 の拒否ルールと一致しています。これをセキュリティ ポリシーの内容と比較すると、このルールは altostrat を含むリファラーの拒否ルールに対応しています。このリクエストには http://www.altostrat.com/ というリファラーがあるため、セキュリティ ルールの適用は正しく動作しています。

Security Command Center の検出に関する問題

このセクションでは、Security Command Center の知見に関する問題について説明します。

Google Cloud Armor カードが Security Command Center に表示されない

Security Command Center インターフェースで Google Cloud Armor の検出結果を有効にします。

Google Cloud Armor の検出結果が Security Command Center に表示されない

Google Cloud Armor の検出結果が Security Command Center に表示されない場合、バックエンド サービスへのトラフィックが検出結果を表示するための基準を満たしていない可能性があります。

バックエンドへのトラフィック量に関する質問については、ネットワーク セキュリティ ポリシーにある Cloud Monitoring ダッシュボードでリクエスト統計を確認してください。

検出結果が多すぎる

この問題に関するサポートについては、Cloud サポートチームにお問い合わせください

Google Cloud Armor 適応型保護に関する問題

適応型保護に関する問題を解決するには、こちらの手順を使用してください。

セキュリティ ポリシーでは適応型保護が有効になっているが、Cloud Logging にログがない

適応型保護ログは、Google Cloud Armor リクエストログとは別に生成され、Cloud Logging 内の別のリソースに表示されます。適応型保護のログとイベントは、Cloud Logging のネットワーク セキュリティ ポリシー リソースの下に表示されます。セキュリティ ポリシーで適応型保護を有効にしてから、適応型保護が不審な攻撃に対するアラートを生成し始めるまでに、少なくとも 1 時間のトレーニング期間があります。トレーニング期間中、適応型保護は受信リクエスト トラフィックを学習し、そのセキュリティ ポリシーで保護されているバックエンド サービスごとにベースラインを作成します。これにより、適応型保護によって不審なアクティビティが特定されます。

セキュリティ ポリシーで適応型保護を有効にして、1 時間トレーニング期間の後にアラートをまったく観測しない場合、そのセキュリティ ポリシーに関連付けられているバックエンド サービスのいずれに対しても、潜在的に悪意のある標的を設定しているとして特定されたアクティビティがないことを示しています。

潜在的な攻撃や異常なトラフィックが数時間以上続くと、適応型保護はその動作をベースラインの動作として判断し、類似するトラフィック パターンに対するアラートを継続しなくなります。攻撃が終了したか、適切な Google Cloud Armor ルールで攻撃をブロックしたかのいずれかの理由で潜在的な攻撃が少なくなり、トラフィック パターンが元のベースラインに戻った後、適応型保護は、それ以降にベースラインから逸脱したと見なされたトラフィックの動作に対してアラートを生成します。

そのほか、適応型保護は、Google Cloud Armor セキュリティ ポリシーで許可されるトラフィックを分析します。トラフィックの制限付き許可リストを使用してアクセスを拒否するデフォルトのルールを設定した場合、適応型保護は、許可リストに関する評価に合格したトラフィック上でのみ、悪意のあるアクティビティを検出します。

適応型保護からのアラートや Cloud Logging のログが多すぎる

適応型保護のアラートは、適応型保護モデルで検出されたアクティビティの異常性と攻撃の可能性の度合いを示す信頼スコアを提供します。ログのエントリは、Cloud Logging を使用してフィルタし、信頼スコアが特定のしきい値を超えたアラートのみを表示(またはダウンストリームに転送)できます。

適応型保護は、アラートを誤検出として報告するメカニズムを備えています。詳細は、モニタリング、フィードバック、イベントエラーの報告をご覧ください。ただし、誤検出の報告をしても、適応型保護によるアラートの対象がすぐに変更されない場合があります。時間が経過すれば、適応型保護モデルはこうしたトラフィック パターンが正常で許容可能であることを学習し、このようなパターンのアラートを停止します。

セキュリティ ポリシーにおいて、適応型保護アラートがバックエンド サービスのサブセットで頻繁に発生している場合は、こうしたバックエンド サービスの通常のトラフィックに、適応型保護によって常に異常な動作として識別されるような大きな変動があることを示している場合があります。適応型保護を有効にせずに、別のセキュリティ ポリシーを作成し、これらのバックエンド サービスを新しいセキュリティ ポリシーに関連付けることができます。

適応型保護によって報告された特定のインシデントが誤検出であると考えられる、または関連性がない

適応型保護は、誤検出アラートを報告するメカニズムを備えています。モニタリング、フィードバック、イベントエラーの報告で説明されている手順を行ってください。ただし、誤検出の報告をしても、適応型保護によるアラートの対象がすぐに変更されない場合があります。時間が経過すれば、適応型保護モデルはこうしたトラフィック パターンが正常で許容可能であることを学習し、このようなパターンのアラートを停止します。

エッジ セキュリティ ポリシーの適用状況を確認する方法

エッジ セキュリティ ポリシーに対して行われた操作を確認するには、モニタリング ダッシュボード、モニタリング指標、リクエストごとのロギングを使用します。

モニタリング ダッシュボード

Cloud Monitoring は、[Monitoring] の [ネットワーク セキュリティ ポリシー] ページで確認できます。このページにあるセキュリティ ポリシー別の内訳を使用すると、構成済みのエッジ セキュリティ ポリシーで許可または拒否されたリクエストの数を測定できます。また、バックエンド サービスの内訳を調べて、特定のバックエンド サービスをデバッグすることもできます。Cloud Monitoring ダッシュボードの詳細については、Google Cloud Armor セキュリティ ポリシーのモニタリングをご覧ください。

モニタリング指標

エッジ セキュリティ ポリシーでは、許可または拒否されたリクエストを測定する未加工の指標が利用できます。詳細については、セキュリティ ポリシーのモニタリング指標をご覧ください。

リクエストごとのロギング

Edge セキュリティ ポリシーの結果は、enforcedEdgeSecurityPolicy の負荷分散リクエストログに記録されます。これは、バックエンドのセキュリティ ポリシーの結果をキャプチャする enforcedSecurityPolicy とは別のものです。

bot 管理

このセクションでは、bot 管理に関する問題のトラブルシューティングについて説明します。

ユーザーが想定どおりに除外されていない

reCAPTCHA 評価用にリダイレクト アクションを含むセキュリティ ポリシー ルールを構成して、正規ユーザーと考えられるユーザーの一部が想定どおりに除外されていないことが判明したとします。以下の手順でトラブルシューティングを行います。

まず、リクエストごとのログを調べて、トラフィックに一致するセキュリティ ポリシー ルールの優先度が高く、アクションが異なるかどうかを確認します。特に、configured_action フィールドと outcome フィールドを確認します。ユーザーを除外するには、少なくとも 2 つのリクエストが必要です。最初のリクエストは除外 Cookie なしで送信されます。以降のリクエストは、ユーザーが reCAPTCHA 評価に合格すると、除外 Cookie 付きで送信されます。そのため、少なくとも 2 つのログエントリが存在するはずです。

  • 構成されたアクションが GOOGLE_RECAPTCHA、結果が REDIRECT の場合、そのリクエストは reCAPTCHA 評価にリダイレクトされたものです。
  • 構成されたアクションが GOOGLE_RECAPTCHA、結果が ACCEPT の場合、そのリクエストは reCAPTCHA 評価へのリダイレクトから除外されたものです。
  • 上記のフィールドに異なる値がある場合は、異なるアクションを持つルールが一致しています。この場合、ユーザーはリダイレクトも除外もされません。

次に、ユーザー側にも、reCAPTCHA 評価へのリダイレクトから除外される要件がいくつかあります。

  1. ユーザーがブラウザを使用している必要があります。
  2. ブラウザは JavaScript を有効にして、reCAPTCHA JavaScript が埋め込まれたリダイレクト ページを正しく読み込めるようにする必要があります。
  3. ブラウザで、除外 Cookie の設定と自動添付を許可するように Cookie を有効にする必要があります。
  4. ユーザーは reCAPTCHA 評価に合格する必要があります。たとえば、ポップアップの確認が現れた場合は、それに回答する必要があります。

reCAPTCHA 評価のリダイレクト アクションを含むルールが一致しても、上記のすべての要件を満たしていないユーザーは除外されません。

さらに、reCAPTCHA 評価は、reCAPTCHA JavaScript を埋め込んだリダイレクト ページがレンダリングされた場合にのみ実行されます。そのため、reCAPTCHA 評価へのリダイレクトは、レスポンスがページ全体に表示されることを期待するリクエストにのみ適用されます。ページ内にロードされるアセットや、レスポンスのレンダリングを想定していない埋め込みスクリプトから発生したリクエストなどは reCAPTCHA 評価を受けるとは限りません。そのため、この条件を満たす URL パスに、一致条件付きのこのアクションを適用することをおすすめします。

たとえば、画像、その他のウェブページへのリンク、スクリプトなどの埋め込み要素を含むウェブページがあるとします。reCAPTCHA 評価で、画像をホストする URL パスや、ページ全体の表示が想定されていないスクリプトがアクセスされる URL パスには、リダイレクト アクションを適用しないでください。代わりに、メイン ウェブページや他のリンク済みウェブページなどのウェブページをホストする URL パスに対して、reCAPTCHA 評価のリダイレクト アクションを適用できます。

最後に、リダイレクト ページが正常にレンダリングされた場合は、ブラウザが提供するデベロッパー ツールで、除外 Cookie が設定されているかどうかを確認し、その Cookie が同じサイトの後続のリクエストに添付されているかどうか確認します。サポートが必要な場合は、Cloud サポートチームにお問い合わせください。

レート制限に関する問題

トラフィックが適切に制限されない

クライアント IP アドレスが、設定したしきい値を超えるレートでアプリケーションに大量のトラフィックを送信していても、予期したとおり制限されない場合があります。次の手順に沿って問題を調査してください。

まず、優先度の高いルールにより、その IP アドレスからのトラフィックが許可されているかどうかを確認します。ログを調べて、IP アドレスに対して ALLOW ルールがトリガーされたかどうかを確認します。これは、ALLOW ルール単体でも、他の THROTTLE ルールや RATE_BASED_BAN ルールの中でも可能です。

優先度の高いルールが見つかった場合は、次のいずれかを行います。

  1. 優先度を変更し、優先度に小さい数値を割り当てて、レート制限ルールに高い優先順位が設定されるようにします。
  2. 優先度の高いルールに一致する式から IP アドレスを除外します。

しきい値が正しく設定されていない可能性もあります。その場合、リクエストは正確に照合されますが、確認アクションがトリガーされます。ログを調べてこれに該当していることを確認したら、ルールのしきい値を下げます。

さらに、IP アドレスがスロットルまたはレートベースの禁止ルールと一致しない場合があります。この問題を解決するには、一致条件に誤りがないことを確認してから、ルールの一致条件を正しい値に変更します。

次のステップ