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

Google Cloud Armor のセキュリティ ポリシーを使用して、ロードバランサの背後で実行されているアプリケーションを分散型サービス拒否攻撃(DDoS)やその他のウェブベースの攻撃から保護します。アプリケーションが Google Cloud にデプロイされているか、ハイブリッド デプロイであるか、マルチクラウド アーキテクチャであるかは関係ありません。

Google Cloud Armor セキュリティ ポリシーは、レイヤ 3、4、7 の属性に基づいてトラフィックをフィルタリングするルールで構成されます。たとえば、受信リクエストの IP アドレス、IP 範囲、リージョン コード、またはリクエスト ヘッダーに一致する条件を指定できます。

Google Cloud Armor セキュリティ ポリシーは、外部 HTTP(S) ロードバランサの後方にあるバックエンド サービスでのみ使用できます。ロードバランサは、プレミアム ティアまたはスタンダード ティアのいずれでも可能です。DDoS 対策は、HTTP(S) 負荷分散、SSL プロキシ負荷分散、TCP プロキシ負荷分散で自動的に提供されます。

HTTP、HTTPS、HTTP/2、QUIC の各プロトコルはすべてサポートされています。Google Kubernetes Engine(GKE)で Google Cloud Armor を構成する方法については、Ingress による Google Cloud Armor の構成をご覧ください。

バックエンド サービスのバックエンドは、インスタンス グループ内の仮想マシン(VM)インスタンス、ゾーン ネットワーク エンドポイント グループ(ゾーン NEG)、インターネット ネットワーク エンドポイント グループ(インターネット NEG)のいずれかとなります。Google Cloud Armor を使用してハイブリッド デプロイまたはマルチクラウド アーキテクチャを保護する場合は、バックエンドはインターネット 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 を使用するロードバランサで QUIC プロトコルを使用できます。

  • Google Cloud Armor は、プレミアム ティアおよびスタンダード ティアの外部 HTTP(S) ロードバランサで使用できます。

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

HTTP(S) 負荷分散のセキュリティ ポリシー

外部 HTTP(S) ロードバランサの各バックエンド サービスは、単一の Google Cloud Armor セキュリティ ポリシーを参照できます。同一または異なる外部 HTTP(S) ロードバランサ上の複数のバックエンド サービスで、同じセキュリティ ポリシーを使用できます。

複数のルールが構成されている場合は、優先度(評価順序)を指定します。

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(不正なゲートウェイ)のレスポンスを返すことができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プレビュー モード

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

ログ

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

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

Google Cloud Armor セキュリティ ポリシーは、外部公開しているアプリケーションやサービスを保護するアプリケーション レイヤ ファイアウォール ルールを適用するために定義する一連のルールです。各ルールは受信トラフィックについて評価されます。

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

条件が満たされた場合のアクションは、トラフィックの許可または拒否のいずれかです。デフォルトではこのアクションが適用されますが、プレビュー オプションも用意されています。プレビュー オプションを true に設定すると、プレビューされたアクションはログに記録されますが、適用されません。

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

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

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

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

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

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

HTTP POST リクエストの場合、Google Cloud Armor は本文(ペイロード)の前にリクエストのヘッダーを受信します。Google Cloud Armor は最初にヘッダー情報を受信するため、ヘッダーと一致するルールを評価しますが、本文に事前構成済みのルールとは一致しません。ヘッダーベースのルールが複数ある場合、Google Cloud Armor は想定の通りに、優先度に基づいてそれらを評価します。

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

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

WebSocket 接続の処理方法

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

Google Cloud Armor セキュリティ ポリシー

以下のセクションでは、Google Cloud Armor が他の Google Cloud の機能やプロダクトとどのように連携するかを説明します。

Google Cloud Armor と VPC のファイアウォール ルール

Google Cloud Armor のセキュリティ ポリシーと VPC ファイアウォール ルールには異なる機能があります。

  • Google Cloud Armor のセキュリティ ポリシーでは、エッジ セキュリティを提供し、Google Front End(GFE)へのクライアント トラフィックを処理します。
  • VPC ファイアウォール ルールは、バックエンドとの間のトラフィックを許可または拒否します。ターゲットが負荷分散されたバックエンド VM で、ソースが外部 HTTP(S) ロードバランサによって使用される IP 範囲である上り(内向き)許可ファイアウォール ルールを作成する必要があります。これらのルールにより、GFE とヘルスチェック システムがバックエンド VM と通信できるようになります。

たとえば、CIDR 範囲 100.1.1.0/24 と CIDR 範囲 100.1.2.0/24 からのトラフィックのみが外部 HTTP(S) ロードバランサにアクセスできるようにするシナリオを考えてみましょう。目標は、トラフィックがバックエンドの負荷分散インスタンスに直接到達できないようにすることです。つまり、関連するセキュリティ ポリシーを持つ外部 HTTP(S) ロードバランサ経由でプロキシされた外部トラフィックのみがインスタンスに到達する必要があります。

Google Cloud Armor セキュリティ ポリシーと上り(内向き)ファイアウォールを使用してアクセスを制限する
Google Cloud Armor セキュリティ ポリシーと上り(内向き)ファイアウォールを使用してアクセスを制限する(クリックして拡大)

上の図では、Google Cloud のデプロイを次のように構成することで、セキュリティ目標を達成しています。

  1. 2 つのインスタンス グループを作成します。1 つは us-west1 リージョンに、もう 1 つは europe-west1 リージョンに作成します。
  2. バックエンド アプリケーション インスタンスをインスタンス グループの VM にデプロイします。
  3. プレミアム ティアで外部 HTTP(S) ロードバランサを作成します。シンプルな URL マップと、前の手順で作成した 2 つのインスタンス グループをバックエンドとする単一のバックエンド サービスを構成します。ロードバランサの転送ルールが 120.1.1.1 外部 IP アドレスを使用していることを確認してください。
  4. 100.1.1.0/24 および 100.1.2.0/24 からのトラフィックを許可し、他のすべてのトラフィックを拒否する Google Cloud Armor セキュリティ ポリシーを構成します。
  5. このポリシーをロードバランサのバックエンド サービスに関連付けます。手順については、セキュリティ ポリシーの構成をご覧ください。より複雑な URL マップを持つ外部 HTTP(S) ロードバランサは、複数のバックエンド サービスを参照できます。必要に応じて、セキュリティ ポリシーを 1 つ以上のバックエンド サービスに関連付けることができます。
  6. 上り(内向き)許可ファイアウォール ルールを構成して、外部 HTTP(S) ロードバランサからのトラフィックを許可します。詳細については、ファイアウォール ルールをご覧ください。

Google Cloud Armor と HTTP(S) 負荷分散および IAP

Identity-Aware Proxy(IAP)は、ユーザーの ID を検証し、そのユーザーにアプリケーションへのアクセスを許可するかどうかを決定します。外部 HTTP(S) ロードバランサの IAP を有効にするには、ロードバランサのバックエンド サービスで有効にします。同様に、エッジ Google Cloud Armor のセキュリティ ポリシーは、外部 HTTP(S) ロードバランサのバックエンド サービスに接続されます。

Google Cloud Armor セキュリティ ポリシーと IAP の両方が外部 HTTP(S) ロードバランサのバックエンド サービスに対して有効になっている場合、IAP による評価が最初に行われます。IAP がリクエストをブロックした場合、Google Cloud Armor はリクエストを評価しません。IAP がリクエストを正常に認証した場合、Google Cloud Armor はリクエストを評価します。Google Cloud Armor セキュリティ ポリシーによって拒否の判断が下された場合、リクエストはブロックされます。

IAP で IP アドレスの拒否リストと許可リストを使用する。
IAP で IP アドレスの拒否リストと許可リストを使用する(クリックして拡大)

IAP と関連する構成の詳細については、Identity-Aware Proxy のドキュメントをご覧ください。

ハイブリッド デプロイの Google Cloud Armor

ハイブリッド デプロイでは、Google Cloud ロードバランサは、別のクラウド プロバイダのインフラストラクチャなど、Google Cloud の外部で実行されるアプリケーションまたはコンテンツ ソースにアクセスする必要があります。Google Cloud Armor を使用すると、このようなデプロイを保護できます。

次の図では、ロードバランサに 2 つのバックエンド サービスがあります。1 つは、バックエンドとしてインスタンス グループを持っています。もう 1 つのバックエンド サービスには、バックエンドとしてインターネット NEG があり、インターネット NEG は、サードパーティ プロバイダのデータセンターで実行されているアプリケーションに関連付けられています。

ハイブリッド デプロイ用の Google Cloud Armor
ハイブリッド デプロイ用の Google Cloud Armor(クリックして拡大)

インターネット NEG をバックエンドとして持つバックエンド サービスに Google Cloud Armor セキュリティ ポリシーを接続すると、Google Cloud Armor は、そのバックエンド サービスを宛先とする外部 HTTP(S) ロードバランサに到着するすべての L7 リクエストを検査します。

ハイブリッド デプロイの Google Cloud Armor 保護には、インターネット NEG に適用されるものと同じ制限が適用されます。

Google Cloud Armor と Cloud CDN

Cloud CDN と Google Cloud Armor を併用して、CDN 配信元サーバーを保護できます。Google Cloud Armor は、CDN 配信元サーバーがアプリケーション攻撃から確実に保護されるようにし、OWASP トップ 10 リスクを軽減して、レイヤ 7 フィルタリング ポリシーを適用します。

Google Cloud Armor は、キャッシュ ミス(Cloud CDN キャッシュを逃しすリクエストやバイパスするリクエスト)に対してのみ Cloud CDN を有効にして、バックエンド サービスにセキュリティ ポリシーを適用します。

Cloud CDN 対応のバックエンド サービスにセキュリティ ポリシーが接続されている場合、Google Cloud Armor は、キャッシュから配信できない受信リクエストをセキュリティ ポリシーと比較して評価し、オリジン サーバーに転送する必要があるかどうかを判断します。ルールがリクエストに一致する場合、ルールで構成されているアクションが実行されます。

ただし、Cloud CDN 対応のバックエンド サービスに接続されているセキュリティ ポリシーは、キャッシュ ヒットに対しては適用されません。リクエストがキャッシュから配信できる場合、セキュリティ ポリシーによるそのリクエストへの対応には関係なく、それ以外の場合は有効なクライアントに配信されます。

次の図は、Google Cloud Armor が Cloud CDN オリジンとどのように連携するかを示しています。

Cloud CDN での Google Cloud Armor の使用
Google Cloud Armor と Cloud CDN(クリックして拡大)

Google Cloud Armor と サーバーレス アプリ

Google Cloud Armor セキュリティ ポリシーは、Cloud RunApp EngineCloud Functions サービスを参照するサーバーレス NEG バックエンドで使用できます。

ただし、サーバーレス NEG と Cloud Functions で、Google Cloud Armor を使用する場合は、セキュリティの問題を回避するために特別な手順を行う必要があります。

Cloud Functions サービスのデフォルト URL が割り当てられたユーザーは、ロードバランサをバイパスして、サービス URL に直接アクセスできます。これにより、Google Cloud Armor セキュリティ ポリシーを回避できます。Google Cloud が Cloud Functions サービスに自動的に割り当てる URL は無効にできません。

このセキュリティ リスクを回避するには、internal-and-gclb を使用して Cloud Functions を構成します。これにより、内部トラフィックと外部 HTTP(S) ロードバランサにより公開されているパブリック IP アドレスに送信されるトラフィックのみが許可されます。Cloud Functions によって設定された cloudfunctions.net や他のカスタム ドメインに送信されたトラフィックは、ブロックされます。これにより、ユーザーは、外部 HTTP(S) ロードバランサを介して設定されたアクセス制御(Google Cloud Armor セキュリティ ポリシーなど)を回避できなくなります。

サーバーレス NEG の詳細については、サーバーレス ネットワーク エンドポイント グループの概要サーバーレス NEG の設定をご覧ください。

一般的な使用例

このセクションでは、Google Cloud Armor セキュリティ ポリシーの一般的な使用例をいくつか紹介します。

使用例 1: Google Cloud 外部 HTTP(S) ロードバランサへのアクセスを制限する

ユーザー IP アドレスを許可リストに設定する一般的な使用例は、外部 HTTP(S) ロードバランサが特定のユーザーセットだけに使用される場合です。次の例では、組織のユーザーだけに、ロードバランサの背後のサービスへのアクセスが許可されています。これらのユーザーには、組織から割り当てられた IP アドレスまたはアドレス ブロックがあります。これらの IP アドレスまたは CIDR 範囲を許可リストに追加して、これらのユーザーのみがロードバランサにアクセスできるようにします。

許可リストによるロードバランサ アクセスの制限
許可リストによるロードバランサ アクセスの制限(クリックして拡大)

ロードバランサへのアクセスを許可する送信元 IP アドレスまたは送信元 CIDR 範囲で許可リストを構成して、外部 HTTP(S) ロードバランサへのアクセスを制御します。次のセクションでは、この構成について詳細に説明します。

この構成では、203.0.113.0/24 の IP アドレスを使用する組織のユーザーにのみ外部 HTTP(S) ロードバランサへのアクセスを許可します。他のトラフィックはすべて拒否します。

この構成は次の手順に沿って作成します。

  1. Google Cloud Armor セキュリティ ポリシーを作成します。
  2. セキュリティ ポリシーで、203.0.113.0/24 を最初のルールとして許可リストに追加するルールを追加します。このルールの記述は allow 203.0.113.0/24 になります。
  3. ポリシーのデフォルト ルールを allow ルールから deny ルールに変更します。デフォルト ルールは、それに先立つルールに一致しないトラフィックに適用されます。デフォルト ルールはポリシー内の最終ルールです。ルールを allow から deny に変更すると、許可リストにある 203.0.113.0/24 の範囲を送信元としないすべてのトラフィックがブロックされます。
  4. このポリシーを外部 HTTP(S) ロードバランサのバックエンド サービスに関連付けます。

使用例 2: 拒否リストによって不正なトラフィックまたは悪意のあるトラフィックをエッジでブロックする

拒否リストを使用して、IP アドレスまたは CIDR 範囲からのトラフィックを拒否する Google Cloud Armor セキュリティ ポリシーを作成します。次の図では、Google Cloud Armor セキュリティ ポリシーに、悪意のあるユーザーが識別された IP アドレス 198.51.100.1 からのトラフィックをブロックする deny ルールがあります。

拒否リストによるロードバランサ アクセスの制限
拒否リストによるロードバランサ アクセスの制限(クリックして拡大)

使用例 3: 外部 HTTP(S) ロードバランサへのトラフィックを、サードパーティのセキュリティ プロバイダと他の承認されたユーザーからのみに制限する

組織でサードパーティのセキュリティ プロバイダを使用してトラフィックをスクラブしている場合は、セキュリティ プロバイダの IP アドレスを許可リストに追加して、スクラブされたトラフィックだけが外部 HTTP(S) ロードバランサとバックエンドにアクセスするようにできます。

次の図では、サードパーティ プロバイダは CIDR 範囲 192.0.2.0/24 で識別されます。この範囲は許可リストに含まれています。

サードパーティのセキュリティ プロバイダからのトラフィックを許可リストに登録してロードバランサへのアクセスを制限
サードパーティのセキュリティ プロバイダからのトラフィックを許可リストに登録してロードバランサへのアクセスを制限(クリックして拡大)

使用例 4: レイヤ 3 からレイヤ 7 のパラメータに一致するカスタムルールで防御をカスタマイズする

Google Cloud Armor カスタムルール言語を使用して、ルールの一致条件で 1 つ以上の式を定義します。Google Cloud Armor はリクエストを受信すると、これらの式に対してリクエストを評価します。一致がある場合、ルールのアクションが有効になり、受信トラフィックが拒否または許可されます。

Common Expression Language(CEL)の Google Cloud Armor 拡張機能で記述された式の例を下に示します。 詳細については、カスタムルール言語リファレンスをご覧ください。

ルールで式を定義するには、gcloud --expression フラグまたは Google Cloud Console を使用します。詳細については、Google Cloud Armor のセキュリティ ポリシー、ルール、式を作成するをご覧ください。

次の例では、AU リージョンの 2001:db8::/32(アルファ テスターなど)からのリクエストが次の式と一致します。

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

次の例は、ユーザー エージェントに文字列 WordPress が含まれている 1.2.3.4 からのリクエストに一致します。

inIpRange(origin.ip, '1.2.3.4/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

その他の例については、カスタムルール言語リファレンスの式の例をご覧ください。

使用例 5: 事前構成済みのルールを使用してアプリケーション レイヤ攻撃を軽減する

事前構成済みのルールを使用して、XSS や SQLi などの一般的なアプリケーション レイヤ攻撃を検出してブロックします。事前構成済みのルールは、Google Cloud Armor セキュリティ ポリシーに追加できる事前定義された式のセットです。これらの式セットをルールに追加するには、gcloud --expression フラグまたは Cloud Console を使用します。詳細については、Google Cloud Armor のセキュリティ ポリシー、ルール、式を作成するをご覧ください。

事前構成済みルールの詳細については、カスタムルール言語リファレンスの事前構成済みルールをご覧ください。

次の例では、事前構成済みのルールを使用して、クロスサイト スクリプティング(XSS)攻撃を軽減しています。

evaluatePreconfiguredExpr('xss-stable')

次の例では、事前構成済みのルールを使用して、SQL インジェクション(SQLi)攻撃を軽減しています。

evaluatePreconfiguredExpr('sqli-stable')

また、事前構成済みのルールを他の式と組み合わせることもできます。次の例では、事前構成済みのルールを使用して、1.2.3.0/24 IP アドレス範囲からの SQLi 攻撃を軽減しています。

inIpRange(origin.ip, '1.2.3.0/24') && evaluatePreconfiguredExpr('sqli-stable')

ハイブリッド デプロイの使用例

このセクションでは、ハイブリッド デプロイでの Google Cloud Armor セキュリティ ポリシーの使用例を示します。

使用例: ハイブリッド ワークロードの OWASP トップ 10 軽減策

Google Cloud Armor は、アプリケーションが Google Cloud、オンプレミス、サードパーティ プロバイダのいずれにデプロイされているかに関係なく、アプリケーションに SQL インジェクション(SQLi)とクロスサイト スクリプティング(XSS)の緩和策を提供します。これらの機能は、OWASP トップ 10 リストに記載されているリスクなど、一般的なウェブ アプリケーションのセキュリティ リスクに対処するうえで活用できます。

Google Cloud Armor の事前構成済みの WAF ルールをセキュリティ ポリシーに追加して、SQLi または XSS の試行を含む望ましくないレイヤ 7 リクエストを検出して拒否できます。Google Cloud Armor は悪意のあるリクエストを検出し、Google のインフラストラクチャのエッジでドロップします。バックエンド サービスがデプロイされている場所に関係なく、リクエストはバックエンド サービスにプロキシされません。

Google のネットワークのエッジでの SQLi または XSS 攻撃から Google Cloud でホストされていないワークロードを防御する手順は次のとおりです。

  1. インターネット NEG をバックエンドとして持つバックエンド サービスを使用して、外部 HTTP(S) ロードバランサを構成します。
  2. Google Cloud Armor セキュリティ ポリシーを作成します。
  3. ポリシーに SQLi ルールと XSS ルールを追加します。
  4. 手順 1 で作成したバックエンド サービスにセキュリティ ポリシーを接続します。
  5. Cloud Logging、Cloud Monitoring、Security Command Center に送信された検出結果を使用して、Google Cloud Armor のアクティビティをモニタリングします。

使用例: Cloud CDN 外部オリジン サーバーの DDoS 防御とレイヤ 7 モニタリング

外部のオリジン サーバーを使用した Cloud CDN デプロイでは、プロキシング、キャッシング、Google Cloud Armor レイヤ 7 フィルタリングのフロントエンドとして、Google のエッジ インフラストラクチャを使用できます。インターネット NEG を使用すると、オリジン サーバーをオンプレミス上に配置できます。またサードパーティのインフラストラクチャ プロバイダとともに配置することもできます。

Google Cloud Armor とその他の Google のエッジ インフラストラクチャによって、L3/L4 攻撃が軽減、ドロップされ、疑わしいレイヤ 7 アクティビティを警告し、カスタムルールを使用して望ましくないレイヤ 7 リクエストを拒否する準備ができています。Cloud Logging、Cloud Monitoring、Security Command Center にまたがる Google Cloud Armor のロギングとテレメトリによって、デプロイされている場所に関係なく、保護されたアプリケーションに関する、行動につながる分析情報が提供されます。

CDN 外部オリジン サーバーの Google Cloud Armor 保護を有効にする手順は次のとおりです。

  1. インターネット NEG をバックエンドとして持つバックエンド サービスを使用して、外部 HTTP(S) ロードバランサを構成します。
  2. このバックエンド サービスに対して Cloud CDN を有効にします。
  3. Google Cloud Armor セキュリティ ポリシーを作成します。
  4. 手順 1 で作成したバックエンド サービスにセキュリティ ポリシーを接続します。
  5. Security Command Center、Cloud Logging、Cloud Monitoring で、Google Cloud Armor のアラート、ロギング、テレメトリにアクセスします。

Cloud CDN の使用例

このセクションでは、Cloud CDN と併用される Google Cloud Armor の 2 つの使用例について説明します。

使用例: SQLi と XSS の軽減

Google Cloud Armor を使用して、SQL インジェクション(SQLi)やクロスサイト スクリプティング(XSS)攻撃などのリスクから Cloud CDN オリジン サーバーを保護できます。キャッシュ内のコンテンツは静的であり、おそらくウェブからの標的型攻撃のリスクが発生することはありません。ただし、基になるコンテンツのオリジン サーバーは、ウェブアプリの既知の脆弱性または潜在的な脆弱性がある動的アプリケーションである可能性があります。セキュリティまたはコンプライアンスの要件により、こうしたリスクを軽減して、インターネットの脆弱性を悪用してオリジン サーバーが攻撃されるのを防ぐ必要があります。

このリスクを低減する手順は次のとおりです。

  1. CDN を有効にしてバックエンド サービスを作成または識別します。
  2. Google Cloud Armor セキュリティ ポリシーを作成します。
  3. セキュリティ ポリシーに 1 つ以上のルールを作成して、XSS および SQLi 攻撃を退けます。
  4. セキュリティ ポリシーのターゲットのいずれかを、ステップ 1 で作成または特定したバックエンド サービスとして構成します。

使用例: レイヤ 7 アクセス制御とキャッシュ無効化攻撃

アプリケーション アーキテクチャに応じて、キャッシュ可能なコンテンツとキャッシュ不可能なコンテンツを含むさまざまな URL のリクエストを処理するように単一のバックエンド サービスを構成できます。このようなデプロイ シナリオでは、特定のリクエストパスでの望ましくないトラフィックは拒否しても、すべてのクライアントが別のリクエストパスの静的コンテンツにアクセスできるようにする Google Cloud Armor セキュリティ ポリシーを作成します。

他の状況では、コンテンツがキャッシュで効率的に処理されている場合でも、悪意のあるクライアントや障害のあるクライアントによって大量のリクエストが生成されてキャッシュ ミスが発生し、基になるオリジン サーバーがリクエストされたコンテンツをフェッチまたは生成する必要が生じる場合があります。こうしたことが起きると限られたリソースに負担がかかり、すべてのユーザーのアプリケーションの可用性に悪影響が出る可能性があります。Google Cloud Armor セキュリティ ポリシーを作成して、問題の原因となっているクライアントの署名を照合すると、そうしたリクエストがオリジン サーバーに到達してパフォーマンスに影響を与える前に拒否できます。

これを行う手順は次のとおりです。

  1. Google Cloud Armor セキュリティ ポリシーを作成します。
  2. ルールを構成します。たとえば、次のルールは "/admin" へのアクセスを拒否します。

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'
    
  3. 手順 1 のセキュリティ ポリシーを、Cloud CDN が有効になっているバックエンド サービスに接続します。

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

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

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

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

制限事項

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

  • Google Cloud Armor は内部 HTTP(S) 負荷分散ではサポートされていません。

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

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

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

次のステップ