AWS のサービスで構築する生成 AI アプリケーションのセキュアなネットワークアーキテクチャ

本ブログは 2025 年 9 月 29 日に公開された AWS Blog “Build secure network architectures for generative AI applications using AWS services” を翻訳したものです。

生成 AI は業界を問わず基盤技術となり、会話型エージェントからリアルタイムのメディア合成まで、あらゆる用途を支えています。その一方で、悪意のある攻撃者が悪用できる新たな機会も生まれています。生成 AI アプリケーションを支える複雑なアーキテクチャには、一般公開された API、推論サービス、カスタムウェブアプリケーション、クラウドインフラストラクチャとの統合など、外部にさらされた広範な攻撃対象領域があります。これらのシステムも、従来型の外部脅威や新たに出現する外部脅威と無縁ではありません。AWS では、生成 AI のセキュリティ確保に関するシリーズ記事を公開しています。最初の記事である「生成 AI をセキュアにする: 生成 AI セキュリティスコーピングマトリックスの紹介」では、デプロイする生成 AI ワークロードの種類に応じてリスクとセキュリティへの影響を整理するモデルを示し、シリーズ全体の土台を築いています。

この記事はシリーズの続編として、多層防御のアプローチにより、Amazon Web Services (AWS) 上に生成 AI アプリケーション向けのセキュアでスケーラブルなネットワークアーキテクチャを構築する方法を解説します。パフォーマンスと信頼性を維持しながら AI ワークロードを保護する方法を紹介します。仮想プライベートクラウド (VPC) による分離、ネットワークファイアウォール、アプリケーション保護、エッジのセキュリティコントロールなど、生成 AI ワークロードの包括的な防御戦略の構築に活用できる複数のセキュリティレイヤーを取り上げます。

生成 AI に対する一般的な外部脅威

このセクションでは、現在の生成 AI アプリケーションが直面している代表的な外部脅威を紹介します。

ネットワークレベルの DDoS 攻撃 (レイヤー 4)

SYN フラッド、UDP フラッド、ICMP フラッドなどのネットワークレベルの分散型サービス拒否 (DDoS) 攻撃またはボリューム型攻撃は、大量のレイヤー 4 リクエストをサーバーに送りつけてネットワークレイヤーを標的にします。その目的は、レイヤー 4 のハーフオープン接続を大量に発生させてサーバーのリソースを枯渇させ、最終的にシステムが正当なユーザーに応答できない状態にすることです。持続的なセッションと低レイテンシーの応答が求められることの多い生成 AI アプリケーションでは、こうした攻撃によって可用性とユーザーエクスペリエンスが深刻な影響を受ける可能性があります。ボリューム型攻撃には、リフレクション攻撃と呼ばれる種類もあります。リフレクション攻撃では、脅威アクターが DNS などのサービスを悪用して、標的に送られるトラフィック量を増幅させます。脆弱なサードパーティのサーバーに送信された小さなリクエストが反射されて大きなレスポンスに増幅され、被害者に向けて送られます。生成 AI の API がパブリックインターネットに公開されている場合、この手法によってエンドポイントが予期しないトラフィックであふれ、サービス品質の低下を招く可能性があるため、特に危険です。

ウェブリクエストフラッド (レイヤー 7)

レイヤー 7 を狙うこの種の高度な攻撃は、正当なトラフィックパターンを模倣して従来のセキュリティフィルターをすり抜けます。悪意のある攻撃者は、過剰な HTTP リクエストでアプリケーションのエンドポイントに過負荷をかけ、特に推論の負荷が高い AI ワークロードにおいて、コンピューティングリソースを枯渇させることができます。ボリューム型の DDoS とは異なり、これらのリクエストは実際のユーザーからのリクエストと区別しにくいことが多いため、攻撃の緩和がより難しくなります。

アプリケーション固有の攻撃

悪意のある攻撃者は、アプリケーション固有のコードや、そのコードを実行する Apache、Nginx、Tomcat などのシステムの脆弱性を狙う傾向を強めています。カスタム API やオーケストレーションレイヤーを含むことが多い生成 AI アプリケーションでは、わずかな設定ミスやパッチが適用されていないコンポーネントが 1 つあるだけでも、不正アクセス、データ漏洩、システム侵害につながる可能性があります。

SQL インジェクション

悪意のある攻撃者は、入力フィールドやクエリパラメータから悪意のある SQL コードを挿入してバックエンドのデータベースを操作し、データを窃取したり破損させたりできます。プロンプトをログに記録したり、ユーザーとのやり取りを保存したりする生成 AI アプリケーションでは、入力のサニタイズが厳格に行われていないと、特にこの攻撃を受けやすくなります。

クロスサイトスクリプティング

クロスサイトスクリプティング (XSS) 攻撃では、信頼されたウェブページに悪意のあるスクリプトを挿入します。ユーザーがそれと気付かずに、こうしたスクリプトが埋め込まれたページを操作すると、悪意のある攻撃者はセッションを乗っ取ったり、データを盗んだり、ユーザーを悪意のあるサイトにリダイレクトしたりできます。AI サービスのフロントエンドインターフェイス、中でもダッシュボードやプロンプトコンソールは、この攻撃に対して特に脆弱です。

OWASP による主要なアプリケーションセキュリティリスク

「OWASP Top 10」は、ウェブアプリケーションにおける一般的なセキュリティリスクを特定するための重要なフレームワークです。アクセス制御の不備、セキュリティの設定ミス、ログ記録と監視の不足などの問題が挙げられています。生成 AI ソリューションでも、ウェブアプリケーションを取り巻く幅広い脅威を緩和するために、OWASP のガイドラインに準拠する必要があります。

共通脆弱性識別子

セキュリティ専門家は、オープンソースライブラリからモデルサービングインフラストラクチャに至るまで、AI スタックのコンポーネントに影響を与える、共通脆弱性識別子 (CVE) が割り当てられた既知の脆弱性に常に注意を払う必要があります。CVE への対応を怠ると、機密性の高いモデル出力、内部 API、ユーザーデータが侵害される攻撃につながる可能性があります。

悪意のあるボットとクローラー

悪意のあるボットが AI アプリケーションを標的にし、生成されたテキスト、価格データ、独自のモデル、ペイウォールの背後にある画像などのコンテンツをスクレイピングするケースが増えています。これらのボットは正当なクローラーやスキャナーを装うこともありますが、実際にはコンテンツを大規模に収集するように設計されており、利用規約に違反したり、インフラストラクチャのコストを押し上げたりする可能性があります。

コンテンツスクレイパーと探査ツール

生成 AI システムをクロール、スクレイピング、スキャンする自動化ツールは、競合情報の収集、モデル反転攻撃、露出しているエンドポイントの探索などによく使われます。これらのツールによってプライバシーの保証が弱まり、意図しない第三者に AI の動作が知られてしまう可能性があります。

生成 AI アプリケーションのセキュリティ確保

ここでは、AWS のサービスを使用して生成 AI アプリケーションのセキュリティ確保に役立つ一般的な戦略をいくつか紹介します。

Amazon Bedrock を使用したプライベートネットワーキング

Amazon Bedrock は AWS が提供するフルマネージドサービスで、開発者は基盤モデル (FM) と、FM を特定のアプリケーション向けにカスタマイズするためのツールを利用できます。開発者は、インフラストラクチャを管理することなく、API を通じて FM を利用した生成 AI アプリケーションを構築し、スケールすることができます。典型的な環境構成を図 1 に示します。この構成には、次のネットワークコンポーネントが含まれます。

Amazon Bedrock のサービスアカウント。サービスコンポーネントを保持し、お客様のアカウントと同じ AWS リージョン内に API エンドポイントを公開します。
お客様の AWS アカウント。Amazon Bedrock を使用するアプリケーションが配置されており、このアプリケーションがクエリリクエストを送信して Amazon Bedrock API を呼び出します。
既存のデータセンター内にあるお客様の企業ネットワーク。AWS グローバルネットワークの外部にあります。ここには、同じく Amazon Bedrock を使用する必要があり、Amazon Bedrock API を呼び出すことがあるお客様のアプリケーションが配置されています。AWS Direct Connect は、パブリックインターネットを経由せずに、オンプレミスネットワークと AWS の間に専用のネットワーク接続を提供します。

Figure 1 – Private networking architecture with Amazon Bedrock

図 1 – Amazon Bedrock を使用したプライベートネットワーキングアーキテクチャ

AWS PrivateLink を使用すると、オンプレミスネットワークまたは Amazon Virtual Private Cloud (Amazon VPC) で実行されている生成 AI アプリケーションと FM の間に、トラフィックをパブリックインターネットに公開することなくプライベート接続を確立できます。Amazon VPC の場合、プライベートサブネットのインスタンスで実行されているアプリケーションが Amazon Bedrock API を呼び出します。API コールは、VPC エンドポイントポリシーが関連付けられた Amazon Bedrock の VPC エンドポイントにルーティングされ、そこから Amazon Bedrock API に送られます。Amazon Bedrock サービスの API エンドポイントは、パブリックインターネットを経由せずに PrivateLink 経由で API リクエストを受信します。NAT ゲートウェイ経由で Amazon Bedrock サービスの API に接続することもできます。この場合も、トラフィックはパブリックインターネットに公開されることなく AWS ネットワークバックボーンを通過する点に留意してください。

また、企業ネットワークから AWS Direct Connect ゲートウェイを介し、VPC エンドポイント経由で Amazon Bedrock API にプライベートにアクセスすることもできます。Direct Connect を利用していない場合は、パブリックインターネット経由で Amazon Bedrock サービスの API に接続できます (図 1 の下側の矢印)。いずれの場合も、Amazon Bedrock の API エンドポイントへのトラフィックは TLS 1.2 以降で転送中に暗号化され、Amazon Bedrock サービス内のトラフィックも少なくとも同じ基準で転送中に暗号化されます。Amazon Bedrock で処理されたお客様のコンテンツは、Amazon Bedrock を使用しているリージョン内に、暗号化された状態で保管されます。

AWS WAF を使用して生成 AI に対するレイヤー 7 の脅威を最小限に抑える

生成 AI システムがコンテンツ作成、カスタマーサービス、意思決定プロセスに欠かせない存在になるにつれて、悪意のあるボットによる脅威の標的となるケースも増えています。こうした攻撃は、出力をゆがめたり、偏りや有害な内容を含むトレーニングデータをモデルに大量に送り込んだり (データポイズニング)、脆弱性を悪用してプロンプトインジェクションを行ったり、自動化された不正利用でシステムに過負荷をかけたりします。その結果、モデルのパフォーマンス低下、誤情報の拡散、データプライバシーの侵害、ユーザーの信頼の低下などを招きます。こうした脅威を緩和するには、ユーザー認証、入力検証、異常検出、継続的な監視などの安全対策を生成 AI パイプラインに組み込む必要があります。AWS WAF は、インテリジェントな検出とルールベースの防御により、ボットによる攻撃からアプリケーション (OSI レイヤー 7) を保護するのに役立つウェブアプリケーションファイアウォールです。AWS WAF の Bot Control 機能は、正当なボットを許可しつつ、有害なボットを識別して除外します。AWS WAF は、レート制限、カスタムルール、異常検出によって、スクレイピング、クレデンシャルスタッフィング、DDoS 攻撃の試みをブロックできます。Anti-DDoS ルールグループは、HTTP リクエストフラッドを伴うアプリケーションへの攻撃の自動緩和に特化しており、マネージドルールグループとして AWS WAF で利用できます。このルールグループは、こうした変化の速い脅威に対処するためのさまざまな AWS WAF ルールや ACL の管理に伴う複雑さを解消します。

AWS WAF は、Amazon CloudFront、Amazon API Gateway、Application Load Balancer (ALB) で有効化でき、これらのサービスと共にデプロイされます (図 2)。これらの AWS サービスが TCP/TLS 接続を終端し、受信した HTTP リクエストを処理してから、リクエストを AWS WAF に転送して検査とフィルタリングを行います。リバースプロキシ、DNS の設定、TLS 証明書は不要です。

Figure 2 – Architecture using AWS WAF to minimize layer 7 generative AI threats

図 2 – AWS WAF を使用して生成 AI に対するレイヤー 7 の脅威を最小限に抑えるアーキテクチャ

生成 AI アプリケーションに対する DDoS をエッジで緩和する

DDoS 攻撃は、大量のトラフィックでサーバーに過負荷をかけ、レイテンシーの増加、パフォーマンスの低下、さらには完全な停止を引き起こすため、生成 AI アプリケーションにとって深刻な脅威です。生成 AI ワークロード (チャットボット、画像生成ツール、コーディングアシスタントなど) は多くの場合リソースを大量に消費し、リアルタイムで動作するため、短時間の中断であってもユーザーエクスペリエンスや信頼に影響する可能性があります。さらに、DDoS 攻撃は、データの窃取やプロンプトインジェクションなど、他の攻撃を隠すための煙幕として使われることもあります。可用性とサービスの継続性を維持するには、レート制限、トラフィックフィルタリング、自動でスケールするインフラストラクチャなどのスケーラブルな防御策で生成 AI システムを保護することが重要です。

AWS Shield は、常時有効な検出と自動緩和により、生成 AI アプリケーションを DDoS 攻撃から保護します。スタンダード階層である AWS Shield Standard は、一般的なボリューム型攻撃と状態枯渇攻撃を追加料金なしで防御します。より高度な保護が必要な場合は、AWS Shield Advanced を使用すると、リアルタイムの脅威インテリジェンスと適応型レート制限を利用できるほか、AWS Shield Response Team (SRT) の支援を 24 時間 365 日受けられます。SRT のサービスを利用するには、ビジネスサポートプランまたはエンタープライズサポートプランへの加入が必要です。これにより、高可用性と低レイテンシーが求められることの多い生成 AI サービスが、脅威にさらされても回復力を保ち、大規模なトラフィックの急増時にもパフォーマンスとアップタイムを維持しやすくなります。Amazon CloudFront や Elastic Load Balancing などのサービスと統合することで、スケーラビリティと保護をさらに強化できます (図 3)。

Figure 3 – Help protect your applications from DDoS attack by using AWS Shield Advance at the edge

図 3 – エッジで AWS Shield Advanced を使用してアプリケーションを DDoS 攻撃から保護する

生成 AI アプリケーション向けの境界ファイアウォール

AWS Network Firewall は、ステートフルおよびステートレスのパケット検査、侵入防止 (IPS)、ドメインフィルタリングの機能を Amazon VPC に直接デプロイできるマネージドネットワークセキュリティサービスです。サブネットレベルで、インバウンドとアウトバウンドの両方のトラフィックを検査し、フィルタリングできます。生成 AI アプリケーションでは、独自のアプライアンスやプロキシを管理する手間をかけずに、きめ細かなトラフィック制御を適用できます。AWS Network Firewall では、カスタムのステートレスルールやステートフルルールを作成して、特定のペイロード、既知のシグネチャ、異常なトラフィックパターンをブロックできます。マルチモデル環境やマルチテナント環境では、ファイアウォールで East-West 方向のセグメンテーションを適用することで、侵害されたマイクロサービスから他の AI コンポーネントや機密性の高いサービスへの横方向のアクセスを防ぐのに役立ちます。Network Firewall は、生成 AI アプリケーションがアクセスしている特定のサイトのホスト名を収集する用途にも有効です。このプロセスはエグレスフィルタリング (egress filtering) と呼ばれ、攻撃者が生成 AI ワークロードを侵害し、外部のコマンドアンドコントロールシステムへの接続を確立しようとする場合に特に役立ちます。Network Firewall を使用して、特定のセキュリティ要件を満たさないパケットをブロックすることで、アウトバウンドトラフィックの保護に役立てることができます。

悪意のあるアクティビティの監視

進化し続けるセキュリティの脅威から生成 AI アプリケーションを保護するには、悪意のあるアクティビティの監視が欠かせません。生成 AI アプリケーションは予測できないユーザー入力を処理し、動的な出力を生成するため、特に悪用されやすい性質があります。継続的に監視することで、潜在的な攻撃の兆候となりうる異常なトラフィックパターン、過剰な API 使用、異常な入力パターンを早期に検出できます。また、プロンプトインジェクション、敵対的な入力、モデルのレスポンスから機密情報を引き出そうとする試みなどによる AI モデルの不正利用の防止にも役立ちます。さらに監視は、放置すれば AI サービスの可用性を損なうおそれのある DDoS の試みやリソースの不正利用を特定するうえでも、重要な役割を果たします。リアルタイムのアクティビティを観察して分析することで、組織は、悪意のある攻撃者のブロック、セキュリティコントロールの調整、生成 AI アプリケーションの完全性と信頼性の維持に向けて、予防的な対策を講じることができます。脅威検出サービスである Amazon GuardDuty は、AWS アカウントのアクティビティ、ネットワークフローログ、DNS クエリを継続的に分析し、環境を標的とした潜在的な侵害や悪意のある動作を検出します。GuardDuty は、AWS 認証情報の流出や、ユーザーによる Amazon SageMaker AI API の不審な利用などの疑わしいアクティビティを識別します。さらに GuardDuty は、Amazon Simple Storage Service (Amazon S3)、Amazon Relational Database Service (Amazon RDS)、Amazon Elastic Kubernetes Service (Amazon EKS)、EKS Runtime Monitoring、Amazon ECS および Amazon EC2 向けの Runtime Monitoring、Amazon EC2 および S3 向けの Malware Protection、AWS Lambda Protection の保護プランも提供しています。Amazon Inspector は、AWS ワークロードにソフトウェアの脆弱性や意図しないネットワークの露出がないかを継続的にスキャンする、自動化された脆弱性管理サービスです。Amazon Detective は、調査プロセスを簡素化し、セキュリティチームがより迅速かつ効果的にフォレンジック調査を行えるよう支援します。

生成 AI のためのネットワーク多層防御

他のモダンアプリケーションと同様に、生成 AI アプリケーションのネットワークアーキテクチャを設計する際にも、多層防御のアプローチが推奨されます。図 4 は、AWS のサービスを活用して多層防御を実現した、生成 AI アプリケーションの完全なリファレンスアーキテクチャです。

Figure 4 – Workflow for generative AI network defense in depth

図 4 – 生成 AI のネットワーク多層防御のワークフロー

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

クライアントがアプリケーションにリクエストを送信します。DNS によって、クライアントは AWS WAF と Shield がデプロイされている CloudFront ロケーションに誘導されます。
CloudFront は、リクエストを AWS WAF ルールで評価し、トラフィックをブロック、監視、許可のいずれにするかを判断します。Shield は、既知の DDoS 攻撃ベクトルやゼロデイ攻撃ベクトルを幅広く緩和できます。設定によっては、Shield Advanced と AWS WAF が連携して、個々の IP アドレスからのトラフィックにレート制限を適用します。AWS WAF または Shield Advanced がトラフィックをブロックしなかった場合、トラフィックは CloudFront のルーティングルールに送られます。
CloudFront はトラフィックを ALB に送信します。ただし、ALB に到達する前に、トラフィックは Network Firewall エンドポイントで検査されます。Network Firewall はディープパケットインスペクションをサポートしており、インターネット、別の VPC、または別のサブネット宛てのインバウンドおよびアウトバウンドの TLS トラフィックを復号、検査、再暗号化することで、データの保護に役立ちます。この段階で、追加の安全対策を講じて脅威アクターのアクセスを制限することもできます。高リスクの国からのトラフィックが想定されない場合は、地理的ブロックでアクセスを制限するか、少なくとも、トラフィックが想定されない国に対しては、イングレスでは AWS WAF ルール、エグレスでは Network Firewall を使用して厳格なレート制限を設定することをお勧めします。

注: Amazon CloudFront の地理的制限を使用して特定の国からのコンテンツへのアクセスをブロックすると、CloudFront はその国からのリクエストをすべてブロックし、AWS WAF には転送しません。地理情報に基づいて AWS WAF の条件でリクエストを許可またはブロックするには、代わりに AWS WAF の地理的一致ルールステートメントを使用してください。
ALB はパブリックサブネットに配置されています。ALB を使用してアプリケーションを実行するインスタンスを外部から分離するとともに、AWS WAF で一般的なレイヤー 7 の攻撃からの保護をさらに強化できます。
ALB のターゲットグループは、プライベートサブネットで生成 AI アプリケーションを実行しているインスタンスで構成されています。セキュリティグループ、ネットワーク ACL (NACL)、セグメンテーションなど、VPC の基本的な構成要素を使用して、インスタンスとそのネットワークインターフェイスの保護に役立てることができます。
アプリケーションが Amazon Bedrock API を呼び出します。PrivateLink を使用すると、VPC と Amazon Bedrock の間にプライベート接続を作成できます。これにより、インターネットゲートウェイ、NAT デバイス、VPN 接続、Direct Connect 接続を使用せずに、Amazon Bedrock が VPC 内にあるかのようにアクセスできます。VPC 内のインスタンスは、パブリック IP アドレスがなくても Amazon Bedrock にアクセスできます。このプライベート接続は、PrivateLink を利用したインターフェイスエンドポイントを作成することで確立します。インターフェイスエンドポイントで有効にする各サブネットに、エンドポイントネットワークインターフェイスを作成します。これらは、Amazon Bedrock 宛てのトラフィックのエントリポイントとして機能する、リクエスタマネージド型ネットワークインターフェイスです。
Amazon VPC コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、Amazon Bedrock のインターフェイスエンドポイントを作成します。Amazon Bedrock のインターフェイスエンドポイントを作成する際に使用するサービス名は com.amazonaws.region.bedrock-runtime です。
インターフェイスエンドポイントのエンドポイントポリシーを作成します。エンドポイントポリシーは、インターフェイスエンドポイントにアタッチできる AWS Identity and Access Management (IAM) リソースです。デフォルトのエンドポイントポリシーでは、インターフェイスエンドポイントを介した Amazon Bedrock へのフルアクセスが許可されます。VPC から Amazon Bedrock へのアクセスを制御するには、カスタムエンドポイントポリシーをインターフェイスエンドポイントにアタッチします。カスタムエンドポイントポリシーの例を図 4 に示します。このポリシーをインターフェイスエンドポイントにアタッチすると、すべてのプリンシパルに対して、すべてのリソースを対象に、リストに記載された Amazon Bedrock アクションへのアクセスが許可されます。
このソリューションでは、Amazon CloudWatch を使用してさまざまなサービスから運用メトリクスを収集し、デプロイのパフォーマンスと運用状態の監視に使用できるカスタムダッシュボードを生成します。
戻りのトラフィックは、同じ経路を逆方向にたどります。

まとめ

この記事では、強力なセキュリティコントロールを維持しながら AWS 上に生成 AI アプリケーションをデプロイするための堅牢な基盤となる、セキュアなネットワーク設計の原則を紹介しました。ここで紹介したパターンを実装することで、機密データとインフラストラクチャを保護しながら、AI の機能を安心して活用できます。

生成 AI のセキュリティについて、さらに他の分野も詳しく知りたい方は、「生成 AI をセキュアにする」シリーズの他の記事もご覧ください。

パート 1 – 生成 AI をセキュアにする: 生成 AI セキュリティスコーピングマトリックスの紹介
パート 2 – 生成 AI ワークロードにおけるレジリエンス設計
パート 3 – 生成 AI をセキュアにする: 関連するセキュリティコントロールの適用
パート 4 – 生成 AI をセキュアにする: データ、コンプライアンス、プライバシーに関する考慮点
パート 5 – AWS のサービスで構築する生成 AI アプリケーションのセキュアなネットワークアーキテクチャ (この記事)

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ