Amazon Web Services ブログ
PartyRock の保護:AWS WAF を利用した Amazon Bedrock エンドポイントを保護する方法
本稿は、2024 年 11 月 7 日に公開された “Securing PartyRock: How we protect Amazon Bedrock endpoints using AWS WAF” を翻訳したものです。
PartyRock は、Amazon Bedrock をベースとした直感的で実践的な生成 AI アプリ構築プレイグラウンドです。それは、ユーザーが生成 AI テクノロジーを実験でき、クイズジェネレーターやレジュメオプティマイザーなどコーディングなしで楽しいアプリケーションを構築できます。無料のオンライン生成 AI プレイグラウンドを開発者に提供することは非常に大きな価値があることですが、それは重要なセキュリティ面での課題も存在します。
この投稿では、AWS WAF を利用して分散型サービス拒否 (DDoS) 攻撃や Wallet 拒否攻撃 (DoW) のような潜在的な脅威から PartyRock を保護した方法を探求します。また、オンラインアプリケーションに生成 AI 機能をインテグレーションしている開発者は、同様の脅威からそのアプリケーションを保護する具体的な AWS WAF の基本テクニックについて学ぶことができます。
セキュリティの課題
ここで述べている 2 つの脅威は、私たちの無料の生成 AI プレイグラウンドの機能やユーザー体験に影響を与えます。
- 分散型サービス拒否 (DDoS) 攻撃 : DDoS 攻撃は、大量のトラフィックであなたのリソースを圧倒して、あなたのサービスをオフラインにする可能性があります。PartyRock は評価を落とし、その可用性を損なう、評判を傷つける、または身代金を要求しようとする攻撃者によって標的にされる可能性があります。
- サービス悪用: 悪意のある攻撃者が、汎用的な生成 AI のコンピュート能力の転売など意図されていない目的でプラットフォームを悪用しようと試みる可能性があります。攻撃者は、PartyRock 上で大量のアプリ実行を生成することにより、私たちのユースケースにおいてクラウドサービスのリソース自動スケーリング機能(クラウドの弾力性)を悪用します。PartyRock での平均的なアプリ実行では、Bedrock 上の Anthropic Sonnet 3 モデルを使用して 2000 個の入力トークンと 400 個の出力トークンを消費するため、1000 回のアプリ実行ごとに約 12 ドルのコストがかかります。アプリ実行の悪用を放置すると、予期しない、そして潜在的に重大なクラウド請求が発生する DoW (Wallet 拒否攻撃)につながり、悪意のある攻撃者がクラウドの柔軟性を PartyRock に対して悪用することを可能にしてしまいます。
これらの課題に対処するため、私たちは最初から堅牢なセキュリティ制御を実装し、AWS WAF が私たちの防御戦略において中心的な役割を果たしています。
PartyRock のサーバーレスアーキテクチャ
セキュリティ対策について詳しく説明する前に、AWS Cloud Development Kit(AWS CDK) を使用してデプロイした PartyRock のサーバーレスアーキテクチャを確認します。
- Amazon CloudFront: PartyRock のエントリーポイントとして機能し、キャッシュとダイナミック API コールの高速化を通じて、より良いユーザー体験を提供します。CloudFront エッジにおいて、Bot Control ルールなどの AWS WAF による保護を実装しています。
- Amazon S3: PartyRock の静的フロントエンドをホストします。
- AWS Lambda: Amazon Cognito や Bedrock などの他のインフラストラクチャコンポーネントと統合し、アプリケーションロジックを実行することで、私たちの React アプリケーションと API を動作させています。レイテンシとコストを削減するため、CloudFront 経由で Lambda 関数を利用可能にしています。Lambda URL を直接 CloudFront のオリジンとして設定しています。私たちのケースでは、API は通常 API ゲートウェイが提供する高度な機能を必要としないため、必要な構成要素を少なくしてアーキテクチャをシンプルに保つことができ、より安価で高速にすることが可能です。さらに、 CloudFront ディストリビューションのみが Lambda URL と通信できるよう、CloudFront の機能である Origin Access Control を使用して Lambda URL を設定しています。Bedrock とのインターフェースを担当する Lambda 関数は、Bedrock のレスポンスをユーザーにストリーミングで返すため、レスポンスストリーミングで設定されています。
- Amazon Cognito: Google、Amazon、Apple などのソーシャルアイデンティティプロバイダーを通じてユーザー認証を管理します。
- Amazon Aurora Serverless: PostgreSQL データベースとして機能し、豊富な機能と自動スケーリングを提供します。Amazon Aurora Serverless はオンデマンド型のマネージドデータベースで、重い作業を軽減し、機能に集中して迅速に反復開発することを可能にします。
- Amazon CloudWatch RUM: クライアントサイドのパフォーマンスとエラーを分析します。
図 1 : PartyRock のアーキテクチャの概要
AWS WAF を用いた多層防御の構築
多層防御は、インフラストラクチャを保護するために複数のセキュリティ制御を採用するサイバーセキュリティ戦略です。単一のセキュリティ対策に依存するのではなく、このアプローチは様々な防御メカニズムの組み合わせを使用します。この考え方は、セキュリティの一つの層が失敗したり侵害されたりした場合でも、他の層が代わりに攻撃を検出、防止、または軽減するというものです。私たちは、PartyRock を保護するために、認証ステップと組み合わせた AWS WAF ルールの組み合わせを使用しました。
IP reputation
私たちは、Amazon の内部脅威インテリジェンスに基づくマネージドルールグループである、Amazon IP 評価リストを設定しました。これは、典型的なボットやその他の脅威に関連する IP アドレスをブロックしたい場合に有用です。このリストには 3 つのルールが含まれています:
AWSManagedIPReputationList: 悪意のある活動に積極的に関与していると特定された IP アドレスを検査します。
AWSManagedReconnaissanceList: AWS リソースに対して偵察活動を行っている IP アドレスからの接続を検査します。
AWSManagedIPDDoSList: DDoS 活動に積極的に関与していると特定された IP アドレスを検査します。
実際の影響: 2024 年 2 月、AWSManagedIPReputationList ルールにより、ユーザーの体験に影響を与えることなく、悪意のある活動に関連する 20 万件のリクエストを数十分で特定してブロックすることができました。
Rate limiting
レートベースルールは、短時間内の大量のリクエストによって Web アプリケーションが圧倒されることを防ぐように設計されています。これは特に、DDoS 攻撃、ボット攻撃、悪意のあるトラフィックを軽減するのに有用です。このルールは定義された基準に従ってリクエストを集約し、ルールの評価ウィンドウ、リクエスト制限、およびアクション設定に基づいて、集約されたグループに対してレート制限を適用します。
私たちは、アプリケーションが圧迫されることを防ぐために、複数のレートベースルールを実装しました:
- 単一のソース IP が Web サイトを圧倒することを防ぐための包括的なレート制限。
- 使用する IP アドレスに関係なく、単一のユーザーセッションが Web サイトを圧倒することを防ぐためのCookieベースのレート制限。
実際の影響: 2024 年 6 月、両方のルールにより、PartyRock のインフラストラクチャを圧迫しようとする数百万件の悪意のあるリクエストをブロックすることができました。
図 2 : レート制限ルールを利用してブロックしたリクエスト数
カスタム緩和ルール
私たちは、AWS WAF で手動対応が必要な DDoS 攻撃に迅速に対応するためのカスタムルールをいくつか作成しました。これらのルールは、私たちが定義した値のリストと一致する特定の属性(例: IP や TLS フィンガープリント (JA3) )を持つリクエストをブロックするように設定されています。通常の状況では、これらのルールにはマッチング文が含まれていないため、どのリクエストもブロックしません。DDoS 攻撃に手動で対応する必要がある場合、まず CloudWatch Logs Insights を使用して攻撃を分析し、トップトーカー(例: 攻撃に最も寄与する JA3 シグネチャ)を特定します。その後、作成したカスタムルールに対応するマッチング文を追加します。これにより、脅威により迅速に対応することができます。
実際の影響: 2024 年 1 月、私たちは JA3 ベースのカスタムルールを使用して、1 時間あたり数百万件のリクエストを生成する継続的な HTTP フラッド攻撃をブロックしました。
図 3 : カスタム JA3 シグネチャーを利用してブロックしたリクエスト数
CAPTCHA による登録ステップのセキュリティ強化
PartyRock のセキュリティにとって登録ステップは重要です。悪意のある攻撃者が偽のアカウントを作成すると、私たちの無
料の生成 AI 計算能力を悪用される可能性があります。
PartyRock を無料にするトレードオフとして、私たちは 3 つのプロバイダー (Amazon、Apple、Google) からの連携アイデンティティのみを使用した登録を限定的に許可することにしました。登録ステップでは、まずこれらのアイデンティティプロバイダーのいずれかを通じてログインし、それらの認証ステップを経て、PartyRock が必要な情報にアクセスすることを認可する必要があります。最後に、PartyRock でユーザーアカウントを作成する前に、AWS WAF のカスタムルールがさらなる認証ステップとして CAPTCHA を提示します。
- 図 4 : 登録ステップ
- 図 5 : 登録ステップでの CAPTCHA チャレンジ
CAPTCHA Javascript API を使用して、PartyRock ウェブアプリケーション内で CAPTCHA フォームを表示するようにフロントエンドコードを変更し、登録体験をよりスムーズにしました。CAPTCHA 統合について詳しくは、この Amazon Networking の投稿をお読みください。
自動化されたボットトラフィックの高度な管理
AWS WAF で設定したセキュリティの最後のレイヤーは Bot Control です。私たちの目標は、匿名ユーザーからのトラフィックかログインユーザーからのトラフィックかに関係なく、自動化されたボットトラフィックを識別し管理することです。Bot Control のマネージドルールグループは 2 つのレベルの保護を提供します。
- 自己識別型のボットにラベルを追加し、一般的に望ましいボットを検証し、高信頼度のボットシグネチャを検出する、基本となる Common インスペクションレベル
- 自己識別しない高度なボットを検出する Targeted インスペクションレベル
実際の影響: 次のグラフを見ると、Bot Control の Common インスペクションレベルが一年を通して異なるHTTPフラッド攻撃を防いだ実績を確認することができます。
- 図 9 : 適切なブラウザの User-Agent ヘッダーを持たないフラッド攻撃をブロック
- 図 8 : 住宅ネットワークからのトラフィックとは異なり、悪意のあるボットの温床として知られるデータセンターから送信された HTTP フラッド攻撃をブロック
- 図 6 : 自動化ツールからのリクエストをブロック
- 図 9 : 適切なブラウザの User-Agent ヘッダーを持たないフラッド攻撃をブロック
Bot Control の Targeted インスペクションは、ブラウザ検査、フィンガープリンティング、行動ヒューリスティックなどの技術に基づいた高度な検出機能を提供し、悪意のあるボットトラフィックを識別します。これらの検出機能には、クライアント側で実行される AWS WAF Javascript Challenge が必要です。
このため、私たちはページに Bot Control Javascript SDK を統合しました。ページが読み込まれると、SDK はユーザー体験に影響を与えないよう非同期で Javascript チャレンジを実行します。チャレンジが正常に解決されると、SDK は暗号化されたトークンを Cookie に配置します。このトークンはユーザーセッションからのすべてのリクエストで AWS WAF に送信され、ユーザーの行動を分析できるようになります。トークンには自動化されたブラウザの検出されたフィンガープリントも含まれています。さらに、SDK はユーザーのナビゲーション中にテレメトリを収集し、検出と緩和ロジックをさらに強化します。
これは非同期であるため、有効なトークンを持たない最初のリクエストも許可する必要があります。Bot Control の TGT_
VolumetricIpTokenAbsent ルールによって、アプリケーションがトークンなしで単一の IP から大量のリクエストを受信した場合、AWS WAF は JavaScript チャレンジペイロードを使用してチャレンジを強制実行し、チャレンジをサイレントに完了してから元のページにリダイレクトします。
- 図 11 : 自動ブラウザのフレームワークの疑わしいフィンガープリントを持つクライアントからのリクエストに対し、CAPTCHA でチャレンジ
- 図 10 : トークンが欠落したリクエストが IP 毎に増加した際に、サイレントな JavaScript でチャレンジでリクエスト
前述したように、Bot Control は JavaScript チャレンジの正常な解決後に取得される暗号化トークンを使用して、ユーザーセッ
ションの行動を分析します。これにより、通常よりも多くのリクエスト量を持つセッションを特定し、CAPTCHA レスポンスでチャレンジすることができました。
実際の影響: 以下のグラフは、2024 年を通じて PartyRock へのセッション毎のトラフィックレベルの上昇により、CAPTCHAでチャレンジされたリクエストを示しています。
図 12 : トラフィックレベルが上昇したセッションからのリクエストに対し、CAPTCHA でチャレンジ
まとめ
生成 AI の実験的なオープンで創造的な環境を維持しながら、潜在的な脅威や悪用から保護するために、私たちは PartyRock に堅牢な多層防御を構築しました。AWS WAF を使用して、高レベルで以下のルールを実装しています。
- DDoS 攻撃のような悪意ある活動に関連した IP からのリクエストをブロックする IP 評価ルールベースのルール
- 単一の IP やセッションが PartyRock のインフラストラクチャを圧迫することを防ぐための様々な種類のレートベース
- インシデント対応中に特定された疑わしい属性に基づいてリクエストをブロックするカスタムルール
- ユーザー登録のワークフローでさらなる認証ステップのための CAPTCHA ルール
- ボットネットからの自動化されたトラフィックを識別し、適切に管理する Bot Control マネージドルール
この AWS WAF 設定は固定的なものではありません。アプリケーションログの継続的な監視と分析を通じて、日常業務で観察される新たな脅威やパターンに対処するため、定期的にルールセットを改良し拡張しています。
私たちはまた、別の AWS WAF ルールセットを使用して Cognito User Pools も保護しました。AWS WAF を使用した Cognito User Pools の保護について詳しくは、ドキュメントで学ぶことができます。
AWS WAF を始めるには、このショートビデオをご覧ください。より詳細な情報は AWS WAF ドキュメントで確認できます。
大規模言語モデル (LLM) アプリでコスト高なトラフィックを回避するための AWS WAF の使用方法について詳しく学ぶには、re:Inforce 2024のこの講演をご覧ください。
翻訳は、パートナーセールスソリューションアーキテクトの小林が担当しました。










