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

Google Cloud Armor セキュリティ ポリシーでは、ロードバランサへのアクセスを許可するか拒否するリクエストを規制することで、アプリケーションを保護します。各セキュリティ ポリシーは、受信リクエストの IP アドレス、IP 範囲、リージョン コード、リクエスト ヘッダーなどの条件に基づいてトラフィックをフィルタリングする一連のルールで構成されています。

Google Cloud Armor セキュリティ ポリシーは、外部 HTTP(S) ロードバランサの後方にあるバックエンド サービスでのみ使用できます。ロードバランサは、プレミアム ティアまたはスタンダード ティアのいずれでも可能です。

バックエンド サービスのバックエンドは、インスタンス グループ内の仮想マシン(VM)インスタンス、ゾーン ネットワーク エンドポイント グループ(ゾーン NEG)、インターネット ネットワーク エンドポイント グループ(インターネット NEG)のいずれかとなります。Google Cloud Armor を使用してハイブリッド デプロイまたはマルチクラウド アーキテクチャを保護する場合は、バックエンドをインターネット NEG に、またはオンプレミスまたは複数の環境でのデプロイに Traffic Director を使用する場合はハイブリッド接続 NEG にする必要があります。 また、ロードバランサを介してトラフィックがルーティングされる場合は、サーバーレス NEG も保護されます。ロードバランサを介してルーティングされたトラフィックのみが NEG に到達することを確認するには、上り(内向き)制御をご覧ください。

Google Cloud Armor セキュリティ ポリシーを使用したエッジ セキュリティ

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

Google Cloud Armor のセキュリティ ポリシーを使用すると、Google Cloud Edge の外部 HTTP(S) ロードバランサへのアクセスを、着信トラフィックのソースにできるだけ近い場所で許可または拒否できます。これにより、望ましくないトラフィックによるリソースの消費や Virtual Private Cloud(VPC)ネットワークへ侵入を防止します。

次の図は、外部 HTTP(S) ロードバランサ、Google ネットワーク、および Google データセンターのロケーションを示しています。

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

要件

Google Cloud Armor セキュリティ ポリシーの要件は次のとおりです。

  • ロードバランサは、外部 HTTP(S) ロードバランサである必要があります。
  • バックエンド サービスの負荷分散スキームは EXTERNAL である必要があります。
  • バックエンド サービスのプロトコルは、HTTPHTTPSHTTP/2 のいずれかにする必要があります。

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

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

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

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 は、次のいずれかのネットワーク サービス階層にある外部 HTTP(S) ロードバランサで使用できます。

    • プレミアム ティア
    • スタンダード ティア
  • GKE とデフォルトの Ingress コントローラでセキュリティ ポリシーを使用できます。

セキュリティ ポリシーのアクション

条件と一致する場合、デフォルトでは次のいずれかのアクションが適用されます。

  • 許可
  • 拒否

ルールの評価順序

ルールの評価順序は、ルールの優先度(数値)を小さい数値から順に選択されます。数値が最も小さいルールが、最も高い論理優先度を持ち、それより低い論理優先度を持つルールよりも先に評価されます。優先度の最小の数字は 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 は想定の通りに、優先度に基づいてそれらを評価します。

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

次の例では、ルール 1、2、3 が IP ヘッダー フィールドと HTTP ヘッダー フィールドでこの順序で評価されます。ただし、IP 9.9.9.1HTTP 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)が割り当てられ、セキュリティ ポリシーに常に存在します。

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

フィンガープリント

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

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

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

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

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

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

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

ルールの種類

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

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

  • IP アドレス / CIDR を拒否リストに登録すると、送信元 IP アドレスまたは CIDR 範囲が外部 HTTP(S) ロードバランサにアクセスすることをブロックできます。

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

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

  • IP アドレスルールでは、個々の送信元 IP アドレスまたは CIDR をブロックおよび許可できます。IPv4 と IPv6 の両方の送信元アドレスがサポートされていますが、IPv6 アドレスには /64 以下のサブネット マスクが必要です。

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

XSS、SQLi、LFI、RFI、RCE に対する事前構成済みルール

事前構成済みルールを使用して以下の攻撃を軽減できます。

  • クロスサイト スクリプティング(XSS)
  • SQL インジェクション(SQLi)攻撃
  • ローカル ファイル インクルード(LFI)攻撃
  • リモート ファイル インクルード(RFI)攻撃
  • リモートコード実行(RCE)攻撃

これらのルールは、OWASP Modsecurity Core Rule Set バージョン 3.0.2 に基づいています。

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

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

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

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

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

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

プレビュー モード

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

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

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

ログ

外部 HTTP(S) ロードバランサへの HTTP(S) リクエストについては、Google Cloud Armor セキュリティ ポリシー名、一致したルールの優先度、関連するアクション、および関連情報がログに記録されます。Google Cloud Armor ロギング情報を記録するには、HTTP(S) リクエストのロギングを有効にする必要があります。

HTTP(S) 負荷分散リクエストのロギング

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

詳細については、IP 拒否リストおよび IP 許可リストのロギングをご覧ください。

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

Google Cloud Armor と Google Kubernetes Engine(GKE)Ingress

Google Cloud Armor セキュリティ ポリシーを構成したら、Kubernetes Ingress を使用してこれを有効にできます。

セキュリティ ポリシーの名前を BackendConfig に追加することで、セキュリティ ポリシーを BackendConfig リソースで参照できます。次の BackendConfig マニフェストでは、example-security-policy という名前のセキュリティ ポリシーを指定しています。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Ingress 機能の詳細については、Ingress 機能の構成をご覧ください。

制限事項

  • HTTP(S) 負荷分散の IP アドレス拒否リスト / 許可リストは、Cloud Storage バックエンド バケットではサポートされていません。

  • セキュリティ ポリシーは、CDN キャッシュミスに対してのみ適用されます。セキュリティ ポリシーのルールがリクエストを拒否した場合でも、コンテンツはキャッシュから配信されます。

WebSocket 接続の処理方法

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

次のステップ