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 の機能

Google Cloud Armor には次の機能があります。

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

  • Google Cloud Armor セキュリティ ポリシーを 1 つ以上の HTTP(S) 負荷分散バックエンド サービスに関連付ける機能。
  • 複数のルールが設定されている場合は、優先度(評価順序)を指定します。
  • 403、404、502 エラーコードを表示する拒否ルールを設定できます。

Google Cloud Armor セキュリティ ポリシーの IP アドレス許可リストと拒否リストのルール

  • IP アドレス / CIDR の拒否リストによって、送信元 IP アドレスまたは CIDR 範囲から外部 HTTP(S) ロードバランサへのアクセスをブロックする機能が提供されます。
  • IP アドレス / CIDR のリストを許可すると、送信元 IP アドレスまたは CIDR 範囲から外部 HTTP(S) ロードバランサにアクセスできるようになります。
  • 許可リスト / 拒否リストルールでは IPv4 アドレスと IPv6 アドレスがサポートされています。

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

  • 着信要求のレイヤー 3 からレイヤー 7 のさまざまな属性で一致するカスタムルール式を記述する機能。Google Cloud Armor では、カスタム一致条件を記述するための柔軟な言語を提供しています。
  • 1 つのルールに複数のサブ式を結合できます。
  • 着信要求の地域コードに基づいてリクエストを拒否または許可する機能。地域コードは、ISO 3166-1 alpha 2 コードに基づいています。 地域コードは特定の国に対応している場合もありますが、国とその関連地域が含まれる場合もあります。たとえば、US コードには米国のすべての州、1 行政区、6 の周辺地域が含まれます。

XSS および SQLi に対して事前設定されたルール

  • 事前設定されたルールを使用して、クロスサイト スクリプティング(XSS)および SQL インジェクション(SQLi)攻撃を軽減します。
  • XSS および SQLi ルールは、OWASP Modsecurity コア ルールセット バージョン 3.0.1 に基づいています。

プレビュー モード

  • ルールのアクションを適用せずに、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 のセキュリティ ポリシーについての記述で違いを確認し、最新のフィンガープリントを取得します。

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

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

  • Google Cloud Armor のセキュリティ ポリシーでは、エッジ セキュリティを提供し、Google フロントエンド(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(クリックして拡大)

一般的な使用例

このセクションでは、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 オリジン サーバーを保護できます。キャッシュ内のコンテンツは静的であり、おそらく Web からの標的型攻撃のリスクが発生することはありません。ただし、基になるコンテンツのオリジン サーバーは、Web アプリの既知の脆弱性または潜在的な脆弱性がある動的アプリケーションである可能性があります。セキュリティまたはコンプライアンスの要件により、こうしたリスクを軽減して、インターネットの脆弱性を悪用してオリジン サーバーが攻撃されるのを防ぐ必要があります。

リスクを軽減するには:

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

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

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

制限事項

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

次のステップ