View a markdown version of this page

メモリのきめ細かなアクセスコントロール - Amazon Bedrock AgentCore
きめ細かなアクセスコントロールの仕組みメモリのきめ細かなアクセスコントロールを設定するメモリアクションとリクエスト属性適用できる内容既存のメモリにきめ細かなアクセスコントロールを採用する他のアクセスコントロールオプションとの関係

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

メモリのきめ細かなアクセスコントロール

Amazon Bedrock AgentCore Memory のきめ細かなアクセスコントロール (FGAC) を使用すると、メモリアクセスを OAuth で認証された発信者の ID にバインドできます。

呼び出し元が IAM 認証情報を使用して Memory AWS に到達すると、Memory の条件キーで IAM アイデンティティベースおよびリソースベースのポリシーを使用して、アクション、Memory リソース、リクエストのアクター、セッション、名前空間スコープによってアクセスを既に制限できます。これらのコントロールについては、AgentCore Memory のメモリ組織」と「Amazon Bedrock AgentCore のリソースベースのポリシー」を参照してください。

これらの IAM コントロールは、Memory を呼び出す IAM プリンシパルと一致します。OAuth 認証呼び出し元は IAM プリンシパルではないため、OAuth/JWT アイデンティティでキーが設定されたルールを表現することはできません。 OAuth これは、エンドユーザーが OpenID Connect プロバイダーを介してサインインするエージェントアプリケーションなど、発信者が AWS 認証情報ではなく OAuth で認証するアプリケーションにとって重要です。このアーキテクチャでは、HTTP 発信者は通常エージェントまたはバックエンドであり、各リクエストでエンドユーザー (またはエージェント自身の) JWT を渡します。FGAC はそのトークンのアイデンティティに対してポリシーを評価します。FGAC では、リクエスト属性をトークンのクレームと比較するポリシーを記述できるため、次のようなルールを適用できます。

  • 発信者は、リクエストの が JWT subクレームとactorId等しいイベントにのみアクセスできます。

  • 呼び出し元は、独自のトークンクレームで実行された名前空間のメモリレコードのみを取得できます。

  • アクセスは、特定の OAuth を提示する発信者にのみ付与されますclient_id。

FGAC ポリシーは、IAM が提供するのと同じアクション、メモリリソース、およびリクエスト属性スコープを条件にすることもできます。そのため、単一のポリシーは、発信者が誰であるかを、アクセスできるオペレーションとデータと組み合わせることができます。

FGAC for Memory は、Amazon Bedrock AgentCore の ポリシーで実装されています。Memory リソースをフロントするポリシーエンジンをゲートウェイにアタッチし、Cedar Policy ウェブサイトに記載されているオープンソースのポリシー言語である Cedar でポリシーを記述します。ゲートウェイは、リクエストをメモリに転送する前に、これらのポリシーを評価します。Cedar ポリシー言語、プリンシパルタイプ、ポリシーエンジン、ポリシー検証はすべて、Amazon Bedrock AgentCore のポリシーに記載されています。このページでは、メモリに固有のもの、メモリコネクタが公開するアクションとリクエスト属性、および発信者によってメモリデータを分離するポリシーパターンについてのみ説明します。

注記

FGAC for Memory は AgentCore Memory コネクタ上に構築されています。最初にメモリコネクタターゲットを使用してゲートウェイを設定します。詳細については、「ゲートウェイ経由で AgentCore メモリにアクセスする」を参照してください。

トピック

きめ細かなアクセスコントロールの仕組み

ポリシーエンジンは、一連の Cedar ポリシーを保持し、関連付けられたゲートウェイを通過する各リクエストについてそれらを評価します。ゲートウェイが発信者を認証し、メモリオペレーションへのリクエストを解決すると、ポリシーエンジンはリクエストのプリンシパル (呼び出し元）、アクション (メモリオペレーション）、リソース (ゲートウェイ）、コンテキスト (パスパラメータや本文フィールドなどのリクエストの属性) に対してポリシーを評価します。評価はdeny-by-defaultされ、 がforbid上書きされますpermit。

Memory コネクタは、各メモリオペレーションをリクエストフィールドを持つ Cedar アクションとして利用可能にするため、ポリシーはリクエスト属性に対して特定のメモリオペレーションと条件を許可または拒否できます。一般的な Cedar モデル — ポリシー構造、permit/forbid、AgentCore::OAuthUserプリンAgentCore::IamEntityシパルタイプ、タグ、および context.input — については、「Cedar ポリシーとコア概念を理解する」で説明されています。 重要な概念

メモリのきめ細かなアクセスコントロールを設定する

注記

メモリのきめ細かなアクセスコントロールは、 AWS マネジメントコンソール、 AWS SDK、および コマンドラインインターフェイス (AWS CLI) AWS を使用して設定できます。

Memory コネクタターゲットを持つゲートウェイがある場合 (ゲートウェイ経由で AgentCore Memory にアクセスするを参照)。

  1. ポリシーエンジンを作成し、Cedar ポリシーを追加します。手順については、「ポリシーエンジンの作成」および「ポリシーの作成」を参照してください。書き込むポリシーについては、「 メモリのポリシー例」を参照してください。

  2. ゲートウェイの を設定して、ポリシーエンジンをメモリリソースの前にあるゲートウェイに関連付けますpolicyEngineConfiguration。CreateGateway でゲートウェイを作成するときに設定することも、後で UpdateGateway で追加することもできます。

ポリシーエンジンの は、ポリシーが強制される (ENFORCE) か、トラフィックをブロックせずに評価およびログ記録される () かmodeを制御しますLOG_ONLY。意図しない拒否を避けるためENFORCE、 に切り替えるLOG_ONLY前に でポリシーをテストします。適用モード、ポリシーの検証、テストについては、「ポリシーの検証とテスト」および「ポリシーの使用」を参照してください。

メモリアクションとリクエスト属性

このセクションは、ポリシーを記述するためのメモリ固有のリファレンスです。各メモリオペレーションの Cedar アクション ID、および で利用可能なリクエスト属性ですcontext.input。

メモリアクション ID

各メモリオペレーションは、 という名前の Cedar アクションです。ここで<target-name>___<METHOD>:<uri-template>、 <target-name>はコネクタターゲットの名前です。URI はパスパラメータプレースホルダーを保持します。これらは具体的な値に置き換えられません。次の表で、 をコネクタターゲットの名前<target-name>に置き換えます。

メモリオペレーション Cedar アクション ID

ListEvents

<target-name>___POST:/memories/{memoryId}/actor/{actorId}/sessions/{sessionId}

CreateEvent

<target-name>___POST:/memories/{memoryId}/events

GetEvent

<target-name>___GET:/memories/{memoryId}/actor/{actorId}/sessions/{sessionId}/events/{eventId}

DeleteEvent

<target-name>___DELETE:/memories/{memoryId}/actor/{actorId}/sessions/{sessionId}/events/{eventId}

ListSessions

<target-name>___POST:/memories/{memoryId}/actor/{actorId}/sessions

ListActors

<target-name>___POST:/memories/{memoryId}/actors

RetrieveMemoryRecords

<target-name>___POST:/memories/{memoryId}/retrieve

ListMemoryRecords

<target-name>___POST:/memories/{memoryId}/memoryRecords

GetMemoryRecord

<target-name>___GET:/memories/{memoryId}/memoryRecord/{memoryRecordId}

DeleteMemoryRecord

<target-name>___DELETE:/memories/{memoryId}/memoryRecords/{memoryRecordId}

ListMemoryExtractionJobs

<target-name>___POST:/memories/{memoryId}/extractionJobs

StartMemoryExtractionJob

<target-name>___POST:/memories/{memoryId}/extractionJobs/start

Action-id ワイルドカードはサポートされていません。1 つのポリシーで複数のオペレーションを付与するには、 でリストしますaction in […​]。

注記

メモリバッチオペレーション (BatchCreateMemoryRecords、、および BatchDeleteMemoryRecords) は Cedar アクションとして利用できずBatchUpdateMemoryRecords、きめ細かなアクセスコントロールで管理することはできません。各 は 1 つのリクエストで複数のレコードを保持し、ポリシーエンジンは個別に評価できないため、レコードごとまたは名前空間ごとの条件を適用することはできません。

IAM アイデンティティベースおよびリソースベースのポリシーでは、バッチオペレーションを全体として許可または拒否できます (たとえば、 bedrock-agentcore:BatchCreateMemoryRecordsアクションを許可または拒否するなど）。欠落しているのはレコードごとの粒度のみです。きめ細かなアクセスコントロールレイヤーでは、バッチオペレーションはall-or-nothing。

リクエストコンテキストフィールド

ゲートウェイは、パスパラメータとリクエスト本文フィールドを組み合わせてcontext.input、各リクエストの属性を の下に公開します。各フィールドを読み取るhas前に で保護します (例: context has input && context.input has actorId)。

パスパラメータ (URI から):

  • context.input.memoryId

  • context.input.actorId

  • context.input.sessionId

  • context.input.eventId

  • context.input.memoryRecordId

Request-body フィールド (オペレーション依存、リクエストペイロードから):

  • context.input.namespace

  • context.input.namespacePath

  • context.input.metadata

  • context.input.filter

  • context.input.payload

  • および各オペレーションのスキーマで定義されるその他の本文フィールド

使用可能なフィールドはオペレーションによって異なります。1 つのオペレーションが保持するフィールド ( などListEvents) actorId は、同じポリシーが一致する別のオペレーションには存在しない場合があります。

警告

コンテキストフィールドを参照するポリシーは、そのスコープ内のアクションのスキーマに対して検証されますが、実行時にリクエストが到達するすべてのオペレーションに対して検証されません。ポリシーが受信リクエストが保持しないフィールドを参照する場合、ポリシーは正常に作成されて に到達できますがACTIVE、参照されるフィールドがないため、ポリシーエンジンがそれを評価するときに403レスポンスでリクエストを拒否できます。この条件は、ポリシーの作成時に報告されません。

予期しない拒否を回避するには:

  • 各ポリシーを、ポリシーが参照するフィールドをリクエストに含む特定のアクションにスコープし、それらのフィールドをメモリアクション ID テーブルの各オペレーションに対して確認します。

  • すべてのフィールドアクセスhasを ( などcontext has input && context.input has actorId) で保護し、フィールドがない場合にpermit条件が予測可能に評価されるようにします。

  • ポリシーを強制する前に LOG_ONLY モードでテストすることで、ライブトラフィックを拒否することなく評価結果を観察できます。詳細については、「メモリのきめ細かなアクセスコントロールを設定する」を参照してください。

適用できる内容

Memory コネクタを介した FGAC 適用は、ゲートウェイのすべてのインバウンド認証モードで使用できます。上記のアクションと属性を使用して、以下を適用できます。

  • プリンシパルタイプのゲート — OAuth のみまたは IAM のみの発信者を対象とするポリシーは、発信者クラスによって一致または拒否されます。

  • ID ごとの分離 — などのリクエスト属性は、JWT 内の認証されたユーザーまたはエージェントのsubクレームと等しく、所有者を許可し、他のユーザーを拒否するために必要actorIdになる場合があります。

  • 名前空間の分離 — リクエストの namespaceまたは をリテラルnamespacePathと比較するか、トークンクレームで伝送される名前空間パスと比較すると、発信者が取得できるレコードが制限されます。

  • アクションスコープ — 1 つのアクション、一連のアクション、または任意のアクションを許可できます。許可されていないアクションは拒否されます。

  • パスパラメータ条件 — memoryId、actorId、 などのパスパラメータsessionId。

  • Request-body 条件 — metadataや などの本文フィールドnamespacePath。

  • リソースの固定 — 一致するゲートウェイ ARN が許可されます。別の ARN は拒否されます。

  • JWT クレーム条件 — subやclient_idゲートアクセス (OAuth インバウンド) などのトークンクレーム。

  • IAM ID 条件 — 呼び出し元の IAM ARN はパターン (IAM インバウンド) で照合できます。

これらを実装するポリシーについては、「 メモリのポリシー例」を参照してください。

既存のメモリにきめ細かなアクセスコントロールを採用する

プライマリ分離パターンでは、リクエストactorIdの が発信者の JWT subクレーム () と等しくなければなりませんcontext.input.actorId == principal.getTag("sub")。既存のデプロイでは、多くの場合、ID プロバイダーsubの値とactorId一致しない内部ユーザー ID が として使用されます。actorId 値がすでにプロバイダーの と等しい場合sub、変更は必要ありません。それ以外の場合は、次のいずれかの方法を選択します。

カスタム JWT クレームで一致

ID プロバイダーが内部ユーザー ID を既に保持しているクレーム (たとえば、actorIdスキームをミラーリングするカスタムクレーム) を発行できる場合は、 sub などではなく、そのクレームと比較しますcontext.input.actorId == principal.getTag("custom:app_user_id")。hasTag 最初に で保護します。これにより、保存されたデータの変更を回避できます。

ではなく名前空間で分離する actorId

長期メモリレコードがユーザーごとの名前空間に編成されている場合は、 ではなく名前空間に分離を適用しますactorId。ID プロバイダーに発信者の完全な名前空間パスを保持するクレームを発行させ、リクエストの をnamespacePathそのクレームと比較します。名前空間分離パターンについては、「 メモリのポリシー例」を参照してください。

actorIdと整列する sub

デフォルトのactorId == subパターンを使用する場合は、新しいイベントとレコードを移行して、プロバイダーの を subとして使用しますactorId。AgentCore Memory はactorId指定した の下にイベントとレコードを保存するため、これは通常、履歴データを書き換えるのではなく、今後適用されます。両方のスキームが存在する移行期間を計画してください。

ヒント

最初に LOG_ONLY モードでポリシーをアタッチし、評価ログを確認することで、ライブトラフィックに影響を与えずにこれらのアプローチを検証できます。「メモリのきめ細かなアクセスコントロールを設定する」を参照してください。

他のアクセスコントロールオプションとの関係

ポリシーエンジンによって評価される Cedar ポリシーは、ゲートウェイを介したメモリトラフィックのアイデンティティ対応、リクエストごとの認可レイヤーです。これらはゲートウェイの他のアクセスコントロールオプションを補完し、組み合わせることができます。