セキュリティポリシーの概要
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

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

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

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

従来のアプリケーションロードバランサを含むすべての外部アプリケーションロードバランサ
リージョン内部アプリケーションロードバランサ
グローバル外部プロキシネットワークロードバランサ（TCP/SSL）
従来のプロキシネットワークロードバランサ（TCP/SSL）
外部パススルーネットワークロードバランサ（TCP / UDP）
外部プロトコル転送
ネットワークインターフェース（NIC）に外部 IPv4 アドレスまたは外部 IPv6 アドレス範囲が割り当てられている VM

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

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

インスタンスグループ
ロードバランサが対応しているすべてのネットワークエンドポイントグループ（NEG）タイプ
Cloud Storage のバケット

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

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

Google Cloud Armor のセキュリティポリシーによって Google Cloud デプロイを保護する

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

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

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

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

要件

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

バックエンドサービスのロードバランシングスキームは EXTERNAL、EXTERNAL_MANAGED または INTERNAL_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 のセキュリティポリシーには次のような特徴があります。

必要に応じて、Google Cloud Armor を使用するロードバランサで QUIC プロトコルを使用できます。
Google Cloud Armor は、次のいずれかのネットワークサービスティアにあるロードバランサで使用できます。
- プレミアムティア
- スタンダードティア
GKE とデフォルトの Ingress コントローラでバックエンドセキュリティポリシーを使用できます。
次のいずれかのロードバランサを構成するときに、ユーザー指定のしきい値でトラフィックを抑制するデフォルトのセキュリティポリシーを使用できます。
- グローバル外部アプリケーションロードバランサ
- 従来のアプリケーションロードバランサ
- リージョン外部アプリケーションロードバランサ
- リージョン内部アプリケーションロードバランサ
- グローバル外部プロキシネットワークロードバランサ
- 従来のプロキシネットワークロードバランサ
- 外部パススルーネットワークロードバランサ

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

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

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

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

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

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

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

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

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

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

バックエンドセキュリティポリシーを使用してリクエストをフィルタリングすることで、上記のタイプのロードバランサの背後にあるインスタンスグループや NEG（対応しているタイプ）を参照するバックエンドサービスを保護できます。ロードバランサが対応している NEG の詳細については、ネットワークエンドポイントグループの概要をご覧ください。

グローバル外部プロキシネットワークロードバランサまたは従来のプロキシネットワークロードバランサを使用する場合、セキュリティポリシールールの 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 がログインページの提供やユーザー認証を行えなくなります。

エッジセキュリティポリシーでは、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 の番号が付いたルールを将来追加できます。実行順序を変更する場合を除き、既存のルールを変更する必要はありません。

通常は、リクエストに一致する最も高い優先度ルールが適用されます。ただし、evaluatePreconfiguredWaf() を使用する事前構成ルールに対して 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 本文検査の制限をご覧ください。

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

例

次の例では、ルール 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: evaluatePreconfiguredWaf('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: evaluatePreconfiguredWaf('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 アドレスの許可リストと拒否リストのルール

セキュリティポリシー内で 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 管理ルールを使用すると、次のことを行えます。

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

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

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

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

サードパーティプロバイダの名前付き IP アドレスリストを Google Cloud Armor と統合します。
許可または拒否される IP アドレス範囲のメンテナンスを簡素化します。
サードパーティプロバイダのリストを毎日同期します。
名前付き IP アドレスリストにはルールごとの IP アドレス数の制限が適用されないため、セキュリティポリシーで IP アドレスと範囲を構成する容量を増やします。

レート制限ルール

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

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

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

スロットリングや禁止といったレート制限アクションは、クライアントからの新しい接続リクエストにのみ適用されます。
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 コンソールを使用することもできます。

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

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

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

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

ロギング

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 コンソールを使用して外部プロキシネットワークロードバランサのロギングを有効にすることはできません。

制限事項

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

POST および PATCH 本文の検査における制限

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

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

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

WebSocket 接続の処理方法

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

セキュリティ ポリシーの概要 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Google Cloud Armor のセキュリティ ポリシーによって Google Cloud デプロイを保護する

要件

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

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

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

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

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

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

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