View a markdown version of this page

Amazon Bedrock AgentCore 支払いのセキュリティ - Amazon Bedrock AgentCore

Amazon Bedrock AgentCore 支払いのセキュリティ

以下のベストプラクティスは、Amazon Bedrock AgentCore 支払いを使用する際のセキュリティインシデントの防止に役立ちます。予防的コントロールは、安全でないアクションが発生する前に停止します。Detective コントロールは予期しないアクティビティを表示するため、応答できます。

予防的コントロール

これらのコントロールを使用して、エージェントができることを制限し、機密性の高いマテリアルが手の届かないようにします。

4 ロールの IAM パターンで最小特権を適用する

AgentCore の支払いは、個別の IAM ロールを使用してコントロールプレーンをデータプレーンから分離します。各ロールに一致するペルソナに基づいて IAM アクセス許可を設定します。このパターンでは、1 つのロールで予算を引き上げ、それに対して支出することはできません。

# ロール 目的

1

ControlPlaneRole

サービスを管理します。

2

ManagementRole

セッションを設定します。このロールは明示的に拒否されますProcessPayment

3

ProcessPaymentRole

支払いを実行します。

4

ResourceRetrievalRole

サービス引き受け。セッションと認証情報の状態を取得します。

詳細については、AgentCore 支払いの IAM ロール」を参照してください。

AgentCore Identity に認証情報を保存する

エージェントコードまたは環境変数にウォレットプロバイダーの認証情報を埋め込まないでください。

  • AgentCoreアイデンティティPaymentCredentialProviderに Coinbase CDP または Stripe (プライベート) 認証情報を として保存します。

  • サービスは、 を使用して実行時にそれらを取得しますResourceRetrievalRole

  • ウォレットプロバイダーの推奨スケジュールに従って認証情報をローテーションします。認証情報が侵害された場合は、すぐに取り消します。

詳細については、AgentCore Identity」を参照してください。

UserId ヘッダーを正しく設定する

IAM 設定のインバウンド認可支払いマネージャーでは、バックエンドは X-Amzn-Bedrock-AgentCore-Payments-User-Idヘッダーをアサートし、AgentCore 支払いはヘッダーを検証しません。この値を正しく設定するのはお客様の責任です。

AgentCore の支払いは、IAM 発信者と JWT (OAuth を使用する場合) を検証しますが、API コールのUserIdヘッダーが正しいかどうかはユーザーの責任です。エンドユーザーまたはエージェントがこのヘッダーに直接影響しないようにします。

マルチテナントデプロイを保護する

複数のエンドユーザーに対応するマルチテナントデプロイの場合は、支払いマネージャーで CUSTOM_JWT (OAuth) 認可タイプを使用します。これにより、検証済みのエンドユーザー ID がサービスに提供されます。IAM 設定の支払いマネージャーでは、AgentCore 支払いはエンドユーザー ID を検証しません。

資金と委任は 2 つの異なるエンドユーザーの決定であり、どちらもエージェントからout-of-bandに行われます。

  • 資金 – エンドユーザーはウォレットプロバイダーポータルを通じて資金を預金します。エージェントには資金への API アクセスがないため、エージェントに要求したり、自動開始したりすることはできません。

  • 委任 – エンドユーザーは、Coinbase Spend Permissions または Privy 委任アクションを通じてアクセス許可を付与します。委任は永続的であると想定しないでください。ユーザーはいつでも取り消すことができます。取り消された委任を適切に処理します。

エージェントを支払い手段から隔離する

エージェントは、カード番号、CVV 値、銀行の詳細、またはウォレットプライベートキーにアクセスしてはなりません。エージェントの表示は「ユーザー所有のウォレットから消費するアクセス許可」で停止します。

  • ウォレットキーは、 AWS または開発者ではなく、プロバイダーが自己管理で保持します。

  • プロンプト、ツール入力、またはコンテキストウィンドウを通じて支払い手段の詳細を渡さないでください。

AgentCore の Policy によるスコープツールアクセス

ツールレベルの認可については、Amazon Bedrock AgentCore Gateway を通じて有料エンドポイントを公開します。Gateway 経由のすべての呼び出しは、エージェントの ID、ツール名、パラメータなど、リクエストを評価し、許可するかどうかを決定する Cedar ベースのエンジンである AgentCore の Policy によって傍受されます。

ポリシーセッションと支払いセッションは、さまざまな決定を対象としています。

  • ポリシー、どのツールをどのパラメータで呼び出すを制御します。

  • 支払いセッションは、使用できる使用量期間を制御します。

これらを組み合わせることで、ツールへのアクセスと使用量の直交レバーが得られます。

  • エージェント ID、ユーザーグループ、およびリクエストパラメータによってスコープされた Cedar ポリシーを記述します。

  • 不要なエージェントの高コストツールへのアクセスを拒否します。

  • ツールカタログの変更に応じて、ポリシーを定期的に確認および監査します。

詳細については、AgentCore のポリシー」を参照してください。

予算制限と TTL で支払いセッションを使用する

すべての支払いは、最大使用額と有効期限がある支払いセッション内で実行されます。インフラストラクチャレイヤーはこれらの制限を適用するため、プロンプトインジェクションとモデル非決定論はそれらを上書きできません。

  • をタスクに必要な最小値maxSpendAmountに設定し、短い TTL を設定します。

  • 控えめな予算から始めて、エージェントが信頼できることを証明した場合にのみ予算を引き上げます。

  • 失敗した署名は、予算の控除を自動的にロールバックします。

詳細については、「支払いセッションの作成」を参照してください。

payTo アドレスの検証と制限

payTo アドレスは受信者ウォレットを指定します。AgentCore の支払いではサーバー側のpayTo制限は適用されないため、アプリケーションは ProcessPayment API を呼び出す前にアドレスを検証する必要があります。

  • 事前に検証されたマーチャントアドレスの許可リストを維持し、不明なアドレスを拒否します。

  • モデルに payTo アドレスを生成させないでください。x402 支払いリクエストや検証済みレジストリなどの信頼できるソースから取得する必要があります。

  • x402 レスポンスを処理するときに、想定されるマーチャントと照合して検証します

  • エンドポイント検出には AgentCore Gateway を優先します。これは、x402 バザールを通じて検証済みpayToアドレスが提供されるためです。

  • Cedar ポリシーを適用して、エージェントが支払うことができるアドレスを制限します。

  • セッション間でアドレスをキャッシュしないでください。許可リストに照らして検証された、現在のマーチャント提供のアドレスを常に使用してください。

安全なネットワークアクセス

  • VPC エンドポイントを使用して、トラフィックをパブリックインターネットから遠ざけます。

  • エンドポイントポリシーと IAM 条件 (aws:sourceVpcaws:sourceVpce) を適用してオリジンを制限します。

  • すべての AgentCore 支払い API コールの Enable AWS CloudTrail。

支払いの失敗とロールバックのための設計

  • 冪等性を実装して、再試行時の重複支払いを防止します。

  • 明確なフォールバック動作で支払いの失敗を処理します。無期限に再試行しないでください。

  • 部分的な障害をモニタリングし、補償トランザクションを実装します。

「発見的コントロール」

これらのコントロールを使用して支払いアクティビティを監視し、異常を表面化して対応できるようにします。

オブザーバビリティと監査ログ記録を有効にする

AgentCore 支払いは、Amazon CloudWatch を通じて自動オブザーバビリティを提供します。

  • 提供されたログ – すべてのデータプレーン呼び出しがログに記録されます (誰が、何を、どのくらい、誰に対して)。

  • 支払済みスパン – フル支払いライフサイクルトレースは AWS X-Ray で利用できます。

  • リストにない住所への支払い、異常な数の個別の受取人、既知のマーチャントの突然の住所変更など、異常な支出パターンのアラームを設定します。

  • コンプライアンス要件に従ってログを保持します。

  • エージェントコードを使用して独自のアクションをログに記録しないでください。

詳細については、Amazon CloudWatch によるオブザーバビリティ」を参照してください。

設定を定期的に確認する

  • 予算を監査し、支出が少ないエージェントの制限を減らします。

  • Cedar ポリシーと IAM ロールを四半期ごとに確認します。

  • ウォレットプロバイダーダッシュボードをモニタリングして、予期しない委任や資金調達アクティビティがないか確認します。