re:Invent 2023: AWS WAFによるボット制御とアカウント詐欺防止の実践的手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - How to control bots and help prevent account fraud using AWS WAF (NET321)
この動画では、AWS WAFを使ってボットをコントロールし、アカウント詐欺を防ぐ方法を学べます。AWS WAFのゼネラルマネージャーKris HatlelidとNitin Saxenaが、Common BotsとTargeted Botsの対策、アカウント乗っ取り防止、アカウント作成詐欺防止について詳しく解説します。実際のゲーム会社や旅行サイトでの導入事例も紹介され、AWS WAFの柔軟な設定によるコスト削減方法まで知ることができます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWS WAFを用いたボットコントロールと詐欺防止の概要
みなさん、こんにちは。re:Inventへようこそ。会場を見渡すと、多くの方がビルダーやセキュリティの専門家、あるいはボットに興味がある方、もしくはボットに関する問題を抱えていて、この講演から何か学べることを期待している方々だと思います。きっと役立つ情報をお伝えできると思います。今日のトピックは、AWS WAFを使ってボットをコントロールし、アカウント詐欺を防ぐ方法についてです。私はAWS WAFのゼネラルマネージャーのKris Hatlelidです。そして、こちらは私のパートナーのNitin Saxenaで、後ほど詳しい説明をしてくれます。
まず、今日お話しする内容について簡単に触れておきましょう。AWS WAFの機能について少しご紹介します。 特にボットと詐欺対策技術に焦点を当てます。これらの技術の仕組みや、ウェブサイトやアプリケーションでどのように活用できるかを詳しく説明します。最後に、この技術を使ってお客様を支援した実際のシナリオをいくつか紹介します。
AWS WAFの基本機能と動作原理
では、AWS WAFとは何でしょうか？ AWS WAFは、リクエストを評価する多層的なセキュリティ実行エンジンです。クロスサイトスクリプティングやSQLインジェクション、アプリケーションの脆弱性など、一般的なインターネットの脅威から保護します。ゼロデイ攻撃の緩和策としても機能します。特定の地域へのサービス提供を制限したい場合のジオブロッキングなどのポリシーを実装することもできます。また、トラフィックシェーピングを行い、DoS攻撃からの保護も提供します。 そしてもちろん、ボットコントロールと不正防止も行います。
これがWAFの通常のデータフローです。ユーザーや悪意のある攻撃者がリクエストを送信すると、AWS WAFがそのリクエストを評価します。評価には、Amazonが管理するルール（一般的な脅威から保護するために常に最新の状態に保たれています）か、お客様独自のルールが使用されます。これらは、Amazon CloudFront、Application Load Balancer、Amazon API Gateway、AWS AppSync、Amazon Cognitoなどのフロントドアサービスによって提供されます。この仕組みの素晴らしい点は、アプリケーションに非常に簡単に実装できることです。オンプレミスのアプリケーションであっても、CloudFrontディストリビューションを前面に配置し、WAFを設定するだけで、基本的なインターネットの脅威に対してかなり高いレベルの保護を得ることができます。
ボットの種類と影響：良性ボットから悪意のあるボットまで
このように、オンプレミスアプリケーションにも有効ですが、AWSワークロードにも非常に適しています。マネージドサービスなので、必要なリソースはすべて自動的にデプロイされます。ほとんど手間をかけずに利用できます。このセッションの焦点はボットに当てられます。 では、ボットとは何でしょうか？実は、皆さんの多くが何らかのボットを運用しているのではないでしょうか。私たちは、ヘルスモニタリングにボットを使用しています。サービスが正常に動作しているかを確認するために、多くのクエリを発行しています。基本的に、ボットはインターネット上で人間の介入なしに自動化されたタスクを実行するソフトウェアアプリケーションです。
インターネットの黎明期からボットは存在していました。最初のボットは、インターネットを探索し、人々が情報を見つけられるようにインデックス化することを目的としていました。また、サイトが稼働しているかを確認するためにも使用されていました。良性のボットは簡単に見分けることができます。なぜなら、それらは隠れようとせず、変更されないuser agentを持ち、robots.txtを尊重するからです。robots.txtについてご存じない方のために説明すると、これはボットに対して、どこを探索してよいか、どこを探索してはいけないか、許可される動作速度などを指示するものです。良性のボットは、サイトを稼働させ続けるように設計されており、運用の観点からもユーザーの観点からも、非常に優れた有用性を提供します。
一方、悪意のあるボットもインターネットの初期から存在していました。これらは、ビジネスに運用上のリスク、事業リスク、セキュリティリスク、財務リスクをもたらすため、絶対に制御する必要があります。最初のものは実際にはDenial of Service（DoS）ボットでした。これらは単にサイトに過負荷をかけ、崩壊させようとするものでした。その後、より高度なボットへと進化しました。セキュリティの脆弱性を見つけようとするボットや、アプリケーションからデータを取得しようとするボットなどです。
これらのボットは、データを公開したり、アグリゲーターとして機能したりすることで、競争上の不利益をもたらす可能性があります。時には、特定の目的のために使用されることもあり、あなたのビジネスを標的にする場合もあります。例えば、ここラスベガスでの例を挙げると、ベッティングオッズを探すためにサイトをクロールし、ベット・アービトラージを行うボットなどがあります。
ボットに関して、あまり考えられていないけれど重要な影響の1つは、すべてのウェブメトリクスを不明確にしてしまうことです。マーケティングキャンペーンが機能しているかどうかを確認しようとしているとき、より多くの人々をサイトに呼び込んでいるかどうか、ユーザーがサイト上でどのような経路をたどっているか、ワークフローを完了できているか、注文を完了できているか、探しているものをすぐに見つけられているかなどを知りたいものです。しかし、大量のボットトラフィックがあると、何が本物で何がそうでないかを見分けるのが非常に難しくなります。サイトの改善が困難になるのです。
評判に関するリスクなど、他にも多くのリスクがあります。ボットは偽のレビューを行い、SEOを操作し、アカウント詐欺を行い、実際にユーザーとしてログインして、レビューから個人データやあなたのデータの盗取まで、さまざまな行為を行います。最後に、これらは多大なコストをもたらします。驚くべきことの1つは、実際に調べてみるまで気づかないのですが、何らかの制御メカニズムを採用していないサイトでは、トラフィックの半分近くがボットトラフィックである可能性があることです。実際、一部の顧客では、一回限りのセールを行う場合、そのコストは何らかの行動を試みるボットからのトラフィックが95%にも達する可能性があります。したがって、ビジネスに重大な影響を与える可能性があるため、これを本当にコントロールする必要があるのです。
AWS WAFのボットコントロール機能の詳細
それでは、ボットコントロールについて詳しく説明するために、Nitinに引き継ぎたいと思います。Nitin、お願いします。
ありがとうございます、Kris。皆さん、こんにちは。re:Inventへようこそ。イントロダクションの後、AWS WAFがどのようにアプリケーションを保護し、ボットや不正行為に関連するリスクを防ぐかについて、皆さんが学びたがっていることはよくわかります。では、さっそく本題に入りましょう。 まず、AWS WAFのアーキテクチャの概要から始めます。リクエストがどのように来て、どのように処理されるかを見ていきます。
CloudFront、ALB、API Gatewayなどの保護されたサービスの背後にあるアプリケーションから始めます。通常のユーザーや悪意のある行為者が（この時点ではどちらかわかりません）、 AWS WAFが設定された保護されたサービスにリクエストを送信すると、 そのリクエストはAWS WAFのルールエンジンによって検査されます。Krisが先ほど言及したように、このエンジンには様々な種類のルールを配置できます。マネージドルール、カスタムルールなど、これからいくつか見ていきます。
保護されたリソースをボットや不正行為から保護するように設定している場合、リクエストはさらにAWS WAFルールエンジンの背後で動作しているボットと不正検出サービスによって検査されます。返される判断に応じて、リクエストが安全と見なされアプリケーションのオリジンに進むことが許可されるか、アプリケーションへの進行が停止されます。
ボットと不正行為の制御の設計を始めたとき、これが進化し続ける領域であることに気づきました。常に変化しています。ボット運営者は戦術を変え、検出を逃れようとしています。そこで、これらのサービスをAmazon Managed Ruleルールグループ、つまりAMRとして提供することにしました。このコンテキストでは、AMRという用語をよく使います。AMRはパッケージ化されたルールのセットです。つまり、事前にパッケージ化されたルールのセットを含むルールグループと考えてください。
これにより、ボットや不正行為者が進化しても、AMRに新しいルールを追加し続けることができます。Amazon Managed Rule グループを追加すると、何もしなくても新しいイノベーションを活用できます。その面での重労働は私たちが全て行います。
ターゲットを絞ったボット対策：チャレンジとトークンの仕組み
3つのAMRと4つのユースケースに注目していただきたいと思います。最初に話すAMRは、AWS Managed Rules bot controlです。このAMRは、一般的なボットと標的型ボットという2つのユースケースをサポートしています。一般的なボットは、検証可能な良いボットを管理するための方法です。これらを管理したい理由があります。検索エンジンボット、広告ボット、監視ボットなど、検証済みの良いボットかもしれませんが、ウェブサイトのインフラに与える影響をどの程度管理するかも考慮する必要があります。時には悪意のあるボットが良いボットを装い、同じユーザーエージェントを使用しようとすることもあります。私たちは、ボットが入ってきたときに、それが主張している通りのものであることを確認し、検証したいのです。
標的型ボットは、同じAMRの一部ですが、異なる検査レベルにあり、回避的で潜在的に悪意のあるボットの管理、制御、検出を目的としています。これらは、人間の行動を模倣し、検出を回避し、戦術を進化させ変更し、レート制限の下を潜り抜け、レート制限が何かを把握しようとするボットです。
2つ目に話すAMRは、AWS managed ATP rule setです。これはアカウント乗っ取り攻撃から保護することを目的としています。最後に話すのは、アカウント作成詐欺防止で、対応するAMRはAWS Managed Rules ACFP rule setで、偽のアカウント作成を防ぐように設計されています。これらのトピックについて見ていきましょう。
設定の基本から始めましょう。最初の概念は、ウェブアクセスコントロールリスト、または親しみを込めてweb ACLと呼んでいるものです。Web ACLは、すべてのリクエストとそれらをどのように検査し処理したいかについて、きめ細かな制御を提供します。まず、保護対象のリソースをweb ACLに追加することから始めます。新しいweb ACLを作成するか、既存のweb ACLを取り上げてそこにリソースを配置することができます。これにより、このリソースを保護したいことをweb ACLに伝えます。
ボットと不正制御を始めるには、ボットや不正対策のAMRの1つを追加します。AMRには2種類の設定があります。1つ目はルールグループ設定で、これはルールグループ内のすべてのルールに適用されます。2つ目の設定レベルは、各ルールに対して取りたいアクションです。各ルールにはアクションのセットが用意されており、AWSにリクエストを処理させたい方法に応じてそれらのアクションを変更できます。最後に、スコープダウンステートメントも追加できます。例えば、ボットと不正サービスにURLのサブセットのみを見てほしい場合、スコープダウンを作成して、そのAMRが特定のリクエストのみを見るようにできます。
同じWeb ACLで、カスタムルールを作成することもできます。ここで説明したい概念の1つはラベルです。ラベルはタグのようなものです。AWS WAFがリクエストを処理する際、リクエストストリームに文字列でタグ付けします。これをラベルと呼びます。ラベルを使用して、検出の微調整やリクエストの処理方法を細かく制御できます。また、パスやURIに基づく正規表現のマッチングなど、カスタムルールを追加することもできます。
レートベースのルールを追加したり、カスタムレスポンスを追加したりすることもできます。例えば、特定の状況で403を返したい場合、ルールを追加してそれを実行できます。では、一般的なボットについて見ていきましょう。
AWS WAFのBot Control AMRの設定と機能
先ほど述べたように、一般的なボットルールセットは良性ボットの管理のために設計されています。始めるには、Bot Control AMRを取り、Web ACLに追加します。ここで検査レベルが重要になり、検査レベルを「common」（一般）に設定します。そうすると、一般的なボットカテゴリー内のこれらすべてのルールが利用可能になります。
ビジネス要件が複雑であることは承知しています。特定の種類のボットを許可したり、禁止したり、レート制限をかけたりしたいかもしれません。例えば、検索エンジンボットは許可したいが、リンクチェッカーやモニタリング、スクレイピングボットは禁止したいかもしれません。そこで私たちは、ボットをカテゴリー別に分類しました。ここでAmazonの小売部門でのボット対策の豊富な経験が活かされています。ボットの追跡に関する多くのシグナルやインテリジェンスを取り入れ、それらをカテゴリー別にルールセットにまとめました。これらのルールは、カテゴリーの進化や新しい脅威の出現に応じて、時間とともに進化し変化しています。私たちが重要な作業を行っている間に、皆さんはこれらすべてを活用できるのです。
次に、ルールアクションについて説明します。 各ルールには5つのアクションの選択肢があります：Allow（許可）、Block（ブロック）、Count（カウント）、CAPTCHA、Challenge（チャレンジ）です。ここで設定の第二部分が関係してきます。例えば、広告カテゴリのルールがあり、デフォルトアクションがブロックになっているとします。しかし、これを許可に変更したい場合があります。ここで特に注目したいのがカウントモードです。許可は許可、ブロックはブロック、CAPTCHAはCAPTCHAを表示、チャレンジはサイレントチャレンジを行います。カウントモードは興味深い機能です。AWS WAFがルールをカウントモードに設定すると、リクエスト数をカウントするだけでなく、カウントしたリクエストにラベルを付けます。
これは、AWS WAFやbot controlを使い始めたばかりの時に非常に有用な機能です。どのようなトラフィックが来ているのか、どのトラフィックを許可したいのか、どのトラフィックをレート制限したいのかがわからない場合があります。そのため、bot controlを新しく始める際は、常にルールアクションをカウントに設定することをお勧めします。これにより、各カテゴリのボットのカウント数が得られ、さらにラベルも付けられます。これらを使って設定を微調整していくことができます。ラベルの使用例の一つがレート制限です。例えば、ウェブサイトで検索エンジンボットを許可したいが、 インフラコストの増加を抑えるために、特定のレート以上は許可したくないという場合があります。
そのためには、AMR（AWS Managed Rules）を使用し、検索エンジンカテゴリをカウントモードに設定します。これにより、カウント数と、アクセスしてくるボットの名前が得られます。そして、カスタムルールを作成できます。この例では、レートベースのルールを示しています。このレートベースのルールでは、制限値を1000に設定しています。そして、ラベル文字列として示されているラベルは、実際の検索エンジンボットの名前に置き換えられます。このような設定により、特定の検索エンジンボットが5分間に1000回までしかアクセスできないようになり、ボットの管理に役立ちます。
Common botsの機能をまとめると、コードや統合作業は不要で、ウェブサイト上の自己識別ボットを管理します。入ってくるリクエストは、長年にわたって生成されたシグナルやインテリジェンス、公開されているIP範囲やリバースDNS情報の参照など、複数の技術を使用して検証されます。検証できないボットはデフォルトでブロックされます。そして、誤検知率は0.01%未満です。
Common botsの使用を開始するのは非常に簡単です。保護したい新規または既存のWeb ACLにリソースを追加するだけです。すべての検証技術はルールグループにパッケージ化されており、ボットを検証するための追加設定は必要ありません。
検証できないものについては、例えばボットが入ってきて自分が特定のボットだと主張しても、そのシグネチャや他の属性を見たときに、そのボットのふりをしているだけで実際にはそのボットではないと判断した場合、デフォルトのアクションは検証できないものをすべてブロックすることです。他のお客様からは、このルールグループは誤検知が非常に少ないと聞いています。そのため、かなりの自信を持って使用することができます。
では、アーキテクチャ図に戻りましょう。少し簡略化したバージョンを使って、リクエストの流れを説明します。このプレゼンテーションを進めていく中で、このアーキテクチャに何度も立ち返ることになります。リクエストが入ってきます。ボットと不正防止のために設定されています。ルールエンジンによって検査され、ボットと不正サービスによって検査されます。シグネチャをチェックし、判断を下します。そして、ルールアクション、ラベル、そして他の要素を使って書いたカスタムスクリプトに基づいて、リクエストを許可したり、レート制限をかけたり、停止したりすることができます。
クライアントチャレンジとAWS WAFトークンの仕組み
次に、ターゲットを絞ったボットについて話しましょう。これらは検出を回避しようとするボットで、人間の行動を模倣しようとし、多くの場合、金銭的な動機に駆られています。では、これらのボットをどのように検出するのでしょうか？彼らは常に手法を変え、進化しています。シグネチャやIPアドレス、レートを見つけたとしても、時には数分のうちにそれらを回避してしまいます。そこで、ターゲットを絞ったボットについて考えるとき、どのような方法でこれらのボットを見つけ、検出するかについて、いくつかの決断を下す必要がありました。
では、私たちの戦略は何でしょうか？まず最初に行いたいのは、彼らのコストを上げることです。多くの場合、彼らには金銭的な動機があり、何かをスクレイピングしたり、チケットを買い占めたり、在庫を抑えたりして、金銭的な影響を与えています。そしてそれは、あなたに金銭的な影響を与え、他の誰かに金銭的な利益をもたらすかもしれません。そのために、私たちは彼らに作業証明を実行させます。作業証明とサイレントチャレンジについては、後ほど詳しく説明します。作業証明は、サーバーがクライアントに特定のスクリプトを実行して問題を解くよう指示する暗号技術です。そして、問題が解かれれば、これが有効なクライアントであることがわかります。
次に、アプリケーションに接続しているクライアントを識別したいと考えています。ここで、アプリケーションにリクエストがどのように入ってくるかを考えてみてください。多くのIPアドレスからリクエストが来ていますが、それらのIPアドレスの背後には多数のクライアントがいます。彼らはIPアドレスを共有している可能性があります。そのため、IPアドレスはボットトラフィックを見るには本当に悪い属性です。私たちがしたいのは、ユニークなクライアントを見ることです。そこで、作業証明が実行される際に2つのことを行います。クライアントのテレメトリを収集し、ユニークIDを生成します。このユニークIDを使用することで、特定のクライアントをグローバルにどこでも追跡することができます。収集されたテレメトリを使用して、どのようなクライアントが接続しているか、そしてアプリケーションに接続しているクライアントの状態がどのようなものかを判断します。
最後に、データサイエンスと機械学習に関する多くの内容があります。 ターゲットを絞ったボットを検出するための私たちの手法の多くは、統計分析と機械学習に深く根ざしています。 ターゲットを絞ったボットに対処する上で重要な概念としては、クライアントチャレンジとフィンガープリンティング、そしてAWS WAFトークンがあります。
ボットオペレーターにとって最も安価で高速な方法を考えてみましょう。 彼らはスクリプトを書き、それを何百、何千ものノードにコピーして攻撃を仕掛けます。スクリプトは安価で高速であり、インフラコストも低くて済みます。しかし、これらのリクエストを処理するあなたのアプリケーションやウェブサイトにとっては、コストがかなり高くなる可能性があります。
ここで、サイレントチャレンジの出番です。 クライアントがAWS WAFに接続し、この簡略化された図がその流れを示しています。 AWS WAFはクライアントをサイレントチャレンジにリダイレクトし、特定のプルーフオブワークを解くよう指示します。この計算によるプルーフオブワークでは、クライアントに対して、スクリプトが処理できない行動を要求します。その理由は2つあります：リダイレクトが必要であること、そして暗号チャレンジを解くためにJavaScriptが有効になっているか、iOSまたはAndroidアプリとの統合が必要だからです。
これにより、クライアントは単純なスクリプトから、シミュレートされた、または自動化されたブラウザへと移行せざるを得なくなります。ボットオペレーターにとって、スクリプトを実行するコストと、Node.js、Selenium、またはPuppeteerを実行するコストの差は、100倍から1000倍にもなる可能性があります。これは単純なスクリプトを排除するのに非常に効果的です。
クライアントが解答を提示すると、AWS WAFがそれを検証し、クライアントにトークンを提供します。このトークンは、その後のすべてのリクエストで送信されます。 トークンを使用することで、AWS WAFはチャレンジが解かれたかどうかを知ることができます。なぜなら、その情報がトークン内に埋め込まれているからです。
クライアント側でスクリプトを実行する一環として、私たちはさまざまな属性も収集しています。これには、ブラウザやクライアントからの情報が含まれます。例えば、GPU機能、canvasフィンガープリント、ブラウザプラグイン、画面サイズ、不整合、チャレンジが解決された時のタイムスタンプ、解決にかかった時間、マウスの動きやクリックなどの人間の操作などです。これらの属性を、私たちが「AWS WAFトークン」と呼ぶものにエンコードします。このトークンは、クッキーまたは特別なリクエストヘッダーとしてAWS WAFに送り返すことができます。これにより、ユニークなクライアントを識別できます。また、このトークンは暗号化され、改ざん防止機能を持っています。
AWS WAFの統合オプションとCAPTCHA機能
アプリケーション環境が複雑で、このようなソリューションを統合する方法に制約があることは認識しています。そのため、クライアント側でトークンを取得し、proof of workを実行するためのさまざまなオプションを用意しました。1つ目は、通常ブラウザのワークロードに適用されるチャレンジアクションです。クライアントが通常のブラウザであるWebワークロードの場合、チャレンジリダイレクトとproof of workは実際のユーザーにほとんど影響を与えませんが、ボット運用者のコストを大幅に増加させます。
また、POSTワークフローやAPIワークロードなど、リダイレクトが適さない状況のためのSDKオプションも用意しています。SDKは同じプロセスをエミュレートしますが、AWS WAFから直接トークンを取得します。さらに、CAPTCHAも2種類用意しています。Webリダイレクトと、シングルページアプリケーションやiframeのためのJavaScript APIを使用した埋め込みバージョンです。Targeted Botsと統合する際は、異なるワークロードやアプリケーションに最適なオプションを検討し、AWS WAFがトークンを取得し、クライアントを理解するのに役立ててください。
CAPTCHAはルールアクションによって呼び出すことができます。ルールとルールアクションのドロップダウンメニューで、CAPTCHAはオプションの1つです。任意のルールでCAPTCHAをオプションとして設定すると、CAPTCHAリダイレクトが呼び出されます。シングルページアプリケーションでは、JavaScript APIを使用してCAPTCHAを埋め込むことができます。CAPTCHAもproof of workとクライアント側のテレメトリー収集を実行します。サイレントチャレンジの裏で起こっていることすべてが、AWS WAF CAPTCHAでも同様に行われています。CAPTCHAを実行して取得したトークンの有効期間を設定することもできます。
Bot Control AMRとその2つの検査レベル（CommonとTargeted）について説明しました。Commonは良いボットと検証可能なボットのためのものです。Targetedの検査レベルは、回避型ボットからアプリケーションを保護するために選択するものです。機械学習を使用するオプションがあり、これはデフォルトで有効になっています。有効にすると、AWS WAFはウェブサイトのトラフィック統計を取得し、それらを機械学習モデルに通して、リクエストがボットから来ているのか人間から来ているのかの信頼度を検出します。ウェブサイトのトラフィック統計を機械学習に使用したくない場合は、このオプションをオフにすることもできますが、デフォルトでは有効になっています。
検査レベルを「targeted」に設定すると、targeted ボット用のすべてのルールが利用可能になります。 最初のルールは、チャレンジの合格または失敗です。このルールのデフォルトアクションはチャレンジです。有効にすると、この時点ではクライアントの正体が不明なため、すべての IP アドレスからいくつかのリクエストを許可します。クライアントが他の方法でトークンを取得していない場合、AWS WAF は強制的にトークン取得を行います。トークン取得に失敗すると、そのリクエストはその場でブロックされます。その IP アドレスからのその後のリクエストはすべてブロックされます。
次に、量的異常を検出します。これはレート制限のように機能しますが、より洗練されています。レート制限では、一定時間内に許可するリクエスト数を指定します。ボットコントロールでは、これを動的に行います。クライアントがアプリケーションにアクセスすると、IP アドレスとその IP アドレス背後にあるトークンを使用した個々のクライアントの両方を追跡できるため、通常のトラフィック範囲のベースラインを確立します。クライアントがこれらのしきい値を超えているのを確認すると、ブロックを開始します。これらのベースラインは、ウェブサイトのトラフィックパターンが変化するにつれて、1日、1週間、または1か月の異なる時間帯で変化する可能性があります。ベースラインは、クライアントベース全体で継続的に再計算されます。ボットオペレーターが DDoS 攻撃を開始したり、より高いレートでアクセスしたりしようとすると、いつでも量的セッションによってブロックされます。
キャンバスフィンガープリントやプラグインなどのシグナルを収集します。これに基づいて、トラフィックが自動化されたブラウザから来ているのか、あるいはその特定のリクエストの背後にあるブラウザに矛盾がないかを判断できます。そのような問題を検出した場合、ブロックするか、デフォルトでは CAPTCHA を発行することができます。トークンは暗号化されているため改ざんできませんが、クライアントの ID であるため再利用することはできます。ブラウザを開いてリクエストを行い、トークンを取得し、そのトークンを開発者コンソールからコピーして複数のスクリプトで使用することを妨げるものは何もありません。
誰かが開発者コンソールからトークンをコピーして複数のスクリプト（例えば100個のスクリプト）で使用すると、2つのことが起こる可能性があります。まず、同じトークンから多くのリクエストが来ているのを確認し始め、これが量的ルールをトリガーする可能性があります。次に、トークンに関連付けられた異なる IP アドレスを見る可能性があります。ここで、有効なシナリオを考えてみましょう。今、スマートフォンでウェブサイトにアクセスし、この会場を出て5Gネットワークに接続した場合、Wi-Fiではなく5Gネットワークに接続されることになります。IP アドレスが変更されています。私たちは一定数の IP アドレス変更を許可しますが、これらの変更が通常のシナリオよりも多いと判断した場合、ブロックすることができます。
IP アドレス変更のしきい値を決定する方法は、人々が IP アドレスを変更する頻度や、90パーセンタイルと99パーセンタイルの値など、通常のパターンに関する広範なデータ研究を行うことです。これらのしきい値を決定するには、多くのデータサイエンスが関与しています。最後に、トラフィックを機械学習にかけ、行動分析を使用します。
私たちは、協調的活動と呼ばれるルールを探します。協調的活動は、リクエストの頻度ではなく、パターンを調べます。通常のユーザーがサイトを操作する際は、あちこちをクリックしています。しかし、botが入ってくると、通常のユーザーとは異なる特定のパターンに従います。機械学習モデルは、通常のユーザーパターンとbotが作り出すパターンの違いを見分けます。ターゲットを絞ったbotでは、各ルールのアクションをカスタマイズすることもできます。
このリクエストフローは、先ほど見たのと同じ図ですが、いくつか新しいことを紹介します。まず、リクエストが来ると、サイレントチャレンジまたはCAPTCHAにリダイレクトします。これが解決されると、リクエストが戻ってきて、bot/不正検出サービスによって検査されます。多くのルールが実行され、結果が出力されます。アクションとラベルに基づいて、リクエストをレート制限するか、ブロックするか、許可するかを決定できます。
アカウント乗っ取り防止とアカウント作成詐欺防止の機能
では、AWS WAF fraud controlに移りましょう。最初に話すのはアカウント乗っ取り防止についてです。私たちの顧客は、総当たり攻撃や認証情報スタッフィング攻撃の大半がbotnetを介して行われると言っています。そのため、アカウント乗っ取り防止とbot制御には大きな重複があります。このルールグループは、ログインページでのbot活動を防ぎ、認証情報スタッフィングや総当たり攻撃などから保護するように設計されています。
アカウント乗っ取り防止（私たちはATPと呼んでいます）には2つの部分があります。ルールグループの設定では、リクエストとレスポンスの両方を見ます。リクエスト検査では、ログインフィールドがどこにあり、どのように配置されているかを教えてもらいます。レスポンス検査では、有効なレスポンスと無効なレスポンスがどのように見えるかを教えてもらいます。これはステータスコード、ヘッダー、またはボディコンテンツかもしれません。リクエストが来ると、AWS WAFは入ってくるリクエストと、オリジンから出ていくレスポンスの両方を見て、これらが通常のユーザーなのか、それとも総当たりや認証情報スタッフィング攻撃のような悪意のあることを試みている人なのかを判断します。
ユーザー名とパスワードを検査する必要があるため、これらのルールはAWS WAFが認証情報を検査できる場合にのみ利用可能です。Amazon Cognitoや他のIDプロバイダーを使用している場合、AWS WAFはユーザーIDとパスワードを見ることができないため、アカウント乗っ取り防止は使用できません。ここでさらに2つ指摘したいことがあります。1つは盗まれた認証情報についてです。私たちは盗まれた認証情報の膨大なデータベースを維持しており、常に最新の状態に保っています。リクエストが盗まれた認証情報と一致した場合、自動的にフラグが立てられてブロックされます。
2つ目に注目したいのは、レスポンス検査です。レスポンス検査機能は一種のセーフガードとして考えてください。例えば、クライアントがアクセスしてきた際、盗まれた認証情報を使用していなくても、複数回失敗するレスポンスが返ってきたとします。これは、誰かがユーザーIDとパスワードの組み合わせを変えながら試行していることを示しています。一定回数の失敗リクエストの後、我々はその特定のIPアドレスを一定期間ブロックし、攻撃を大幅に遅らせます。攻撃がそこまで遅くなると、credential stuffingはもはや有効な手法ではなくなります。
アカウント作成詐欺防止は、アカウント乗っ取り防止と非常によく似た仕組みで動作しますが、これはログインページではなく、サインアップページでのボット活動を防ぐために設計されています。ここでの目的は、偽アカウントの作成を防ぐことです。ここでも、リクエスト検査とレスポンス検査があります。リクエスト検査では、フォームの解析方法を指定し、レスポンス検査では、アカウント作成の成功または失敗の試行をどのように解析するかを指定します。
アカウント作成詐欺防止を有効にすると、多くのルールが利用可能になります。これまで見てきたように、各ルールのアクションは設定可能です。ここで3つの点に注目したいと思います。まず、これらのルールは標準的なページでのボット活動を自動的にチャレンジするように設計されています。次に、リクエストに関連するIPアドレスやメールアドレスの繰り返しなど、繰り返しスコアを使用します。リスクスコアに基づいて、特定のリクエストからのアカウント作成をブロックすることができます。3つ目は、行動パターンを見ています。同じ電話番号から大量のアカウントが作成されるのはその一例です。合理的な制限があり、その制限を超えると、そのようなクライアントのブロックを開始します。ここではトークンを取得しているので、IPアドレスだけでなく、トークンを持つ個々のクライアントに基づいてブロックすることもできます。最後に、盗まれた認証情報を使ってアカウントを作成しようとする人がいれば、アプリケーションやウェブサイト上のユーザーのセキュリティ態勢を改善することで、それもブロックすることができます。
こちらは、ATP（Account Takeover Prevention）とアカウント作成詐欺防止のリクエストフローです。ターゲットを絞ったボットと非常によく似ています。ここでこの図を示す理由、そしてなぜこれが重要かというと、bot controlと詐欺防止の設計を始めた際、これらの攻撃者が常に進化していることに気づいたからです。そこで、私たちは2つのことを行いました。まず、設定をmanaged rule groupsにパッケージ化し、そのルールグループにさらに多くのルールを追加できるようにしました。次に、バックエンドに非常に補完的なアーキテクチャを構築しました。これは拡張可能で、新しい種類のサービスや新しいルールを追加すると、自動的にAMRsの一部として利用可能になります。では、Krisに戻して、いくつかの実際のシナリオについて話をしてもらいましょう。ありがとうございました。
実例：オンラインゲーム会社とDDoS攻撃対策
ありがとう、Nitin。ここにゲーマーはいますか？ 私です。私はゲームが好きで、ゲームをプレイできないようにする人が嫌いです。この特定の事例では、あるオンラインゲーム会社が課題を抱えていました。彼らはdenial of service攻撃を受けていたのです。そのdenial of service攻撃は、複雑さの面では特に驚くべきものではありませんでしたが、インフラに影響を与え、ユーザーがログインできなくなり、彼らに損失を与えていました。そこで私たちは彼らと協力しました。彼らのシナリオの素晴らしい点は、トラフィックからかなり迅速に識別できたことでした。
さて、このようなDDoSイベントが発生しており、それらはおそらく大部分が複雑ではないスクリプトから生成されています。そこで私たちがすることは、bot controlを有効にし、challenge actionを有効にすることです。Nitinが先ほど話していたことを思い出してください。つまり、顧客がサイト上でアクションを実行している場合、またはDDoSエージェントがサイト上でアクションを実行している場合、私たちはチャレンジを送り返すということです。
不審なアクティビティを検知した際、悪意のある攻撃者はスクリプトを実行し、作業証明を提示しなければ先に進めないようにしました。そうでない場合は、それらのアクションをブロックしました。上のグラフを見ると、スクリプトの実行がいかに高かったかがわかります。しかし、下のグラフを見ると、ウェブサイトのトラフィック統計がほとんど動いていないことに気づくでしょう。これは、このチャレンジがDDoS攻撃を効果的に防ぎ、ゲーム会社の運営を維持したことを示しています。
もう一つの素晴らしい事例は、旅行ウェブサイトに関するものです。彼らはいくつかの課題に直面していました。まず、多数のウェブサイトを運営しており、広範なフットプリントを持っていたため、InfoSecチームが保護するのが難しい状況でした。さらに、単にウェブサイトを混乱させたり過負荷にしたりするランダムな試みだけでなく、ボットによる標的型攻撃にも対処していました。最初のステップは、ウェブサイトをより少数のWeb ACLに統合することでした。これには、CloudFrontを管理された入り口として使用し、セキュリティの管理を容易にすることが含まれていました。
2番目のステップは、余裕を持たせることでした。何か悪いことが起こってサイトが機能していない場合、長期的な解決策を見つける時間が必要です。最も簡単なアプローチは、一般的なボットとチャレンジアクションを有効にすることでした。これにより、彼らのシナリオではトラフィックが約50%即座に減少し、インフラストラクチャに余裕ができました。しかし、余裕ができるにつれて、ボットは進化し始めました。攻撃はこの会社を標的とし、金銭的な動機があったため、ボットは単純なスクリプトの代わりに自動化されたブラウザを使い始めました。
トラフィック分析を行った後、私たちは標的型ボットルールといくつかのカスタムルールの実装を提案しました。これにより、トラフィックが再び増加し始めた後でも、さらに19%のトラフィックが削減されました。彼らにとっては比較的簡単に実装できる解決策であり、運用の健全性とトラフィックの削減の両面で大きな効果がありました。
実例：eコマースアプリのアカウント乗っ取り対策
最後の例は、モバイルのeコマースアプリに関するものです。彼らはアカウントの乗っ取りを行う悪意のあるボットからの脅威に直面していました。これらのボットは人間を装い、偽のレビューを投稿し、ユーザー情報を抽出しようとしていました。この会社は独自のカスタムビルドソリューションを持っていました。これは長年established企業では一般的なことです。しかし、これらの脅威との戦いは猫とネズミのゲームであり、継続的な投資とメンテナンスが必要であることは明らかです。AWS WAFの利点の一つは、私たちがこの負担を引き受けることです。
私たちは彼らのためにアカウント乗っ取り保護を実装しました。 効果的でしたが、彼らは膨大な数のリクエストを受け取っていました - わずか5分間で約2800万件です。攻撃の緩和には成功しましたが、多数のチャレンジを発行し、多くの応答を処理する必要があり、予想以上のコストがかかりました。これに対処するため、私たちは彼らと協力し、Solutions Architectureチームに異なるソリューションの開発を依頼しました。
AWS WAFやAWSサービス全般の強みの1つは、その組み合わせ可能性です。ソリューションをカスタマイズする方法は多数あります。例えば、Amazon Managed Rules (AMRs)を使用して、一般的なボットや標的型ボットを単純にブロックすることができ、ほとんどの作業を自動的に処理してくれます。この場合、彼らはcount modeでルールを実行する最適化されたソリューションを開発しました。
count modeで増加が観察された場合、アカウント乗っ取りトラフィックの急増を示すため、block modeに切り替えました。アカウント乗っ取りトラフィックの急増を確認したので、block modeに切り替え、さらにソースIPをTTL付きのdeny listに追加しました。これにより、IPを永久にブロックするのではなく、時間とともに期限切れになるようにしました。結果として、 レイテンシーを犠牲にする代わりに、同様のレベルの保護を達成しつつ、コストを約99%削減することができました。ここで素晴らしいのは、私たちが組み合わせ可能なシステムを持っていることです。独自のルールを作成し、ログを活用して特定のユーザーシナリオに対応できます。これにより柔軟性が得られ、常にコスト削減を試みることができます。また、この特定のケースでは、その特定のアクションの価格を引き下げ、階層化しました。なぜなら、私たちは物事を作る過程で学んでいくからです。
AWS WAF活用のベストプラクティスとまとめ
では、まとめましょう。 トークンを取得するための最適なオプションを決定してください。Nitinが言っていたように、ウェブブラウザで作業している場合は、リダイレクトのノーコードオプションが素晴らしいでしょう。モバイルアプリを使用している場合は、SDKを使用したいでしょう。コスト管理にはスコープダウンステートメントを使用してください。順番に適用することが重要で、まず安価なルールを実行し、その後により高価なルールを適用します。懸念するエンドポイントの範囲を絞り込んでください。問題を引き起こす可能性が低いと思われるものについては、あまり心配する必要はありません。
再度、ルール評価を考慮してください。おそらく最も安価なものから最も高価なものへと順番に適用します。常にcount modeをオンにしておいてください。これにはコストがかからず、DDoSの観点からベースラインを得られるだけでなく、AWS WAFがどのように機能しているかについても多くの情報を知ることができます。それでは、まとめに移りましょう。 ここで紹介した使いやすいソリューションは、今日すぐに実装して役立つはずです。DDoS攻撃やその他の攻撃に対処する際は、常に余裕を持つようにしてください。まず緩和に集中し、その後修正に集中します。最後に、私たちに助けを求めることを恐れないでください。私たちはこの仕事を愛しており、お客様と協力してさらに良いものにすることを楽しんでいます。
関連するセッションがいくつかありますので、QRコードをご利用ください。これらのセッションを通じて、AWS WAFについてさらに詳しく学ぶことができます。ご来場いただき、誠にありがとうございました。アンケートへのご協力もよろしくお願いいたします。重ねて御礼申し上げます。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion