このページでは、Google Cloud Armor セキュリティ ポリシーの一般的なユースケースについて説明します。Google Cloud Armor セキュリティ ポリシーでは、IP アドレスの許可リストや拒否リストなどの機能や、一般的なウェブ攻撃を阻止する事前構成ルールによってアプリケーションを保護します。
ウェブ アプリケーションとサービスへのアクセスの制御
このセクションでは、Google Cloud Armor セキュリティ ポリシーを使用してアプリケーションやサービスへのアクセスを制御する方法について説明します。
許可リストを使用して特定の IP アドレスでのユーザーのアクセスを有効にする
ユーザー IP アドレスを許可リストに設定する一般的なユースケースは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサに特定のユーザーセットのみがアクセスする場合です。次の例では、組織のユーザーだけに、ロードバランサの背後のサービスへのアクセスが許可されています。これらのユーザーには、組織から割り当てられた IP アドレスまたはアドレス ブロックがあります。これらの IP アドレスまたは CIDR 範囲を許可リストに追加して、これらのユーザーのみがロードバランサにアクセスできるようにします。
ロードバランサへのアクセスを許可する送信元 IP アドレスまたは送信元 CIDR 範囲で許可リストを構成して、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサへのアクセスを制御します。次のセクションでは、この構成について詳細に説明します。
この構成では、IP 範囲の IP アドレスを使用する組織内のユーザーにのみ、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサへのアクセスを許可します。他のトラフィックはすべて拒否します。
この構成は次の手順に沿って作成します。
- Google Cloud Armor セキュリティ ポリシーを作成します。
- セキュリティ ポリシーで、最初のルールとして、許可リストに範囲を追加するルールを追加します。このルールの説明は
allow [RANGE]とします。ここで、[RANGE]は、対象の IP 範囲を記述します。 - ポリシーのデフォルト ルールを allow ルールから deny ルールに変更します。デフォルト ルールは、それに先立つルールに一致しないトラフィックに適用されます。デフォルト ルールはポリシー内の最終ルールです。ルールを
allowからdenyに変更すると、許可リストの範囲外のトラフィックはすべてブロックされます。 - このポリシーをグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサのバックエンド サービスに関連付けます。
組織でサードパーティのセキュリティ プロバイダを使用してトラフィックをスクラブしている場合は、セキュリティ プロバイダの IP アドレスを許可リストに追加して、スクラブされたトラフィックだけがグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサとバックエンドにアクセスするようにできます。
次の図では、サードパーティ プロバイダは CIDR 範囲 192.0.2.0/24 で識別されます。この範囲は許可リストに含まれています。
拒否リストを使用して特定の IP アドレスでのユーザーのアクセスをブロックする
拒否リストを使用して、IP アドレスまたは CIDR 範囲からのトラフィックを拒否する Google Cloud Armor セキュリティ ポリシーを作成します。次の図では、Google Cloud Armor セキュリティ ポリシーに、悪意のあるユーザーが識別された IP アドレス 198.51.100.1 からのトラフィックをブロックする deny ルールがあります。
レイヤ 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 が含まれている 192.0.2.0/24 からのリクエストに一致します。
inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
その他の例については、ルール言語リファレンスの式の例をご覧ください。
アプリケーション レイヤへの攻撃からデプロイを保護し、OWASP 上位 10 件のリスクを軽減する
Google Cloud Armor を使用すると、SQL インジェクション（SQLi）やクロスサイト スクリプティング（XSS）などのアプリケーション レイヤ（L7）攻撃から Cloud CDN 送信元サーバーを保護できます。キャッシュ内のコンテンツは静的であり、おそらくウェブからの標的型攻撃のリスクが発生することはありません。ただし、基になるコンテンツのオリジン サーバーは、ウェブアプリの既知の脆弱性または潜在的な脆弱性がある動的アプリケーションである可能性があります。セキュリティまたはコンプライアンスの要件により、こうしたリスクを軽減して、インターネットの脆弱性を悪用してオリジン サーバーが攻撃されるのを防ぐ必要があります。
このリスクを低減する手順は次のとおりです。
- CDN を有効にしてバックエンド サービスを作成または識別します。
- Google Cloud Armor セキュリティ ポリシーを作成します。
- セキュリティ ポリシーに 1 つ以上のルールを作成して、L7 攻撃を退けます。
- セキュリティ ポリシーのターゲットのいずれかを、ステップ 1 で作成または特定したバックエンド サービスとして構成します。
事前構成されたルールを使用して、一般的なアプリケーション レイヤの攻撃を検出してブロックすることもできます。事前構成済みのルールは、Google Cloud Armor セキュリティ ポリシーに追加できる事前定義された式のセットです。これらの式セットをルールに追加するには、gcloud --expression フラグまたは Google Cloud コンソールを使用します。詳細については、セキュリティ ポリシー、ルール、式の作成をご覧ください。
事前構成済みルールの詳細については、カスタムルール言語リファレンスの事前構成済みルールをご覧ください。
次の例では、事前構成済みのルールを使用して、クロスサイト スクリプティング（XSS）攻撃を軽減しています。
evaluatePreconfiguredExpr('xss-stable')
次の例では、事前構成済みのルールを使用して、SQL インジェクション（SQLi）攻撃を軽減しています。
evaluatePreconfiguredExpr('sqli-stable')
また、事前構成済みのルールを他の式と組み合わせることもできます。次の例では、事前構成済みのルールを使用して、192.0.2.1/24 IP アドレス範囲からの SQLi 攻撃を軽減しています。
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredExpr('sqli-stable')
ハイブリッド ワークロードの OWASP トップ 10 軽減策
Google Cloud Armor には、Google Cloud、オンプレミス、サードパーティ プロバイダのいずれにデプロイされていても、次の攻撃に対する緩和策が用意されています。
- SQL インジェクション（SQLi）
- クロスサイト スクリプティング（XSS）
- ローカル ファイル インクルード（LFI）
- リモート ファイル インクルード（RFI）
- リモートコード実行（RCE）
これらの機能は、OWASP トップ 10 リストに記載されているリスクなど、一般的なウェブ アプリケーションのセキュリティ リスクに対処する際に活用できます。
Google Cloud Armor の事前構成済みの WAF ルールをセキュリティ ポリシーに追加して、SQLi または XSS の試行を含む望ましくないレイヤ 7 リクエストを検出して拒否できます。Google Cloud Armor は悪意のあるリクエストを検出し、Google のインフラストラクチャのエッジでドロップします。バックエンド サービスがデプロイされている場所に関係なく、リクエストはバックエンド サービスにプロキシされません。
Google Cloud でホストされているワークロードを Google ネットワークのエッジでこれらの攻撃から防御するには、次の操作を行います。
- インターネット NEG をバックエンドとして持つバックエンド サービスを使用して、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを構成します。
- Google Cloud Armor セキュリティ ポリシーを作成します。
- ポリシーに事前構成された SQLi ルールと XSS ルールを追加します。
- 手順 1 で作成したバックエンド サービスにセキュリティ ポリシーを接続します。
- 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 保護を有効にする手順は次のとおりです。
- インターネット NEG をバックエンドとして持つバックエンド サービスを使用して、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを構成します。
- このバックエンド サービスに対して Cloud CDN を有効にします。
- Google Cloud Armor セキュリティ ポリシーを作成します。
- 手順 1 で作成したバックエンド サービスにセキュリティ ポリシーを接続します。
- Security Command Center、Cloud Logging、Cloud Monitoring で、Google Cloud Armor のアラート、ロギング、テレメトリにアクセスします。
さらに、エッジ セキュリティ ポリシーを使用して、キャッシュに保存されたコンテンツを保護することもできます。エッジ セキュリティ ポリシーの詳細については、セキュリティ ポリシーの概要をご覧ください。
レイヤ 7 アクセス制御とキャッシュ無効化攻撃
アプリケーション アーキテクチャに応じて、キャッシュ可能なコンテンツとキャッシュ不可能なコンテンツを含むさまざまな URL のリクエストを処理するように単一のバックエンド サービスを構成できます。このようなデプロイ シナリオでは、特定のリクエストパスでの望ましくないトラフィックは拒否しても、すべてのクライアントが別のリクエストパスの静的コンテンツにアクセスできるようにする Google Cloud Armor セキュリティ ポリシーを作成します。
他の状況では、コンテンツがキャッシュで効率的に処理されている場合でも、悪意のあるクライアントや障害のあるクライアントによって大量のリクエストが生成されてキャッシュミスが発生し、基になるオリジン サーバーがリクエストされたコンテンツをフェッチまたは生成する必要が生じる場合があります。こうしたことが起きると限られたリソースに負担がかかり、すべてのユーザーのアプリケーションの可用性に悪影響が出る可能性があります。Google Cloud Armor セキュリティ ポリシーを作成して、問題の原因となっているクライアントの署名を照合すると、そうしたリクエストがオリジン サーバーに到達してパフォーマンスに影響を与える前に拒否できます。
これを行う手順は次のとおりです。
- Google Cloud Armor セキュリティ ポリシーを作成します。
ルールを構成します。たとえば、次のルールは
"/admin"へのアクセスを拒否します。request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')手順 1 のセキュリティ ポリシーを、Cloud CDN が有効になっているバックエンド サービスに接続します。