セキュリティ ポリシーの概要

このページでは、Google Cloud Armor セキュリティ ポリシーを使用して Google Cloud のデプロイを保護する方法について説明します。

Google Cloud Armor セキュリティ ポリシーは、一般的なウェブ攻撃やトラフィックを妨げる可能性のある他のレイヤ 7 属性のリクエストをレイヤ 7 フィルタリングやスクラブによりブロックし、負荷分散されたバックエンド サービスまたはバックエンド バケットに到達させないようにすることで、アプリケーションを保護します。各セキュリティ ポリシーは、受信リクエストの IP アドレス、IP 範囲、リージョン コード、リクエスト ヘッダーなどの条件に基づいてトラフィックをフィルタリングする一連のルールで構成されています。

Google Cloud Armor のセキュリティ ポリシーは、次のロードバランサとエンドポイント タイプで使用できます。

• グローバル外部アプリケーション ロードバランサ（HTTP/HTTPS）
• 従来のアプリケーション ロードバランサ（HTTP/HTTPS）
• リージョン外部アプリケーション ロードバランサ（HTTP/HTTPS）
• グローバル外部プロキシ ネットワーク ロードバランサ（TCP/SSL）
• 従来のプロキシ ネットワーク ロードバランサ（TCP/SSL）
• 外部パススルー ネットワーク ロードバランサ（TCP / UDP）
• プロトコル転送
• パブリック IP アドレスを持つ VM

ロードバランサは、プレミアム ティアまたはスタンダード ティアのいずれでも可能です。

バックエンド サービスのバックエンドは次のいずれかになります。

• インスタンス グループ
• ゾーン ネットワーク エンドポイント グループ（NEG）
• サーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Functions サービス
• 外部バックエンドのインターネット NEG
• Cloud Storage のバケット

Google Cloud Armor を使用してハイブリッド デプロイまたはマルチクラウド アーキテクチャを保護する場合は、バックエンドはインターネット NEG にする必要があります。また、ロードバランサを介してトラフィックがルーティングされる場合は、サーバーレス NEG も保護されます。ロードバランサを介してルーティングされたトラフィックのみがサーバーレス NEG に到達することを確認するには、上り（内向き）制御をご覧ください。

Google Cloud Armor は、外部パススルー ネットワーク ロードバランサ、プロトコル転送、パブリック IP アドレスを持つ VM に対して、高度なネットワーク DDoS 保護も提供します。高度な DDoS 対策の詳細については、高度なネットワーク DDoS 対策の構成をご覧ください。

Google Cloud Armor セキュリティ ポリシーで Google Cloud デプロイメントを保護する

外部ロード バランシングは、Google の世界中の接続拠点（PoP）で Google ネットワークのエッジに実装されています。プレミアム ティアでは、外部ロードバランサを送信先とするユーザー トラフィックは、ユーザーに最も近い PoP に入ります。その後、Google のグローバル ネットワークでロードバランスされて、十分な容量がある最も近いバックエンドに送られます。スタンダード ティアでは、ユーザー トラフィックは、Google Cloud リソースをデプロイしたリージョンのピアリング、ISP、またはトランジット ネットワークを介して Google のネットワークに転送されます。

Google Cloud Armor のセキュリティ ポリシーを使用すると、受信トラフィックの送信元にできるだけ近い場所で、Google Cloud エッジにあるバックエンド サービスへのリクエストを許可、拒否、レート制限、またはリダイレクトできます。これにより、望ましくないトラフィックによるリソースの消費や Virtual Private Cloud（VPC）ネットワークへ侵入を防止します。

次の図は、グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、Google ネットワーク、Google データセンターの場所を示しています。

ネットワーク エッジでの Google Cloud Armor ポリシー（クリックして拡大）

要件

Google Cloud Armor セキュリティ ポリシーを使用するための要件は次のとおりです。

• ロードバランサは、グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、グローバル外部プロキシ ネットワーク ロードバランサ、または従来のプロキシ ネットワーク ロードバランサでなければなりません。
• バックエンド サービスのロード バランシング スキームは EXTERNAL または EXTERNAL_MANAGED である必要があります。
• バックエンド サービスのプロトコルは、HTTP、HTTPS、HTTP/2、UDP、TCP、SSL、UNSPECIFIED のいずれかにする必要があります。

Google Cloud Armor のセキュリティ ポリシーについて

Google Cloud Armor セキュリティ ポリシーは、外部公開しているアプリケーションとサービスを保護するために、レイヤ 3 からレイヤ 7 の属性と照合するルールのセットです。各ルールは受信トラフィックについて評価されます。

Google Cloud Armor セキュリティ ポリシーのルールは、一致条件とその条件が満たされたときに実行するアクションで構成されています。条件は、受信トラフィックの送信元 IP アドレスが特定の IP アドレスまたは CIDR 範囲（IP アドレス許可リストおよび拒否リストルールとも呼ばれる）と一致するかどうかなどの簡単なものでかまいません。または、Google Cloud Armor カスタムルール言語リファレンスを使用して、受信トラフィックのさまざまな属性（URL パス、リクエスト メソッド、リクエスト ヘッダー値）に一致するカスタム条件を作成できます。

受信リクエストがセキュリティ ポリシー ルールの条件と一致する場合、Google Cloud Armor は、そのルールが許可ルール、拒否ルール、またはリダイレクト ルールかどうかに基づいて、リクエストを許可、拒否、またはリダイレクトします。リクエスト ヘッダーの挿入など、追加のアクション パラメータを適用することもできます。この機能は Google Cloud Armor の bot 管理に含まれています。bot 管理の詳細については、bot 管理の概要をご覧ください。

Google Cloud Armor セキュリティ ポリシーを 1 つ以上のバックエンド サービスに関連付けることができます。1 つのバックエンド サービスに関連付けられるセキュリティ ポリシーは 1 つだけですが、すべてのバックエンド サービスを同じセキュリティ ポリシーに関連付ける必要はありません。

バックエンド サービスに関連付けられている Google Cloud Armor セキュリティ ポリシーは削除できません。バックエンド サービスは、セキュリティ ポリシーが関連付けられているかどうかにかかわらず削除できます。

複数の転送ルールが、セキュリティ ポリシーが関連付けられているバックエンド サービスを指している場合、これらの転送ルールの各 IP アドレスに送信されるすべてのトラフィックに対してポリシールールが適用されます。

次の図では、Google Cloud Armor セキュリティ ポリシー internal-users-policy がバックエンド サービス test-network に関連付けられています。

ネットワーク エッジでの Google Cloud Armor のセキュリティ ポリシー（クリックして拡大）

Google Cloud Armor セキュリティ ポリシーには、次の機能が含まれています。

• 必要に応じて、Google Cloud Armor を使用するロードバランサで QUIC プロトコルを使用できます。

• Google Cloud Armor は、次のいずれかのネットワーク サービス ティアにあるロードバランサで使用できます。

  • プレミアム ティア
  • スタンダード ティア

• GKE とデフォルトの Ingress コントローラでバックエンド セキュリティ ポリシーを使用できます。

• 次のいずれかのロードバランサを構成するときに、ユーザー指定のしきい値でトラフィックを抑制するデフォルトのセキュリティ ポリシーを使用できます。

  • グローバル外部アプリケーション ロードバランサ
  • 従来のアプリケーション ロードバランサ
  • リージョン外部アプリケーション ロードバランサ
  • グローバル外部プロキシ ネットワーク ロードバランサ
  • 従来のプロキシ ネットワーク ロードバランサ
  • 外部パススルー ネットワーク ロードバランサ

さらに、Google Cloud Armor の事前構成 WAF ルールを構成できます。これは、オープンソースの業界標準から集められた多数のシグネチャを持つ複雑なウェブ アプリケーション ファイアウォール（WAF）ルールです。各シグネチャは、ルールセット内の攻撃検出ルールに対応しています。Google はこれらのルールをそのまま提供します。このルールにより、Google Cloud Armor では、各シグネチャを手動で定義する必要がなく、便利に命名されたルールを参照することで、数十の異なるトラフィック シグネチャを評価できます。事前構成 WAF ルールの詳細については、事前構成 WAF ルールの概要をご覧ください。

セキュリティ ポリシーの種類

次の表に、セキュリティ ポリシーの種類とそのポリシーでできることを示します。チェックマーク（）は、そのタイプのセキュリティ ポリシーで機能がサポートされることを示します。

グローバル スコープのセキュリティ ポリシー

	バックエンド セキュリティ ポリシー		Edge のセキュリティ ポリシー
フロントエンド タイプ	グローバル外部アプリケーション ロードバランサ 従来のアプリケーション ロードバランサ	グローバル外部プロキシ ネットワーク ロードバランサ 従来のプロキシ ネットワーク ロードバランサ	グローバル外部アプリケーション ロードバランサ 従来のアプリケーション ロードバランサ
アタッチメント ポイント（保護されたリソース）	バックエンド サービス	バックエンド サービス	バックエンド サービス バックエンド バケット
ルールの操作	許可 拒否 リダイレクト（GOOGLE_RECAPTCHA、EXTERNAL_302） スロットル レートベースの禁止	許可 拒否 スロットル レートベースの禁止	許可 拒否
送信元 IP アドレス
ソースの地理的情報
送信元の ASN
レート制限
JA3 フィンガープリント
bot 管理
レイヤ 7 フィルタリング
WAF
適応型保護
脅威インテリジェンス
Security Command Center
Cloud Monitoring
リクエストのロギング

リージョン スコープのセキュリティ ポリシー

	リージョン バックエンド セキュリティ ポリシー	ネットワーク エッジのセキュリティ ポリシー
フロントエンド タイプ	リージョン外部アプリケーション ロードバランサ	外部パススルー ネットワーク ロードバランサ プロトコル転送 パブリック IP アドレスを持つ VM
アタッチメント ポイント（保護されたリソース）	バックエンド サービス（リージョン）	ターゲット プール ターゲット インスタンス バックエンド サービス（リージョン） インスタンス
ルール アクション	許可 拒否 スロットル レートベースの禁止	許可 拒否
送信元 IP アドレス
ソースの地理的情報
送信元の ASN
レート制限
JA3 フィンガープリント
bot 管理
レイヤ 7 フィルタリング
WAF
適応型保護
脅威インテリジェンス
バイト オフセット フィルタリング
Security Command Center
Cloud Monitoring
リクエストのロギング

バックエンド セキュリティ ポリシー

バックエンド セキュリティ ポリシーは、次のロードバランサ タイプによって公開されるバックエンド サービスで使用されます。

• グローバル外部アプリケーション ロードバランサ
• 従来のアプリケーション ロードバランサ
• リージョン外部アプリケーション ロードバランサ
• グローバル外部プロキシ ネットワーク ロードバランサ
• 従来のプロキシ ネットワーク ロードバランサ

これらを使用してリクエストをフィルタし、インスタンス グループや、インターネット、ゾーン、ハイブリッド、サーバーレス NEG などのネットワーク エンドポイント グループ（NEG）を参照するバックエンド サービスを保護できます。すべてのロードバランサがすべてのタイプの NEG をサポートしているわけではありません。ロードバランサがサポートする NEG の詳細については、ネットワーク エンドポイント グループの概要をご覧ください。

グローバル外部プロキシ ネットワーク ロードバランサまたは従来のプロキシ ネットワーク ロードバランサを使用する場合、Google Cloud Armor は新しい接続リクエストに対してのみセキュリティ ポリシー ルール deny アクションを適用します。deny アクションは TCP 接続を終端します。また、deny アクションでステータス コードを指定した場合、ステータス コードは無視されます。

バックエンド セキュリティ ポリシーには、オプションの type フラグの値 CLOUD_ARMOR があります。type フラグを設定しない場合、デフォルト値は CLOUD_ARMOR です。

エッジ セキュリティ ポリシー

エッジ セキュリティ ポリシーを使用すると、キャッシュに保存されているコンテンツに対するフィルタリング ポリシーやアクセス制御ポリシーを構成できます。これには、Cloud CDN 対応のバックエンド サービスや Cloud Storage バケットなどのエンドポイントが含まれます。エッジ セキュリティ ポリシーでは、バックエンド セキュリティ ポリシーと比較した、パラメータのサブセットに基づくフィルタリングがサポートされています。エッジ セキュリティ ポリシーをバックエンド ポリシーとして設定することはできません。エッジ セキュリティ ポリシーは、次のエンドポイントでサポートされています。

• グローバル外部アプリケーション ロードバランサ
• 従来のアプリケーション ロードバランサ

エッジ セキュリティ ポリシーは、Google のキャッシュからリクエストが提供される前にフィルタするように構成できます。エッジ セキュリティ ポリシーは、Cloud CDN のキャッシュが存在するアップストリームの Google ネットワークの最も外側の境界の近くにデプロイされ、適用されます。エッジ セキュリティ ポリシーとバックエンド セキュリティ ポリシーを併用すると、2 つの保護レイヤを提供できます。これらは、バックエンド サービスがポイントするリソース（インスタンス グループやネットワーク エンドポイント グループなど）に関係なく、バックエンド サービスに同時に適用できます。バックエンド バケットには、エッジ セキュリティ ポリシーのみを適用できます。

エッジ セキュリティ ポリシーとバックエンド セキュリティ ポリシーが同じバックエンド サービスに接続されている場合、バックエンド セキュリティ ポリシーは、エッジ セキュリティ ポリシーを通過したキャッシュミス リクエストに対してのみ適用されます。

エッジ セキュリティ ポリシーは、Identity-Aware Proxy（IAP）の前に評価され、適用されます。エッジ セキュリティ ポリシーでブロックされたリクエストは、IAP がリクエスト送信者の ID を評価する前に拒否されます。エッジ セキュリティ ポリシーのルールでリクエストをブロックすると、IAP はログインページの提供やユーザー認証を行えなくなります。

Edge のセキュリティ ポリシーでは、type フラグの値が CLOUD_ARMOR_EDGE になっています。

ネットワーク エッジ セキュリティ ポリシー

ネットワーク エッジのセキュリティ ポリシーを使用すると、Google のネットワークのエッジでトラフィックをブロックするルールを構成できます。ネットワーク エッジのセキュリティ ポリシーを適用することで、VM やホストのリソースは消費されません。これにより、大量のトラフィックがターゲット ワークロードのリソースを使い果たしたり、サービス拒否を引き起こすのを防ぐことができます。ネットワーク エッジのセキュリティ ポリシーは、次のリソースに構成できます。

• 外部パススルー ネットワーク ロードバランサ
• プロトコル転送
• パブリック IP アドレスを持つ VM

ネットワーク エッジのセキュリティ ポリシーは、バックエンド セキュリティ ポリシーと同じパラメータの一部に基づくフィルタリングをサポートしており、バイト オフセット フィルタリングをサポートする唯一のセキュリティ ポリシー タイプです。使用可能なすべてのパラメータのリストについては、セキュリティ ポリシーの種類の表をご覧ください。

ネットワーク エッジのセキュリティ ポリシーでは、type フラグの値が CLOUD_ARMOR_NETWORK になっています。ネットワーク エッジのセキュリティ ポリシーを構成するには、まず、ポリシーを作成するリージョンで高度なネットワーク DDoS 対策を構成します。高度な DDoS 対策の詳細については、高度なネットワーク DDoS 対策の構成をご覧ください。

ルールの評価順序

ルールの評価順序は、ルールの優先度（数値）を小さい数値から順に選択されます。数値が最も小さいルールが、最も高い論理優先度を持ち、それより低い論理優先度を持つルールよりも先に評価されます。優先度の最小の数字は 0 です。ルールの優先度は、その数が増えると低下します（1、2、3、N+1）。同じ優先度で複数のルールを構成することはできません。各ルールの優先度は 0～2,147,483,646 の数値に設定する必要があります。優先度値 2,147,483,647（INT-MAX）は、デフォルトのルール用に予約されています。

優先度の番号には抜けがあってもかまいません。したがって、ルールを追加または削除しても、残りのルールには影響しません。たとえば、1、2、3、4、5、9、12、16 は有効な一連の優先度番号であり、6～8、10～11、13～15 の番号が付いたルールを将来追加できます。実行順序を変更する場合を除き、既存のルールを変更する必要はありません。

通常は、リクエストに一致する最も高い優先度ルールが適用されます。ただし、evaluatePreconfiguredExpr() を使用する事前構成ルールに対して HTTP POST リクエストを評価する場合は、例外があります。例外は次のとおりです。

HTTP POST リクエストの場合、Google Cloud Armor は本文（ペイロード）の前にリクエストのヘッダーを受信します。Google Cloud Armor は最初にヘッダー情報を受信するため、ヘッダーと一致するルールを評価しますが、本文に事前構成済みのルールとは一致しません。ヘッダーベースのルールが複数ある場合、Google Cloud Armor は想定の通りに、優先度に基づいてそれらを評価します。redirect アクションとカスタム ヘッダー アクションの挿入は、ヘッダー処理フェーズでのみ機能します。redirect アクションが次の本文処理フェーズで一致すると、deny アクションに変換されます。カスタム リクエスト ヘッダー アクションが本文の処理フェーズで一致した場合は有効になりません。

Google Cloud Armor は、HTTP POST の本文を受け取ると、リクエスト ヘッダーと本文の両方に適用されるルールを評価します。このため、リクエストの本文をブロックする優先度の高いルールよりも前に、リクエストのヘッダーを許可する優先度の低いルールが一致する可能性があります。この場合、リクエストの HTTP ヘッダー部分がターゲット バックエンド サービスに送信される可能性がありますが、悪意のあるコンテンツを含む可能性がある POST 本文はブロックされます。 Google Cloud Armor は POST 本文の最初の 8 KB を検査します。この制限の詳細については、POST 本文検査の制限をご覧ください。

事前構成されたルールの evaluatePreconfiguredExpr() 式は、リクエスト本文に対して評価される唯一の式です。他のすべての式は、リクエスト ヘッダーに対してのみ評価されます。Google Cloud Armor は、リクエスト本文を含む HTTP リクエスト タイプのうち POST リクエストのみを処理します。検査は POST 本文の最初の 8 KB に制限され、URL クエリ パラメータのようにデコードされます。Google Cloud Armor は、JSON 形式の POST 本文（Content-Type = "application/json"）用に事前構成された WAF ルールを解析し、適用できます。ただし、Google Cloud Armor は、XML、Gzip、UTF-16 などの他の HTTP Content-Type/Content-Encoding ベースのデコーダをサポートしていません。

例

次の例では、ルール 1、2、3 が IP ヘッダー フィールドと HTTP ヘッダー フィールドでこの順序で評価されます。ただし、IP 9.9.9.1 が HTTP POST 本文で XSS 攻撃を開始した場合、本文のみがブロックされます（ルール 2）。HTTP ヘッダーは（ルール 3 によって）バックエンドに渡されます。

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

次の例では、ポリシーにより XSS 攻撃はスキャンされずに IP 9.9.9.1 が許可されます。

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

デフォルトのルール

各 Google Cloud Armor セキュリティ ポリシーにはデフォルトのルールがあり、デフォルトのルールよりも優先度の高いルールが一致しない場合、またはポリシー内に他のルールがない場合には、デフォルトのルールが適用されます。デフォルト ルールには自動的に優先順位 2,147,483,647（INT-MAX）が割り当てられ、セキュリティ ポリシーに常に存在します。

デフォルト ルールは削除できませんが、変更は可能です。デフォルト ルールのデフォルト アクションは deny ですが、これを allow に変更できます。

フィンガープリント

各 Google Cloud Armor セキュリティ ポリシーには、fingerprint フィールドがあります。フィンガープリントは、ポリシーに保存されているコンテンツのハッシュです。新しいポリシーを作成する場合は、このフィールドに値を指定しないでください。値を指定すると、その値は無視されます。ただし、セキュリティ ポリシーを更新する場合は、ポリシーをエクスポートまたは記述するときに取得される現在のフィンガープリントを指定する必要があります（それぞれ EXPORT または DESCRIBE を使用します）。

フィンガープリントは、別のユーザーの更新をオーバーライドしないように保護します。指定したフィンガープリントが無効になっている場合は、最後にフィンガープリントを取得してからセキュリティ ポリシーが更新されたことを意味します。違いを確認して最新のフィンガープリントを取得するには、DESCRIBE コマンドを実行します。

ルール言語と実行エンジン

ルール言語と実行エンジンには次のような機能があります。

• 受信リクエストのレイヤ 3 からレイヤ 7 のさまざまな属性で一致するカスタムルール式を記述する機能。Google Cloud Armor では、カスタム一致条件を記述するための柔軟な言語を提供しています。

• 1 つのルールで最大 5 つのサブ式を組み合わせる機能。

• 受信リクエストのリージョン コードに基づいてリクエストを拒否または許可する機能。リージョン コードは、ISO 3166-1 alpha 2 コードに基づいています。リージョン コードは特定の国に対応している場合もありますが、国とその関連地域が含まれる場合もあります。たとえば、US コードには米国のすべての州、1 つの特別区、6 つの海外領土が含まれます。

ルールの種類

Google Cloud Armor には、次の種類のルールがあります。

注: エッジ セキュリティ ポリシーでは、送信元 IP アドレスと地理的属性（origin.ip や origin.region_code）に基づくフィルタリングのみがサポートされます。

IP アドレスの許可リストと拒否リストのルール

セキュリティ ポリシー内で IP アドレスの許可リストと拒否リストのルールを作成できます。以下はその一例です。

• IP アドレス / CIDR を拒否リストに登録すると、送信元 IP アドレスまたは CIDR 範囲が、サポートされているロードバランサにアクセスすることをブロックできます。

• IP アドレス / CIDR を許可リストに登録すると、送信元 IP アドレスまたは CIDR 範囲が、サポートされているロードバランサにアクセスできるようになります。

• 許可リスト / 拒否リストルールでは IPv4 アドレスと IPv6 アドレスがサポートされています。

• 拒否ルールは、HTTP 403（未承認）、404（アクセス拒否）、502（不正なゲートウェイ）のレスポンスを返すことができます。

• アクション ルールを超えると、HTTP 429（リクエストが多すぎる）が返される可能性があります。

送信元の地域ルール

Unicode の国コードで定義されている特定の地理的地域から発信されたリクエストを許可または拒否できます。

Google Cloud Armor は、独自の IP 位置情報データベースを使用してリクエストの地理的位置を識別します。データベースは定期的に更新されます。特定の更新頻度を保証することはできませんが、通常のオペレーションでは、Google Cloud Armor が使用するマッピングは約 1 週間に 1 回更新されます。

更新されたマッピングは、Google のインフラストラクチャにグローバルに伝播する必要があります。ロールアウト プロセスは、Google Cloud Armor がデプロイされている複数のゾーンとリージョンに、通常は数日間かけて段階的に行われます。この段階的なロールアウト プロセスにより、位置情報マッピングの送信元 IP アドレスが変更された場合、ロールアウト中に同じ送信元 IP アドレスからのリクエストが一貫して処理されない可能性があります。

事前構成 WAF ルール

Google Cloud Armor では、OWASP ModSecurity Core Rule Set（CRS）に基づく事前構成の WAF ルールの包括的なリストが用意されています。これは、次のものを検出する場合に役立ちます。

• SQL インジェクション攻撃
• クロスサイト スクリプティング攻撃
• ローカル ファイル インクルージョン攻撃
• リモート ファイル インクルージョン攻撃
• リモートコード実行攻撃
• メソッド適用攻撃
• スキャナ検出攻撃
• プロトコル攻撃
• PHP インジェクション攻撃
• セッション修正攻撃
• Java 攻撃
• NodeJS 攻撃

詳細については、Google Cloud Armor の事前構成 WAF ルールの概要をご覧ください。

bot 管理ルール

bot 管理ルールを使用すると、次のことができます。

1. オプションの手動確認を行い、reCAPTCHA Enterprise の評価にリクエストをリダイレクトする。
2. リクエストに添付された reCAPTCHA Enterprise トークンを評価し、トークン属性に基づいて構成されたアクションを適用する。
3. 302 レスポンスを使用して構成済みの代替 URL にリクエストをリダイレクトする。
4. カスタム ヘッダーをリクエストに挿入した後、バックエンドにプロキシ転送する。

bot 管理の詳細については、bot 管理の概要をご覧ください。

名前付き IP アドレスリストに対する事前構成済みルール

名前付き IP アドレスリストに対する事前構成済みルールは、以下を行います。

• サードパーティ プロバイダの名前付き IP アドレスリストを Google Cloud Armor と統合します。

• 許可または拒否される IP アドレス範囲のメンテナンスを簡素化します。

• サードパーティ プロバイダのリストを毎日同期します。

• 名前付き IP アドレスリストにはルールごとの IP アドレス数の制限が適用されないため、セキュリティ ポリシーで IP アドレスと範囲を構成する容量を増やします。

レート制限ルール

レート制限ルールを使用すると、次のことが可能になります。

• 構成したしきい値に基づいて、クライアントあたりのリクエスト数を調整する
• 構成した期間のリクエストしきい値を超えるクライアントを一時的に禁止する

グローバル外部プロキシ ネットワーク ロードバランサまたは従来のプロキシ ネットワーク ロードバランサでレート制限を使用する場合には、次の制限が適用されます。

• Google Cloud Armor は、クライアントからの新しい接続リクエストのスロットリングや禁止などのレート制限アクションのみを適用します。
• キータイプ ALL と IP のみがサポートされています。
• TCP / SSL ロードバランサでキータイプ HTTP-HEADER または HTTP-COOKIE を使用すると、キータイプは ALL として解釈され、XFF-IP は同様に IP として解釈されます。

レート制限とその仕組みの詳細については、レート制限の概要をご覧ください。

プレビュー モード

ルールを適用しなくても、その影響をプレビューできます。プレビュー モードでは、Cloud Monitoring にアクションが記録されます。セキュリティ ポリシー内の個々のルールをプレビューすることも、ポリシー内のすべてのルールをプレビューすることもできます。 プレビュー モードでは、ルールに通常のリクエストごとの料金が請求されます。

ルールのプレビュー モードを有効にするには、Google Cloud CLI と gcloud compute security-policies rules update の --preview フラグを使用します。

プレビュー モードを無効にするには、現在は文書化されていない --no-preview フラグを使用します。Google Cloud コンソールを使用することもできます。

リクエストによってプレビューがトリガーされた場合、一致が見つかるまで Google Cloud Armor は他のルールを評価し続けます。一致したルールとプレビュー ルールの両方がログに記録されます。

カスタム エラー レスポンス

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

グローバル外部アプリケーション ロードバランサを使用する場合は、ロードバランサまたはバックエンド インスタンスによって生成されるエラーの HTTP ステータス コードのカスタムエラー レスポンスを構成できます。さらに、既存のセキュリティ ポリシー ルールで使用されているのと同じ 4xx シリーズまたは 5xx シリーズのエラーコードに対するカスタム レスポンス ページを構成することで、Google Cloud Armor が拒否するトラフィックのカスタム エラーコードを構成できます。

カスタムエラー レスポンスの詳細については、カスタムエラー レスポンスの概要をご覧ください。構成手順については、カスタム エラー レスポンスを構成するをご覧ください。

ロギング

Google Cloud Armor には広範なロギング機能があり、ロギングの重大度を定義できます。ロギングの詳細については、リクエスト ロギングを使用するをご覧ください。

Google Cloud Armor ログを表示するには、ログの表示をご覧ください。

外部アプリケーション ロードバランサ リクエストのロギング

Google Cloud Armor セキュリティ ポリシーに対して評価された各 HTTP(S) リクエストは、Cloud Logging によってログに記録されます。ログには、適用されたセキュリティ ポリシーの名前、一致するルール、ルールが適用されたかどうかなどの詳細が記録されます。デフォルトでは、新しいバックエンド サービス リソースのリクエスト ロギングは無効になっています。Google Cloud Armor リクエストが確実にログに記録されるようにするには、セキュリティ ポリシーで保護されているバックエンド サービスごとに HTTP(S) ロギングを有効にする必要があります。

詳細については、外部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

外部プロキシ ネットワーク ロードバランサのリクエストのロギング

TCP / SSL プロキシ ロード バランシングのロギングとモニタリングに記載されている Google Cloud CLI コマンドを使用して、外部プロキシ ネットワーク ロードバランサのロギングを構成できます。Google Cloud コンソールを使用して外部プロキシ ネットワーク ロードバランサのロギングを有効にすることはできません。

詳細ログを使用する場合

事前構成済みの WAF ルールが特定のリクエストによってトリガーされた理由を判断できない場合があります。Google Cloud Armor のデフォルトのイベントログには、トリガーされたルールとサブシグネチャが含まれます。ただし、トラブルシューティング、ルールの検証、またはルールの調整を目的として、ルールをトリガーした受信リクエストの詳細情報が必要になることがあります。

ログに記録される詳細レベルを調整できます。最初にポリシーを作成するとき、ポリシーを変更するとき、またはポリシーのトラブルシューティングを行うときにのみ、詳細ロギングを有効にすることをおすすめします。詳細ログを有効にすると、プレビュー モードのルールと、標準オペレーション中のアクティブな（プレビューされていない）ルールが有効になります。

詳細ログの詳細については、詳細ログをご覧ください。

POST 本文コンテンツの解析

デフォルトでは、Google Cloud Armor は事前構成の WAF ルールのシグネチャに対して、POST 本文の内容全体を均一な文字列（本文のサイズ制限の対象）として評価します。JSON などの代替エンコードを含むリクエストの場合、メッセージの構造コンポーネント（ユーザー指定ではない）が、事前構成された WAF 署名との照合をトリガーする可能性があります。ノイズを避け、誤検出のリスクを軽減するために、保護されたワークロードが以下を行うときは、サポートされている任意の Content-Type に対して代替解析が有効になるよう Google Cloud Armor を構成することをおすすめします。

• REST API を提供する
• GraphQL を使用する
• JSON エンコード コンテンツが含まれるリクエストを受信する。

事前構成 WAF ルールの詳細については、カスタム Content-Type ヘッダー値に JSON 解析を適用するをご覧ください。

Google Cloud Armor セキュリティ ポリシーに対して評価された各 HTTP(S) リクエストは、Cloud Logging によってログに記録されます。ログには、適用されたセキュリティ ポリシーの名前、一致するルール、ルールが適用されたかどうかなどの詳細が記録されます。デフォルトでは、新しいバックエンド サービス リソースのリクエスト ロギングは無効になっています。Google Cloud Armor リクエストが確実にログに記録されるようにするには、セキュリティ ポリシーで保護されているバックエンド サービスごとに HTTP(S) ロギングを有効にする必要があります。

詳細については、グローバル外部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

制限事項

以降のセクションでは、セキュリティ ポリシーの制限について詳しく説明します。

POST 本文検査の制限

事前構成されたルールの evaluatePreconfiguredExpr() 式は、Google Cloud Armor がリクエスト本文に対して評価する唯一の式です。Google Cloud Armor は、リクエスト本文を含む HTTP リクエスト タイプのうち POST リクエストのみを処理します。

検査は POST 本文の最初の 8 KB に制限され、URL クエリ パラメータのようにデコードされます。POST 本文の残りの部分には、アプリケーションが受け入れる可能性のある悪意のあるコードが含まれている可能性があります。サイズが 8 KB を超える POST 本文でこのリスクを軽減するには、トラブルシューティング ガイドをご覧ください。

Google Cloud Armor は、デフォルトの URL エンコードされた JSON 形式の POST 本文（Content-Type = "application/json"）用に事前構成された WAF ルールを解析し、適用できます。この場合、ルールはデコードされた名前とデータの値に個別に適用されます。他のコンテンツ タイプとエンコード タイプの場合、Google Cloud Armor はデータをデコードしませんが、事前に構成されたルールを元のデータに適用します。

WebSocket 接続の処理方法

グローバル外部アプリケーション ロードバランサには、WebSocket プロトコルのサポートが組み込まれています。WebSocket チャネルは、HTTP(S) リクエストから開始します。Google Cloud Armor は、IP アドレス拒否リストによって発信元 IP アドレスがブロックされている場合などに、WebSocket チャネルの確立をブロックする可能性があります。ただし、チャネル内の後続のトランザクションは HTTP プロトコルに準拠せず、Google Cloud Armor は最初のリクエストの後にはメッセージを評価しません。

次のステップ

• セキュリティ ポリシー、ルール、式を構成する
• Cloud Armor Enterprise ティアの機能について学習する
• 名前付き IP アドレスリストについて学習する
• 問題のトラブルシューティングを行う