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

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

一般的な問題

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

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

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

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

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

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

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

configuredAction は、ルールで構成されたアクションと一致する必要があります。
name は、このバックエンドサービスに接続された Google 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 コマンドを使用して、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 を指定します。

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

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

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

gcloud compute security-policies rules create 1000
   --security-policy POLICY_NAME
   --expression "evaluatePreconfiguredExpr('xss-stable')"
   --action deny-403
   --preview

url や cookie などの 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'

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

ログをもう一度確認してから、プレビューモードを無効にしてルールを実装します。

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

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 アドレスからのトラフィックがブロックされている場合があります。

トラフィックが名前付き IP アドレスの許可リスト上の IP アドレスから発信されていることを確認します。
トラフィックをブロックする可能性のある他のセキュリティルールがあるかどうかを確認します。問題が解決しない場合は、Cloud サポートチームにお問い合わせください。
セキュリティポリシーが正しいバックエンドサービスに接続されていることを確認します。
```
gcloud compute backend-services describe BACKEND_SERVICE
```

セキュリティポリシーにあるルールを確認します。次に例を示します。

 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 を含むリファラーの拒否ルールです。また、それぞれの優先度も表示されます。

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

ログの例を次に示します。
```
 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 評価へのリダイレクトから除外される要件がいくつかあります。

ユーザーがブラウザを使用している必要があります。
ブラウザは JavaScript を有効にして、reCAPTCHA JavaScript が埋め込まれたリダイレクトページを正しく読み込めるようにする必要があります。
ブラウザで、除外 Cookie の設定と自動添付を許可するように Cookie を有効にする必要があります。
ユーザーは 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 ルールの中でも可能です。

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

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

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

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

次のステップ

サポートを利用する