ウェブ アプリケーションと API サービスを確実に保護できるよう、Cloud Armor WAF 機能が強化されました

※この投稿は米国時間 2023 年 7 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

ウェブ アプリケーションと API をクラウドに移行する組織には、エクスプロイトや分散型サービス拒否（DDoS）攻撃からアプリと API を保護するためのソリューションが必要になります。こうした DDoS 攻撃や OWASP トップ 10 のリスクに対する防御機能を提供しているのが、ネットワーク セキュリティ サービスの Google Cloud Armor です。  

ここでご紹介するのは、Cloud Armor に導入された画期的な新機能です。まず、DDoS に対する防御とウェブ アプリケーションの保護をさらに強化するために、きめの細かいレート制限 で複数のキーの組み合わせを使用できるようになりました。さらに、リクエストの送信元に基づくより柔軟な IP ベースのカスタムルールを作成できるようにもなっています。

1 つまたは複数の一意のキー ID の組み合わせを基準にレート制限を適用

2022 年 6 月に、サービスの可用性を確保するためにリクエストのボリュームに応じてレイヤ 7 のウェブ リクエスト数や TCP / SSL 接続数を抑制する、Cloud Armor のレート制限機能を発表しました。その後、Google は Cloud Armor のクライアント単位のレート制限機能の拡張に取り組み、レート制限キーを追加するとともに、複数のキーを組み合わせてトラフィックをスロットル調整できるようにしました。

Cloud Armor のレート制限ルールを構成するには、Google Cloud コンソールまたは API を使用して、クライアントあたりの最大リクエスト数または接続数を適用する対象をキーで指定します。そのために使用できるキーに、次の新しいタイプが追加されました。

• HTTP-PATH: リクエストの HTTP URL パスごとに一意のキー

• REGION-CODE: リクエスト送信元の国 / 地域ごとに一意のキー

• SNI: HTTPS リクエストの TLS セッションで使用される Server Name Indication 値ごとに一意のキー

Cloud Armor のユーザーは、上記のリストに示されているキータイプの中から最大 3 つを選択できます。選択したタイプのキーの値を組み合わせたものが、レート制限を適用する基準として実際に使用されるキーになります。

送信元 IP に基づく以前のレート制限では、単一のクライアントが多数の URL パスを考慮して設計されたウェブ アプリケーションのページにアクセスすると、誤検出が発生する可能性がありました。このような設計で正当なトラフィックが誤ってスロットリングされないようにするには、たとえば「IP」と「HTTP-PATH」に基づく、Cloud Armor の複数キーによるレート制限ルールが有効なソリューションになります。

この例でのサンプル gcloud コマンドは次のようになります。

新しい属性 True-Client-IP とその他のカスタム IP で柔軟に WAF ルールを構成

この懸念に対処すべく、最近、公開プレビュー版でユーザーが構成できる「user_ip」というフィールドを導入し、リクエスト ヘッダーの True-Client-IP とその他の IP ソースに対応できるようにしました。現在、ユーザーは以下のコマンドを使用して、Cloud Armor に対し、L7 フィルタリング ルール、適応型保護および Threat Intelligence に使用する IP アドレスを指定できます。

同じサンプル シナリオで、Cloud Armor への単一の受信リクエストのヘッダーに、IP に関する一連の情報が含まれているとします。Cloud Armor はこの場合も、アップストリーム プロキシに属する Client-IP（この例では 23.220.162.152）をデフォルトで検査します。ただし、追加のフィールドを構成すれば、Cloud Armor で検査する対象を指定できます。

• 例 1: Cloud Armor で「True-Client-IP」（142.251.163.99）をポリシー全体の検査対象にするには、「--user-ip-request-headers=True-Client-IP」を使用します。

• 例 2: Cloud Armor で XFF ヘッダー（142.251.163.102）の左端の値を検査対象にするには、「--user-ip-request-headers=X-Forwarded-For」を使用します。

• 例 3: Cloud Armor で一連の IP ヘッダー情報を検査対象にするには、「--user-ip-request-headers=True-Client-IP, X-Forwarded-For」を構成して Cloud Armor が以下のように動作するようにします。

• 最初の選択肢として、True-Client-IP（142.251.163.99）を検査対象にする

• True-Client-IP が存在しない場合は、XFF ヘッダー（142.251.163.102）の左端の値を検査対象にする

• True-Client-IP も XFF も存在しない場合は、デフォルトの Client-IP（142.251.163.99）を検査対象にする

Cloud Armor での評価のための IP の選択について詳しくは、こちらをご覧ください。IP 解決戦略を選んだら、user_ip を Cloud Armor のカスタムルール、適応型保護、Threat Intelligence に適用できます。適切な user_ip を設定することで、適応型保護が有効にされている際の誤検出が少なくなります。

user_ip フィールドを使用するということは、その IP を信頼していることを意味します。したがって、user_ip に基づく機能はアップストリームが信頼できるものと見なされている場合にのみ使用されるよう、注意を払う必要があります。たとえば、適応型保護の自動デプロイが、True-Client-IP を使用して DDoS モデルのベースラインを確立するように構成されている場合、サニタイズされていない True-Client-IP ヘッダーを送信する、CDN 以外のアップストリームといった信頼できない送信元が、自動デプロイルールの不正利用を目的としたヘッダー インジェクション攻撃を仕掛ける可能性があります。

GraphQL コンテンツ解析で API ワークロードを保護

これにより、ネイティブに GraphQL 形式のリクエストを使用しているお客様は、事前構成済みの WAF ルールによる誤検出を減らすことができると同時に、Cloud Armor によるフィールド内の OWASP 攻撃ベクトル検査を JSON と GraphQL のペイロードに拡張できます。

Cloud Armor のさらなる拡張

Cloud Armor については、2023 年の前半は慌ただしくてエキサイティングな数か月になりました。Google は今年の初め、事前構成済みの WAF ルールの高度な調整の一般提供を発表しました。これにより、WAF 調整の柔軟性の向上、誤検出の低減、適応型保護の自動デプロイが可能になりました。また、プレビュー版のリージョン HTTP(S) ロードバランサ対応 Cloud Armor を発表しました。これを使用すれば、リージョンにスコープを設定したセキュリティ ポリシーを作成して、指定した Cloud リージョンで Cloud Armor ルールを保存、評価、適用できるため、信頼性を高めることができます。

Cloud Armor 機能のリリースに関する最新情報を入手するには、このページをフィード リーダーに追加してください。