このページの情報の一部またはすべては、S3NS の Trusted Cloud には適用されない場合があります。

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

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

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

Cloud Armor のセキュリティポリシーは、リージョン外部アプリケーションロードバランサで使用できます。

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

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

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

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

プレミアムティアの場合、外部ロードバランサを宛先とするユーザートラフィックは、ユーザーに最も近い PoP に入ります。その後、Google のグローバルネットワークでロードバランシングされて、十分な容量がある最も近いバックエンドに送られます。

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

要件

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

バックエンドサービスのロードバランシングスキームは EXTERNAL_MANAGED である必要があります。
バックエンドサービスのプロトコルは、HTTP、HTTPS、HTTP/2、UDP、TCP、SSL、UNSPECIFIED のいずれかである必要があります。

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

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

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

受信リクエストがセキュリティポリシールールの条件と一致する場合、Cloud Armor は、そのルールが許可ルール、拒否ルール、またはリダイレクトルールのいずれであるかに基づいて、リクエストを許可、拒否、またはリダイレクトします。

Cloud Armor には、階層型セキュリティポリシーとサービスレベルのセキュリティポリシーの 2 つのカテゴリのセキュリティポリシーがあります。階層型セキュリティポリシーは組織、フォルダ、プロジェクトレベルで接続されますが、サービスレベルのセキュリティポリシーは 1 つ以上のバックエンドサービスに関連付けられます。階層型セキュリティポリシーの詳細については、階層型セキュリティポリシーの概要をご覧ください。

バックエンドサービスは、2 つのサービスレベルのセキュリティポリシーを同時に関連付けることができますが、2 つのバックエンドセキュリティポリシーまたは 2 つのエッジセキュリティポリシーを同時に関連付けることはできません。ただし、すべてのバックエンドサービスを同じセキュリティポリシーに関連付ける必要はありません。対応しているバックエンドサービスや機能にセキュリティポリシーを接続する方法や削除の方法については、セキュリティポリシーの接続と削除をご覧ください。

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

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

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

ネットワークエッジにある Cloud Armor セキュリティポリシー。 — ネットワークエッジにある Cloud Armor セキュリティポリシー（クリックして拡大）

Cloud Armor のセキュリティポリシーには次のような特徴があります。

必要に応じて、Cloud Armor を使用するロードバランサで QUIC プロトコルを使用できます。
GKE とデフォルトの Ingress コントローラでバックエンドセキュリティポリシーを使用できます。
リージョン外部アプリケーションロードバランサを構成するときに、ユーザー指定のしきい値を超えたトラフィックをスロットルするデフォルトのセキュリティポリシーを使用できます。

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

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

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

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

	リージョンバックエンドセキュリティポリシー
フロントエンドタイプ	リージョン外部アプリケーションロードバランサ
接続ポイント（保護されたリソース）	バックエンドサービス（リージョン）
ルールアクション	許可拒否スロットルレートベースの禁止
送信元 IP アドレス
送信元の地理的情報
送信元の ASN
レート制限
JA4 フィンガープリント
JA3 フィンガープリント
HTTP フィルタリング
WAF
Cloud Monitoring
リクエストのロギング

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

バックエンドセキュリティポリシーは、リージョン外部アプリケーションロードバランサによって公開されるバックエンドサービスで使用されます。

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

内部サービスセキュリティポリシー

内部サービスセキュリティポリシーを使用すると、Cloud Service Mesh で fairshare レート制限を構成できます。内部サービスセキュリティポリシーは、バックエンドサービスまたはバックエンドバケットに接続するのではなく、Cloud Service Mesh エンドポイントポリシーに接続します。内部サービスセキュリティポリシーの詳細については、Cloud Service Mesh ドキュメントの Cloud Armor でレート制限を構成するをご覧ください。

ルールの評価順序

ルールの評価順序は、ルールの優先度（数値）を小さい数値から順に選択されます。数値が最も小さいルールが、最も高い論理優先度を持ち、それより低い論理優先度を持つルールよりも先に評価されます。優先度の最小の数字は 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 リクエストの場合、Cloud Armor は本文（ペイロード）の前にリクエストのヘッダーを受信します。Cloud Armor は最初にヘッダー情報を受信するため、ヘッダーと照合するルールを評価しますが、本文に対する事前構成済みのルールは照合しません。ヘッダーベースのルールが複数ある場合は、想定されているとおり、優先度に基づいてルールが評価されます。redirect アクションとカスタムヘッダーアクションの挿入は、ヘッダー処理フェーズでのみ機能します。redirect アクションが次の本文処理フェーズで一致した場合は、deny アクションに変換されます。カスタムリクエストヘッダーアクションが本文処理フェーズで一致した場合、それらのアクションは実行されません。

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

事前構成されたルールの evaluatePreconfiguredWaf() 式のみがリクエスト本文に対して評価されます。他のすべての式は、リクエストヘッダーに対してのみ評価されます。リクエスト本文を含む HTTP リクエストタイプのうち、POST リクエストと PATCH リクエストのみが処理されます。検査は、構成済みの検査上限（リクエスト本文の最初の最大 64 KB（8 KB、16 KB、32 KB、48 KB、64 KB のいずれか））に制限され、URL クエリパラメータのようにデコードされます。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

次の例では、IP 9.9.9.1 は許可され、XSS 攻撃に対してスキャンされません。

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

デフォルトのルール

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

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

フィンガープリント

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

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

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

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

受信リクエストのレイヤ 3 からレイヤ 7 のさまざまな属性と照合するカスタムルール式を記述する機能。Cloud Armor には、カスタム一致条件を記述するためのカスタムルール言語属性が用意されています。
1 つのルールで最大 5 つのサブ式を組み合わせる機能。
受信リクエストのリージョンコードに基づいてリクエストを拒否または許可する機能。リージョンコードは、ISO 3166-1 alpha 2 コードに基づいています。リージョンコードは特定の国に対応している場合もありますが、国とその関連地域が含まれる場合もあります。たとえば、US コードには米国のすべての州、1 つの特別区、6 つの海外領土が含まれます。

ルールの種類

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

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

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

IP アドレスまたは CIDR 範囲を拒否リストに追加すると、送信元 IP アドレスまたは CIDR 範囲からサポート対象のロードバランサへのアクセスをブロックできます。
IP アドレスまたは CIDR 範囲を許可リストに追加すると、送信元 IP アドレスまたは CIDR 範囲からサポート対象のロードバランサにアクセスできるようになります。
許可リスト / 拒否リストのルールでは IPv4 と IPv6 のアドレスを利用できます。
拒否ルールは、HTTP 403 Unauthorized、404 Access Denied、502 Bad Gateway のステータスコードを返すことができます。
アクションルールを超過すると、HTTP 429 Too Many Requests ステータスコードが返される可能性があります。

送信元の地域ルール

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

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

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

事前構成 WAF ルール

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

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

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

レート制限ルール

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

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

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

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

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

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

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

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

ロギング

Cloud Armor には広範なロギング機能があり、ロギングの詳細度を定義できます。Cloud Armor のログは、セキュリティポリシーがプレビューモードであるかどうかにかかわらず、受信リクエストに一致した最初の（優先度が最も高い）ルールに基づいて生成されます。つまり、一致しなかったルールや優先度の低い一致ルールに対してログは生成されません。

ロギングの詳細については、リクエストロギングの使用をご覧ください。詳細ログの詳細については、詳細ログをご覧ください。Cloud Armor ログを表示するには、ログの表示をご覧ください。

制限事項

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

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

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

検査は、構成済みの検査上限（POST 本文または PATCH 本文の最初の最大 64 KB（8 KB、16 KB、32 KB、48 KB、64 KB のいずれか））に制限されます。事前構成済みの WAF ルールを使用する場合にリクエスト本文の検査上限を構成する方法については、事前構成済みの WAF ルールの検査上限を更新するをご覧ください。

リクエスト本文の残りの部分に、アプリケーションが受け入れる可能性のある、WAF ルールシグネチャに一致するペイロードが含まれている可能性もあります。構成済みの検査上限（最初の最大 64 KB（8 KB、16 KB、32 KB、48 KB、64 KB のいずれか））を超えるリクエスト本文のリスクを軽減するには、構成済みの検査上限を超えるリクエスト本文のリスクを軽減するをご覧ください。

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

WebSocket 接続の処理方法

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