生成 AI のためのネットワーク境界でのセキュリティ保護

本ブログは 2024 年 8 月 7 日に公開された「Network perimeter security protections for generative AI」を翻訳したものとなります。

生成 AI ベースのアプリケーションは、ここ数年で人気が高まっています。大規模言語モデル (LLM) を使ったアプリケーションは、企業が顧客に提供する価値を高める可能性があります。本ブログでは、生成 AI アプリケーションのネットワーク境界の保護について詳しく説明します。ネットワーク境界の保護の検討すべき様々な領域を説明し、それらが生成 AI ベースのアプリケーションにどのように適用されるかを議論し、アーキテクチャパターンを提供します。生成 AI ベースのアプリケーションにネットワーク境界の保護を実装することで、不正使用、コスト超過、分散型サービス拒否攻撃 (DDoS)、その他の脅威アクターや好奇心旺盛なユーザーからの保護に役立つコントロールが得られます。

LLM の境界での保護

Web アプリケーションのネットワーク境界の保護は、次のような重要な質問に答えるのに役立ちます。

アプリにアクセスできるのは誰ですか?
アプリに送信されるデータの種類は何ですか?
アプリが使用できるデータ量はどのくらいですか?

ほとんどの場合、他の Web アプリと同じネットワーク保護の方法が生成 AI アプリにも機能します。これらの方法の主な焦点は、アプリが作成する特定のリクエストや応答ではなく、アプリにアクセスしようとするネットワークトラフィックをコントロールすることです。ここでは、ネットワーク境界の保護の 3 つの主要な領域に焦点を当てます。

アプリのフロントエンドの認証と認可
Web アプリケーションファイアウォールの使用
DDoS 攻撃からの保護

これらのアプリで LLM を使用することに関するセキュリティ上の懸念 (プロンプトインジェクション、機密情報の漏洩、過剰な代理行為など) については、この記事の範囲外です。

フロントエンドの認証と認可

ネットワーク境界の保護を設計する際、まずユーザーが認証 (AuthN) されているかどうか、および生成 AI ベースのアプリケーションに特定の質問をする権限 (AuthZ) があるかどうかに基づいて、特定のユーザーにアプリケーションへのアクセスを許可するかどうかを決める必要があります。多くの生成 AI ベースのアプリケーションは認証レイヤーの背後に配置されているため、ユーザーはアプリケーションにアクセスする前に ID プロバイダーにサインインする必要があります。認証の背後にない公開アプリケーション (チャットボットなど) の場合、次の 2 つのセクションで説明する AWS WAF と DDoS 保護に関して、追加の考慮が必要です。

例を見てみましょう。Amazon API Gateway はアプリケーションフロントエンドのお客様向けのオプションであり、認証と認可を使用してユーザーや API を可視化します。フルマネージドされたサービスで、開発者が大規模に API を公開、保守、監視、セキュアにするのに役立ちます。API Gateway では、AWS Lambda オーソライザーを作成してアプリケーション内の API へのアクセスをコントロールします。図 1 は、この例でのアクセスの仕組みを示しています。

図 1: クライアント～ LLM 間のシグナルパスにおける API Gateway、Lambda オーソライザー、基本的なフィルター

図 1 のワークフローは次のとおりです。

クライアントは API Gateway がフロントエンドとなる API にリクエストを送信します
API Gateway はリクエストを受信すると、OAuth、SAML、または他のメカニズムを通じてリクエストを認証する Lambda オーソライザーにリクエストを送信します。Lambda オーソライザーは、API Gateway に AWS Identity and Access Management (IAM) ポリシーを返し、リクエストを許可または拒否します
許可された場合、API Gateway は API リクエストをバックエンドアプリケーションに送信します。図 1 では、これは LLM セキュリティの領域で追加の機能を提供し、より複雑なフィルタリングの代わりとなる Lambda 関数です。Lambda オーソライザーに加えて、クライアントごと、またはクライアントがアクセスするアプリケーションメソッドごとに API Gateway でスロットリングを設定できます。スロットリングにより、DDoS 攻撃だけでなく、モデルクローニングやモデル反転攻撃に対してある程度の緩和策を提供できます
最後に、アプリケーションは AWS 上にデプロイされた LLM にリクエストを送信します。この例では、LLM は Amazon Bedrock にデプロイされています

Lambda オーソライザーとスロットリングの組み合わせにより、境界での様々な保護メカニズムをサポートできます。まず、認証されたユーザーのみがアプリケーションにアクセスできるため、ボットや一般ユーザーのアクセスを防ぐことができます。次に、認証されたユーザーに対して、LLM への過剰な呼び出しによるコストを防ぐため、呼び出しレートを制限できます。そして、ユーザーがアプリケーションによって認証および承認された後、アプリケーションはユーザーが認可されているデータにのみアクセスできるように、ID の情報をバックエンドのデータアクセスレイヤーに渡すことができます。

API Gateway の他にも、AWS ではフロントエンドの認証と認可を提供するためのオプションがあります。AWS Application Load Balancer (ALB) は、アクセス前に OIDC プロバイダーへの認証をリクエストする OpenID Connect (OIDC) 機能をサポートしています。内部アプリケーションの場合、AWS Verified Access は、アイデンティティとデバイスの信頼シグナルの両方を組み合わせて、生成 AI アプリケーションへのアクセスを許可または拒否します。

AWS WAF

認証または認可の決定が行われた後、次の考慮事項はアプリケーション側のネットワーク境界の保護です。OWASP Top 10 for Large Language Model Applications で説明されているように、生成 AI ベースのアプリケーションには新しいセキュリティリスクが特定されています。これらのリスクには、安全が確認されていない出力ハンドリング、安全が確認されていないプラグイン設計、およびアプリケーションが望ましい基準から外れた応答を返す原因となるその他のメカニズムが含まれます。例えば、脅威アクターは LLM への直接的なプロンプトインジェクションを作成し、LLM の不適切な動作を引き起こす可能性があります。これらのリスク (安全が確認されていないプラグイン設計) の一部は、ID の情報をプラグインやデータソースに渡すことで対処できます。ただし、これらの保護の多くは、ネットワーク境界の保護の範囲外であり、アプリケーション内のセキュリティの領域に該当します。ネットワーク境界の保護では、アプリケーションにアクセスできるユーザーを検証し、アプリケーションアクセスの前にアプリケーションレベルでネットワークルールとパターンに基づいて Web リクエストを許可、ブロック、または監視するルールをサポートすることに重点が置かれています。

さらに、ボットトラフィックは Web ベースのアプリケーションにとって重要な検討事項です。Security Today によると、インターネットトラフィックの 47% がボットから発生しています。パブリックアプリケーションにリクエストを送信するボットは、より多くのリクエスト負荷を引き起こすため、生成 AI ベースのアプリケーションの使用コストを押し上げます。

ボットトラフィックから保護するため、アプリケーションへアクセスする前の境界の保護の一部として AWS WAF を実装できます。AWS WAF を使用すると、保護対象の Web アプリケーションリソースに転送される HTTP(S) リクエストを監視およびブロックするファイアウォールをデプロイできます。これらのリソースは、API Gateway、ALB、AWS Verified Access、およびその他のリソースの背後に存在します。Web アプリケーションの観点では、AWS WAF は LLM の呼び出しが行われる前に、アプリケーションへのアクセスを防止または制限するために使用されます。これは重要な検討事項です。なぜなら、LLM への入力と出力を保護するだけでなく、正当なトラフィックのみがアプリケーションにアクセスできるようにする必要があるからです。AWS マネージドルールまたは AWS Marketplace のマネージドルールグループでは、ルールグループの一部として定義済みのルールが提供されます。

もうすこし前の例を掘り下げてみましょう。図 1 のアプリケーションがスケールアップし始めたので、Amazon CloudFront の背後に移動することにしました。CloudFront は、エッジロケーションのグローバルネットワークを使用して、AWS への分散型のイングレスを提供する Web サービスです。分散型のイングレスを提供するだけでなく、CloudFront を使用すると AWS WAF ルールの一部として SQL インジェクション、ボット制御、その他のオプションに対する保護をグローバルにデプロイできます。図 2 の新しいアーキテクチャを見ていきましょう。

図 2:クライアントからモデルへのシグナルパスに AWS WAF と CloudFront を追加する

図 2 に示されたワークフローは次のとおりです。

クライアントは API にリクエストを送信します。DNS はクライアントを AWS WAF がデプロイされている CloudFront のロケーションに向けます
CloudFront はリクエストを AWS WAF ルールに送り、トラフィックをブロック、監視、または許可するかを決定します。AWS WAF がトラフィックをブロックしない場合、AWS WAF はそれを CloudFront のルーティングルールに送ります注: API Gateway へのアクセスを制限して、ユーザーが CloudFront ディストリビューションをバイパスしてAPI Gateway にアクセスできないようにすることをお勧めします。この目標を達成する方法の例は、「Restricting access on HTTP API Gateway Endpoint with Lambda Authorizer」ブログ記事にあります
CloudFront はトラフィックを API Gateway に送り、図 1 で説明したのと同じトラフィックパスを通過します

さらに詳しく見るために、ボットトラフィックに焦点を当てましょう。AWS WAF Bot Control を使用すると、スクレイパー、スキャナー、クローラー、ステータスモニター、検索エンジンなどのボットを監視、ブロック、またはレート制限できます。Bot Control は、設定済みのルールと複数の検査レベルのオプションを提供します。たとえば、ルールグループの Targeted レベルを使用すると、自己識別しないボットにチャレンジを仕掛けることができるため、悪意のあるボットがあなたの生成 AI ベースのアプリケーションに対して操作するのがより困難で高コストになります。Bot Control のマネージドルールグループを単独で、または他の AWS マネージドルールグループと独自のカスタム AWS WAF ルールと組み合わせて使用できます。Bot Control は、図 3 に示すように、あなたのアプリケーションを標的にしているボットの数について詳細に可視化できます。

図 3: Bot Control ダッシュボードで確認できるボットリクエストと非ボットリクエスト

この機能はどのように役立つでしょうか? 生成 AI ベースのアプリケーションでは、ボットやその他のトラフィックがアプリケーションをどのように標的にしているかを確認できます。AWS WAF は、特定のボットを許可したり、ボットトラフィックをアプリケーションからブロックしたりするなど、ボットトラフィックの Web リクエスト処理を監視およびカスタマイズするオプションを提供します。Bot Control に加えて、AWS WAF には、ベースラインルールグループ、ユースケース固有のルールグループ、IP レピュテーションルールグループなど、さまざまなマネージドルールグループが用意されています。詳細については、AWS マネージドルールグループと AWS Marketplace マネージドルールグループのドキュメントをご覧ください。

DDoS 保護

本ブログで最後に取り上げるトピックは、LLM における DDoS です。他のレイヤー 7 アプリケーションに対する脅威と同様に、脅威アクターは非常に多くのリソースを消費するリクエストを送信する可能性があり、その結果サービスの応答性が低下したり、大量のリクエストを処理する LLM の実行コストが増加したりします。スロットリングは、ユーザーごとまたはメソッドごとのレート制限をサポートするのに役立ちますが、DDoS 攻撃はスロットリングでは対処が困難な、より高度な脅威ベクトルが使用されます。

AWS Shield は、インターネットに面するアプリケーションに対する DDoS 保護を提供し、Shield Standard ではレイヤー 3 と 4、Shield Advanced ではレイヤー 7 を保護します。例えば、Shield Advanced は、既にデプロイされている AWS WAF の一部である Web アクセスコントロールリスト (ACL) を使用して、エクスプロイトの一部である Web リクエストをカウントまたはブロックすることで、自動的にアプリケーションの脅威を緩和します。要件に応じて、Shield は複数のレイヤーで DDoS 攻撃から保護できます。

図 4 は、Shield を追加した後のデプロイメントの様子を示しています。

図 4: クライアントからモデルへのシグナルパスに Shield Advanced を追加する

図 4 のワークフローは次のとおりです。

クライアントは API にリクエストを送信します。DNS はクライアントを CloudFront のロケーションに向けます。そこには AWS WAF と Shield がデプロイされています
CloudFront はリクエストを AWS WAF ルールに送り、トラフィックをブロック、監視、または許可するかを判断します。AWS Shield は、さまざまな既知の DDoS 攻撃ベクトルとゼロデイ攻撃ベクトルを軽減できます。設定に応じて、Shield Advanced と AWS WAF が連携して、個々の IP アドレスからのトラフィックをレート制限します。AWS WAF または Shield Advanced がトラフィックをブロックしない場合、サービスはそれを CloudFront のルーティングルールに送ります
CloudFront はトラフィックを API Gateway に送り、図 1 で説明したのと同じトラフィックパスを通過します

AWS Shield と Shield Advanced を実装すると、セキュリティイベントに対する保護と、グローバルおよびアカウントレベルのイベントの可視性が得られます。例えば、アカウントレベルでは、アカウントで見られたイベントの総数、各リソースの最大ビットレートとパケットレート、CloudFront の最大リクエストレートに関する情報が得られます。Shield Advanced では、Shield Advanced が検出したイベントの通知と、検出されたイベントと緩和策に関する追加情報にもアクセスできます。これらのメトリクスとデータは、AWS WAF とともに、あなたの生成 AI ベースのアプリケーションにアクセスしようとしているトラフィックの可視性を提供します。これにより、アプリケーションへのアクセスや LLM の呼び出しの前に、緩和機能が提供されます。

考慮事項

生成 AI アプリケーションをデプロイする際の境界の保護については、以下の点を考慮してください。

AWS では、フロントエンド側の認証と認可と、AWS WAF 側の両方で境界の保護を構成する複数のオプションを提供しています。アプリケーションのアーキテクチャとトラフィックパターンに応じて、複数のリソースが AWS WAF で境界の保護を提供し、認証と認可の決定のために ID プロバイダーと統合できます
また、Lambda 関数やその他の AWS サービスを使用して、デプロイメントアーキテクチャの一部として、より高度なLLM 固有のプロンプトフィルターと応答フィルターをデプロイすることもできます。境界の保護機能は、望ましくないトラフィックがエンドアプリケーションに到達するのを防ぐことに重点が置かれています
LLM で使用される大半のネットワーク境界の保護は、他の Web アプリケーションのネットワーク境界の保護メカニズムと同様です。違いは、通常の Web アプリケーションと比べて、追加の脅威ベクトルが発生する点です。脅威ベクトルの詳細については、OWASP Top 10 for Large Language Model Applications と MITRE ATLAS を参照してください

結論

本ブログでは、従来のネットワーク境界の保護戦略が、生成 AI ベースのアプリケーションに多層防御を提供する方法について説明しました。LLM ワークロードと他の Web アプリケーションの類似点と相違点について説明しました。認証と認可の保護が重要な理由を説明し、API Gateway を使用してスロットリングと Lambda オーソライザーを通じた認証を行う方法を示しました。次に、AWS WAF を使用してアプリケーションをボットから保護する方法について説明しました。最後に、AWS Shield がさまざまなタイプの DDoS 攻撃からスケーラブルで高度な保護を提供する方法について説明しました。ネットワーク境界の保護と生成 AI セキュリティの詳細については、AWS Security Blog チャンネルの他のブログ記事を参照してください。

本ブログについてご質問がある場合は、AWS サポートにお問い合わせください。

翻訳はプロフェッショナルサービス本部の藤浦雄大が担当しました。

Amazon Web Services ブログ