re:Invent 2024: AWS WAFチームが語るBot対策とDeception技術
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - I didn’t know AWS WAF did this (CDN303)
この動画では、AWS WAFのSenior Product ManagerとSolutions Architect Specialistが、進化するWeb脅威とその対策について解説しています。全トラフィックの47%がBotトラフィックとなっている現状や、AI Botの出現による攻撃の高度化について触れた後、AWS Bot Control、ATP（Account Takeover Prevention）、ACFP（Account Creation Fraud Prevention）などのAWS WAFの主要機能を詳しく説明しています。特に注目すべきは、Deceptionと呼ばれる手法で、Botをブロックするのではなく、検知されていることに気付かせないよう巧妙に対処する方法が紹介されています。また、Rate-based ruleを活用した段階的な防御戦略など、実践的なBot対策の具体例も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS WAFセッションの概要と新たなWeb脅威
これは300レベルのセッションですので、WAFについてある程度の知識があることを前提としています。ただし、もしそうでない場合でも、WAFの機能について簡単な基礎知識から説明させていただきます。私はKaustubh Phatakと申します。AWS WAFのSenior Product Managerとして、Bot対策と不正防止のソリューションを担当しています。そして私はTzoori Tamamと申します。AWS WAFを含むEdgeサービスのSolutions Architect Specialistを務めています。本日はWAFについて詳しくお話しさせていただきますので、よろしくお願いいたします。
まず、本セッションの内容についてご説明させていただきます。はじめに、最近見られる新たなWebの脅威についてお話しします。特にBot対策とBot関連の脅威、そしてAI Botの出現に伴う進化についてご説明します。その後、AWS Bot ControlとAWS WAFに焦点を当て、WAFの機能について詳しく見ていきます。設定方法についても触れた後、実際の活用事例についてご紹介させていただきます。
AI Botの台頭とBot対策の重要性
それでは、Botのトレンドについてお話ししましょう。自動化されたトラフィックについて、現在では全トラフィックの47%がBotトラフィックであることが分かっています。 この1年半で大きく変化したのは、AI Botの出現に伴う攻撃の進化と高度化です。AI BotやAIツールの登場により、攻撃者が攻撃を実行するためのハードルが大幅に下がりました。さらに、これらのBotクローラー、スクレイパー、スキャルパーの目的も変化してきており、もはやPII（個人識別情報）の取得だけでなく、モデルの学習用データとしてあらゆる情報をスクレイピングすることを目的としています。
Botについてご存じない方のために説明しますと、Botとは特定の作業を実行するように設計された自動化ソフトウェアプログラムで、良いものも悪いものも存在します。検索エンジン最適化のBot、Webサイトのパフォーマンスやアップタイムを改善するBotなどは良いBotの例です。一方、悪いBotはオンラインシステムの脆弱性を悪用します。最近では、スキャルピング活動の増加、スクレイピング活動の増加、アカウントの乗っ取り活動の増加なども見られます。 私たちが目指すのは、良いBotの利点を活かしながら、Botによるアクセスのデメリットを軽減するという、そのバランスを取ることです。
AIの登場により、状況は大きく変化しています。もはや単なるBot活動や、良いBotと悪いBotの区別だけの問題ではありません。この1年半で新たなリスクが出現しています。例えば、Residential ProxyやMobile Proxyを使用したDDoS攻撃を容易に実行できる自動化ソフトウェアによるネットワーク攻撃や、攻撃者が電話番号を回転させて使用するSMS詐欺の増加などが挙げられます。本物らしいメールを作成できるようになり、ソーシャルエンジニアリングも容易になりました。プロパガンダキャンペーンの作成も簡単になっています。AI特有の、あるいはLLMアプリケーションに関しては、Prompt Injection、Hallucination、データポイズニングといった新たな脅威も出現しています。
AWSで私たちが観察している状況についてお話ししましょう。私たちは、GPT、ByteDanceなど、さまざまなAI Botが、Webサイト全体にわたって活動しているのを確認しています。また、これらのBotがWebサイトの様々なURLと相互作用する頻度も増加しています。第3四半期から第4四半期にかけて、Bot活動は月間で155%も増加しています。では、これらのBotが何を狙っているのかについて見ていきましょう。まず、ニュース記事などの出版コンテンツが標的となっています。
このような情報は、顧客があなたのWebサイトを訪れる必要がないようにトレーニングデータとして使用され、結果として広告収入の損失につながります。また、価格、商品説明、レビュー、チケットやスニーカーなどの転売に関する詳細情報を得るために、商品ページもスクレイピングの対象となっています。最近では、ユーザープロファイルのスクレイピングも確認されています。AI Botを開発している企業が、チャットボットを利用する個人のペルソナを作成するために、ユーザープロファイルから人口統計学的情報を収集し、より効果的なターゲティングを行おうとしているのです。
スクレイピングの対象となるパスに違いはありません。ドキュメント、画像、CSSファイルなど、見つけられるものは何でもスクレイピングしています。従来、私たちはrobots.txtを使用してBotが何をスクレイピングできるか、できないかを指定してきました。しかし、現在ではほとんどのBotがrobots.txtに従っていないことがわかっています。これらのBotはrobots.txtを参照せず、可能な限り全てをスクレイピングしています。これにより状況は大きく変化しています。robots.txtだけに頼ったり、単純にこれらのBotをブロックしたりすることはできません。なぜなら、AI Botに情報が提供されることで検索エンジン最適化の状況が変化するため、AI Botにコンテンツをスクレイピングさせたい場合もあるからです。
AWS WAFの機能と実装方法
特定の情報へのアクセスは許可したいと考えており、そこで私たちは将来の方向性として、AI Botが何をスクレイピングできるか、どの頻度で、どのURLを、1日または1週間のどの時間帯に行えるかを指定するスクレイピング契約の開発を検討しています。そのためには可視性が必要不可欠です。可視性がなければ、非常に困難な課題となります。これが、何がスクレイピングされているのか、どのような頻度で、1日または1週間のどの時間帯に行われているのかを理解する方法について、お客様から寄せられている新たな要件です。
現在、Bot制御とBot対策はさらに重要性を増しています。なぜなら、もしあなたのワークロードで生成AIアプリケーションを使用している場合、Bot制御に使用する1ドルで277ドルを節約できるからです。これは、従来型の計算処理と生成AI計算処理のコスト差によるものです。高負荷な計算処理を行うアプリケーションに到達する前に、エッジで不正なトラフィックを排除できれば、コスト削減の観点で大きな効果が得られます。また、脅威やサービス低下に対する効果的な保護も実現できます。先ほど見たように、Botはrobots.txtやWebサイトのどの部分がスクレイピング対象かを気にしないため、データ窃取やデータ整合性の問題が発生し始めています。
Bot対策が必要となった今、新たな脅威に対応するために進化が求められています。まずはAWS WAFについて簡単に説明させていただき、そこから話を進めていきたいと思います。ひとつ注意点なのですが、WAFの話になると私は非常に興奮してしまい、普段以上に早口になってしまうんです。なるべく普通のスピードで話すようにしますが、だんだん早くなってしまうと思います。これからお話しするのは、WAFの機能についてあまり詳しくない方や復習が必要な方向けの内容で、皆さんと同じ出発点に立つためのものです。 AWS WAFは、HTTPトラフィックのみを扱うWeb Application Firewallです。 非常に柔軟な方法でルールを作成したり、マネージドルールを使用したりすることができます。私の考えでは、WAFは中身を気にせずにオンにするだけで良いことをしてくれるブラックボックスとして使うこともできますし、カスタムルールを書いて完全にカスタマイズすることもできます。実際のお客様の利用状況を見ると、AWS独自のマネージドルールやパートナーのマネージドルールと、かなりの量のカスタマイズを組み合わせて使用されているケースが多いですね。
これらのカスタムルールは、多くの場合、特定のビジネスロジックのリスクに対応するものです。このプレゼンテーションを通じて、カスタムルールについて詳しく説明していきます。
もうひとつの重要な機能として、 インテリジェントな脅威保護があります。これにより、アプリケーションとやり取りしている相手が誰なのかを理解することができます。単なるシグネチャマッチングやリクエストのカウントよりも高度な機能です。incoming botを識別し、人間とbot（非人間）のアクターを区別し、ログインやサインアッププロセスに関連する不正に特化して対処することができます。これから様々なユースケースを見ていく中で、これらの高度なルールを設定で使用していく様子をご覧いただけます。
Web ACLとルールの詳細設定
また、可視性も提供しています。 私がいつも言っているのですが、たとえAWS WAFを管理する余裕がなかったり、強制やブロッキングを管理するマンパワーがなかったりしても、WAFをオンにするだけで価値があります。なぜなら、どのようなリクエストがどこからどのような頻度で来ているのかについて、広範な可視性を提供してくれるからです。Webロギングを有効にするだけでも、それ自体が大きな価値を持っています。また、ほとんどのAWSサービスと同様に、Amazon CloudWatchにメトリクスを送信し、WAFルールがどれだけヒットしたか、ブロックされた数、許可された数、Web ACL全体での様々な動作などの高レベルな集計を確認することができます。
Web ACLについて説明しますと、 これは7つのリバースプロキシサービスのいずれかに適用する基本的な構成要素です。このセッションでは「Web ACL」と「Webポリシー」という言葉を使いますが、これらは同じものを指し、正式名称はWeb ACLです。Web ACLを作成し、これら7つのリバースプロキシサービスのいずれかにアタッチします。一般的に、お客様はAWS WAFをAmazon CloudFrontと組み合わせて使用することが多いです。CloudFrontは当社のCDNサービスで、WAFがなくても独自の保護機能を多く備えています。ほとんどのWebアプリケーション、ALB、API Gatewayなどに適していますが、上位3つが最もよく使用されています。
Web ACLに設定するルールには、Managedルールと、Unmanaged（カスタマー）ルールの2種類があり、すべてのルールは順番に処理されます。各ルールには、トラフィックを許可またはブロックする特定のアクションが関連付けられています。特定のリクエストがルールに一致すると判断された場合、トラフィックの処理を停止し、それ以降のルールは処理されません。つまり、ルールの順序が重要になります。これについては、プレゼンテーションを進めながら具体例を見ていきましょう。
許可とブロック以外にも、各ルールには3つのアクションが可能です。Challengeは、JavaScriptが実行可能なブラウザであることを確認するための中間的なJavaScriptを送信する便利なツールで、どのルールにも適用できます。セキュリティを強化するために、CAPTCHAアクションを有効にすることもできます。これは最初にJavaScriptをトリガーし、その後ユーザーにCAPTCHAを解かせることで、人間による操作を確認します。最後のアクションはCountで、リクエストの処理は停止しませんが、特定のルールに一致したことを示すフラグを立て、ログに記録します。また、特定のリクエストにラベルを付けることもでき、Web ACLを通過させながら、他のルールが処理できるように情報を付加することができます。これについては後ほど説明します。
まとめると、特定のルールに焦点を当てた場合、ルールはManagedかCustomのいずれかになります。Customルールを選択する場合は、通常のルール（一致した場合にアクションを実行する）として設定する必要があります。
ルールのタイプについてさらに詳しく説明すると、通常のルールは一致した場合にアクションを実行しますが、Rate-basedルールは一致した後、一致したリクエストの数をカウントし始め、特定のしきい値を超えた場合にのみアクションを適用します。つまり、Rate-basedルールは基本的に通常のルールと同じですが、設定された数のリクエストが通過した後でのみアクションを開始します。 そして、特定のルールで何を探すのかを決定する一致基準を設定する必要があります。これは特定のUser-Agentヘッダーや、HTTPリクエストのあらゆる部分が対象となります。
アクションとしては、Allow、Block、Count、Capture、Challengeから選択できます。 リクエストやレスポンスをカスタマイズすることもできます。これは非常に強力なツールで、特に後ほど説明するDeceptionの文脈で重要になります。入力されるリクエストを修正することができます。許可する場合は、基盤となるアプリケーションが処理するためのヘッダーを追加して情報を豊かにすることができ、本質的にはアプリケーションに対するダウンストリームのシグナリングメカニズムとして使用できます。リクエストをブロックする場合は、送信するレスポンスをカスタマイズできます。通常は403 Forbiddenですが、任意のエラーコードやコンテンツにカスタマイズできます。200 OKや429 Too Many Requestsを送信することもできます。アプリケーションに送信しないことを選択した場合、レスポンスは自由にカスタマイズできます。
AWS WAFの高度な機能とBot対策戦略
最後に、発行するラベルを選択します。ラベルとは、すべてのリクエストに付加される metadata のことです。マネージドルールはデフォルトでラベルを発行します。つまり、リクエストがマッチした場合、それをブロックするかどうかに関係なく、SQL インジェクションリクエストや IP レピュテーションリクエスト、その他提供しているマネージドルールのすべてにラベルが付加されます。さらに重要なのは、カスタムルールを通じて独自のラベルを作成できることです。信頼済み IP リストからのリクエストや特定の国からのリクエストといったシンプルなものから、JSON ボディの要素が特定の正規表現にマッチするといった細かいものまで、あるいはそれらを組み合わせたものまで、どのようなリクエストマッチング条件でも設定できます。
カスタムルールで設定できるマッチング条件の1つに「has label」（ラベルを持つ）という条件があります。あるルールでラベルを発行してリクエストをマークし、Web ACL 内の後続のルールがそれらの発行されたラベルを読み取って処理を行うことができます。これにより、様々なルールを通じて特定のリクエストに関する複数のデータポイントを収集し、そのリクエストについて得られたすべての情報に基づいて判断を下すことができます。この機能は、これから説明する様々なユースケースで非常に役立ちます。
Rate-based ルールについて簡単に説明させていただきます。先ほど述べたように、これは特定のマッチング条件に該当するリクエスト数をカウントするルールです。しきい値は10リクエストから20億リクエストまで設定でき、時間枠は1分から10分まで設定できます。これらは数ヶ月前から利用可能になった新しいしきい値です。例えば、しきい値を100万リクエストに設定し、それが30秒以内に発生した場合、時間枠全体を待たずに30秒後にアクションを実行します。リクエストの集計は複数の条件に基づいて行うことができ、IP ベースの集計が最も straightforward なアプローチです。すべての Web ACL には少なくとも1つの IP ベースの Rate ルールを有効にすべきです。非常に効果的だからです。また、メソッド、ラベル、ラベル名前空間に基づく非 IP キーを使用することもできます。さらに、単純にリクエストの総数をカウントするスコープダウンのない Rate-limiting ルールを設定することもできます。各 Web ACL には最大10個の Rate-based ルールを設定できます。
少なくとも3〜4個の Rate-based ルールを設定することを強くお勧めします。非常に効果的だからです。詳しく知りたい方のために、2つの優れたブログがあります。1つは基本的な Rate limiting ルールについてのもので、Web ACL に設定できる最も重要な3つの Rate limiting ルールについて説明しています。これらはすべて IP ベースの Rate limiting ルールです。もう1つは、より高度な Rate limiting ルールについてのもので、他にどのような条件で Rate limiting を設定できるかを説明しています。週末の帰りの飛行機での読み物として非常に有用です。
マネージドルールについて触れましたが、AWS が提供する3つのマネージドルールについて詳しく説明したいと思います。これらは、これから説明する様々なユースケースで重要になってきます。1つ目は Bot Control で、Web 上で有効にできる高度な脅威対策ルールの1つです。Common モードでは、単純な一般的なボットを検出します。これらは通常、User Agent を通じて自己報告するボットです。Social media ボット、SEO エンジン、一般的なボットなど、正規のボットや望ましいボットを検証するために使用します。例えば、Google ボットのような User Agent で報告されるトラフィックが、実際に Google ボットが通常使用するアドレス範囲から来ているかどうかを検証します。
Bot Controlが重要なのは、現在では全てにラベル付けを行っているからです。Rate limiting rulesは、検証済みのBotには適用されないか、あるいはビジネスのユースケースによっては通常の10倍厳しく適用されることもあります。Bot Controlから発行される全てのラベル（カテゴリー、検証済みBotかどうか、Botの名前など）は、何も強制的な対策を講じない場合でも、トラフィックのどれだけがBotによるものかを理解する上で非常に有用です。
Bot Controlのもう一つのモードは、Targeted Bot Controlで、これはアプリケーションを特に狙ってくるBotに焦点を当てています。単純にCurlスクリプトをループで実行するようなものではなく、より巧妙に作られたBotを対象としています。これらのBotは検出を避けるような行動を知っています。Targeted Bot Controlでは、リクエストへのチャレンジ、デバイスフィンプリントの追跡、セッションが通常の人間の行動の基本ルールに従っているかの確認など、積極的な対策を開始します。機械学習モデルを構築してアプリケーションにおける一般的なユーザーフローを理解し、それと異なる動きを示すものにフラグを立てたりブロックしたりします。
2番目のManaged RuleはATP（Account Takeover Prevention）で、これはログインプロセスを扱います。このManaged Ruleではログインページを設定でき、ウェブサイトやアプリケーション全体のトラフィックではなく、ログイントラフィックのみを監視します。設定が完了すると、ユーザー名とパスワードが既知の盗難データベースからのものかどうかの追跡を開始します。私たちは何十億もの盗難された認証情報を追跡しています。特定のセッションやIPに対する成功や失敗が多すぎる場合は、Brute Force攻撃を検出できます。これを強制モードで使用して不審なトラフィックにチャレンジしてブロックするか、シグナルを送るだけでアプリケーションに向けてラベルやカスタムヘッダーを追加するために使用することができます。
不正関連の2番目のルールはACFP（Account Creation Fraud Prevention）で、これはログインプロセスではなく、サインアッププロセスを扱います。これも同様に、ログインフォームまたはサインアップAPIエンドポイントを設定すると、サインアッププロセスに関連する異常の検出を開始します。
これには不審なメールドメインや盗難された認証情報の検出が含まれ、これら2つのManaged Rulesには様々な異常を追跡する数多くのルールが含まれています。新しい脅威が出現するたびに、私たちは継続的にこれらを更新しています。
Bot Control、Targeted Bot Control、ATP、ACFPは、インバウンドリクエストに対して積極的にチャレンジを行うことでより効果を発揮します。リクエストが到着し、チャレンジを実施することを選択した場合、まずブラウザが私たちのチャレンジを実行できるかを確認します。シンプルなJavaScript SDKを使用してWebアプリケーションに私たちのSDKを実装することができます。また、iOS、Android、Android TV、Apple TV向けのモバイルSDKも用意しており、ネイティブアプリケーションに直接実装してチャレンジを行うことができます。
まず、単なるスクリプトではなく、実際にJavaScriptを処理し、Cookieを返し、リダイレクトに従うことができるブラウザであることを確認します。これにより、大規模なボット運用のコストが高くなります。また、セッションIDという、そのセッション固有のフィンガープリントを取得し、異常を検知するために追跡することができます。簡単に切り替えたり隠蔽したりできるIPアドレスに依存する代わりに、実際のセッションを追跡することで、より強力な追跡ポイントを得ることができます。
不正対策とAdaptive Defenseの実践
これまで検知機能、緩和策、アクションについて見てきましたが、ここからは検知後の対策について、異なる戦略を説明していきましょう。高度な攻撃への対策は、通常複数のコンポーネントを組み合わせて行います。一つのアプローチだけに頼るのは効果的ではありません。戦略的な観点から、ゼロトラストアーキテクチャから脅威インテリジェンスの活用、インシデント対応の構築まで、すべてを考慮する必要があります。この発表では、高度なボットを検知されたことに気付かせることなく対処する方法として、お客様が創意工夫を凝らしているAdaptive Defenseに焦点を当てていきます。
ここで、緩和策の4つのDについて説明しましょう。Adaptive Mitigationを実装する方法には4つあります。Diversionは、悪意のあるエージェントや攻撃者からのトラフィックを特定してブロックする方法です。これは単純なボットやスクリプトキディには効果的ですが、検知されたことに気付くと攻撃ベクトルを変更する標的型ボットには効果がありません。Distortionは異なるアプローチで、既知の正常なトラフィックを許可するポジティブセキュリティを実装します。Depletionは、Command & Controlサーバーを検知した際に、様々なパートナーと協力してテイクダウン要求を実行する方法です。
Deceptionは特に興味深く、ユースケースに応じて様々な効果的な手法を提供します。一つの手法は「偽装成功」で、ボットを検知してカスタムレスポンスを実装します。HTTPコードとレスポンスボディの両方をカスタマイズでき、リクエストがアプリケーションに到達するのを防ぎながら、検知されていないと思い込ませることができます。もう一つのアプローチは「偽装失敗」で、ボットを検知して429ステータスコードを送信して速度を低下させたり、301リダイレクトを送信したりします。高度なボット攻撃者はレスポンスを調べ、期待する内容が返ってこない場合は攻撃ベクトルを変更します。
高度なBotの攻撃者が攻撃手法を変更することを見越して、単にブロックするだけでなく、予期せぬレスポンスによって攻撃者の考え方を混乱させる戦略を取ります。フェイクの失敗やフェイクの実行テクニックでは、ラベルの概念を使用して特定のリクエストにタグを付け、それらを通過させます。例えば、BotがアタッチされたCloudFrontディストリビューションがある場合、カスタムヘッダーを追加し、Application Load BalancerやAPI Gatewayのルーティング層で、トラフィックを実際のアプリケーションとHoneypotのどちらに送るかを判断できます。
オンラインデーティングサービスを提供するお客様の中には、AIで生成した画像に対してこの戦略を実装している例があり、攻撃者は自分がスクレイピングしている画像が本物か偽物かを判断できません。これにより、脅威インテリジェンスチームやSOCチームがHoneypot環境での攻撃の進行を観察し、将来の攻撃からより良く保護することができます。通常の実行では、一部の攻撃が通過することを認識し、それを受け入れます。明らかな脅威はブロックしますが、正常なトラフィックか悪意のあるトラフィックか判断が難しいグレーゾーンでは、ユースケースに応じて、Botをブロックすることよりも正当な顧客をブロックすることの方が大きな懸念となる場合があります。
お客様が一般的に使用するアーキテクチャは、CloudFrontから始まります。Webアプリケーションの前段にCloudFrontを置くことには、パフォーマンス、コスト、セキュリティ、バックエンドサーバーの負荷軽減など、複数のメリットがあります。CloudFrontは、ALBを指すビヘイビアを通じて実際のアプリケーションにトラフィックをルーティングできます。また、S3バケットに保存された画像やCSSファイルなどの静的アセットへのトラフィックもルーティングできます。これはシングルページアプリケーションの基本的なレイアウトとなります。
AWS WAFは通常、CloudFrontの前段に配置して攻撃者の近くで攻撃に対処することが望ましく、特にボリューメトリック攻撃に効果的です。また、Defense-in-Depthアプローチとして、ALBにもAWS WAFを使用するお客様もいます。この場合、エッジで特定のセキュリティ対策を行い、ALBで別の対策を行うなど、異なるチームで管理することもあります。ただし一般的には、CloudFrontが主要なエントリーポイントとなり、その背後にすべてが配置される構成となります。
この理論的な知識を実践的な応用に移してみましょう。ここで、サインアップ報酬と紹介ボーナスを提供しているWebサイトを運営するお客様の立場になってみます。サインアップ時に提供している5ドルのボーナスを悪用する偽アカウントや不正ログインの問題に直面しており、収益が失われています。目標は、不正行為者をブロックしつつも、ブロックされていることを気付かせないようにして、彼らの不正手法の進化を防ぐことです。
まず、先ほど説明した2つのFraudルール、つまりATP（Account Takeover Prevention）とACFP（Account Creation Fraud Prevention）を追加していきます。ただし、最初からブロックしないように設定し、これらのManaged Rulesに含まれる多くのサブルールをBlockモードではなくCountモードに設定します。さらに、フロントエンドにAWS WAF SDKを実装することも必要です。
アプリケーションにSDKを実装することには多くのメリットがあり、すべての受信リクエストが適切に処理されるように、フロントエンドに簡単にコピー＆ペーストするだけで済みます。すべての受信リクエストやセッションが、すぐにトークンを取得するためのチャレンジを受けるようになります。チャレンジが失敗してもブロックはされません。単に、トークンが存在しないことを示すラベルが付くだけです。このやり方なら、ルールを通じてアクティブにチャレンジするよりもコストを抑えることができます。アーキテクチャの観点からは、 いくつかのルールを追加し、フロントエンドにAWS WAF SDKを追加しただけで、特に大きな変更はありません。
さて、これを実装した後は、受信リクエストをブロックしたくありません。 これはATP/ACPのスクリーンショットですが、より多くの異常な動作に対応するため、少し長くなっています。最初にBlockに設定されているものを、Countモードに変更する必要があります。これにより、Session IDを取得してユーザーを追跡できるようになります。違反行為があってもブロックはしませんが、ラベルを付けることで、不審な行動に関する追加データを得ることができます。
その上で、Customルールを作成します。ここで順序が重要になります。このCustomルールは、ATPとACFPの後ろ、つまりATPとACFPが発行するラベルを探すルールの後に配置する必要があります。Label Matchルールを作成する際、特定の違反だけでなく、ATPやACFPが発行するすべてのラベル、つまりネームスペース全体を指定することもできます。これは非常にシンプルな設定方法です。
このルールには3つの動作のいずれかを設定できます。1つ目は単純なカウントで、ATPまたはACFPの動作に一致したリクエストをすべてカウントします。一致した場合でもブロックせず、代わりにカスタムヘッダーを追加します。フロントエンドアプリケーションがこのカスタムヘッダーを読み取り、特定のヘッダーを探してアプリケーションに任意のビジネスロジックを実装できます。これらのヘッダーには、リクエストで何が問題だったのかが正確に記載されます。つまり、AWS WAFを不正検知ソリューションのための下流シグナリングメカニズムとして使用するのです。
2番目に、フェイクの成功レスポンスを返すことができます - 200 OKレスポンスを返すのです。「ユーザーXさん、ようこそ。10ドルのクーポンをどうぞご利用ください」というように。このフェイクの成功レスポンスによって、不正利用者は自分がブロックされていることに気付きにくくなります。これが分かれば、偽のクーポン番号を配布して、そのクーポンが使用された時を追跡することができ、不正利用された時にループを閉じることができます。不正行為は最初の一歩に過ぎず、私たちが実際に支払うのはクーポンが使用された時なのです。
最後に、リルーティングを行うことができます。最初のシナリオと同様に、カウントするだけでカスタムヘッダーを追加し、Amazon CloudFrontの背後にある任意のサービスがそのカスタムヘッダーを処理できます。CloudFront Functionでオリジンを書き換えたり、Lambda@Edge Functionでヘッダーを読み取ってHoneypotやより安全なアプリケーション、その他のオリジンに書き換えたりすることができます。ALBルールを使用して、カスタムヘッダーに基づいてトラフィックを異なる方向にルーティングし、不正利用者に成功したと思わせながら、実際に何が行われたかを追跡することができます。
複雑なアプリケーション保護のためのAWS WAF活用
さて、フェイクアカウントやフェイクログインの問題が解決されました - 素晴らしい、収益も増えたので、今度は実際の顧客を獲得するためにマーケティングキャンペーンを実施しましょう。マーケティングチームがキャンペーンを実施しています。主に静的アセットを公開していますが、これは公開予定でしょうか、それとも既に公開されているのでしょうか？昨日公開されたという予感がします。そうですね、昨日公開されました。静的アセットについては、Webサイトの複雑さはそれほど気にしていません。キャンペーン期間中にWebサイトが利用可能であることだけが重要です。可用性が鍵となります。何かスクリプトが試されても気にする必要はありません - 悪用できるものは何もないので、主に可用性が重要なのです。そして既に本番環境にあるということなので、とてもタイムリーですね。
不審な動作が始まった時にセキュリティを強化したり、より積極的な対応ができるような設定が必要です - 基本的に、何も起こらない限り何もしないか、ほとんど何もしない設定です。そこで、まずRate-based ruleを追加します。 スコープを絞り込まずに、特定のトラフィックパターンを見るのではなく、すべてのリクエストをカウントするRateルールを使用します。QAツールからのリクエストなどは除外してカウントすることもできます - 一部のリクエストのスコープを絞り込むことはできますが、基本的にはそのアプリケーションに対するすべての受信リクエストをカウントします。
このルールはブロックするように設定されておらず、カウントするだけです。これはRate-basedルールで、5分間で5000リクエスト、100万、1000万かもしれません - あなたにとって不審と考えられる数値の閾値を待ちます。そうなると、直近1分間で100万を超えたすべてのリクエストに対してラベルを発行し始めます（この数値は変更可能です）。これで、特定のトラフィックサージに対するウェイトを持つルールができました。これはすべてWeb設定です。Amazon CloudWatchのメータリングと自動化、設定を変更するLambda Functionを使用することもできますが、特定のIPアドレスや特定の国からではなく、すべてのリクエストの中で特定の数を超えたリクエストに対してラベルを発行するルールを追加するだけなので、とてもシンプルです。
では、このラベルをどのように使用するかについて説明しましょう。分かりやすくするために、このラベルを「volumetric traffic」と呼ぶことにします。 volumetric trafficラベルが付いたリクエストを検知し始めると、何か不審な動きが発生していることが分かります。そこで、もう1つのRate-based ruleを事前に設定します。先ほど、ポリシーには少なくとも3つのRate-based ruleが必要だと言いましたが、これがその理由の良い例です。2つ目のRate-based ruleでは、小規模なサイトなので、IPアドレスごとのリクエスト数を制限します。1分間に1つのIPアドレスから200リクエストあれば十分でしょう。ただし、volumetric trafficラベルが付いたリクエストだけを監視します。つまり、通常時はこのルールは何もしません。誰かが1000リクエストを送信してもブロックされません。なぜなら、その程度では被害が出るほどではないからです。
しかし、全体のトラフィックが一定のポイントを超えると、このルールが適用され始めます。そうすると、ノイズの多いIPアドレスは制限されますが、通常のIPアドレスは問題なくミニサイトを利用し続けることができます。これが相互に連携する2つのRate limitingルールです。また、このラベルを使ってIP reputationの適用を開始することもできます。通常は悪意のあるIPを気にしませんが、可用性が脅かされる場合は、一定のしきい値を超えた時点で、volumetric trafficラベルの付いたトラフィックに対してのみIP reputation managed ruleを適用したいと考えます。これにより、緊急時に自動的にセキュリティ態勢を強化することができます。このRate limitingルールは次のようになります - とてもシンプルです。このケースではvolumetric trafficというラベルの付いたリクエストのみを検査するRate-based ruleです。
最後に、AWS WAF Bot Controlも使用できます。Bot Controlは別料金がかかるため、不必要に実行される高額なソリューションは避けたいところです。そこで、アプリケーションに対する攻撃や大量のフラッド攻撃が発生している場合にのみBot Controlの範囲を限定することができます。それ以外の状況では使用しません。つまり、Bot Controlは有効になっていますが、volumetric trafficラベルの付いたトラフィックのみを監視します。
不正対策が整い、マーケティングも新規ユーザーも確保できたので、より自信を持ってAWS WAFを実際のアプリケーションや収益を生み出すアプリケーションの保護に使用したいと考えています。これはより複雑な状況で、静的コンテンツだけでなく、動的なAPIがあり、ブラウザやモバイルデバイスなど異なるタイプのデバイスからのアクセスがあり、最もコスト効率の良い方法で異なるタイプのトラフィックに対して異なる制御を行いたいと考えています。 そこで、トラフィックのマーキングのみを行えるようにWeb ACLを開始します。特定の基準に一致するものを検出してラベル付けするだけで、何も強制しないCountルールを設定します。信頼できるIPアドレス、パートナー、テスターからのすべてのトラフィックにラベルを付けるだけでも十分で、そのラベルを後で使用します。Managed rulesの場合、SQLインジェクションルールを適用したいとします。しかし、誤検知に対する許容度が低く、アプリケーションのすべての部分がSQLインジェクションの影響を受けるわけではありません。そのため、誤検知を避けたいと考えています。このルールを有効にしますが、強制はせず、Countモードに切り替えて、SQLインジェクションの試みを検出した場合にのみラベルを付けるようにします。不審な国からのアクセスについても同様です。
SQLインジェクションの試み、不審な国、または特定のURIに一致した場合にラベルを付けます。例えば、検索ページやダウンロードメカニズムなど、大量のトラフィックを発生させる計算負荷の高いURIがある場合、これらの機密性の高いURIは、Countとラベルのみを行うMatch criteriaルールでフラグを立てることができます。複数のCountとラベルのルールを持ち、トラフィックがAWS WAFを通過する際に、特定のトラフィックパターンに関する様々なラベルを収集します。機密URIラベルを発生させないS3バケットを対象としたSQLインジェクションでフラグが立てられたリクエストや、より危険なログインAPIエンドポイントを対象としたクロスサイトスクリプティング攻撃を含むリクエストを識別できます。これにより、各リクエストについてより詳しく知ることができ、Web ACLでリスクベースの設定を行うことができます。
のラベルを検査するルールを作成する前に、Bot Controlを実装することができます。これは別料金のルールで、Common Modeで実行できます。Common Modeはより経済的で、ナイブなボットを検知し、検証済みボットにフラグを立てます。Common Bot Controlを実行すると、インバウンドリクエストに未検証ボットのラベルが付与され、検証済みボットからのトラフィックかどうかを判断できるようになります。後続のブロッキングアクションを実施するルールでは、検証済みボットを除外したい場合があるでしょう。また、アプリケーションの特定の部分に対してTargeted Bot Controlを使用することもできますが、これはより高価なモードであり、特定のラベル付きトラフィックに対してのみ使用したいものです。
Web ACLに2つのバージョンのBot Controlを追加することは、UIを通じては簡単ではありません。UIでは1つのインスタンスしか許可されないためです。しかし、CLI、SDK、Terraformテンプレート、直接のAPIコールなど、AWS WAFを管理する他の方法では、Web ACLに複数バージョンのBot Controlを設定できます。これにより、検索URIに対するBot Controlの使用など、特定のラベル付きリクエストに限定したBot Controlが可能になります。Web ACLの下部には、のルールが含まれ、適切にラベル付けされた場合にのみ、インバウンドリクエストのブロックやチャレンジを実施します。
SQLインジェクションの例を使用すると、初期の段階で複数の要素を確認するルールがありました。SQLインジェクションパターンを含むリクエストを検出した場合、ラベルを確認します：Managed Ruleからのインジェクションラベル、Sensitive URIルールからのSensitive URIラベル、そしてTrusted IPラベルが付いていないことを確認します。この時点でSQLインジェクションのブロックを開始します。このように、ルールの適用を慎重に選択することで、誤検知のリスクを制限します。このアプローチにより、アプリケーションの異なる部分を異なる方法で保護し、IPレピュテーションや不審な国からの高リスクソースに対して異なるセキュリティポリシーを適用できます。
推奨リソースとして、ボット対策戦略を構築する際の重要な考慮事項をカバーするBot Mitigation Strategy Guideがあります。の設定例やチャレンジフローに関する詳細情報も用意されています。より詳しく知りたい方は、これらのリソースをご確認ください。質問の時間を設けておりますので、ご質問がありましたらお気軽にどうぞ。お時間をいただき、ありがとうございました。LinkedInでつながることもできますし、アンケートにご協力いただければ大変ありがたく存じます。ご清聴ありがとうございました。よい一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion