【AWS】Bedrock 環境を狙う 8 つの攻撃ベクトルと実践的セキュリティ対策

はじめに

AWS Bedrock は、エンタープライズ企業が生成 AI アプリケーションを構築するための強力なプラットフォームです。しかし、基盤モデルを社内のデータベースや SaaS システムと直接連携させるその利便性が、新たなセキュリティリスクを生み出しています。

本記事では、XM Cyber の脅威リサーチチームによって報告された、AWS Bedrock 環境に潜む 8 つの攻撃ベクトルについて解説します。攻撃者がどのようにしてクラウド環境の権限や周辺機能を悪用し、機密データやインフラの制御を奪うのかを技術的に紐解き、AWS の IAM ポリシーやアーキテクチャ設計に組み込むべき具体的な防御策を客観的な視点で提示します。

AWS Bedrock を取り巻く脅威の全体像

AWS Bedrock は、Salesforce インスタンスへのクエリ実行、Lambda 関数のトリガー、SharePoint のナレッジベースからのデータ抽出など、自律的なエージェント機能を提供します。攻撃者はこの「つながり」をインフラ内のノードとして悪用します。

モデルそのものではなく「周辺機能と権限」が狙われる理由

今回報告された 8 つの攻撃ベクトルは、基盤モデル（LLM）自体の脆弱性を突くものではありません。

参考: We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them
“These eight Bedrock attack vectors share a common logic: attackers target the permissions, configurations, and integrations surrounding the model – not the model itself.”
（これら 8 つの Bedrock 攻撃ベクトルは共通の論理を共有しています。攻撃者はモデルそのものではなく、モデルを取り巻く権限、構成、および統合を標的にします。）
https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html

攻撃の起点は、常に「過剰に付与された権限（Over-privileged Identity）」です。単一の過剰な権限が存在するだけで、攻撃者は AWS Bedrock 環境内に足場を築き、重要なオンプレミスシステムやクラウド上の機密データへと到達することが可能になります。

OWASP Top 10 for LLM と Bedrock の攻撃ベクトルの関係

これらの脅威は、OWASP が定義する「LLM アプリケーション向けトップ 10（OWASP Top 10 for LLM）」の概念と密接に関連しています。

例えば、エージェントが不正な Lambda 関数を実行させられる攻撃は「LLM07: 安全でないプラグイン設計（Insecure Plugin Design）」に該当し、ナレッジベースを通じて認証情報が窃取される脅威は「LLM06: 機密情報の漏洩（Sensitive Information Disclosure）」として説明できます。

クラウドインフラエンジニアは、AI 固有のリスクフレームワークと AWS の標準的なセキュリティベストプラクティスを統合し、システム全体を俯瞰したアーキテクチャの保護に取り組む必要があります。

データソースとナレッジベースを狙う攻撃と対策（Vector 2、3）

AWS Bedrock のナレッジベースは、RAG（検索拡張生成）を通じて基盤モデルと企業の独自データ（S3 バケット、Salesforce、SharePoint など）を結びつけます。攻撃者はこの連携部分の権限を標的とします。

S3 やベクトルデータベースからの機密情報窃取メカニズム

ナレッジベースの背後にあるデータソース（Vector 2）やデータストア（Vector 3）は、直接的な攻撃経路になり得ます。

参考: We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them
“For example, an attacker with s3:GetObject access to a Knowledge Base data source can bypass the model entirely and pull raw data directly from the underlying bucket.” （例えば、ナレッジベースのデータソースに対する s3: GetObject アクセス権を持つ攻撃者は、モデルを完全にバイパスして、基盤となるバケットから直接生データを引き出すことができます。）
https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html

データが格納されている S3 バケットの読み取り権限を奪取できれば、AI モデルの制御を迂回して直接データを窃取できます。さらに深刻なのは、Bedrock が SaaS 連携に使用する認証情報（API キーなど）が奪われるケースです。Pinecone や Redis といったベクトルデータベースの認証情報がインターセプトされた場合、攻撃者はデータの格納領域全体への管理者アクセスを獲得し、Active Directory 等への横展開（ラテラルムーブメント）を試みる可能性があります。

IAM ポリシーとネットワーク分離によるデータストアの保護

データソースを保護するための最重要課題は、AI ワークロードを取り巻くネットワークとアクセス権限の分離です。

ナレッジベースとして機能する S3 バケットやベクトルデータベースへのアクセス権限（IAM ポリシー）は、Bedrock のサービスロールのみに限定し、人間や他のアプリケーションからの直接アクセスを最小権限の原則に基づいて遮断することが不可欠です。また、VPC エンドポイント（AWS PrivateLink）を利用して Bedrock とデータストア間の通信をプライベートネットワーク内に閉じ込め、インターネット経由の不正アクセス経路を物理的に排除するアーキテクチャ設計が推奨されます。

エージェントとワークフローのハイジャックと対策（Vector 4、5、6）

Bedrock エージェントとフローは、ユーザーの入力に基づいて自律的にタスクを実行するオーケストレーターです。ここが侵害されると、AI ワークフローが攻撃者の手足として機能してしまいます。

Lambda 関数への不正コード注入とフローの改ざん

エージェントに対する攻撃は、直接的（Vector 4）なものと間接的（Vector 5）なものに分かれます。エージェントの構成を変更する権限（UpdateAgent など）を持つ攻撃者は、内部の指示やツールスキーマを漏洩させたり、悪意のある実行ツールを追加したりすることが可能です。

さらに巧妙な間接的攻撃として、エージェントがタスク実行に使用する Lambda 関数のコード自体を改ざんする手法が存在します。

フロー（Vector 6）に対する攻撃では、タスクの実行手順の中に攻撃者が制御する「不正な S3 ストレージノード」や「悪意のある Lambda 関数ノード」が密かに注入されます。これにより、アプリケーションの論理を破壊することなく、機密性の高い入力データが攻撃者のエンドポイントへ静かにルーティングされてしまいます。

最小権限の原則に基づく Bedrock リソースの権限管理

これらのハイジャックを防ぐためには、AI エージェントが依存するインフラストラクチャに対する変更権限を厳格に管理する必要があります。

エージェントが呼び出す Lambda 関数に対するコード更新権限やレイヤーの公開権限を、開発者個人から剥奪し、承認された CI/CD パイプライン（自動化ロール）のみに限定することが不可欠です。また、フロー機能を利用する際は、KMS（AWS Key Management Service）のキーポリシーを厳格化し、攻撃者が用意したカスタマーマネージドキーへの意図しない差し替え（暗号化の乗っ取り）を防ぐ設定を適用してください。

プロンプト汚染とガードレール無効化と対策（Vector 1、7、8）

AWS Bedrock の安全性を担保するガードレール機能やプロンプト管理メカニズムも、権限設定の不備により無効化されるリスク（Vector 7、8）を抱えています。さらに、インシデントの痕跡自体がログ操作（Vector 1）によって消し去られる可能性があります。

プロンプトテンプレートの改ざんとログの隠蔽工作

一元管理されているプロンプトテンプレート（Managed Prompt）に対する更新権限を奪われると、システム全体に深刻な影響を及ぼします。

参考: We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them
“Because prompt changes do not trigger application redeployment, the attacker can alter the AI’s behavior “in-flight,” making detection significantly more difficult for traditional application monitoring tools.” （プロンプトの変更はアプリケーションの再デプロイを引き起こさないため、攻撃者は AI の動作を「実行中」に変更でき、従来のアプリケーション監視ツールでの検出を著しく困難にします。）
https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html

攻撃者は、悪意のあるプロンプト（常に特定のリンクを含める、PII 制限を無視するなど）をテンプレートに注入し、AI の挙動を密かに操ります。また、防御層であるガードレールの設定レベルを下げて毒性フィルターを無効化したり、モデルの呼び出しログの出力先（S3 バケットなど）を変更・削除して、フォレンジック調査の証拠を完全に隠蔽（スクラブ）したりする手法が確認されています。

アプリケーション側の防御策と継続的なセキュリティ監視

これらの高度な内部犯行や権限昇格を防ぐためには、モデル周辺の構成変更に対する強力なガバナンスが必要です。

プロンプトやガードレールを更新するための API（UpdatePrompt や UpdateGuardrail など）の実行権限を、日常的な運用ロールから完全に分離し、変更には厳格な承認プロセスを設けることが不可欠です。さらに、AWS CloudTrail を活用して Bedrock 関連の API 呼び出しや S3 バケットのログ削除イベントを継続的に監視し、異常な構成変更が検出された場合には即座にアラートを発砲する統合的なセキュリティ監視体制を構築してください。

まとめ

本記事では、AWS Bedrock 環境における 8 つの攻撃ベクトルと、それらに対する実践的なセキュリティ対策を解説しました。

• 攻撃者はモデル自体ではなく、モデル周辺の過剰な権限や統合機能を標的とする。
• ナレッジベースの背後にある S3 等のデータソースは、IAM と VPC エンドポイントで保護する。
• エージェントやフローの改ざんを防ぐため、Lambda 等のインフラへの変更権限を最小化する。
• プロンプト汚染やログ隠蔽に対抗するため、構成変更 API の分離と CloudTrail 監視を徹底する。

以上、最後までお読みいただきありがとうございました。