セキュリティ & アイデンティティ

Cloud Armor と reCAPTCHA Enterprise でアプリを bot から保護する

2021年10月12日

Google Cloud Japan Team

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

bot からの望ましくないウェブトラフィックが大幅に増加し、ビジネスおよび運用にとって大きなリスク要因となっています。bot 制御側の動機は、DDoS 攻撃によるビジネスの妨害からクレデンシャルスタッフィング、在庫アクセスの妨害、スクレイピング、カードの不正使用などの不正行為まで多岐にわたります。Google は AI / ML の両方の強みを活かして bot トラフィックに立ち向かい、さらにグローバル規模のネットワークによって最大規模の脅威でさえも吸収するため、これらのリスクの検出および軽減のサポートにおいて有利な立場にあります。

本日 Google は reCAPTCHA Enterprise を活用した Cloud Armor bot 管理の公開プレビュー版を発表いたします。この一連の新機能では、Google のウェブアプリと API の保護（WAAP）ソリューション（Apigee を含む）の一部として reCAPTCHA Enterprise と Cloud Armor の新しい緊密なインテグレーションが中心に据えられています。500 万を超えるサイトを保護することから得られる reCAPATCHA のインテリジェンスの力を Cloud Armor で直接活かして、bot やアプリケーションレイヤに潜む他の脅威からのリスクを包括的に管理できるようになりました。この保護機能は、Cloud Armor で簡単に構成できるポリシーを使ってシングルクリックで有効にできます。サーバーサイドでのアプリケーションへの変更は必要ありません。検出と適用はインラインまたは Google のネットワークのエッジで行われるため、GCP、オンプレミス、ハイブリッド、マルチクラウドデプロイのいずれで稼働するアプリケーションであっても、影響がおよぶ前に脅威を軽減できます。

Google Cloud Armor

Cloud Armor は DDoS 軽減サービスおよびウェブアプリケーションファイアウォール（WAF）であり、グローバル規模の Google のネットワークを活かして、望ましくないトラフィックをインフラストラクチャより上流でブロックします。Cloud Armor は、ボリュームベースやプロトコルベース（レイヤ 3/4）の DDoS 攻撃、アプリケーションレベルの DDoS 攻撃からのウェブサイトとアプリケーションの保護に役立ち、残りの OWASP トップ 10 のリスク緩和にも効果的です。Cloud Armor によって、カスタムのレイヤ 7 フィルタリングとレート制限ポリシーをエッジで適用して、ワークロードの可用性を確保し、セキュリティおよびコンプライアンス要件を遵守できます。

reCAPTCHA Enterprise

reCAPTCHA Enterprise は Google の不正行為検出サービスであり、500 万を超えるサイトから成る Google のネットワークのデータとインターネットを 10 年以上防御してきた経験が活かされています。reCAPTCHA Enterprise は、スクリプト、bot ソフトウェア、人間による不正行為および攻撃の対策として使用できます。ウェブページにインストールされていると、ログイン、購入、アカウント作成などのアクションが行われた時点で reCAPTCHA Enterprise は正規ユーザーがウェブページを使用して進行できるようスムーズなユーザーエクスペリエンスを提供する一方で、不正ユーザーと bot をブロックします。

Cloud Armor と reCAPTCHA Enterprise のインテグレーション

ユーザーは Cloud Armor セキュリティポリシーを構成して、reCAPTCHA が送信元を bot だと判断するリクエストをブロックできるようになりました。適用するにはいくつかの方法があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/cloud_armor_bot_management_1.max-1500x1500.jpg

クリックして拡大

1）reCAPTCHA Enterprise のフリクションレスアセスメントを適用する

reCAPTCHA Enterprise は、ウェブサイトでの操作（ログイン、サインアップ、ギフトカードの利用、チェックアウトなど）にリスクスコアを割り当てます。これらの操作に基づいて、0.0～1.0 のスコアを返します。0.0 は不正である可能性が高い操作、1.0 は正当である可能性が高い操作を表します。不正行為を減らすために、返されたスコアが 0.5 未満のログインに対してアクションを取り、これよりも高いスコアの場合は、ユーザーがスムーズにログインを続行できるよう選択することが可能です。

今回の新たなインテグレーションでは、クライアントサイドでのインストルメンテーションからの reCAPTCHA 評価に基づき、スコアに応じて Cloud Armor がリクエストのブロックやリダイレクトなどのアクションを行うこともできます。クライアントサイドでのインストルメンテーションは、reCAPATCHA の JavaScript ライブラリをブラウザアプリケーションにインストールするか、reCAPTCHA SDK をモバイルアプリケーションで使用することで有効にできます。ユーザーのリクエストがクライアントから送信されるときには、すでに reCAPTCHA による評価と bot スコアが添付されています。このスコア付けは、ユーザーのリクエストが Cloud Armor のセキュリティポリシーをとおして評価される際に、インラインで実施されます。重要な点は、これが reCAPTCHA サービスへの追加のリクエスト / レスポンスによるレイテンシなしで行われることです。

2）Cloud Armor で reCAPTCHA チャレンジを実施する

このシナリオでは、不審なユーザーが reCAPTCHA Enterprise チャレンジを解くまで Cloud Armor によってブロックされます。Cloud Armor セキュリティポリシールールに一致するリクエストすべてに対して reCAPTCHA チャレンジを提供するよう Cloud Armor を構成できます。そのために、reCAPTCHA Enterprise にリダイレクトして CAPTCHA を提供するアクション付きのルールを Google Cloud CLI で構成できます。

読み込んでいます...

上の例では、ログインページにアクセスを試みるすべてのリクエストを評価するように reCAPTCHA Enterprise をデプロイして、bot によるサービスへのログインを防いでいます。Cloud Armor がリクエストに対しまず reCAPTCHA Enterprise による bot リスク評価を要求することで、bot からの望ましくないトラフィックはエッジでブロックされます。

3）リデンプションフロー

最初の reCAPTCHA 評価では可能な限り正確を期していますが、reCAPTCHA スコアが定義済みのしきい値を下回った場合に、エンドユーザーに課題を解かせることでもう一度チャンスを与えることが望まれる場合もあります。今回のリリースの一環として、フリクションレスアセスメントと手動でのチャレンジの両方を組み合わせて「リデンプションフロー」と呼ばれるものを作ることができます。そのためには、低い reCAPTCHA トークンスコアを検出する Cloud Armor ルールの一致条件を構成し、reCAPTCHA チャレンジにリダイレクトするアクションを同じルールに構成できます。

読み込んでいます...

これらのシナリオの両方をリデンプションフローに組み合わせることで、不審なクライアントに bot ではないことを証明して利用する機会を与えることができます。

これらの bot 検出および軽減のユースケースでは、すべての決定が Google のネットワークのエッジで行われます。そのため、どちらもまとめて実施しているか、それとも個別に実施しているかを問わず、保護されたワークロードに影響を与えることなく bot 管理戦略をスケールアップできます。

bot 管理の追加機能

reCAPTCHA Enterprise とのインテグレーションの他にも、Cloud Armor には効果的な bot 管理戦略の実装をサポートする機能がさらに追加されました。

リダイレクトアクション – Cloud Armor ルールは現在、ユーザーが構成した URL にエンドクライアントをリダイレクトするリダイレクトアクションをサポートしています。そのようなルールに一致するリクエストの場合は、エンドクライアントに HTTP 302 による応答が返され、リクエストが代替の宛先に送られます。
ヘッダーの挿入 – 受信リクエストに条件付きでカスタムのヘッダーおよび値を挿入できることで、ユーザーが任意の Cloud Armor ルールの一致条件の基準に応じてリクエストをタグ付けできるようになりました。これにより、タグ付きリクエストをアプリケーションのダウンストリームで異なる扱いにできます。たとえば、不審なリクエストをハニーポットに転送することや、検出されたことを bot に知らせないようにするため、通知せずにトランザクションの処理を行わないこともできます。