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

概要

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

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

Google Cloud Armor セキュリティ ポリシーは、外部 HTTP(S) ロードバランサの後方にあるバックエンド サービスでのみ使用できます。ロードバランサは、プレミアム ティアまたはスタンダード ティアのいずれでも可能です。HTTP、HTTPS、HTTP/2、QUIC の各プロトコルはすべてサポートされています。Google Kubernetes Engine での Google Cloud Armor の構成については、Ingress による Google Cloud Armor の構成をご覧ください。

バックエンド サービスのバックエンドは、インスタンス グループ内の VM、ゾーン ネットワーク エンドポイント グループ(ゾーン NEG)、インターネット ネットワーク エンドポイント グループ(インターネット NEG)のいずれかとなります。Google Cloud Armor を使用してハイブリッド デプロイまたはマルチクラウド アーキテクチャを保護する場合は、バックエンドはインターネット NEG にする必要があります。

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

Google Cloud HTTP(S) 負荷分散は、Google の世界中の接続拠点で 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 セキュリティ ポリシーには、次のコア機能が含まれています。

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

  • 外部 HTTP(S) ロードバランサの各バックエンド サービスは、1 つの Google Cloud Armor セキュリティ ポリシーを参照できます。同じまたは異なる外部 HTTP(S) ロードバランサ上の複数のバックエンド サービスで、同じセキュリティ ポリシーを使用できます。
  • 複数のルールが構成されている場合は、優先度(評価順序)を指定します。

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

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

  • IP アドレス / CIDR の拒否リストによって、送信元 IP アドレスまたは CIDR 範囲から外部 HTTP(S) ロードバランサへのアクセスをブロックする機能が提供されます。
  • IP アドレス / CIDR のリストを許可すると、送信元 IP アドレスまたは CIDR 範囲から外部 HTTP(S) ロードバランサにアクセスできるようになります。
  • 許可リスト / 拒否リストルールでは IPv4 アドレスと IPv6 アドレスがサポートされています。
  • 個々の送信元 IP アドレスまたは CIDR をブロックまたは許可する IP アドレスルール。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 リストを 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 つのバックエンド サービスに関連付けることができる Google Cloud Armor セキュリティ ポリシーは 1 つだけです。

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

複数の転送ルールが、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 の番号が付いたルールを将来追加することが可能で、実行順序の変更を除いて、既存のルールに変更はありません。

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

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

Google Cloud Armor は、HTTP POST の本文を受け取ると、リクエスト ヘッダーと本文の両方に適用されるルールを評価します。このため、リクエストの本文をチェックする優先度の高いルールよりも前に、リクエストのヘッダーをチェックする優先度の低いルールが一致する可能性があります。

次の例では、IP ヘッダー フィールドと HTTP ヘッダー フィールドに対して、ルール 1、2、3 がこの順序で評価されます。ただし、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 攻撃はスキャンされずに 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 セキュリティ ポリシーに常に存在します。デフォルト ルールは削除できませんが、変更は可能です。デフォルト ルールのデフォルトのアクションは拒否ですが、これを許可に変更できます。

フィンガープリント

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

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

WebSocket 接続の処理方法

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

HTTP(S) 負荷分散と VPC ファイアウォール ルールの Google Cloud Armor セキュリティ ポリシー

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) ロードバランサからのトラフィックを許可します。詳細については、ファイアウォール ルールをご覧ください。

HTTP(S) 負荷分散と Identity-Aware Proxy の Google Cloud Armor セキュリティ ポリシー

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(クリックして拡大)

Cloud Functions で Google Cloud Armor を使用する

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

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

このセキュリティ リスクを回避するには、Cloud Functions を構成するときに、internal-and-gclb を使用することで、内部トラフィックと、外部 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. Google Cloud Armor のセキュリティ ポリシーで、リスト 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 拡張機能で記述された式の例を下に示します。詳細については、Google Cloud Armor カスタムルール言語リファレンスをご覧ください。

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

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

origin.region_code == "AU" && inIpRange(origin.ip, '1.2.3.0/24')

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

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

その他の例については、ルール言語リファレンスの式の例をご覧ください。調整ルールの詳細については、Google Cloud Armor WAF ルールの調整をご覧ください。

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

事前構成済みのルールを使用して、XSS や SQLi などの一般的なアプリケーション レイヤ攻撃を検出してブロックします。事前構成済みのルールは、Google Cloud Armor セキュリティ ポリシーに追加できる事前定義された式のセットです。これらの式セットをルールに追加するには、gcloud --expression フラグまたはコンソールを使用します。詳細については、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. Operations Logging、Operations Monitoring、および Cloud 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 リクエストを拒否する準備ができています。Operations Logging、Operations Monitoring、Cloud 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 つを、手順 1 で作成または識別したバックエンド サービスになるように構成します。

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

アプリケーション アーキテクチャに応じて、キャッシュ可能なコンテンツとキャッシュ不可能なコンテンツを含むさまざまな URL のリクエストを処理するように 1 つのバックエンド サービスを構成できます。このようなデプロイ シナリオでは、特定のリクエストパスでの望ましくないトラフィックは拒否しても、すべてのクライアントが別のリクエストパスの静的コンテンツにアクセスできるようにする 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) ロギングを有効にする必要があります。

詳細については、HTTP(S) 負荷分散のドキュメントのロギングをご覧ください。

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

制限事項

  • HTTP(S) 負荷分散の IP 拒否リスト / 許可リストは、Cloud Storage バックエンド バケットではサポートされていません。
  • Google Cloud Armor は内部 HTTP(S) 負荷分散ではサポートされていません。
  • セキュリティ ポリシーは、CDN キャッシュ ミスに対してのみ適用されます。
    • セキュリティ ポリシーのルールがリクエストを拒否した場合でも、コンテンツはキャッシュから配信されます。

次のステップ