Nginx
イベント
マガジン
技術ブログ
本ブログは 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 の間に専用のネットワーク接続を提供します。 図 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 証明書は不要です。 図 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)。 図 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 アプリケーションの完全なリファレンスアーキテクチャです。 図 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 アプリケーションのセキュアなネットワークアーキテクチャ (この記事) Joydipto Banerjee Joydipto は AWS Financial Services の Solutions Architect です。ソフトウェアアーキテクチャの経験に加え、ビジネスワークロードやクリティカルなワークロードを含むソリューションの開発に携わってきました。大手銀行や金融機関と協力し、AWS のツールやサービスを活用してイノベーションを推進し、新しいデジタル製品を構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。
本ブログは 2025 年 8 月 11 日に公開された AWS Blog “ Amazon EC2 defenses against L1TF Reloaded ” を翻訳したものです。 AWS Nitro System および Nitro Hypervisor を使用する AWS のお客様のゲストデータが、「L1TF Reloaded」と呼ばれる攻撃によって危険にさらされることはありません。お客様による追加の対応は不要です。ただし AWS は、AWS の公開ドキュメントに記載されているとおり、インスタンス、エンクレーブ、または関数の境界を使用してワークロードを分離することを引き続き推奨しています。AWS Nitro System と Nitro Hypervisor は、この種の攻撃からの保護に役立つように設計されています。 研究論文「 Rain: Transiently Leaking Data from Public Clouds Using Old Vulnerabilities 」と、その講演「 Spectre in the real world: Leaking your private data from the cloud with CPU vulnerabilities 」では、L1TF Reloaded という攻撃が実証されています。この攻撃は、ハーフ Spectre ガジェット (half-Spectre gadget) と L1 Terminal Fault (L1TF) を組み合わせてゲストデータを漏洩させるものです。アップストリームの Linux/カーネルベース仮想マシン (KVM) や他のクラウドプロバイダーからはゲストデータを漏洩させることに成功していますが、 AWS Nitro System および Nitro Hypervisor を使用する AWS のお客様のゲストデータには影響しません。 Nitro Hypervisor が L1TF Reloaded を防げているのは、特定のパッチや事後的な緩和策によるものではなく、AWS がセキュリティに対してプロアクティブなアプローチを取っているためです。Nitro Hypervisor の基本的なセキュリティ設計原則は、この種の攻撃に対して強力な保護を提供します。特に重要なのが、 XPFO (eXclusive Page Frame Ownership) の概念 (文脈によっては プロセスローカル メモリ とも呼ばれます) を広範に活用したシークレットハイディング (secret hiding) の実装です。L1TF Reloaded は、一時的実行攻撃 (transient execution attack) における革新的な手法です。この攻撃は、一見すると緩和済みの脆弱性を脅威アクターが組み合わせることで、個々の要素の総和を超える新たな攻撃を生み出せることを示しています。この研究はすばらしいもので、実環境に適用可能な多層的なエンドツーエンドのエクスプロイトを構築しています。AWS はこの研究の一部をスポンサーとして支援しました。また、研究者の皆様の協力と協調的な情報開示に感謝いたします。以降では、公開された研究について詳しく解説します。 Nitro Hypervisor: セキュリティのための専用設計 Nitro Hypervisor は AWS Nitro System の基盤となるコンポーネントであり、セキュリティを最優先事項として一から設計されています。汎用オペレーティングシステムから発展してきた従来のハイパーバイザーとは異なり、Linux/KVM をベースとする Nitro Hypervisor は意図的に最小化されており、割り当てられた役割の遂行に必要な機能だけを備えた専用設計となっています。 Nitro Hypervisor の役割は、意図的に限定されています。Nitro Hypervisor は、Nitro Controller から仮想マシン (VM) の管理リクエストを受け取り、ハードウェアの仮想化機能を使用してメモリと CPU リソースを分割し、PCIe デバイスを VM に割り当てます。これらの PCIe デバイスには、Nitro ハードウェアが提供する物理機能 (PF) とシングルルート I/O 仮想化 (SR-IOV) の仮想機能 (VF) の両方が含まれます。例えば、EBS およびインスタンスストレージ用の NVMe や、ネットワーク用の Elastic Network Adapter がこれに該当します。さらに、サードパーティーのデバイス (GPU) も含まれます。重要な点として、Nitro Hypervisor では、従来のハイパーバイザーに存在する機能がカテゴリごと除外されています。ネットワークスタック、汎用ファイルシステムの実装、周辺機器のデバイスドライバーのサポート、シェル、対話型アクセスモードは一切ありません。このように不要な機能を徹底的に除外することで、リモートネットワーク攻撃やドライバーを悪用した権限昇格など、他のハイパーバイザーに影響しうる問題や攻撃ベクトルのカテゴリ全体を回避しやすくなります。 一時的実行の脆弱性の理解 Nitro Hypervisor の防御が L1TF Reloaded に有効である理由を理解するには、まず 2018 年に明らかになった一時的実行の脆弱性の基本を理解しておくことが重要です。現代の CPU は、アウトオブオーダー実行や、予測に基づく投機的実行を実装しています。これにより、操作が必要になる前、あるいはその操作を実行すべきかどうかを CPU が判断する前に操作を実行して、パフォーマンスを最適化しています。予測が誤っていた場合や、実行時のフォールトが発生した場合、CPU は最終的にこれらのエラーを検出し、投機的に計算されたアーキテクチャ状態への変更をすべてロールバックします。しかし、こうした「一時的実行」の痕跡は、CPU キャッシュに投機的に読み込まれたデータなど、マイクロアーキテクチャ状態に検出可能な形で残ります。その結果、サイドチャネル攻撃によってデータが漏洩する余地が生まれます。 ハーフ Spectre ガジェット: 不完全だが危険なコードパターン 従来の Spectre 攻撃には、シークレットデータへのアクセスと、サイドチャネルを通じたそのデータの送信の両方を行う、完全な「ガジェット」が必要です。これに対して研究者たちは、「ハーフ Spectre ガジェット」と呼ばれる、より弱いクラスのガジェットを特定しました。これは、投機的な境界外メモリアクセスを実行するものの、それだけで悪用可能になるための送信コンポーネントを備えていない、不完全な Spectre 類似のコードパターンです。 典型的な Spectre v1 ガジェットには、2 つの主要な要素があります。1 つ目は、シークレットデータを読み込む投機的アクセスです (例えば、 x = A[index] で index が境界外である場合)。2 つ目は、サイドチャネルを通じてデータを漏洩させる送信メカニズムです (例えば、 y = B[64 * x] のように、シークレット値に基づいたキャッシュパターンを生成するもの)。ハーフ Spectre ガジェットには、1 つ目の要素である投機的アクセスのみが含まれ、送信コンポーネントは含まれていません。 ハーフ Spectre ガジェットは単独では無害に見えるため、ハイパーバイザーを含むさまざまなソフトウェアに広く存在しています。これらのガジェットは通常、境界チェックを伴う配列インデックス操作から生じます。しかし、境界チェックの結果が確定する前の一時的実行のウィンドウでは、境界外アクセスが可能になります。ガジェットには、絶対型 (アクセスするアドレスを直接指定する) と相対型 (ベースアドレスからのオフセットを制御する) があり、一般的な配列インデックスのパターンにより、相対型ガジェットの方が多く見られます。L1TF Reloaded の重要な洞察は、ハーフ Spectre ガジェットは単独では無害であっても、L1TF のような他の脆弱性と組み合わせると危険になるという点です。脅威アクターは、ハイパーバイザー内のハーフ Spectre ガジェットをトリガーして任意のデータを L1 データキャッシュに投機的に読み込ませ、その後 L1TF を使用してキャッシュされたデータを抽出できます。これにより、「無害な」ハーフ Spectre ガジェットが、事実上完全なガジェットに変わります。 Intel L1TF: 投機的なアドレス変換の悪用 L1TF は、2018 年 1 月に発見され、2018 年 8 月に公開された、一時的実行の脆弱性の中でも重大なものです。この脆弱性は、Coffee Lake までの Intel プロセッサに影響します。これらのプロセッサは、一部の第 5 世代 EC2 インスタンスファミリーと、それより古いすべてのインスタンスタイプで使用されています。L1TF は、一時的実行中に無効なページテーブルエントリにアクセスした際に発生する、誤ったアドレス変換を悪用します。通常の動作では、present ビットがクリアされている、または予約ビットが設定されているページテーブルエントリ (PTE) に CPU が遭遇すると、アドレス変換は直ちに停止するはずです。しかし、L1TF の影響を受ける Intel プロセッサは、一時的実行中にこうした無効なページテーブルの状態を無視し、部分的に変換されたアドレスを使用します。対象データが L1 データキャッシュに存在する場合、本来はブロックされるべきアクセスであるにもかかわらず、CPU はそのデータを投機的に読み込み、後続の命令から利用できるようにします。この動作は、仮想化環境で特に問題になります。悪意のあるゲストオペレーティングシステムは、自身のページテーブルの present ビットを意図的にクリアして、ターミナルフォールトをトリガーできます。すると CPU は、通常のホストアドレス変換プロセスをスキップし、ゲストの物理アドレスを L1 データキャッシュに直接渡します。これにより、脅威アクターは、所有権や特権の境界に関係なく、システム上のキャッシュされた任意の物理メモリを読み取れる可能性があります。影響を受けるプロセッサにおいて、ソフトウェアで包括的に緩和するには、同時マルチスレッディング (SMT) の無効化、コンテキストスイッチごとの L1 データキャッシュのフラッシュ、拡張ページテーブル (EPT) の完全な無効化といった、コストの高い対策が必要です。これらのパフォーマンスへの影響は非常に大きいため、多くのシステムでは部分的な緩和策しか実装されていません。 L1TF Reloaded 攻撃: Spectre を使って緩和策の不備を悪用 この研究論文は、脅威アクターがハーフ Spectre ガジェットと L1TF を組み合わせることで、前述の緩和策が完全には実装されていないハイパーバイザーに対する強力な攻撃ベクトルを生み出せることを実証しています。この攻撃は、個別には緩和済みとみなされている脆弱性であっても、新しい方法で組み合わせれば依然として悪用できることを示しています。L1TF の緩和策である L1 データキャッシュのフラッシュやコアスケジューリングは、ゲスト間の攻撃の防止には役立ちますが、ゲストからホストへの攻撃を完全には緩和できません。L1TF Reloaded は、この点を突いた攻撃です。この攻撃は、SMT コア内で L1 データキャッシュを共有する論理コアにまたがって動作します。脅威アクターは、一方の論理コアでハーフ Spectre ガジェットをトリガーします。分岐予測器を意図的に誤学習させることで、ハイパーバイザーに境界外メモリへ投機的にアクセスさせ、機密データを共有 L1 データキャッシュに読み込ませます。同時に、もう一方の論理コアで L1TF を使用して、キャッシュされたデータを抽出します。 他の研究論文でも L1TF の悪用は実証されています が、この研究論文は、アップストリームの Linux/KVM や他のクラウドプロバイダーに対する多層的なエンドツーエンドの攻撃の実証に成功しました。著者らが実行した手順は次のとおりです。まず、既存のハーフ Spectre ガジェットを使用してホストのカーネルアドレス空間配置のランダム化 (KASLR) を突破し、ホストのアドレス変換機能を獲得しました。次に、ホスト上で実行されているすべてのプロセスを見つけ出し、被害者の VM を特定しました。さらに、ゲストの KASLR を突破してゲストのアドレス変換機能を獲得し、被害者の VM 内の init プロセスを特定しました。その後、init プロセスの子プロセスを列挙して nginx ウェブサーバーのプロセスを特定し、ゲストプロセスのヒープ内でプライベート TLS 証明書を見つけ出し、最終的にその証明書を漏洩させました。しかし、AWS インスタンスで同じ攻撃を試みたところ、著者らは重大な制約に直面しました。機密性のない一部のホストデータは漏洩させることができたものの、ゲストデータにはアクセスできなかったのです。著者らはその原因を「ハイパーバイザー内に存在する、被害者のデータをハイパーバイザーからアンマップする文書化されていない防御」と説明しています。この「文書化されていない防御」こそが Nitro Hypervisor によるシークレットハイディングの実装であり、この種の攻撃を防いだアーキテクチャ上の基本的な設計判断です。 シークレットハイディング: ハイパーバイザーのメモリアーキテクチャの再考 従来のハイパーバイザーの設計は、上位の特権レベルがそれより下位のレベルのすべてのメモリにアクセスできる、階層型の特権モデルに従っています。従来のシステムでは、最も高い特権レベルで実行されるハイパーバイザーが、正当な管理目的という名目で、すべての VM メモリにアクセスできます。しかし、この設計には脆弱性があります。脅威アクターがハイパーバイザーをだましてゲストデータに投機的にアクセスさせることができれば、そのデータはサイドチャネル攻撃によって抽出可能になってしまうのです。Nitro Hypervisor は、シークレットハイディングと呼ばれる手法によって、根本的に異なるアプローチを採用しています。ハイパーバイザーがすべての VM メモリにアクセスできる従来のモデル (図 1) に従うのではなく、ゲストデータがハイパーバイザーの仮想アドレス空間に存在しないようにしています。AWS は、VM メモリページをハイパーバイザーの仮想アドレス空間から取り除く (図 2) ことで、たとえ脅威アクターがハイパーバイザー内のガジェットをトリガーできたとしても、一時的実行攻撃によってゲストデータにアクセスされる可能性を排除しています。 図 1: VM1 のコンテキストにおける、緩和策のないハイパーバイザーのメモリビュー 図 2: VM1 のコンテキストにおける Nitro Hypervisor のメモリビュー。ゲストメモリはマッピングされておらず、アクセスできるのはアクティブなゲストの状態のみです。他のゲストの状態にはアクセスできません。 このアーキテクチャ上の設計判断により、L1TF、ハーフ Spectre ガジェット、その他の一時的実行の脆弱性のいずれによって Nitro Hypervisor で一時的実行が発生しても、漏洩しうるゲストデータがそもそも存在しません。これが、この種の脆弱性に対する障壁となります。Nitro Hypervisor がアクセスできるのは自身のデータのみであり、ゲストデータは分離され、アクセスできない状態に保たれます。AWS は、L1TF Reloaded そのものを正確に予測できたわけではありません。しかし、一時的実行の脆弱性が今後も発見され続けることはわかっていたため、AWS インスタンス上のゲストデータの抽出を阻止する多層防御の仕組みを構築しました。この設計判断は、Nitro Hypervisor の開発時にプロアクティブに行われたもので、ハイパーバイザーを悪用するゲストからホストへの攻撃を明示的に想定した AWS の脅威モデルに基づいています。AWS は、L1TF のような既知の脆弱性か、将来の未知の攻撃ベクトルかを問わず、脅威アクターが Nitro Hypervisor 内で一時的実行の脆弱性をトリガーする方法を見つけ出す可能性があると想定しました。そのうえで、こうした攻撃の影響範囲を当初から限定するようにシステムを設計しました。 メモリにとどまらず: ゲスト CPU コンテキストの保護 VM のスケジューリングやコンテキストスイッチの際には、汎用レジスタや浮動小数点レジスタの内容などのゲスト CPU コンテキスト情報を保存および復元する必要があります。ゲスト CPU コンテキストには、機密性の高い情報が含まれる場合があります。例えば、レジスタには、暗号鍵、アドレス空間配置のランダム化 (ASLR) を突破しうるメモリアドレス、アプリケーションがセキュリティのために依存しているその他のシークレットが含まれている可能性があります。従来のハイパーバイザーでは、ゲスト CPU コンテキストはハイパーバイザーからアクセス可能なメモリに保存されることが多く、一時的実行攻撃のもう 1 つの潜在的な標的となります。元の XPFO の実装では、メモリページにアクセスできるのはユーザー空間とカーネルのどちらか一方のみであり、両方がアクセスすることはできません。ただし、ゲスト CPU コンテキストはカーネルが排他的に所有しているため、保護の対象外です。Nitro Hypervisor は、XPFO の概念をゲスト CPU コンテキストにまで拡張しています。前述の図 2 に示すように、ゲスト CPU コンテキストは、プロセス固有のカーネル PTE によってのみマッピングされるメモリ (プロセスローカルメモリとも呼ばれます) に保存されます。このメモリは、所属するプロセスのコンテキストにおいてのみ、Nitro Hypervisor からアクセスできるように設計されています。そのため、たとえ脅威アクターが Nitro Hypervisor 内で一時的実行の脆弱性をトリガーできたとしても、他のゲストの CPU コンテキストにはアクセスできません。研究者たちもこの保護を確認しており、AWS の脅威モデルがゲストからホストへの攻撃を考慮していること、そしてシークレットハイディングが既存の L1 データキャッシュのフラッシュおよびコアスケジューリングと組み合わさることで、ゲストデータの漏洩を防いだことを指摘しています。シークレットハイディングに対するこの包括的なアプローチは、Nitro System の多層防御の理念を示しています。既知の攻撃ベクトルへの対策にとどまらず、 AWS は、ゲストデータの漏洩につながる潜在的な発生源を体系的に特定して保護しています 。これには、VM メモリとゲスト CPU コンテキストの両方が含まれます。 Xen へのシークレットハイディングの原則の適用 現在、AWS の Xen インスタンスの大部分は AWS Nitro System 上で実行されており、 Xen-on-Nitro によって Nitro Hypervisor のメリットを享受しています。AWS Xen Hypervisor 上で実行されるインスタンスファミリーについても、AWS は一時的実行攻撃から保護するために、同様の シークレット ハイディング の原則を実装しています。 多層防御: Nitro Hypervisor の実証されたセキュリティモデル L1TF Reloaded は、一見すると緩和済みの脆弱性を組み合わせて新たな攻撃ベクトルを生み出せることについての理解を大きく深めるものです。Rain 論文の研究者たちは、L1TF とハーフ Spectre ガジェットを連携させて、ハイパーバイザーからゲストデータを漏洩させる方法を実証しました。AWS は、研究者たちの取り組みを支援し、協力できることをうれしく思います。Nitro Hypervisor が L1TF Reloaded を防げているのは、特定のパッチや事後的な緩和策によるものではなく、高度な攻撃者からマルチテナントのクラウド環境を保護するために AWS が多大な投資を続けてきた結果です。この研究により、既知および未知の攻撃ベクトルに対する Nitro System のセキュリティモデルへの確信がさらに強まりました。AWS のプロアクティブなセキュリティアプローチには、多層防御の原則に基づいてシステムを一から設計することが含まれます。脅威の状況は今後も変化し続けます。それと同時に、Nitro Hypervisor や AWS のその他の製品およびサービスに組み込まれた多層防御の仕組みは、お客様が必要とするパフォーマンスと機能を維持しながら、今後も高度な攻撃から AWS のお客様を保護するのに役立ちます。 この記事に関するご質問やフィードバックがある場合は、 AWS サポートにお問い合わせ ください。 Ali Saidi Ali は AWS のバイスプレジデント兼 Distinguished Engineer です。ミシガン大学でコンピュータサイエンスおよびエンジニアリングの博士号を取得しています。2017 年に AWS に入社して以来、AWS Nitro System、AWS Graviton、EC2 インスタンスファミリーの設計と開発に注力しています。 Filippo Sironi Filippo は AWS の Sr. Principal Engineer です。ミラノ工科大学でコンピュータサイエンスエンジニアリングの博士号を取得しています。2015 年に AWS に入社して以来、AWS Nitro System、Nitro Hypervisor、および EC2 の Core、High Memory、高速コンピューティングインスタンスファミリーの設計と開発に注力しています。 Moritz Lipp Moritz は AWS の Sr. Security Engineer です。グラーツ工科大学でコンピュータサイエンスの博士号を取得しており、在学中はマイクロアーキテクチャ攻撃を専門としていました。2022 年に AWS に入社して以来、ハードウェアセキュリティの研究と安全なシステムアーキテクチャの開発を通じて、クラウドインフラストラクチャの保護に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。
動画
該当するコンテンツが見つかりませんでした
