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