Amazon Web Services ブログ
生成 AI ワークロードのセキュリティリスクを評価するための脅威モデリング
本ブログは 2024 年 11 月 18 日に公開された「Threat modeling your geneyfujiurarative AI workload to evaluate security risk」を翻訳したものです。
生成 AI モデルがますますビジネスアプリケーションへ統合されるにつれ、それらがもたらす潜在的なセキュリティリスクを評価することが極めて重要になります。AWS は、AWS re:Invent 2023 でこのトピックについてプレゼンテーションを行い、何百ものお客様が新技術を安全に採用するため迅速な意思決定を維持することに役立ちました。このセッションに参加したお客様は、セキュリティリスクを評価し、構築するアプリケーションに対して高いセキュリティ基準を維持するための推奨アプローチをより深く理解することができました。本ブログでは、生成 AI ワークロードに対する効果的な脅威モデリングを実施するための主要なステップを再確認し、各段階で期待される典型的なアウトプットや検討結果を含む、さらなるベストプラクティスと例を紹介します。本ブログ全体を通して、 AWS Threat Composer tool を使用して作成した具体的な事例のリンクを提供します。 Threat Composer は、脅威モデルを文書化するために使用できる AWS のオープンソースツールで、追加費用なしで利用可能です。
本ブログでは、生成 AI ワークロードの脅威モデリングを行うための実践的なアプローチを扱い、脅威モデリングの基本を理解していることを前提としています。脅威モデリングの概要を知りたい方は、このブログをご確認ください。加えて、本ブログは生成 AI のセキュリティとコンプライアンスの考慮事項に関する長編シリーズのひとつです。
なぜ生成 AI に脅威モデリングを使用するのか？
新しい技術にはそれぞれ、固有のセキュリティリスクを特定し軽減するうえで、独自の学習曲線があります。ワークロードへの生成 AI の採用も例外ではありません。大規模言語モデル (LLM) の使用は、ユーザーのプロンプトに基づいて高度にカスタマイズされた非決定論的な出力を生成できるため、潜在的な誤用や悪用の可能性をもたらし、新たなセキュリティ課題をもたらします。さらに、大規模でカスタマイズされたデータセットへのアクセスに依存しており、多くの場合、機微情報を含む可能性のある内部データソースを利用します。
LLM を活用することは比較的新しい実践であり、独特で微妙なセキュリティリスクと影響を伴いますが、LLM はより大きなワークロードの一部分に過ぎないことを忘れないことが重要です。システムの各パーツに脅威モデリングのアプローチを適用し、インジェクションや認証情報の侵害といった既知の脅威を考慮に入れることが重要です。AWS ブログシリーズ「生成 AI をセキュアにする」のパート 1 「生成 AI セキュリティスコーピングマトリックスの紹介」では、これらの微妙な点について優れた概要を提供し、組織での LLM の使用方法によってリスクがどのように異なるかを説明しています。
生成 AI における脅威モデリングの 4 つのステージ
簡単な復習として、脅威モデリングは、特定のシステムやアプリケーションにおけるセキュリティリスクを特定し、理解し、対処し、伝えるための構造化されたアプローチです。これは設計フェーズの基本的な要素であり、適切な緩和策を特定して実装し、できるだけ早期に基本的なセキュリティの決定を行うことを可能にします。
AWS では、脅威モデリングは AWS の開発者チーム向けアプリケーションセキュリティ (AppSec) プロセスを開始するために必要なインプットであり、開発者チームはセキュリティガーディアンからサポートを受けて、機能やサービスの脅威モデルを作成します。
専門家の Adam Shostack が考案した脅威モデリングへのアプローチを構造化する有用な方法は、 4 つの重要な質問に答えることです。これらの質問が生成 AI ワークロードにどのように適用するかを見ていきます。
- 何に取り組んでいるのか？
- 何が問題になり得るか？
- それについて何をするのか？
- 十分な対応ができているか？
何に取り組んでいるのか？
この質問は、ビジネスコンテキストとアプリケーションアーキテクチャについての詳細な理解を得ることを目的としています。求める詳細情報は、すでに生成 AI ソリューションの開発者によって作成された包括的なシステム文書の一部として捕捉されているはずです。この文書から始めることで、脅威モデリングのプロセスを効率化し、基本的なシステムの知識を再構築するのではなく、潜在的な脅威と脆弱性の特定に焦点を当てることができます。
アウトプットや検討結果の例
開発者は少なくとも、データフロー、前提条件、設計上の決定事項を含む、ソリューションの主要コンポーネントを把握する必要があります。これは潜在的な脅威を特定するための基礎となります。文書化すべき主要な要素は以下の通りです。
- リクエストから応答までアプリケーションの主要なデータの流れを示すデータフロー図 (DFD) 。各コンポーネントまたは hop（訳者注 :hop とはデータがあるコンポーネントから別のコンポーネントへ遷移する、DFD の線の部分に該当します）で何が起こるかを詳細に説明します。
- ユーザーがシステムとどのような対話をするか、またはモデルがシステムとどのようなやりとりをするかを、明確にした前提条件。例えば、RAG シナリオにおいて、モデルが他のシステムに保存されたデータを取得する必要がある場合、どのように認証を行い、そのデータをユーザーにとって適切な応答に変換するか、などを含みます。
- ビジネスによって下された重要な設計上の決定事項の文書化。これには決定の背景にある根拠も含みます。
- アプリケーションに関する詳細なビジネスコンテキスト。例えば、重要システムとみなされるかどうか、扱うデータの性質（機密性、完全性、可用性など）、アプリケーションの主要なビジネス上の懸念事項（データの機密性、データの整合性、システムの可用性など）を含みます。
図 1 は、Threat Composer が Application Information（アプリケーション情報）、Architecture（アーキテクチャ）、Dataflow（データフロー）、および Assumptions（前提条件） のセクションでアプリケーションに関する情報を入力する方法を示しています。
図 1: 生成 AI チャットボットの例に関する Threat Composer のデータフロー図
何が問題になり得るか?
この質問では、前の質問で収集したコンテキストと情報を使用し、アプリケーションに対する潜在的な脅威を特定します。可能性のある脅威を特定するために、既存の情報源を活用してください。特に採用する新技術に関連するものを重視してください。多くの場合、アプリケーションに適用できる具体的な例が含まれています。有用なリソースとしては、 OWASP top 10 for LLMs 、 MITRE ATLAS framework、AI Risk Repository などがあります。また、STRIDE などの構造化されたフレームワークを活用することもできます。「何を構築しているのか ? 」という質問から得た情報から、最も関連性の高い STRIDE カテゴリを適用してください。例えば、アプリケーションがビジネスにとってリスクを許容できない重要なデータを扱う場合、まず情報漏洩の脅威について様々な角度から検討する必要があるかもしれません。
アプリケーションに対する潜在的な脅威は、脅威ステートメントの形式で記述・文書化することができます。脅威ステートメントは、脅威を文書化する際の一貫性と簡潔性を維持するための方法です。 AWS では、以下の構文の脅威文法を採用しています。
[前提条件] を持つ [脅威の発生源] が [脅威となるアクション] を実行することで、[脅威の影響] が発生し、[影響を受ける資産] に悪影響を及ぼす可能性があります。
この脅威モデリングのアプローチにより、一貫性を維持し、有用な脅威ステートメントを反復的に作成することができます。図 2 に示すように、 Threat Composer は新しい脅威ステートメントをこのような構造で提供し、記述例も含まれています。
図 2: Threat Composer 脅威ステートメントビルダー
脅威ステートメントを作成するプロセスを行うと、「何が問題になり得るか」の要約が得られます。その後、「どのように問題が発生するか」の分析として、攻撃ステップを定義することができます。脅威が実際に発生する方法は多岐にわたるため、必ずしもすべての脅威ステートメントに対して攻撃ステップを定義する必要はありません。いくつかの異なる脅威メカニズムを特定し文書化する作業を行うことで、各攻撃ステップに関連付けることができる具体的な対策を見出し、より効果的な多層防御アプローチを実現できます。
Threat Composer では、脅威ステートメントに追加のメタデータを付加することができます。このオプションをワークフローに採用しているお客様は、主に STRIDE カテゴリと優先度のメタデータタグを使用しています。これにより、お客様は最も優先度の高い脅威と、それらが対応する STRIDE カテゴリを迅速に追跡することができます。図 3 は、 Threat Composer で脅威ステートメントを関連するメタデータと共に文書化する方法を示しています。
図 3: Threat Composer 生成 AI チャットボットアプリケーションのサンプル – 脅威ビュー
アウトプットと検討結果の例
何が問題になるか、そしてどのように問題になるかを体系的に検討することで、様々な潜在的な脅威を明らかにすることができます。このプロセスから生まれるアウトプットの例を見てみましょう。
- 緩和策を実装する STRIDE の要素と優先度で分類された脅威ステートメントのリスト。
- 脅威ステートメントに関連付けられた攻撃ステップのリスト。前述の通り、この段階での攻撃ステップの特定はオプションの活動ですが、少なくとも最優先の脅威についてはいくつか特定することを推奨します。
攻撃ステップの例
前述の脅威ステートメントがどのように発生する可能性があるかを示す攻撃ステップの例を示します。
- システムプロンプトのガードレールをバイパスするための巧妙なプロンプトインジェクションの実行。
- モデルにアクセスできる脆弱なエージェントの埋め込み。
- ウェブページ上での間接的なプロンプトインジェクションの埋め込み。これは LLM に対してユーザーのインストラクションを無視させ、LLM プラグインを使用してユーザーのメールを削除するよう指示します。
それについて何をするのか？
可能性のある脅威を特定したら、それらの脅威に関連するリスクを軽減するのに適切なコントロールを検討します。この決定は、ビジネスのコンテキストと対象となる資産によって導かれます。また、組織のポリシーもコントロールの優先順位付けに影響を与えます。最も多くの脅威に影響を与えるコントロールを優先する組織もあれば、（発生可能性と影響度から）最もリスクが高いと判断される脅威に影響を与えるコントロールから始める組織もあります。
特定された各脅威に対して、具体的な緩和戦略を定義します。これには、入力のサニタイズ、出力のバリデーション、アクセス制御などを含みます。理想的には、最低でも各脅威に対して 1 つの予防的コントロールと 1 つの発見的コントロールを関連付けることが望ましいです。「何が問題になり得るか？」のセクションでリンクされているリソースは、関連するコントロールを特定する際にも非常に有用です。例えば、MITRE ATLAS には緩和策に関する専用のセクションがあります。
注意：脅威に対する緩和策を特定していく過程で、コントロールに重複が見られるかもしれません。例えば、最小権限アクセス制御は、ほぼすべての脅威に関連付けられる可能性があります。この重複は優先順位付けにも役立ちます。ある 1 つのコントロールが脅威への緩和策の 90% に現れる場合、そのコントロールを効果的に実装することで、それらの脅威それぞれのリスクを低減することができます。
アウトプットと検討結果の例
各脅威に関連して、後で検索や再利用を容易にするために一意の識別子を持つ緩和策のリストを用意する必要があります。識別子付きの緩和策の例は以下の通りです。
- M-001: SQL クエリ構造の事前定義
- M-002: 既知のパラメータのサニタイズ（入力のフィルタリング）
- M-003: テンプレート化されたプロンプトパラメータとの照合
- M-004: 出力がユーザーに関連していることの確認（出力のフィルタリング）
- M-005: LLM のコンテキストウィンドウの制限
- M-006: モデルによって実行される高リスクアクションに対する動的な権限チェック（認証パラメータをプロンプトから分離する）
- M-007: アプリケーションのすべてのコンポーネントへの最小権限の適用
生成 AI ワークロードに関連するセキュリティコントロールの詳細については、生成 AI をセキュアにするシリーズのパート 3: 関連するセキュリティコントロールの適用をご確認ください。
図 4 は、Threat Composer で完成した脅威ステートメントの例を示しており、それぞれに緩和策がリンクされています。
図 4: メタデータや関連付けられた緩和策を含む完成した脅威ステートメント
最初の 3 つの質問に答えることで、脅威モデルが完成します。文書には、データフロー図（DFD）、脅威ステートメント、[オプションの] 攻撃ステップ、および緩和策が含まれているはずです。
脅威サマリーの内訳を示す視覚的なダッシュボードを含む、より詳細な例については、Threat Composer の生成 AI チャットボットの例を参照してください。
十分な対応ができているか？
脅威モデルは生きた文書です。本ブログでは、脅威モデルの作成が脅威に対する技術的コントロールを特定するのにどのように役立つかを説明してきましたが、脅威モデリングのプロセスがもたらす非技術的な利点も考慮することが重要です。
最後の活動として、脅威モデリング活動の両要素を検証する必要があります。
特定された緩和策の有効性の検証：特定した緩和策の中には新しいものもあれば、すでに導入されているものもあるかもしれません。いずれにせよ、セキュリティ対策が意図したとおりに機能しているかを継続的にテストし検証することが重要です。これには、ペネトレーションテストや自動化されたセキュリティスキャンが含まれる場合があります。AWS では、脅威モデルはパイプラインに組み込まれる自動テストケースへのインプットとして機能します。また、定義された脅威は、それらの脅威が十分に緩和されているかを確認するために、ペネトレーションテストの範囲を定義するためにも使用されます。
プロセスの有効性の検証：脅威モデリングは本質的に人間の活動です。ビジネス、開発チーム、セキュリティ機能の間での相互作用が必要です。アプリケーションの作成と運用に最も近い人々が脅威モデルの文書を所有し、セキュリティチーム（またはセキュリティガーディアン相当）のサポートを受けながら、頻繁に見直すべきです。これをどの程度の頻度で行うかは、組織のポリシーやワークロードの重要性によって異なりますが、脅威モデルの見直しを開始するトリガーを定義することが重要です。トリガーの例としては、脅威インテリジェンスの更新、データフローを大きく変更する新機能、システムのセキュリティ関連の側面（認証や認可、ログ記録など）に影響を与える新機能などが挙げられます。特に新技術を採用する場合は、脅威の状況が通常よりも速く進化するため、定期的にプロセスを検証することが重要です。
脅威モデリングプロセスの振り返りを行うことは、何がうまくいき、何がうまくいかなかったか、そして次回の脅威モデルを見直す時にどのような変更を行うかを検討し議論する良い方法でもあります。
出力例
このプロセスのステップにおける出力例は以下の通りです。
- 緩和策に基づく自動テストケースの定義
- ペネトレーションテストの定義された範囲と、脅威に基づくテストケース
- アプリケーションの文書（データフロー図を含む）と共に保存される、生きた文書としての脅威モデル
- 脅威モデリング参加者からの教訓とフィードバック、および次回の改善に向けたレトロスペクティブの概要
まとめ
本ブログでは、生成 AI ワークロードに対する実践的かつプロアクティブな脅威モデリングのアプローチを探りました。取り上げた主要なステップは、ビジネスコンテキストとアプリケーションアーキテクチャの理解から、潜在的な脅威の特定、緩和戦略の定義、そしてプロセス全体の有効性の検証に至るまで、効果的な脅威モデリングを実施するための構造化されたフレームワークを提供しています。
このアプローチに従うことで、組織は生成 AI 技術を採用する際に高いセキュリティ基準を維持するための準備を整えることができます。脅威モデリングプロセスは、既知のリスクを緩和するだけでなく、組織が採用すべき重要なセキュリティ志向の文化も育成します。これにより、システムとデータのセキュリティとプライバシーを維持しながら、強力な技術の可能性を最大限に引き出すことができます。
生成 AI セキュリティのその他の領域についてさらに詳しく知りたい場合は、生成 AI をセキュアにするシリーズの他のブログをご覧ください。
- パート 1 — 生成 AI をセキュアにする : 生成 AI セキュリティスコーピングマトリックスの紹介
- パート 2 — 生成 AI ワークロードにおけるレジリエンス設計
- パート 3 — 生成 AI をセキュアにする：関連するセキュリティコントロールの適用
- パート 4 — 生成 AI をセキュアにする：データ、コンプライアンス、プライバシーに関する考慮点
著者について
翻訳はプロフェッショナルサービスの舘、藤浦が担当しました。