生成 AI ワークロードのインシデント対応方法論

本ブログは「Methodology for incident response on generative AI workloads」を翻訳したものとなります。

AWS カスタマーインシデント対応チーム (CIRT) は、生成 AI ベースのアプリケーションに関連するセキュリティインシデントの調査に使用できる方法論を開発しました。生成 AI ワークロードに関連するセキュリティイベントに対応するには、引き続き AWS セキュリティインシデント対応ガイドに記載されているガイダンスと原則に従う必要があります。生成 AI ワークロードでは、いくつかの追加要素も考慮する必要があるため、このブログ投稿で詳しく説明します。

本ブログでは、はじめに生成 AI ワークロードの一般的なコンポーネントについて説明します。次に、イベント発生前における準備と生成 AI ワークロードのインシデント対応方法論をご紹介します。インシデント対応方法論は、生成 AI ワークロードのセキュリティイベントをトリアージして対応する際に考慮すべき 7 つの要素で構成されています。最後に、方法論を検討するのに役立つインシデントの例を応用シナリオを使用してご紹介します。

生成 AI ワークロードのコンポーネント

図 1 に示すように、生成 AI アプリケーションには次の 5 つのコンポーネントが含まれます。

インフラストラクチャ、生成 AI アプリケーション、および組織のプライベートデータを所有または管理する組織。
生成 AI アプリケーション自体に特に関係のない組織内のインフラストラクチャ。これには、データベース、バックエンドサーバー、および Web サイトが含まれます。
生成 AI アプリケーション。これには以下が含まれます。
- 基盤モデル — 多数のパラメーターを持ち、膨大な量の多様なデータに基づいてトレーニングされた AI モデル。
- カスタムモデル — 組織固有の要件に合わせて、組織の特定のデータやユースケースに基づいてファインチューニングまたはトレーニングされたモデル。
- ガードレール — 生成 AI アプリケーションが希望する範囲内で動作することを保証するためのメカニズムまたは制約。例としては、コンテンツフィルタリング、安全上の制約、倫理ガイドラインなどがあります。
- エージェント — 生成 AI アプリケーションが会社のシステムやデータソース全体で複数ステップのタスクを実行できるようにするワークフロー。
- ナレッジベース — 生成 AI アプリケーションがアクセスして使用できるドメイン固有の知識、ルール、またはデータのリポジトリ。
- トレーニングデータ — 検索拡張生成 (RAG) などの手法用のデータを含む、生成 AI アプリケーションのモデルのトレーニング、ファインチューニング、または拡張に使用されるデータ。
  
  注: トレーニングデータは組織のプライベートデータとは異なります。生成 AI アプリケーションは通常、プライベートデータに直接アクセスすることはありませんが、一部の環境では設定によってアクセスが可能な場合もあります。

- プラグイン — 生成 AI アプリケーションと統合して、特殊な機能を提供したり、外部サービスやデータソースにアクセスしたりできる追加のソフトウェアコンポーネントまたは拡張機能。
プライベートデータとは、生成 AI リソースまたはアプリケーションが通常の運用中に操作しないプライベートに保存されたお客様の機微データを指します。
ユーザーとは、生成 AI アプリケーションの操作や、アプリケーションにアクセスするアイデンティティです。人間でも人間以外 (機械など) でもかまいません。

Figure 1: Common components of an AI/ML workload

図 1 : 生成 AI ワークロードの一般的なコンポーネント

生成 AI ワークロードでのインシデント対応に備える

セキュリティイベントに備えるには、「人」、「プロセス」、「テクノロジー」の 3 つのドメインに渡って準備が必要です。準備内容の概要については、『セキュリティインシデント対応ガイド』の準備項目を参照してください。さらに、生成 AI ワークロードに関連するセキュリティイベントの準備には、以下を含める必要があります。

人材: インシデント対応スタッフとセキュリティ運用スタッフへの生成 AI に関するトレーニング — 担当スタッフが生成 AI の概念と組織で使用されている AI/ML サービスに精通していることを確認する必要があります。AWS Skill Builder では、これら両方の科目に関する無料コースと有料コースの両方を提供しています。
プロセス: 新しいプレイブックの開発 — 生成 AI ワークロードに関連するセキュリティイベントのための新しいプレイブックを開発する必要があります。これらの開発方法の詳細については、以下のサンプルプレイブックを参照してください。
- Amazon Bedrock セキュリティイベントへの対応
- Amazon SageMaker セキュリティイベントへの対応
- Amazon Q セキュリティイベントへの対応
  各サービスのプレイブックを出発点として使用し、組織や各サービスの使用状況に合わせて変更することができます。
テクノロジー: 生成 AI アプリケーションのプロンプトと呼び出しをログに記録する — AWS CloudTrail で利用できるような基本的なログに加えて、アプリケーションに入力されるプロンプトと出力内容を分析できるように、Amazon Bedrock モデルの呼び出しログを記録することを検討する必要があります。詳細については、「Amazon Bedrock モデル呼び出しのログ記録」を参照してください。CloudTrail データイベントのログは、Amazon Bedrock、Amazon Q、Amazon SageMaker でも利用できます。一般的なガイダンスについては、「セキュリティインシデント対応のためのロギング戦略」を参照してください。

重要: ログには機微情報が含まれる場合があります。この情報を保護するには、他のセキュリティログと同様に、これらのログへの最小権限アクセスを設定する必要があります。データマスキングを使用して機微なログデータを保護することもできます。Amazon CloudWatch では、ロググループのデータ保護ポリシーを使用してデータをネイティブにマスクできます。

生成 AI ワークロードにおけるインシデント対応の方法論

準備項目が完了したら、生成 AI ワークロードのインシデント対応方法論を使用したアクティブな対応が可能になります。これは生成 AI アプリケーションに関連するセキュリティイベントを迅速にトリアージするのに役立ちます。

方法論には 7 つの要素があり、このセクションで詳しく説明します。各要素は、コンポーネントが別のコンポーネントと相互作用する方法や、コンポーネントを変更する方法を記述します。これらの要素を考慮することは、検知、分析、封じ込め、根絶、復旧の各段階を含むセキュリティインシデントの運用段階における行動の指針となります。

アクセス — 生成 AI アプリケーションのコンポーネントをホストする組織のアクセスパターンを特定し、それらのパターンからの逸脱や異常を調査します。アプリケーションが外部からアクセス可能か、または内部からアクセス可能かを確認します。Amazon GuardDuty を使用すると、AWS 環境への異常なアクセスや潜在的な不正アクセスを特定しやすくなります。アプリケーションに外部からアクセスできる場合、脅威アクターは AWS 環境に直接アクセスできない可能性があり、 GuardDuty はそれを検出しません。アプリケーションへの認証の設定方法によって、不正アクセスの検出と分析の方法が決まります。
AWS アカウントまたは関連するインフラストラクチャへの不正アクセスの証拠がある場合は、関連する権限やタイムラインなど、不正アクセスの範囲を特定します。不正アクセスにサービスの認証情報 (Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの認証情報など) が含まれる場合は、サービスに脆弱性がないか確認してください。
インフラストラクチャの変更 — サーバー、データベース、サーバーレスコンピューティングインスタンス、内部または外部の Web サイトなどの生成 AI アプリケーションをサポートするインフラストラクチャを確認して、アクセスまたは変更されたかを判断します。インフラストラクチャの変更を調査するには、CloudTrail ログを分析して対象範囲内のリソースの変更を調べたり、他のオペレーティングシステムログやデータベースアクセスログを分析します。
AI の変更 — ユーザーが生成 AI アプリケーションのコンポーネントにアクセスしたか、またそれらのコンポーネントに変更を加えたかを調査します。カスタムモデルの作成または削除、モデルの可用性の変更、生成 AI ロギング機能の改ざんまたは削除、アプリケーションコードの改ざん、生成 AI ガードレールの削除または変更など、不正アクティビティの兆候がないか確認します。
データストアの変更 — 設計または意図されたデータアクセスパターンを特定し、ユーザーが生成 AI アプリケーションのデータストアにアクセスしたかどうか、およびこれらのデータストアに変更を加えたかどうかを判断します。また、生成 AI アプリケーションへのエージェントの追加または変更も検討する必要があります。
呼び出し — 文字列やファイル入力を含む生成 AI モデルの呼び出しを分析して、プロンプトインジェクションやマルウェアなどの脅威がないかを確認します。OWASP Top 10 for LLM は、呼び出し関連の脅威を理解するための出発点として使用できます。また、呼び出しログを使用して、プロンプトを分析して、プロンプトインジェクションの試みを示唆する可能性のある疑わしいパターン、キーワード、または構造がないか調べることができます。ログにはモデルの出力と応答も記録されるため、プロンプトインジェクションを示唆する特徴的でない、または安全でないモデルの動作を特定するための動作分析に役立ちます。ログ内のタイムスタンプを時系列分析に使用すると、組織的なプロンプトインジェクションの試みを経時的に検出し、モデル呼び出しを開始したユーザーまたはシステムに関する情報を収集できるため、潜在的な悪用の原因を特定するのに役立ちます。
プライベートデータ — 対象範囲の生成 AI アプリケーションが、個人データまたは機微データにアクセスが可能か確認します。次に、そのデータへの不正アクセスや改ざんがないか調べます。
代理行為 — 代理行為とは、アプリケーションが組織のリソースを変更したり、ユーザーに代わってアクションを実行したりする機能を指します。たとえば、生成 AI アプリケーションは、メールを送信するために使用されるコンテンツを生成し、そのために別のリソースまたは関数を呼び出すように構成されている場合があります。生成 AI アプリケーションに他の機能を呼び出す機能があるかどうかを判断する必要があります。次に、不正な変更が行われたのか、それとも生成 AI アプリケーションが不正な機能を呼び出したのかを調査します。

次の表は、方法論の 7 つの要素に取り組むのに役立ついくつかの質問を示しています。回答を参考にしてください。

トピック	トピックに対する質問
アクセス	コンピューティング環境にまだアクセスできますか？あなたの組織に不正アクセスの証拠は残っていますか？
インフラストラクチャの変更	サポートするインフラリソースへのアクセス、および変更が実施されましたか？
AI の変更	AI モデル、コード、リソースへのアクセス、および変更が実施されましたか？
データストアの変更	データストア、ナレッジベース、エージェント、プラグイン、またはトレーニングデータへのアクセス、および変更が実施されましたか？
呼び出し	どのようなデータ、文字列、ファイルがモデルへの入力として使用されましたか？どのようなプロンプトが送信されましたか？その結果、どのような応答が生成されましたか？
プライベートデータ	生成AIリソースはどのような個人データや機微データにアクセスできますか？プライベートデータの変更や改ざんは発生していませんか？
代理行為	生成 AI リソースを使用して組織内でコンピューティングサービスを開始できますか? 生成 AI リソースに変更を加える権限がありますか? 不正な変更が加えられましたか?

インシデントの例

調査と対応のための方法論の使い方を見ていきましょう。ここでは不正なユーザーが公開されたコードリポジトリに流出した認証情報を使用して、 AWS 上でホストされている生成 AI アプリケーションに侵入するというセキュリティイベントの例を扱います。私たちの目標は、どのリソースがアクセス、変更、作成、削除されたかを判断することです。

AWS で生成 AI のセキュリティイベントを調査するために確認すべき主なログソースは以下の通りです:

CloudTrail
CloudWatch
VPC Flow Logs
Amazon Simple Storage Service (Amazon S3) データイベント (組織の S3 バケットへのアクセスの証拠用)
Amazon Bedrock モデル呼び出しのログ (アプリケーションがこのサービスを使用している場合)

アクセス

生成 AI アプリケーションのアクセス分析は、標準的な 3 層ウェブアプリケーションのアクセス分析と似ています。まず、組織が AWS アカウントにアクセスできるかどうかを判断します。AWS アカウントのルートユーザーのパスワードを紛失または変更した場合は、パスワードをリセットします。次に、ルートユーザーの多要素認証（MFA）デバイスをすぐに有効にすることを強くお勧めします。これにより、脅威アクターがルートユーザーでアクセスするのを防ぐことができます。

次に、アカウントへの不正アクセスが続いているかどうかを確認します。AWS Identity and Access Management (IAM) と AWS Security Token Service (Amazon STS)によって記録された変更を伴うアクションを特定するには、GitHub の「AWS アカウントの認証情報が侵害された場合のセキュリティプレイブック」の「分析」セクションを参照してください。最後に、アクセスキーがパブリックリポジトリやアプリケーションコードに保存されていないことを確認してください。代替案については、「長期的なアクセスキーに対する代替方法」を参照してください。

インフラストラクチャの変更

アプリケーションのインフラストラクチャの変更を分析するには、コントロールプレーンとデータプレーンの両方を考慮する必要があります。この例では、生成 AI アプリケーションのダウンストリームコンポーネントへの認証に Amazon API Gateway が使用され、他の付帯的なリソースがアプリケーションとやり取りしていたとします。CloudTrail でこれらのリソースに対するコントロールプレーンの変更を確認することもできますが、リソースのオペレーティングシステムで行われた変更を確認するには、追加のログ記録を有効にする必要があります。この要素に関して CloudTrail で見つかる可能性のあるコントロールプレーンイベントの一般的な名称は次のとおりです。

ec2:RunInstances
ec2:StartInstances
ec2:TerminateInstances
ecs:CreateCluster
cloudformation:CreateStack
rds:DeleteDBInstance
rds:ModifyDBClusterSnapshotAttribute

AI の変更

許可されていない変更には、システムプロンプト、アプリケーションコード、ガードレール、およびモデルの可用性が含まれますが、これらに限定されません。AWS がホストする生成 AI リソースへの内部ユーザーアクセスは CloudTrail に記録され、次のいずれかのイベントソースで表示されます。

bedrock.amazonaws.com
sagemaker.amazonaws.com
qbusiness.amazonaws.com
q.amazonaws.com

以下は、このシナリオ例における生成 AI リソースログの改ざんを表す CloudTrail のイベント名の例をいくつか示しています。

bedrock:PutModelInvocationLoggingConfiguration
bedrock:DeleteModelInvocationLoggingConfiguration

AI/ML モデルのサービス設定へのアクセスを表す CloudTrail の一般的なイベント名は次のとおりです。

bedrock:GetFoundationModelAvailability
bedrock:ListProvisionedModelThroughputs
bedrock:ListCustomModels
bedrock:ListFoundationModels
bedrock:ListProvisionedModelThroughput
bedrock:GetGuardrail
bedrock:DeleteGuardrail

このシナリオ例では、不正なユーザーが AWS アカウントにアクセスしています。ここで、侵害されたユーザーに、すべてのリソースへのフルアクセスを許可するポリシーが添付されているとします。このアクセスにより、権限のないユーザーは Amazon Bedrock の各コンポーネントを列挙し、アプリケーションの一部であるナレッジベースとガードレールを特定できます。

その後、不正なユーザーは Amazon Bedrock 内の他の基盤モデル (FM) へのモデルアクセスをリクエストし、既存のガードレールを削除します。他の基盤モデルにアクセスできるということは、不正なユーザーが生成 AI アプリケーションを自分の目的で使用しようとしていることを示している可能性があり、ガードレールの削除により、モデルによるフィルタリングや出力チェックが最小限に抑えられます。AWS では、IAM ポリシーとリソースベースのポリシーを使用してきめ細かなアクセス制御を実装し、必要な Amazon Bedrock リソース、AWS Lambda 関数、およびアプリケーションに必要なその他のコンポーネントのみへのアクセスを制限することを推奨します。また、Amazon Bedrockなどの重要なコンポーネントや生成 AI アプリケーションの他のコンポーネントにアクセスできる IAM ユーザー、ロール、サービスアカウントには、MFA の使用を強制する必要があります。

データストアの変更

通常、データストアやナレッジベースの使用およびアクセスはモデル呼び出しを通じて行います。Amazon Bedrock の場合は、bedrock:InvokeModelという API を呼び出します。

ただし、不正なユーザーが環境にアクセスした場合、生成 AI アプリケーションが統合するデータソースとナレッジベースを作成、変更、または削除できます。これにより、データまたはモデルの流出または破壊、データ汚染が発生し、モデルのサービス拒否状態が発生する可能性があります。以下は、このシナリオ例の AI/ML データソースへの変更を表す CloudTrail の一般的なイベント名です。

bedrock:CreateDataSource
bedrock:GetKnowledgeBase
bedrock:DeleteKnowledgeBase
bedrock:CreateAgent
bedrock:DeleteAgent
bedrock:InvokeAgent
bedrock:Retrieve
bedrock:RetrieveAndGenerate

実行可能なアクションの完全なリストについては、Amazon Bedrock API リファレンスを参照してください。

このシナリオでは、不正なユーザーが生成 AI アプリケーションへのフルアクセス権を持ち、ある程度の一覧の取得が行われたことを確認しました。その後、不正なユーザーが生成 AI アプリケーションのナレッジベースである S3 バケットを特定し、不正確なデータをアップロードしたため、LLM が破損しました。この脆弱性の例については、LLM アプリケーションの OWASP TOP 10 の「 LLM03 訓練データの汚染」セクションを参照してください。

呼び出し

Amazon Bedrock は特定の API を使用してモデル呼び出しを行います。Amazon Bedrock のモデルが呼び出されると、CloudTrail はそのモデルをログに記録します。ただし、生成 AI モデルに送信されたプロンプトと、そこから受信した出力応答を確認するには、モデル呼び出しのログ記録を設定しておく必要があります。

これらのログは非常に重要です。なぜなら、脅威アクターがモデルを使ってデータストアから情報を引き出そうとしたり、モデルが学習またはファインチューニングされたデータを開示しようとしたかどうかなど、重要な情報を明らかにする可能性があるからです。たとえば脅威アクターが、機微データを抽出したり、セキュリティコントロールをバイパスしたり、ポリシーに違反するコンテンツを生成したりするように巧妙に作りこまれたプロンプトをモデルに与えようとしたかどうかが、ログから明らかになることがあります。ログを使用すると、セキュリティイベントで使用される可能性のある誤った情報、スパム、またはその他の悪意のある出力を生成するためにモデルが使用されたかどうかもわかります。

注: Amazon Bedrock などのサービスでは、呼び出しログの記録はデフォルトで無効になっています。可能な場合は、生成 AI サービスのデータイベントとモデル呼び出しのログ記録を有効にすることをお勧めします。ただし、プライバシーや法的な理由から、組織によっては呼び出しログを取得して保存したくない場合があります。一般的な懸念事項の 1 つは、ユーザーが機微データをインプットとして入力することです。これにより、保護する資産の範囲が広がります。これはビジネス上の決定であり、考慮に入れる必要があります。

このシナリオの例では、モデル呼び出しのログ記録が有効になっていないため、インシデント対応者が呼び出しログを収集して、不正呼び出しに関するモデルへの入力または出力データを確認できなかったとします。インシデント対応者は、 LLM からのプロンプトとそれに続く応答を特定することができませんでした。このログを有効にしないと、呼び出し要求に関連するリクエストデータ、応答データ、メタデータ全体を確認することもできませんでした。

Amazon Bedrock のモデル呼び出しのログ記録に含まれる可能性のあるイベント名には、次のものが含まれます。

bedrock:InvokeModel
bedrock:InvokeModelWithResponseStream
bedrock:Converse
bedrock:ConverseStream

以下は、Amazon Bedrock モデル呼び出しログ記録のログエントリのサンプルです。

Figure 2: sample model invocation log including prompt and response

図 2: プロンプトと応答を含むモデル呼び出しログのサンプル

プライベートデータ

アーキテクチャの観点から見ると、生成 AI アプリケーションは組織のプライベートデータに直接アクセスすべきではありません。生成 AI アプリケーションのトレーニングに使用されるデータまたは RAG 用のデータをデータストアデータとして分類し、プライベートデータから分離する必要があります。ただし、生成 AI アプリケーションがプライベートデータを使用する場合を除きます（たとえば、生成 AI アプリケーションが患者の医療記録に関する質問に答える必要がある場合）。組織のプライベートデータを生成 AI アプリケーションから確実に分離する 1 つの方法は、別のアカウントを使用し、最小権限の原則に従って必要に応じて認証と認可を行うことです。

代理行為

LLM における過剰な代理行為とは、AI システムが過度の自律性や意思決定力を持ち、意図せず潜在的に有害な結果をもたらすことを指します。これは、LLM が不十分な監視や制約、または人間の価値観との整合性が不十分な状態で導入された場合に発生する可能性があります。その結果、多くの人間が有益または倫理的と考えるものとは異なる選択をモデルが行うことになります。

このシナリオの例では、生成 AI アプリケーションには、アプリケーションが必要としないサービスに対する過剰な権限を持っています。アプリケーションコードが Amazon Simple Email Service (Amazon SES) へのフルアクセス権を持つ実行ロールで実行されていたとします。これにより、LLM がプロンプトに応答して不正なユーザーに代わってスパムメールを送信する可能性があります。生成 AI アプリケーションプラグインとエージェントの権限と機能を制限することで、これを防ぐことができます。詳細については、LLM08 過剰な代理行為の証拠である OWASP LLM Top 10 を参照してください。

調査中にログを分析する際、 SourceIpAddress フィールドと UserAgent フィールドの両方が生成的な AI アプリケーション (たとえば、sagemaker.amazonaws.com 、bedrock.amazonaws.com 、q.amazonaws.com) に関連付けられます。他のサービスから一般的に呼び出されたり呼び出されたりする可能性のあるサービスの例としては、Lambda、Amazon SNS、Amazon SES などがあります。

結論

生成 AI ワークロードに関連するセキュリティイベントに対応するには、引き続き AWS セキュリティインシデント対応ガイドに記載されているガイダンスと原則に従う必要があります。ただし、これらのワークロードでは、いくつかの追加要素も考慮する必要があります。

本ブログで紹介した方法論を参考にして、これらの新しい要素に対応することができます。この手法は、生成 AI アプリケーションの使用が不正使用の対象または仕組み、あるいはその両方となるインフラストラクチャへの不正アクセスを調査する場合に参考になります。この方法論により、生成 AI ワークロードに関連するセキュリティインシデントに備えて対応するための体系的なアプローチが可能になり、これらの重要なアプリケーションのセキュリティと整合性を維持するのに役立ちます。

生成 AI アプリケーションを設計するためのベストプラクティスの詳細については、「AWS セキュリティリファレンスアーキテクチャ用の生成 AI」を参照してください。一般的な生成 AI アプリケーションの戦術的緩和策については、「セキュアデザインのためのブループリントとアンチパターンへの緩和戦略」を参照してください。

この投稿について質問がある場合は、AWS セキュリティ、アイデンティティ、コンプライアンス re: Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

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

Amazon Web Services ブログ