View a markdown version of this page

ゲートウェイ経由で AgentCore Memory にアクセスする - Amazon Bedrock AgentCore
AgentCore Memory コネクタリクエストがゲートウェイを通過する方法インバウンド認証モードとアウトバウンド認証モードアウトバウンド認証情報モードがメモリアクセスコントロールに与える影響

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ゲートウェイ経由で AgentCore Memory にアクセスする

デフォルトでは、アプリケーションは Amazon Bedrock AgentCore Memory データプレーンを直接呼び出し、各リクエストは AWS 署名バージョン 4 (SigV4) で認証されます。このアクセスは、IAM アイデンティティベースポリシーとリソースベースのポリシーの両方で制御できます。これは、バックエンドサービスがすべてのユーザーに代わって Memory を呼び出し、Memory Layer でユーザーごとの分離を強制する必要がない場合に適しています。

バックエンドが多くのユーザーに対して Memory を呼び出すと、Memory はバックエンドの IAM ロールのみを表示します。リクエストの対象となるエンドユーザーを確認できません。アプリケーションコードは、リクエストごとに正しい actorIdと名前空間を設定して、あるユーザーのデータを別のユーザーのデータから分離する必要があります。

AgentCore メモリの前に AgentCore Gateway を配置すると、その適用をアプリケーションコードからインフラストラクチャに移動できます。ゲートウェイは、メモリトラフィックの単一の安全なエントリポイントになります。各発信者を認証し、アクセスコントロールポリシーを評価し、許可されたリクエストをメモリに転送します。ゲートウェイを使用したフロンティングメモリには、直接アクセスでは実現できない 2 つの機能があります。

エンドユーザーの OAuth 認証

メモリのデータプレーンは SigV4-onlyです。OAuth (JWT) インバウンド認証用に設定されたゲートウェイを使用すると、エンドユーザーは標準の OpenID Connect プロバイダーで認証でき、アプリケーションは AWS 認証情報を配布しません。詳細については、「エンドユーザーを OAuth でメモリに認証する」を参照してください。

きめ細かなアクセスコントロール

ゲートウェイは、発信者を独自のアクター、独自の名前空間、または OAuth で認証された発信者を含む特定のメモリオペレーションのセットに制限するポリシーを評価できます。詳細については、「メモリのきめ細かなアクセスコントロール」を参照してください。

注記

メモリバッチオペレーション (BatchCreateMemoryRecords、、および ) ではBatchUpdateMemoryRecords、きめ細かなアクセスコントロールはサポートされていませんBatchDeleteMemoryRecords。これらの各オペレーションは、ポリシーエンジンが個別に評価できない複数のレコードを 1 つのリクエストに保持します。

どちらの機能も、このページで説明されている AgentCore Memory コネクタ上に構築されています。コネクタのセットアップは、どちらかの前提条件です。

トピック

AgentCore Memory コネクタ

AgentCore Memory コネクタ (agentcore-memory) は、ゲートウェイターゲットを AgentCore Memory データプレーンにワイヤリングするマネージドゲートウェイコネクタです。 AgentCore コネクタは組み込みターゲットタイプです。API スキーマを作成し、エンドポイントを自分で接続するのではなく、コネクタタイプのターゲットを作成し、コネクタ ID とターゲットパラメータのみを指定します。

メモリコネクタターゲットを作成するときは、以下を指定します。

  • コネクタ ID (agentcore-memory)、および

  • ターゲットパラメータ、特にターゲットが前面にあるメモリリソースmemoryIdの 。

次に、コネクタは次の操作を行います。

メモリエンドポイントを解決します

ターゲットのメモリリソースの正しいメモリデータプレーンエンドポイントを決定します。

サポートされているメモリオペレーションを Cedar アクションとして利用可能に

コネクタは、次の Memory データプレーンオペレーションを Cedar アクションとして利用できるようにします。それぞれが受け入れるリクエストフィールド: ListEvents、CreateEvent、、GetEventDeleteEvent、、ListSessions、、、ListActorsRetrieveMemoryRecordsListMemoryRecordsGetMemoryRecordDeleteMemoryRecord、ListMemoryExtractionJobs、、および StartMemoryExtractionJob。これは、きめ細かなアクセスコントロールポリシーがリクエスト属性に対する特定のメモリオペレーションと条件を許可または拒否できるようにするものです。アクション ID とリクエスト属性については、「メモリのきめ細かなアクセスコントロール」を参照してください。

注記

メモリバッチオペレーション (BatchCreateMemoryRecords、BatchUpdateMemoryRecords、および BatchDeleteMemoryRecords) は、きめ細かなアクセスコントロールではサポートされていません。これらの各オペレーションは、ポリシーエンジンが個別に評価できない複数のレコードを 1 つのリクエストに保持します。

リクエストを転送する

ターゲットが設定したアウトバウンド認証情報モードを使用して、許可された各リクエストをメモリデータプレーンに転送します。

コネクタはすぐにメモリモデルが提供されるため、スキーマを手作業で作成したり、エンドポイントのワイヤリングを管理したりすることはありません。

リクエストがゲートウェイを通過する方法

クライアントがゲートウェイ経由で Memory を呼び出すと、ゲートウェイは 4 つのステップでリクエストを処理します。

  1. インバウンド認証 — ゲートウェイは、OAuth (JWT) ベアラートークン、 AWS SigV4、または認証されていないリクエストのインバウンドオーソライザータイプに従って発信者を検証します。「インバウンド認証モードとアウトバウンド認証モード」を参照してください。

  2. アクション解決 — ゲートウェイは、着信 HTTP リクエスト (メソッドとパス) を、呼び出し元が試行しているメモリオペレーションの Cedar アクションにマッピングします。パスパラメータと request-body フィールドは、リクエストコンテキストオブジェクトに抽出されます。

  3. ポリシー評価 — ゲートウェイにポリシーエンジンがアタッチされている場合、設定されたアクセスコントロールポリシーをリクエストに対して評価します。評価はdeny-by-default。「メモリのきめ細かなアクセスコントロール」を参照してください。

  4. アウトバウンド認証 — リクエストが許可されている場合、ゲートウェイはターゲットのアウトバウンド認証情報モードを使用してメモリデータプレーンに転送します。「アウトバウンド認証情報モード」を参照してください。

インバウンド認証モードとアウトバウンド認証モード

ゲートウェイには発信者の認証方法を制御するインバウンドオーソライザータイプがあり、各メモリコネクタターゲットには、ゲートウェイがメモリの呼び出しに使用する ID を制御するアウトバウンド認証情報モードがあります。ほとんどのデプロイでは、次の 2 つの組み合わせのいずれかを使用します。

OAuth エンドユーザー (主要なきめ細かなアクセスコントロールパス)

CUSTOM_JWT インバウンドとGATEWAY_IAM_ROLEアウトバウンド。ユーザーまたはエージェントは OpenID Connect プロバイダーで認証し、ゲートウェイは独自のゲートウェイ実行ロールで Memory を呼び出します。これは、IAM プリンシパルではない発信者のユーザーごとの分離が必要な場合に使用する組み合わせです。詳細については、「エンドユーザーを OAuth でメモリに認証する」を参照してください。

ID パススルーを使用した IAM バックエンドサービス

AWS_IAM インバウンドとCALLER_IAM_CREDENTIALSアウトバウンド。ゲートウェイは各発信者独自の IAM ID を Memory に転送するため、Memory は発信者の IAM アクセス許可を評価し、ゲートウェイに転送されたトラフィックをソースピンできます。発信者がすでに IAM プリンシパルであり、メモリで直接承認する場合は、これを使用します。

AWS_IAM やGATEWAY_IAM_ROLEアウトバウンドのNONEインバウンドなど、その他の組み合わせは、IAM 発信者の一元化された Cedar 適用や開発とテストなどの特殊なシナリオでサポートされています。完全なセットについては、互換性マトリックスを参照してください。

インバウンドオーソライザータイプ

ゲートウェイの作成時にインバウンドオーソライザーを選択します。Memory コネクタは、AgentCore Gateway がサポートするすべてのインバウンドオーソライザータイプをサポートします。詳細については、「Amazon Bedrock AgentCore Gateway のコア概念」を参照してください。

  • CUSTOM_JWT (OAuth/JWT) — きめ細かなアクセスコントロールのプライマリパス。発信者の JWT クレームをアクセスコントロールポリシーで使用できるようにし、エンドユーザーの OAuth 認証を有効にします。「エンドユーザーを OAuth でメモリに認証する」を参照してください。

  • AWS_IAM (SigV4) — は、呼び出し元の IAM ID をアクセスコントロールポリシーで使用できるようにします。IAM 認証のバックエンド発信者、一元化された Cedar エンフォースメント、またはソースピンニングに使用します。

  • AUTHENTICATE_ONLY — には有効な署名付きリクエストが必要ですが、ID ベースのポリシールールの型付き発信者 ID は公開されません。

  • NONE — 認可なし。開発とテストのみを目的としており、本番環境のメモリアクセスには使用しないでください。

アウトバウンド認証情報モード

アウトバウンド認証情報モードは、メモリデータプレーンが表示する ID を決定します。ルールはシンプルです。

  • インバウンド認証が CUSTOM_JWTまたは の場合NONE、ゲートウェイは常に を使用しますGATEWAY_IAM_ROLE。ゲートウェイ実行ロールでメモリを呼び出します。他に有効なオプションはなく、選択するオプションもありません。

  • インバウンド認証が AWS_IAMまたは の場合AUTHENTICATE_ONLY、ゲートウェイ実行ロールを使用する代わりに、発信者自身の IAM ID をメモリCALLER_IAM_CREDENTIALSに転送することもできます。

アウトバウンドモード ゲートウェイがメモリを呼び出す方法

GATEWAY_IAM_ROLE

ゲートウェイは、ゲートウェイ実行ロール (ファーストパーティーコール) でメモリを呼び出します。すべてのインバウンドタイプで動作します。

CALLER_IAM_CREDENTIALS

ゲートウェイは、発信者自身の IAM ID をメモリ (委任アクセス) に転送します。転送するには発信者 IAM ID が必要なため、 AWS_IAMまたは AUTHENTICATE_ONLY インバウンドが必要です。

互換性マトリックス

次の表に、Memory コネクタターゲットでサポートされているインバウンドオーソライザーモードとアウトバウンド認証情報モードの組み合わせを示します。

インバウンド GATEWAY_IAM_ROLE CALLER_IAM_CREDENTIALS

CUSTOM_JWT

サポート

ターゲットの作成時に拒否

AWS_IAM

サポート対象

サポート対象

NONE

サポート

ターゲットの作成時に拒否

AUTHENTICATE_ONLY

サポート対象

サポート

アウトバウンド認証情報モードがメモリアクセスコントロールに与える影響

アウトバウンド認証情報モードでは、Memory がどの ID を許可するかが決定されるため、発信者にスコープされた IAM ポリシーの動作はモードごとに異なります。また、メモリリソースベースのポリシーを使用してゲートウェイ転送トラフィックを制限する方法も決定します。

GATEWAY_IAM_ROLE

ゲートウェイはゲートウェイ実行ロールで Memory を呼び出すため、Memory はそのロールとしてリクエストを承認します。このゲートウェイへのアクセスを制限するには、ゲートウェイ実行ロール ARN に対して aws:PrincipalArn条件を使用し、そのロールの ID ポリシーをゲートウェイが必要とするメモリアクションのみにスコープできます。ゲートウェイによって転送されたリクエストでは、ゲートウェイ ARN に設定されたaws:SourceArn条件キーも保持されます (次のモードを参照）。

CALLER_IAM_CREDENTIALS

ゲートウェイは発信者の IAM ID をメモリに転送するため、メモリは発信者としてリクエストを承認します。プリンシパルはゲートウェイではなく発信者であるため、 aws:SourceArn条件を使用してゲートウェイ転送トラフィックへのアクセスを制限します。

どちらのアウトバウンドモードでも、ゲートウェイはリクエストを転送したゲートウェイの ARN でaws:SourceArn条件キーをスタンプします。したがって、メモリリソースベースのポリシーは、アウトバウンド認証情報モードに関係なく、ゲートウェイ ARN aws:SourceArnと照合することで、特定のゲートウェイへのアクセスを制限できます。

重要

アウトバウンド認証情報モードによって ID Memory が承認する ID が変更されるため、発信者を対象とする IAM ポリシーの動作は異なります。

  • を使用するとCALLER_IAM_CREDENTIALS、メモリは発信者自身の IAM ID を確認します。特定の Denyの を含む発信者を参照する IAM アイデンティティベースおよびリソースベースのポリシーactorId、または bedrock-agentcore:namespaceや などのメモリ条件キーbedrock-agentcore:namespacePathは、その発信者に対して評価されます。

  • ではGATEWAY_IAM_ROLE、メモリはゲートウェイ実行ロールのみを表示します。すべての発信者のリクエストは、その単一のロールでメモリに到達するため、個々の発信者のアイデンティティ (特定の Denyの などactorId) を対象とする IAM ポリシーは、元の発信者に対して評価されず、有効になりません。このモードでは、発信者スコープの IAM ポリシーに依存して発信者ごとのアクセスを強制しないでください。

を使用してGATEWAY_IAM_ROLEいて、発信者ごとのアクセスコントロールが必要な場合 (例えば、発信者を独自の actorIdまたは名前空間に制限する場合）、発信者スコープの IAM ポリシーではなく、ゲートウェイできめ細かなアクセスコントロール (Cedar ポリシー) を適用します。これは、主要なきめ細かなアクセスコントロールパスです。詳細については、「メモリのきめ細かなアクセスコントロール」を参照してください。

リソースベースのポリシー条件キーと JSON ポリシーの例については、「Amazon Bedrock AgentCore のリソースベースのポリシー」を参照してください。