OWASP Top 10 for LLM を活用した生成 AI アプリケーションの多層防御セキュリティ設計

本稿は、2024年1月26日に公開された “Architect defense-in-depth security for generative AI applications using the OWASP Top 10 for LLMs” を翻訳したものです。

大規模言語モデル (LLM) を中心に構成された生成 AI (人工知能) アプリケーションは、ビジネスに経済的価値を生み出し、さらに加速する可能性を示してきました。アプリケーションの例には、会話型検索、カスタマーサポートエージェントアシスト、カスタマーサポート分析、セルフサービス仮想アシスタント、チャットボット、リッチメディア生成、コンテンツモデレーション、セキュアで高パフォーマンスなソフトウェア開発を加速するコーディングコンパニオン、マルチモーダルコンテンツソースからのより深いインサイト、組織のセキュリティ調査と緩和策の加速などがあります。多くのお客様が、生成 AI アプリケーションを開発する際に、セキュリティ、プライバシー、コンプライアンスの管理手法についてのガイダンスを求めています。設計およびアーキテクティングのフェーズで LLM の脆弱性、脅威、リスクを理解し対処することで、チームは経済性および生産性のメリットを最大化することに集中できます。リスクを認識することは、生成 AI アプリケーションの透明性と信頼性を高め、可観測性を向上させ、コンプライアンス要件を満たすのに役立ち、十分な情報に基づくリーダーの意思決定を促進します。

この記事の目的は、AI と機械学習 (ML) のエンジニア、データサイエンティスト、ソリューションアーキテクト、セキュリティチーム、その他のステークホルダーが、共通のメンタルモデルとフレームワークを持ち、セキュリティのベストプラクティスを適用できるようにすることです。これにより、AI/ML チームは、セキュリティを犠牲にすることなく、スピードを上げることができます。具体的には、これまでセキュリティの原則について触れたことのない AI/ML およびデータサイエンティストが、LLM を使用した生成 AI アプリケーションの開発に関連する中核となるセキュリティとプライバシーのベストプラクティスを理解するのに役立つことを目的としています。また、Open Worldwide Application Security Project (OWASP) Top 10 for LLM Applications によって特定された、AI への信頼を損なう可能性のある一般的なセキュリティ上の懸念についても説明します。そして、生成 AI でイノベーションを起こしながら、AWSを使用してセキュリティ態勢と信頼性を高める方法を示します。

この記事では、LLM を使用して生成 AI アプリケーションを開発する際に、リスク管理戦略を構築するための 3 つの手順を紹介します。まず、LLM ソリューションの実装、デプロイ、使用から生じる脆弱性、脅威、リスクについて掘り下げ、セキュリティを念頭に置いたイノベーションの始め方についてのガイダンスを提供します。次に、安全な基盤の上に構築することが、生成 AI にとって不可欠である理由について説明します。最後に、これらを LLM ワークロードの例と結び付けて、信頼境界を越えた多層防御のセキュリティを構築するためのアプローチを説明します。

この記事により、AI/ML エンジニア、データサイエンティスト、セキュリティ指向の技術者は、生成 AI アプリケーションのための多層防御を設計する戦略を特定し、OWASP Top 10 for LLM のセキュリティ上の懸念への対応策を理解できます。そして、お客様のアプリケーションに関する、次のようなよくある質問に答えるための基礎的な知識を構築できるようになります。

LLM ベースの生成 AI をアプリケーションで使用する際の、一般的なセキュリティとプライバシーのリスクのうち、この記事に示すガイダンスにより最も影響があるものは何ですか ?
AWS 上の生成 AI アプリケーションの開発ライフサイクルにセキュリティとプライバシー制御を実装するにはどのような方法がありますか ?
LLM を使用した生成 AI アプリケーションのリスクを管理し信頼性を高めるために、組織が生成 AI アプリケーションを構築する方法において、どのような運用面および技術面でのベストプラクティスを組み込むことができますか ?

生成 AI の開発をしながらセキュリティレベルを高める

LLM を使用した生成 AI でイノベーションを起こすためには、セキュリティを念頭に置き、組織のレジリエンスを高め、安全な基盤の上に構築し、多層防御のセキュリティアプローチと統合する必要があります。セキュリティは、AWS と AWS のお客様の間で共有される責任です。 AWS 責任共有モデルのすべての原則が、生成 AI ソリューションに適用されます。LLM ソリューションを構築する際に、インフラストラクチャ、サービス、データ適用される AWS 責任共有モデルを新たに理解しましょう。

セキュリティを念頭において組織のレジリエンスを構築する

セキュリティを念頭に置き、セキュリティとコンプライアンスの目標を満たす生成 AI アプリケーション開発のための組織のレジリエンスを構築します。組織のレジリエンスは、AWS Well-Architected フレームワークのレジリエンシーの定義を取り入れ拡張したもので、組織が混乱から回復する能力が含まれています。 LLM を使用した生成 AI を開発するための全体的な準備状況と、潜在的な影響に対する組織のレジリエンスを評価する際は、セキュリティ態勢、ガバナンス、およびオペレーショナルエクセレンスの優位性を考慮してください。組織が生成 AI や LLM などの新興テクノロジーの利用を進めるにつれ、資産や事業部門を意図しない結果から保護するための多層防御の基礎として、組織全体のレジリエンスを考慮する必要があります。

組織のレジリエンスは LLM アプリケーションにとって極めて重要です

すべてのリスク管理プログラムではレジリエンスから恩恵を受けることができますが、組織のレジリエンスは生成 AI にとって非常に重要です。LLM アプリケーションの上位 10 のリスクのうち OWASP が特定した 5 つは、リスクを管理するためにアーキテクチャおよび運用上のコントロールを定義し、組織規模でそれらを適用することに依存しています。これら 5 つのリスクは、安全が確認されていない出力ハンドリング、サプライチェーンの脆弱性、機密情報の漏えい、過剰な代理行為、過度の信頼です。アイデアの発案から研究、アプリケーションの開発、デプロイ、使用に至る製品のライフサイクル全体で、AI、ML、生成 AI のセキュリティを中心的なビジネス要件であり最優先事項であるとチームに認識させることで、組織のレジリエンスを高めることから始めてください。意識の向上に加えて、チームはガバナンス、保証、コンプライアンス検証の実践の中で生成 AI を考慮するための行動を取る必要があります。

生成 AI を中心に組織のレジリエンスを構築する

組織は、組織内での AI/ML および生成 AI セキュリティのための能力と機能を構築する方法を採用し始めることができます。まずは既存のセキュリティ、保証、コンプライアンス、開発プログラムを拡張して、生成 AI を考慮することから始める必要があります。

組織の AI、ML、および生成 AI のセキュリティにおける 5 つの主要な関心領域は以下の通りです。

AI/ML のセキュリティの状況を理解する
セキュリティ戦略に多様な視点を取り入れる
研究開発活動のセキュリティ対策に積極的に取り組む
インセンティブを組織の成果と整合させる
AI/ML と生成 AI における現実的なセキュリティシナリオに備える

生成 AI のライフサイクル全体を通じて脅威モデルを開発する

生成 AI を構築する組織は、リスクの排除ではなく、リスク管理に重点を置き、生成 AI ワークロードの計画、開発、運用において脅威モデリングと事業継続計画を含める必要があります。生成 AI の本番利用から逆算して、従来のセキュリティリスクと生成 AI 特有のリスクの両方を用いて、各アプリケーションの脅威モデルを開発することから始めてください。あるリスクはビジネスにとって許容できる可能性があり、脅威モデリングの実施により許容できるリスク範囲を特定するのに役立ちます。例えば、生成 AI アプリケーションに 99.999% の稼働時間を要求しない場合、AWS Backup と Amazon S3 Glacier を使用したリカバリに関連する追加のリカバリ時間は、許容できるリスクとなる可能性があります。反対に、モデル内のデータが極めて機密性が高く、規制対象である場合、AWS Key Management Service (AWS KMS) のカスタマーマネージドキー (CMK) のローテーションからの逸脱や、データ漏えいから保護するために AWS Network Firewall を使用したり入出力トラフィックに Transport Layer Security (TLS) を適用することは、許容できないリスクとなる可能性があります。

生成 AI アプリケーションを本番環境で使用する際の固有リスクと残存リスクを評価し、基盤およびアプリケーションレベルの適切なコントロールを特定します。OWASP Top 10 for LLM で挙げられている、プロンプトインジェクション、訓練データの汚染、モデルの DoS 、モデルの盗難などの本番環境でのセキュリティイベントやサービス中断のロールバックと復旧を計画し、アプリケーション要件を定義する際に使用するリスク軽減策を早期に定義します。リスクとコントロールについて学ぶことは、生成 AI アプリケーション構築のための最適な実装アプローチを定義するのに役立ち、ステークホルダーや意思決定者がリスクに関する情報に基づいたビジネス上の意思決定を行うための情報を提供します。AI および ML の全体的なワークフローに不慣れな場合は、まず機械学習ワークロードのセキュリティを改善する 7 つの方法を確認して、従来の AI/ML システムに必要なセキュリティコントロールの理解を深めてください。

他の ML アプリケーションを構築するのと同様に、生成 AI アプリケーションを構築するには、一連の研究開発ライフサイクルの段階を経る必要があります。選択した生成 AI ソリューションに応じて考慮すべき主要なセキュリティ領域を理解するためのメンタルモデルを構築するのに役立つ AWS 生成 AI セキュリティスコーピングマトリックスを確認することをおすすめします。 LLM を使用した生成 AI アプリケーションは、通常、次の順序立ったステップに従って開発および運用されます。

アプリケーションの要件 – ユースケースのビジネス目的、要件、成功基準を特定する
モデルの選択 – ユースケースの要件と整合する基盤モデルを選択する
モデルの適応とファインチューニング – データの準備、プロンプトの作成、モデルのファインチューニングを行う
モデルの評価 – ユースケース固有のメトリクスで基盤モデルを評価し、最もパフォーマンスの高いモデルを選択する
デプロイとインテグレーション – 選択した基盤モデルを最適化されたインフラストラクチャにデプロイし、生成 AI アプリケーションと統合する
アプリケーションのモニタリング – アプリケーションとモデルのパフォーマンスをモニタリングして、根本原因の分析を可能にする

ソフトウェア開発ライフサイクルの初日から、設計およびアーキテクチャフェーズの一部として、セキュリティが極めて重要であるとチームが理解していることを確認してください。これは、ソフトウェアの構成要素や開発サイクルの各レイヤーでセキュリティについて議論し、セキュリティとプライバシーをビジネス目標を達成するための手段として位置付けることを意味します。LLM アプリケーションのリリース前に脅威に対するコントロールを設計し、モデルの適応とファインチューニングに使用するデータと情報が、研究・開発・トレーニング環境でのコントロールの実装を必要とするかどうかを検討してください。品質保証テストの一環として、定期的に防御とセキュリティ態勢をテストするために、統合されたセキュリティ脅威 (訓練データを汚染したり、悪意のあるプロンプトエンジニアリングを通じた機密データを抽出することを試行するなど) を導入してください。加えて、ステークホルダーは、本番の AI、ML、生成 AI ワークロードについて一貫したレビューの頻度を設定し、人間と機械の制御およびエラーのトレードオフを理解することを組織の優先事項として設定する必要があります。デプロイされた LLM アプリケーションにおいて、これらのトレードオフが尊重されていることを検証および保証することで、リスク軽減が成功する可能性が高まります。

セキュアなクラウド基盤上で生成 AI アプリケーションを構築する

AWS において、セキュリティは最優先事項です。 AWS は、アプリケーションとワークロードを構築、移行、管理するための、最もセキュアなグローバルクラウドインフラストラクチャとして設計されています。これは、300 を超えるクラウドセキュリティツールの豊富なセットと、政府機関、ヘルスケア、金融サービスなどのセキュリティ要件の高い組織を含む、数百万のお客様からの信頼に支えられています。 AWS 上で LLM を使用して生成 AI アプリケーションを構築する場合、セキュアで信頼性が高く、柔軟な AWS クラウドコンピューティング環境からセキュリティ上のメリットを得ることができます。

セキュリティ、プライバシー、コンプライアンスのためにAWS グローバルインフラストラクチャを活用する

AWS でデータ集約型アプリケーションを開発する際、AWS のグローバルリージョンインフラストラクチャを活用できます。このインフラストラクチャは、セキュリティとコンプライアンスに関する中核となる要件を満たす機能を提供するよう設計されています。これは、クラウドで利用できる最も高度な統制管理と機能のセットを提供するという、AWS のデジタル統制に関するお客様との約束によって強化されています。AWS は、パフォーマンス、イノベーション、セキュリティ、スケールを犠牲にすることなく、お客様のデジタル主権に関するニーズを満たすための機能を拡張することにコミットしています。セキュリティとプライバシーのベストプラクティスを簡単に実装するために、AWS セキュリティリファレンスアーキテクチャ (AWS SRA) や AWS プライバシーリファレンスアーキテクチャ (AWS PRA) などのリファレンスデザインやインフラストラクチャコードリソースをご利用ください。プライバシーソリューションの設計、設計による主権、AWS でのコンプライアンスの詳細をご確認ください。また、AWS Config、AWS Artifact、AWS Audit Manager などのサービスを利用して、プライバシー、コンプライアンス、監査、可観測性のニーズをサポートします。

AWS Well-Architected フレームワークとクラウド導入フレームワークを使用したセキュリティ態勢を理解する

AWS は、AWS Well-Architected フレームワークを使用してクラウド環境を設計したり、AWS Cloud Adoption Framework (AWS CAF)を使用してクラウドテクノロジーからビジネス価値を実現したりと、お客様をサポートする長年の経験から得られたベストプラクティスのガイダンスを提供しています。 AI、ML、生成 AI ワークロードのセキュリティ態勢を理解するために、Well-Architected フレームワークのレビューを実施してください。レビューは、AWS Well-Architected Tool などのツールを使用して実施できます。または、AWS エンタープライズサポートを通じて AWS チームの支援を受けることもできます。 AWS Well-Architected Tool は、AWS Trusted Advisor からのインサイトを自動的に統合して、ベストプラクティスがどの程度実装されているか、機能とコスト最適化を改善するためにどのような機会があるか評価します。また、AWS Well-Architected Tool には、Machine Learning Lens などの特定のベストプラクティスを備えたカスタマイズされたレンズも用意されているため、アーキテクチャを定期的にベストプラクティスと比較して改善点を特定できます。 AWS のお客様が人工知能、機械学習、生成 AI の AWS クラウド導入フレームワークにより組織的な能力を開発するための戦略をどのように採用しているかを理解してすることで、価値の実現とクラウドの成熟への道のりを歩むチェックポイントを設定します。また、AWS クラウドレディネスアセスメントに参加することで、全体的なクラウド準備状況を理解するメリットもあるかもしれません。 AWS では追加のエンゲージメントの機会も提供しています – Generative AI Innovation Center の利用を開始する方法についての詳細は、AWS アカウントチームにお問い合わせください。

セキュリティと AI/ML の学習をベストプラクティスのガイダンス、トレーニング、認定で加速させる

AWS は、トレーニング、開発、テスト、運用環境を保護する方法を特定するのに役立つ、セキュリティ、アイデンティティ、コンプライアンスのベストプラクティスや AWS セキュリティドキュメントからの推奨事項をまとめています。初めての方は、セキュリティトレーニングと認定資格についてさらに詳しく学習し、AWS セキュリティの基礎と AWS セキュリティラーニングプランから始めることをおすすめします。また、AWS セキュリティ成熟度モデルを利用して、Quick Wins から基礎、効率化、最適化の各段階で、AWS 上の最適なアクティビティを見つけて優先順位付けすることもできます。 AWS 上のセキュリティの基本的な理解ができたら、脅威モデリングのアプローチ方法を確認し、チームと Threat Modeling For Builders ワークショップトレーニングプログラムから始める脅威モデリング演習を主導することを強くおすすめします。その他にも、利用可能な AWS セキュリティトレーニングと認定資格が多数あります。

LLM アプリケーションを保護するための多層防御アプローチを適用する

生成 AI ワークロード、データ、情報に対して多層防御のセキュリティアプローチを適用することで、ビジネス目標の達成に最適な条件を整えるのに役立ちます。多層防御のセキュリティベストプラクティスは、あらゆるワークロードが直面する一般的なリスクの多くを軽減し、あなたのチームが生成 AI イノベーションを加速するのに役立ちます。多層防御のセキュリティ戦略は、AWS アカウント、ワークロード、データ、資産を保護するために、複数の冗長な防御を使用します。これにより、セキュリティコントロールの 1 つが侵害されたり失敗した場合でも、脅威を分離し、セキュリティイベントから防御、検知、対応、回復するのに役立つ追加のレイヤーが存在することを確認するのに役立ちます。 AWS サービスとソリューションを含む複数の戦略を組み合わせて、各レイヤーで使用することで、生成 AI ワークロードのセキュリティとレジリエンスを向上させることができます。

多くの AWS のお客様は、NIST のサイバーセキュリティフレームワークなどの業界標準のフレームワークに準拠しています。このフレームワークは、識別、防御、検知、対応、復旧、最近追加されたガバナンスの柱にわたってセキュリティ防御を確実に保護するのに役立ちます。このフレームワークは、AWS のセキュリティサービスや統合されたサードパーティのサービスに簡単にマッピングできるため、組織が遭遇するあらゆるセキュリティイベントに対して、適切な対応範囲とポリシーを検証するのに役立ちます。

（訳者注：CloudEndure Disaster Recovery は一部リージョンを除いて廃止が予定されているため、代わりに AWS Elastic Disaster Recovery の利用をご検討ください）

多層防御 : 環境をセキュアにし、強化された AI/ML 固有のセキュリティとプライバシーの機能を追加する

多層防御の戦略は、最初にアカウントと組織を保護することから始め、その後 Amazon Bedrock や Amazon SageMaker などのサービスに組み込まれたセキュリティとプライバシーの機能を、階層的に追加していく必要があります。Amazonは 30 を超えるセキュリティ、アイデンティティ、コンプライアンスのポートフォリオを持ち、それらは AWS の AI/ML サービスと統合されており、ワークロード、アカウント、組織を保護するのに役立ちます。OWASP Top 10 for LLM の観点で適切に防御するには、これらのセキュリティサービスを AWS の AI/ML サービスと合わせて使用していく必要があります。

まず、最小権限のポリシーを実装し、IAM Access Analyzer などのサービスを使用して、アクセス許可が広範囲に設定されたアカウント、ロール、リソースを見つけ、一時的な認証情報を使用してアクセスを制限します。次に、AWS KMS を使用して、CMK の利用も考慮しつつ、保管中のすべてのデータが暗号化されていることを確認します。また、Amazon S3 のバージョニングとオブジェクトレベルの不変性を適用するための Amazon S3 オブジェクトロックを使用して、すべてのデータとモデルをバージョン管理しバックアップします。サービス間を転送するすべてのデータは、AWS Certificate Manager や AWS Private CA を使用して保護し、AWS PrivateLink を使用して VPC 内にとどめておきます。改ざんやデータ漏洩からの保護のために、AWS Network Firewall ポリシーを使用した VPC を利用して、データの厳格な入出力ルールを定義します。悪意のあるボット、SQL インジェクション攻撃、クロスサイトスクリプティング (XSS)から Web アプリケーションと API を保護するために、AWS WAF を前面に配置し、アカウントの乗っ取り防止のため Fraud Control を使用することも検討します。ログの記録に AWS CloudTrail 、Amazon VPC フローログ、 Amazon EKS 監査ログを使用することにより、フォレンジックの際に Amazon Detective などのサービスで各トランザクションをレビューすることができます。 Amazon Inspector を使用して、Amazon EC2 インスタンス、コンテナ、AWS Lambda 関数の脆弱性の自動で発見し管理することができたり、ワークロードのネットワーク到達可能性を特定することもできます。データとモデルを疑わしいアクティビティから保護するために、 Amazon GuardDuty の ML を利用した脅威モデルと脅威インテリジェンスフィードを使用します。さらに EKS Protection、ECS Protection、S3 Protection、RDS Protection、Malware Protection、Lambda Protection など、追加の機能を有効にします。 AWS Security Hub のようなサービスを使用することで、セキュリティチェックを集中化および自動化し、セキュリティのベストプラクティスからの逸脱の検出や、調査の迅速化、プレイブックを使用した修復の自動化が可能となります。さらに、ゼロトラストアーキテクチャを AWS 上で実装し、人間のユーザーまたはマシン間プロセスがリクエストごとにアクセスできるものに対し、きめ細かい認証認可の制御を強化することもできます。また、Amazon Security Lake を使用して、AWS 環境、SaaS プロバイダー、オンプレミス、クラウドソースからのセキュリティデータを自動的に集約し、アカウント内に構築された専用のデータレイクに保存することも検討します。Security Lake を使用することで、組織全体のセキュリティデータをより包括的に理解できます。

生成 AI ワークロード環境をセキュリティで保護した後は、Amazon SageMaker Data Wrangler を使用してデータ準備における潜在的なバイアスを特定したり、Amazon SageMaker Clarify を使用して ML データとモデルのバイアスを検出するなど、AI/ML 固有の機能を追加できます。また、Amazon SageMaker Model Monitor を使用して、本番環境の SageMaker ML モデルの品質を評価し、データ品質、モデル品質、Feature Attribution のドリフトが発生した場合に通知を受けることもできます。これら AWS の AI/ML サービス (Amazon Bedrock と連携する Amazon SageMaker を含む) と AWS のセキュリティサービスが連携することで、バイアスの潜在的なソースを特定し、悪意のあるデータ改ざんから保護するのに役立ちます。 AWS サービスの価値を最大限に活用して、データとワークロードを保護するための多層防御を実装するために、OWASP Top 10 for LLM の各脆弱性についてこのプロセスを繰り返してください。

AWS Enterprise Strategist の Clarke Rodgers 氏がブログ記事「CISO Insight: Every AWS Service Is A Security Service」で次のように述べています。「AWS クラウド内のほぼすべてのサービスはセキュリティが単体で確保されており、お客様がセキュリティ、リスク、コンプライアンスの目的を達成するために、単体または 1 つ以上のサービスと組み合わせて使用できます」。加えて、「お客様の最高情報セキュリティ責任者 (CISO)、またはそれらの関連チームは、すべての AWS サービスに精通しているかどうか確認する時間を取ることが望ましいです。なぜなら、サービスが『セキュリティ、アイデンティティ、コンプライアンス』のカテゴリに含まれていなくても、セキュリティ、リスク、コンプライアンスの目的を満たすことができるためです。」と述べています。

LLM アプリケーションの信頼境界における各レイヤーの防御

生成 AI ベースのシステムやアプリケーションを開発する際には、MITRE ATLAS Machine Learning Threat Matrix で述べられているように、ソフトウェアおよびデータコンポーネントの出所 (オープンソースソフトウェア監査の実行、ソフトウェア部品表 (SBOM) のレビュー、データワークフローと API インテグレーションの分析など) に注意を払うことや、LLM サプライチェーンの脅威に対する必要な保護を実装することなど、他の ML アプリケーションと同様の懸念事項を考慮する必要があります。業界のフレームワークからの洞察を取り入れ、脅威インテリジェンスやリスク情報といった複数のソースを使用し、従来のフレームワークには含まれていない AI、ML、および生成 AI の新たなセキュリティリスクに対応できるよう、セキュリティ対策を調整および拡張する方法を認識してください。この分野では定期的に新しい脅威が出現し、かつ進化しているため、フレームワークやガイドも頻繁に更新されています。そのため、AI 固有のリスクに関する情報を、業界、国防、政府、国際機関、学術機関などのソースから探してください。たとえば、検索拡張生成 (RAG) モデルを使用する場合、モデルに必要なデータが含まれていないと、推論とファインチューニングの際に外部データソースへ要求する可能性があります。このようなクエリを実行するソースは管理外にある可能性があり、サプライチェーンでの潜在的な侵害源となり得ます。外部ソースに対しても多層防御アプローチを拡張し、アクセスしているデータの信頼性、認証、認可、アクセス、セキュリティ、プライバシー、正確性を確立する必要があります。より深く掘り下げるには、「Build a secure enterprise application with Generative AI and RAG using Amazon SageMaker JumpStart」を確認してください。

LLM アプリケーションにおけるリスクを分析し軽減する

このセクションでは、信頼境界とインタラクション、または同様の適切なコントロールの範囲とリスクプロファイルを持つワークロードの個別の領域に基づいて、いくつかのリスク軽減手法を分析して説明します。以下のチャットボットアプリケーションのサンプルアーキテクチャでは、AWS のお客様が一般的な LLM アプリケーションを構築する方法に基づいて、コントロールが実証される 5 つの管理されている信頼境界があります。実際の LLM アプリケーションには、より少ない、またはより多くの定義可能な信頼境界がありえます。次のサンプルアーキテクチャでは、これらの信頼境界は次のように定義されています:

ユーザーインターフェースのインタラクション (リクエストとレスポンス)
アプリケーションのインタラクション
モデルのインタラクション
データのインタラクション
組織のインタラクションと利用

ユーザーインターフェースのインタラクション : リクエストとレスポンスのモニタリングの開発

生成 AI アプリケーションの入力と出力に関するリスク戦略を評価することにより、生成 AI に関連するサイバーインシデントをタイムリーに検知および対応します。例えば、LLM アプリケーションの場合、ドメインまたは組織の外部への機密情報の漏洩を検知するために、挙動とデータ流出のための追加のモニタリングが必要となる場合があります。

生成 AI アプリケーションは、データを保護する際にも標準的なセキュリティのベストプラクティスを維持する必要があります。セキュアなデータ境界を確立し、センシティブなデータストアを保護します。 LLM アプリケーションで使用されるデータと情報は、保管時および転送時に暗号化します。モデルの訓練データは、どのユーザー、プロセス、ロールがデータストアにアクセスできるかを理解し制御することにより、訓練データの汚染（Training Data Poisoning）から保護します。また、アプリケーション内のデータフロー、バイアスの監視、Amazon S3などのストレージサービスでのバージョニングとイミュータブルストレージを使用することも重要です。 AWS Network Firewall や AWS VPC などのサービスを使用して、厳格なデータの入出力制御を確立し、疑わしい入力やデータ漏洩の可能性から保護します。

学習、再学習、ファインチューニングのプロセス中は、利用される個人情報に注意を払う必要があります。これらのプロセスのいずれかでデータが利用された後、プロンプトインジェクション技術を用いて、ユーザーがデータや情報をモデルから抽出できるシナリオを想定する必要があります。モデルと推論に個人情報を利用することのリスクと効果を理解します。細かいアクセス許可を設定し管理するために、LLM アプリケーションロジックに依存しないロバストな認証認可メカニズムを実装します。生成 AI アプリケーションへのユーザーが管理する入力は、一部の条件下において、モデルやユーザー管理外の入力から情報を抽出するベクトルを提供できることが実証されています。これはプロンプトインジェクションを通じて発生する可能性があります。 LLM アプリケーションが想定するガードレールから逸脱した出力をするような入力がなされ、その出力の中には、モデル学習に使われたオリジナルのデータセットに関する情報も含まれることになります。

モデルへの入力やモデルからの出力を受け取るユーザーに対して、ユーザーレベルのアクセス制御を実装します。トレーニングデータや情報の機密性が高い場合や、攻撃者によって入力とモデル出力に基づいてモデルを模倣されるリスクがある場合は、匿名アクセスを許可しないアプローチを検討する必要があります。一般に、モデルへの入力の一部が任意のユーザー提供のテキストで構成されている場合、出力がプロンプトインジェクションに対して脆弱であると見なされます。そのため、安全が確認されていない出力ハンドリング（Insecure Output Handling）、過剰な代理行為（Excessive Agency）、過度の信頼（Overreliance）といったリスクに対して技術的および組織的な対策が実行されているか確認する必要があります。前述の AWS WAF を使用した悪意のある入力のフィルタリングの例では、プロンプトの誤用の可能性に対してアプリケーションの前にフィルターを構築し、モデルとデータが成長するにつれてそれらをどのように処理および進化させるかのポリシーを開発することを検討します。また、品質、精度、コンテンツモデレーションの基準を満たしていることを確認するために、ユーザーに返される前に出力をフィルタリングするレビューを行うことも検討してください。組織のニーズに合わせて、モデルの前に入力と出力の追加の制御レイヤーを追加することで、疑わしいトラフィックパターンを軽減できます。

アプリケーションのインタラクション : アプリケーションのセキュリティと可観測性

LLM アプリケーションをレビューする際は、ユーザーがモデルを利用して、本来はアクセスや使用の許可がない下流のツールやツールチェーンへの標準認可を回避しないか注意してください。このレイヤーでのもう 1 つの懸念は、緩和されていない技術的または組織的な LLM リスクを使用した攻撃メカニズムとしてモデルを利用して、外部データストアにアクセスすることです。例えば、機密データを含む可能性のある特定のデータストアにアクセスするようモデルがトレーニングされている場合は、モデルとデータストアの間で適切に認可の確認がなされることを確認する必要があります。認可チェックを実行する際には、モデルからではなく、ユーザーに関する不変の属性を使用します。安全が確認されていない出力ハンドリング（Insecure Output Handling）、安全が確認されていないプラグイン設計（Insecure Plugin Design）、過剰な代理行為（Excessive Agency）などの対策が講じられていない場合は、攻撃者が認可システムを騙すためにモデルを使用し、実行権限をエスカレーションさせる状況を作り出す可能性があります。これにより下流コンポーネントが、ユーザーがデータの取得や特定のアクションの実行を認可されていると信じてしまうことにつながります。

生成 AI プラグインやツールを実装する際には、付与されるアクセスレベルを検証し、理解することが不可欠です。また、設定されたアクセス制御を精査することも重要です。対策の講じられておらず安全でない生成 AI プラグインを使用すると、サプライチェーンの脆弱性や脅威にシステムがさらされる可能性があり、リモートコードの実行などの悪意のあるアクションにつながる可能性があります。

モデルのインタラクション : モデル攻撃の防止

使用するモデル、プラグイン、ツール、データの出所を認識しておく必要があります。これにより、サプライチェーンの脆弱性を評価および軽減することができます。例えば、一部の一般的なモデルフォーマットでは、モデル自体に任意の実行可能コードを埋め込むことが許可されています。組織のセキュリティ目標に関連する場合は、パッケージをミラーしたり、スキャンや追加の検査を実行します。

モデルのトレーニングとファインチューニングを行うために使用するデータセットもレビューする必要があります。ユーザーからのフィードバック (またはその他のエンドユーザーがコントロールできる情報) に基づいてモデルの自動ファインチューニングを行う場合は、悪意のある攻撃者がレスポンスを操作することでモデルを任意に変更し、訓練データの汚染（Training Data Poisoning）を引き起こす可能性があるかどうかを考慮する必要があります。

データのインタラクション : データ品質と利用状況のモニタリング

大規模言語モデル (LLM) のような生成 AI モデルは、一般的に大量のデータで訓練されているため、優れた性能を発揮します。このデータは LLM が複雑なタスクを遂行するのに役立ちますが、同時に訓練データの汚染 (Training Data Poisoning) のリスクにシステムをさらす可能性もあります。これは、不適切なデータが訓練データに含まれたり省かれたりすることで、モデルの振る舞いが変わることを指します。このリスクを軽減するには、モデルで使用する前に、システムのデータレビュープロセスとサプライチェーンを確認する必要があります。トレーニングパイプラインはデータ汚染攻撃の主な発生源ですが、他にも RAG モデルやデータレイクなど、モデルがデータを取得する方法も確認する必要があります。そのデータソースが信頼でき保護されているかどうかを確認します。 AWS Security Hub、Amazon GuardDuty、Amazon Inspector などの AWS セキュリティサービスを使用して、Amazon EC2、Amazon EKS、Amazon S3、Amazon Relational Database Service (Amazon RDS)、ネットワークアクセスなどでの疑わしいアクティビティを継続的に監視し、新たな脅威の兆候を検知します。また Detective を使用してセキュリティ調査を視覚化することもできます。さらに、Amazon Security Lakeなどのサービスを使用して、AI/ML ワークロードに貢献する AWS 環境、SaaS プロバイダー、オンプレミス、およびクラウドソースから、セキュリティデータを自動的に集約する専用データレイクを作成することで、セキュリティ調査を加速することも検討します。

組織のインタラクション : 生成 AI のためのエンタープライズガバナンスガードレールの実装

ビジネスにおける生成 AI の利用に関連するリスクを特定します。生成 AI ソリューションを展開する際には、組織のリスクを分類し、リスク評価を実施し、情報に基づく意思決定が必要です。AI/ML、生成 AI ワークロードを含めた事業継続計画(BCP) を策定し、影響を受けたりオフラインになった LLM アプリケーションの機能を迅速に置き換えて、SLA を満たすことができるようにします。

プロセスとリソースのギャップ、非効率性、不整合性を特定し、ビジネス全体の認知とオーナーシップを向上させます。すべての生成 AI ワークロードを脅威モデリングし、データの不正アクセス、サービスの拒否、リソースの誤用など、ビジネスに影響を与える可能性のあるセキュリティ上の脅威を特定し軽減します。脅威モデリングを実施する際には、新しい AWS Threat Composer モデリングツールが価値創出までの時間短縮に役立ちます。開発サイクルの後半では、セキュリティカオスエンジニアリングのフォールトインジェクションの試みを導入して、システムが未知の問題にどのように反応するかを理解し、システムの回復力とセキュリティに対する信頼性を高めるための実環境での条件を作成することを検討します。

すべての職種と機能にわたって AI/ML や生成 AI に関するセキュリティの遵守とカバレッジを確保するため、セキュリティ戦略とリスク管理メカニズムの開発に多様な視点を取り入れます。生成 AI アプリケーションの初期やリサーチの段階から要件と整合させるためにセキュリティの考え方を取り入れます。 AWSからの追加のサポートが必要な場合は、AWS のアカウントマネージャーに相談し、AWS セキュリティと AI/ML のソリューションアーキテクトのサポートをリクエストし、協力して取り組みます。

セキュリティ組織は、プロダクトマネージャー、ソフトウェア開発者、データサイエンティスト、経営陣などの生成 AI のステークホルダー間で、リスクの認識とリスク管理の理解を促進するコミュニケーションを定期的に行うようにします。これにより、脅威インテリジェンスとコントロールのガイダンスが、影響を受ける可能性のあるチームに届くようになります。セキュリティ組織は、ディスカッションに参加し、ビジネス目標に関連する新しいアイデアや情報を生成 AI のステークホルダーに提供することで、責任ある情報開示と反復的な改善の文化を支援できます。より詳細については、責任ある AI に関する私たちの取り組みや、お客様を支援する責任ある AI のリソースをご確認ください。

組織の既存のセキュリティプロセスにおける時間対効果に対する障害を取り除くことにより、生成 AI のためのよりよい組織態勢に向けた優位性が得られます。組織が生成 AI のセキュリティの状況下で過度に負担を強いられるプロセスがあるかを積極的に評価し、これらを改善して、適切なコントロールをもとにローンチする計画を開発者やデータサイエンティストに提供します。

インセンティブの調整や、リスクの低減、目標とする結果への明確な見通しを提供する機会があるかどうかを評価します。 AI/ML と生成 AI アプリケーション開発の進化するニーズを満たすように、コントロールのガイダンスと防御を更新することで、開発時間のコスト増加、リスクの増加、影響範囲の増加を招くような混乱と不確実性を軽減します。

セキュリティの専門家ではないステークホルダーが、組織のガバナンス、ポリシー、リスク管理のステップが自分のワークロードにどのように適用されるかを理解できるようにするとともに、リスク管理メカニズムを適用できるようにしてください。組織が生成 AI アプリケーションで発生しうる現実的なイベントとシナリオに対応できるよう準備し、生成 AI ビルダーの役割と対応チームが、疑わしい活動について懸念がある場合のエスカレーションパスとアクションを認識していることを確認します。

結論

先進技術を活用して市場でのイノベーションを成功させるには、セキュリティを最優先に考え、セキュアなインフラストラクチャーの基盤上に構築していくことが必要です。また、多層防御のセキュリティアプローチをもとに、テクノロジースタックの各レイヤーでセキュリティをさらに統合できる方法を考えることが必要です。これには、組織のレジリエンシーを確保するための、テクノロジースタックの複数のレイヤー間のインタラクションと、デジタルサプライチェーン内の統合ポイント間のインタラクションが含まれます。生成 AI はいくつかの新しいセキュリティとプライバシーの課題をもたらしますが、レイヤー化されたセキュリティサービスを使用した多層防御などの基本的なセキュリティのベストプラクティスに従えば、多くの共通的な問題や進化する脅威から組織を保護するのに役立ちます。生成 AI ワークロード全体と組織全体にわたって、レイヤー化されたAWSセキュリティサービスを実装し、デジタルサプライチェーンの統合ポイントに焦点を当てて、クラウド環境を保護する必要があります。そして、Amazon SageMaker や Amazon Bedrock などの AWS AI/ML サービスで強化されたセキュリティとプライバシー機能を利用して、生成 AI アプリケーションにさらなるセキュリティとプライバシーコントロールのレイヤーを追加できます。セキュリティを最初から組み込むことで、コンプライアンスを簡素化しながら、生成 AI でのイノベーションをより迅速かつ容易、そしてコスト効率よく実現できます。これにより、従業員、顧客、パートナー、規制機関、その他の利害関係者のために、生成 AI アプリケーションのコントロール、信頼性、可観測性を高めることができます。

追加の参考資料

AI/ML 固有のリスク管理とセキュリティの業界標準フレームワーク:

著者について

Christopher Rae は、AWS のセキュリティサービスの採用を加速および拡大する戦略的イニシアチブを開発および実行することに焦点を当てたプリンシパルワールドワイドセキュリティ GTM スペシャリストです。サイバーセキュリティと新興テクノロジーの交差点に情熱を注ぎ、20 年以上にわたってメディア、エンターテインメント、テレコムのお客様にセキュリティソリューションを提供するグローバルな戦略的リーダーシップの経験を持っています。読書、旅行、食べ物とワイン、新しい音楽の発見、初期段階のスタートアップへのアドバイスを通じてリフレッシュしています。

Elijah Winter は、サイバーセキュリティ工学の学士号を持ち、ハリー・ポッターへの愛に満ちたシニアセキュリティエンジニアです。 AI システムの脆弱性を特定し対処することに秀でており、技術的専門知識と魔法使いのような感覚を融合させています。 AI エコシステムのためのカスタマイズされたセキュリティプロトコルを設計し、デジタル防御に魔法のような魅力をもたらしています。正直さを重んじる Elijah は、信頼を守ることに焦点を当てた公共および民間セクターの両方の組織でセキュリティのバックグラウンドを持っています。

Ram Vittal は、AWS のプリンシパル ML ソリューションアーキテクトです。 30 年以上にわたり、分散型、ハイブリッド、クラウドアプリケーションのアーキテクチャ設計と構築の経験があります。セキュアでスケーラブルな AI/ML とビッグデータのソリューションを構築し、エンタープライズのお客様がクラウドへの移行と最適化の旅を支援し、ビジネス成果を向上させることに情熱を注いでいます。余暇には、バイクに乗ったり、3 歳のシーパドゥードルと散歩したりしています!

Navneet Tuteja は、Amazon Web Services のデータスペシャリストです。AWS に加入する前は、データアーキテクチャの近代化と包括的な AI/ML ソリューションの実装を目指す組織のファシリテータとして働いていました。Thapar University で工学の学位を取得し、Texas A&M University で統計学の修士号を取得しています。

Emily Soward は、AWS プロフェッショナルサービスのデータサイエンティストです。スコットランドのエディンバラ大学で人工知能の理学修士号を取得しており、自然言語処理 (NLP) に重点を置いています。Emily は、公共および民間セクターの組織で実行されている AI ワークロードの運用効率とガバナンスに焦点を当てた、AI を活用した製品の研究開発に従事してきました。AWS シニアスピーカーとして顧客へのガイダンスに貢献するとともに、最近では機械学習レンズの AWS Well-Architected の著者としても活動しています。

翻訳はプロフェッショナルサービスの藤浦雄大、相川遼介が担当しました。原文はこちらです。

Amazon Web Services ブログ