クレデンシャル スタッフィング攻撃の阻止に向けた Google Cloud の取り組み

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

Google はこれまで 20 年以上、分散型サービス拒否（DDoS）攻撃、およびウェブ アプリケーションに対するきわめて高度な攻撃から自社のコアサービスを保護してきました。Cloud Armor を利用することで、お客様は、Google 検索、Gmail、YouTube などのグローバルに分散された Google プロダクトを保護してきた Google の幅広い経験を活用できます。

Google の調査によると、商用アンチ DDoS システムやウェブ アプリケーション ファイアウォール（WAF）のほとんどをバイパスしたりオーバーライドしたりする、進化した新手の手法が増えてきています。クレデンシャル スタッフィングは、こうした高度な手法の一つです。

クレデンシャル スタッフィングは、ウサギというよりは亀のようなその性質から、検出するのが最も困難な攻撃の部類に入ります。攻撃者はゆっくりながらも着実に、ユーザー名とパスワードのリストを搾取していきます。その仕組みは多くの場合、まずデータ侵害によってユーザー名とパスワードの不正利用を可能にした後、自動化された手法で、これらの漏洩した認証情報にウェブサーバーへの不正なアクセス権を与えるというものです。

パスワードを再利用する習慣を利用して盗まれる認証情報が増加の一途を辿る中、組織にとってこの種の「ブルートフォース」攻撃を見つけて法執行機関やテクノロジー プロバイダに報告するのは比較的簡単になっています。しかし、bot や不正侵入された IT デバイスがしばしば使用される現在のクレデンシャル スタッフィング攻撃は、数年前に展開された種類のブルートフォース攻撃よりもはるかに多くの成果を攻撃者にもたらす規模と自動化のレベルに達しています。

それでも、クラウド セキュリティの多層防御アプローチは、きわめて高度なクレデンシャル スタッフィング攻撃でさえも封じ込めるのに役立ちます。多層防御アプローチにおける手法の一つは、多要素認証（MFA）でユーザー アカウントを保護することです。ユーザー アカウントが侵害された場合、MFA が設ける追加の保護層があれば、パスワード漏洩しても不正なログインにつながらないように防止できます。あいにく、このような要件を課すことが常に適切であるとは限らず、常に可能であるとも限りません。MFA が失敗した場合や、MFA を実装するのが困難な場合には、ログイン フォームを公開するウェブサイトをクレデンシャル スタッフィング攻撃から保護するための追加の対策をデプロイできます。

以下に説明するように、Google Cloud ではクレデンシャル スタッフィング攻撃が成功する可能性を抑えるための取り組みとして、Google Cloud Armor や reCAPTCHA Enterprise などの Google ネイティブ テクノロジーを活用する階層型セキュリティ戦略を構築しています。

Google Cloud Armor の概要

Google Cloud またはオンプレミス デプロイを使用してさまざまな脅威を軽減しそれに対処しているお客様には、Google Cloud Armor が役立ちます。こうした攻撃には DDoS 攻撃や、クロスサイト スクリプティング（XSS）、SQL インジェクション（SQLI）などのアプリケーションへの攻撃があります。

Google Cloud Armor の DDoS 対策は常時稼働し、Google のグローバル ネットワークの容量に合わせてスケーリングします。ネットワーク攻撃を検知して軽減する能力があり、正しい形式のリクエストだけがロード バランシング プロキシを通過できます。

このプロダクトにはアンチ DDoS 機能だけでなく、一連の事前構成済みルールも備わっています。これらのルールを使用すれば、インターネットからの一般的な攻撃からウェブ アプリケーションとサービスを保護し、OWASP トップ 10 の脆弱性を軽減できます。

特にクレデンシャル スタッフィング攻撃からの保護という点で Cloud Armor にはとりわけ興味深い特長、つまりレートベースのルールを適用する機能があります。これによりお客様は、大量のリクエストをインスタンスに送り込んで正当なユーザーのアクセスをブロックするという攻撃からアプリケーションを保護できます。

Google Cloud Armor には、次の 2 種類のレートベースのルールがあります。

• スロットル: ユーザーが構成したしきい値で個々のクライアントをスロットル調整することにより、1 クライアントまたは全クライアントに対して最大リクエスト数の上限を適用できます。このルールでは、ルールの一致条件を満たす各クライアントからのトラフィックを制限するしきい値を適用します。しきい値は、指定された時間間隔における指定されたリクエスト数として構成されます。

• レートベースの禁止: クライアントごとにルールに一致するリクエストをレート制限できます。ユーザーが構成したしきい値を超えると、指定の期間にわたり、クライアントを一時的に禁止できます。

Google Cloud Armor のセキュリティ ポリシーを使用すると、着信トラフィックの送信元にできるだけ近い場所で、Google Cloud エッジにある外部 HTTP(S) ロードバランサへのアクセスを許可または拒否できます。これにより、望ましくないトラフィックによるリソース消費や Virtual Private Cloud（VPC）ネットワークへの侵入を防止します。

次の図は、外部 HTTP(S) ロードバランサ、Google ネットワーク、Google データセンターの場所を示しています。

多層防御アプローチによるクレデンシャル スタッフィングからの保護

単一の防御メカニズムだけに頼らず、階層型アプローチでセキュリティ対策を設計することは重要です。この戦略は「多層防御」と呼ばれ、これを適切に適用すれば、かなり高度なセキュリティが実現します。

以降のセクションでは、クレデンシャル スタッフィング攻撃から保護する目的で Google Cloud Armor を使って実装できる防御層について説明します。

防御層 1 - ジオブロッキングと IP ブロッキング

それほど高度ではないクレデンシャル スタッフィング攻撃の場合、限られた数の IP アドレスが使用される傾向があり、しばしばその国まで追跡できます。したがって、多層防御アプローチの出発点として、保護すべきウェブサイトを利用可能にする対象地域を特定できます。たとえば、あるウェブサイトが米国のユーザーのみによって使用されることが想定される場合、次のような式を使用して拒否ルールを設定できます。

同様に、アプリケーションを利用可能にすべきでない対象地域から発信されたトラフィックをブロックするための拒否ルールも適用できます。たとえば、米国とイタリアからのトラフィックをブロックするには、次の式を使用できます。

さらに、ルールごとに最大 10 個の IP アドレスまたは IP 範囲を設定した IP アドレスまたは CIDR の拒否リストを作成することで、進行中の攻撃に対応できます。以下に例を示します。

ジオブロッキングと IP ブロッキングは一般的な攻撃を阻止したり制限したりするには有効なメカニズムですが、攻撃者をブロックするにはさらに対策を講じることができます。高度なクレデンシャル スタッフィング攻撃ツールの大半は、プロキシを使用するように構成されたり、不正侵入した IoT デバイスを使って IP ベースのセキュリティ制御をバイパスするように構成されたりします。

防御層 2 - HTTP ヘッダー

防御構造を強化する別の方法は、アプリケーションに送信されてくるリクエストの HTTP ヘッダーを追加的に検査することです。その主な例の一つは user-agent です。user-agent は、ユーザー エクスペリエンスの向上などを目的に、どんなオペレーティング システムやブラウザが使われているかをアプリケーション側で特定できるようにするリクエスト ヘッダーです。攻撃者が、ユーザーにとって便利なアプリケーションにしようと意図することは滅多にありません。つまり攻撃のシナリオでは HTTP ヘッダーが完全に欠落するか、不適切な形式になります。以下に、user-agent の存在と正確性をチェックするルールの例を示します。

HTTP ヘッダーは攻撃対象領域をさらに減らすうえで役立つ可能性がありますが、限界もあります。HTTP ヘッダーを管理するのはクライアント側であることに変わりはありません。つまり、攻撃者がクライアントになりすます可能性があります。HTTP ヘッダーを構成することでセキュリティの効果を最大限にするには、アプリケーションが想定する HTTP ヘッダーについて詳しく理解し、Google Cloud Armor ルールを適切に構成する必要があります。

防御層 3 - レート制限

前に言及したように、クレデンシャル スタッフィング攻撃の性質上、攻撃を特定することは困難です。またクレデンシャル スタッフィング攻撃にはしばしば、漏洩したユーザー名 / パスワードのペアだけでなく、広く使われ脆弱であることがわかっているパスワード（「123456」など）をターゲットとするパスワード スプレー手法が伴います。このようなシナリオでさらに防御層を追加するには、レート制限が極めて有効です。

レート制限を扱う際に重要な点は、正当なユーザーに適用する標準レートを見極め、ブロックの基準とするリクエスト数のしきい値を把握することです。多くの場合、セキュリティとユーザー エクスペリエンスとの適切なバランスを見つけるのは簡単なことではありません。Google Cloud Armor には、正当なユーザーがブロックされないようにレート制限を微調整するうえで役立つプレビュー モードがあり、セキュリティ チームはレート制限を実際に適用することなくテストできます。ユーザーへの影響を最小限に抑えるには、この方法でレート制限をテストしてから、テスト結果を分析することを強くおすすめします。

予備的な分析が完了したら、Google Cloud Armor を使用してレート制限のルールを実装できます。以下のルールの例では、同じ IP アドレスから 1 分以内に 50 回の接続が行われた後、5 分間の禁止を適用します（ユーザーには 404 エラーを表示します）。

レート制限の基礎となるのは、クライアントの識別です。その際、IP アドレスが最初のオプションとなるでしょう。しかしそれだけでは不十分な可能性もあります。たとえば多くのインターネット サービス プロバイダは、必要なパブリック IP アドレス スペースを減らす目的でネットワーク アドレス変換手法を使用しています。もちろん、IP 競合が発生する確率は低いですが、レート制限のしきい値と戦略を設定する際にはそれを考慮に入れるべきです。Cloud Armor は、IP アドレス、HTTP ヘッダー、HTTP Cookie、XFF-IP の使用など、さまざまな方法で個々のクライアントを特定できます。

たとえばモバイルアプリの設計では、信頼できる方法で各クライアントを特定しやすくする目的で、一意の値を持つカスタム ヘッダーを使用することがよくあります。この場合、IP アドレスではなく、このカスタム ヘッダーに基づいてクライアント識別を行うのが適切でしょう。以下に、カスタム ヘッダー「client-random-id」に基づくルールの例を示します。

防御層 4 - reCAPTCHA Enterprise と Google Cloud Armor のインテグレーション

上述の手法と組み合わせた保護強化策となるのは、Google Cloud Armor と reCAPTCHA Enterprise テクノロジーとのネイティブ インテグレーションです。

上述のようなレート制限ルールを使用して、このインテグレーションを実装できます。404 エラーを返す代わりに、WAF レイヤにある reCAPTCHA Enterprise チャレンジに接続をリダイレクトするように構成できます。 この段階で、次のイベントが発生します。

1. Cloud Armor がレート制限基準を検証し、基準を超えている場合は、接続を reCAPTCHA Enterprise にリダイレクトします。

2. reCAPTCHA Enterprise がクライアント インタラクションを評価し、必要に応じて CAPTCHA チャレンジでユーザー確認を行います。

3. ユーザーが評価で不合格になると、エラー メッセージが返されます。評価に合格すると、reCAPTCHA が一時的な除外 Cookie を発行します。

4. Cloud Armor が除外 Cookie の有効性を検証し、サイトへのアクセス権を付与します。

次の図は、イベントのシーケンスを示しています。

まとめ

クレデンシャル スタッフィングは高度な攻撃であり、まず多要素認証メカニズムとユーザーの教育によって攻撃を軽減するのが適切です。多層防御モデルを適用するには、いくつかの技術的な対策を実装できます。Google Cloud Armor を使用して、次のようなセキュリティ メカニズムを実装してください。

• ジオブロッキング

• HTTP ヘッダーの検証

• レート制限

さらに、追加のセキュリティ層として次の対策を実装できます。

• reCAPTCHA Enterprise と Google Cloud Armor の組み合わせ

これらの対策により、クレデンシャル スタッフィング攻撃だけでなくブルート フォース アタックに対してもかなりの程度の保護を実現できます。また、bot 駆動型攻撃からの全般的な保護も提供します。

- Google Cloud、セキュリティおよびコンプライアンス担当 Davide Annovazzi