本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Fine-grained 存储器的访问控制
借助亚马逊基岩 AgentCore 内存的精细访问控制 (FGAC)，您可以将内存访问权限绑定到呼叫者的身份。 OAuth-authenticated
当调用者使用 AWS IAM 证书到达 Memory 时，您已经可以使用 IAM 基于身份和基于资源的策略以及 Memory 的条件密钥，通过操作、内存资源以及请求的参与者、会话和命名空间范围来限制访问权限。有关这些控制措施，请参阅内存中的 AgentCore 内存组织和亚马逊 Bedrock AgentCore 的Resource-based 政策。
这些 IAM 控件与调用 Memory 的 IAM 主体相匹配。他们无法表达以OAuth/JWT身份为键的规则，因为 OAuth-authenticated 调用者不是 IAM 委托人。这对于呼叫者使用 OAuth 而不是 AWS 凭据进行身份验证的应用程序很重要，例如，最终用户通过 OpenID Connect 提供商登录的代理应用程序。在该架构中，HTTP 调用者通常是代理或后端，它在每次请求中传递最终用户（或代理自己的）JWT；FGAC 根据该令牌中的身份评估策略。使用 FGAC，您可以编写将请求属性与代币的声明进行比较的策略，这样您就可以强制执行以下规则：
-
调用者只能访问请求
actorId等于其 JWTsub声明的事件。 -
调用者只能检索自己的令牌声明中包含的命名空间下的内存记录。
-
仅向出示特定 O
client_idAuth 的呼叫者授予访问权限。
FGAC 策略还可以以 IAM 提供的相同操作和请求属性范围为条件，因此单一策略可以将调用者的身份与他们可以访问的操作和数据相结合。 Memory-resource
内存版 FGAC 是通过亚马逊基岩中的政策实施的。 AgentCore 您可以将策略引擎附加到前端存储资源的网关，并使用 Cedar（Cedar Policy 网站上记录的一种开源策略语言）编写策略。
注意
FGAC for Memory 建立在内存连接 AgentCore 器之上。首先设置带有内存连接器目标的网关。有关更多信息，请参阅通过网关访问 AgentCore 内存。
细粒度访问控制的工作原理
策略引擎保存一组 Cedar 策略，并针对流经关联网关的每个请求对其进行评估。在网关对调用者进行身份验证并将请求解析为内存操作后，策略引擎将根据请求的主体（谁在调用）、操作（哪个内存操作）、资源（哪个网关）和上下文 （请求的属性，例如路径参数和正文字段）评估策略。默认情况下，评估是拒绝的，会被覆盖。forbid permit
由于内存连接器将每个内存操作作为具有请求字段的 Cedar 操作提供，因此您的策略可以允许或拒绝特定的内存操作及其请求属性的条件。了解雪松策略AgentCore::OAuthUser和核心概念中描述了通用 Cedar 模型context.input（策略结构forbid、permit/、和AgentCore::IamEntity主要类型、标签和）。
为内存设置细粒度的访问控制
注意
您可以通过 AWS 管理控制台、 AWS SDK 和 AWS 命令行接口 (AWS CLI) 为内存设置细粒度的访问控制。
在你有了带有内存连接器目标的网关之后（请参阅通过网关访问 AgentCore 内存）：
-
创建策略引擎并添加您的 Cedar 策略。有关步骤，请参阅创建策略引擎和创建策略。有关要编写的策略，请参阅内存策略示例。
-
通过设置网关，将策略引擎与前端内存资源的
policyEngineConfiguration网关关联起来。可以在创建网关时使用进行设置 CreateGateway，也可以稍后使用添加UpdateGateway。
策略引擎mode控制策略是强制执行 (ENFORCE) 还是仅在不阻止流量的情况下进行评估和记录 (LOG_ONLY)。在切换LOG_ONLY之前测试您的政策，ENFORCE以避免意外拒绝。有关实施模式、策略验证和测试，请参阅验证和测试策略和使用策略。
内存操作和请求属性
本部分是编写策略的 Memory-specific 参考：每个内存操作的 Cedar 操作 ID 以及下方可用的请求属性context.input。
记忆动作 ID
每个 Memory 操作都是一个名为 Cedar 的操作<target-name>___<METHOD>:<uri-template>，其中<target-name>是您的连接器目标的名称。URI 保留其路径参数占位符——它们不能被具体值所取代。在下表中，<target-name>替换为连接器目标的名称。
| 存储器操作 | 雪松动作 ID |
|---|---|
|
ListEvents |
|
|
CreateEvent |
|
|
GetEvent |
|
|
DeleteEvent |
|
|
ListSessions |
|
|
ListActors |
|
|
RetrieveMemoryRecords |
|
|
ListMemoryRecords |
|
|
GetMemoryRecord |
|
|
DeleteMemoryRecord |
|
|
ListMemoryExtractionJobs |
|
|
StartMemoryExtractionJob |
|
Action-id 不支持通配符；要在一个策略中授予多个操作，请将它们列出。action in […]
注意
内存批处理操作（BatchCreateMemoryRecordsBatchUpdateMemoryRecords、和BatchDeleteMemoryRecords）不能作为 Cedar 操作使用，也不能受细粒度访问控制的约束。每条记录都在单个请求中携带多条记录，策略引擎无法单独评估这些记录，因此不能将每条记录或每个命名空间的条件应用于它们。
您仍然可以通过基于 IAM 身份和基于资源的策略（例如，通过允许或拒绝该bedrock-agentcore:BatchCreateMemoryRecords操作）来允许或拒绝整个批量操作。缺少的只是每条记录的粒度：在细粒度的访问控制层，批量操作要么全有要么全无。
请求上下文字段
网关在下方公开了每个请求的属性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 -
以及由每个操作的架构定义的其他正文字段
可用字段因操作而异。一个操作携带的字段（例如，actorId开启ListEvents）可能不存在于同一策略匹配的另一个操作中。
警告
引用上下文字段的策略会根据其范围内操作的架构进行验证，但不会针对请求在运行时可能达成的每项操作进行验证。如果策略引用了传入请求未携带的字段，则可以成功创建并到达该策略ACTIVE，但是在策略引擎评估请求时通过403响应拒绝该请求，因为引用的字段缺失。创建策略时不会报告此情况。
为避免意外拒绝：
-
将每个策略的范围限定为其请求带有策略引用的字段的特定操作，并针对内存操作 ID 表中的每个操作确认这些字段。
-
使用
has（例如context has input && context.input has actorId）保护每个字段的访问权限，这样当字段不存在时，permit条件的计算结果是可预测的。 -
在执行策略之前，先在
LOG_ONLY模式下测试策略，这样您就可以在不拒绝实时流量的情况下观察评估结果。有关更多信息，请参阅为内存设置细粒度访问控制。
你可以强制执行什么
通过内存连接器强制执行 FGAC 适用于网关的所有入站身份验证模式。使用上面的操作和属性，你可以强制执行：
-
Principal-type gating — 按呼叫者类别限定范围 OAuth-only 或 IAM-only 呼叫者匹配或拒绝的策略。
-
Per-identity 隔离 —
actorId可以要求的请求属性等同于 JWT 中经过身份验证的用户或代理的sub声明，允许所有者而拒绝其他人。 -
命名空间隔离 — 将请求
namespace或namespacePath与文字进行比较，或与令牌声明中携带的命名空间路径进行比较，限制调用者可以检索哪些记录。 -
操作范围界定 — 可以允许单个操作、一组操作或任何操作；不允许的操作将被拒绝。
-
Path-parameter 条件 — 路径参数
memoryId，如actorId、和sessionId。 -
Request-body 条件 — 正文字段，例如
metadata和namespacePath。 -
资源固定 — 允许使用匹配的网关 ARN；拒绝不同的 ARN。
-
JWT 索赔条件 — 令牌索赔，例如
sub和client_id门禁访问权限（OAuth 入站）。 -
IAM 身份条件 — 呼叫者的 IAM ARN 可以通过模式（IAM 入站）进行匹配。
有关实现这些策略的策略，请参阅内存策略示例。
对现有内存采用细粒度的访问控制
主要隔离模式要求请求中的actorId等于调用者的 JWT sub 声明 (context.input.actorId == principal.getTag("sub"))。现有部署通常使用内部用户 ID 作为与其身份提供商的sub值不匹配的。actorId如果您的actorId价值已经等于提供商的价值观sub，则无需进行任何更改。否则，请选择以下方法之一：
- 根据自定义 JWT 声明进行匹配
-
如果您的身份提供商可以发布已持有您的内部用户 ID 的声明（例如，反映您的
actorId方案的自定义声明），请与该声明进行比较，而不是，例如context.input.actorId == principal.getTag("custom:app_user_id")。subhasTag先保护它。这样可以避免更改任何存储的数据。 - 按命名空间隔离，而不是
actorId -
如果你的长期内存记录被组织到每个用户的命名空间中，请在命名空间上强制隔离，而不是在命名空间上进行隔离。
actorId让您的身份提供商发出包含调用者完整命名空间路径的声明，并将该请求与该声明进行比较。namespacePath有关命名空间隔离模式，请参阅内存策略示例。 -
actorId与... 对齐sub -
如果要使用默认
actorId == sub模式，请迁移新事件和记录以使用提供商的sub作为actorId。由于 Memory 根据actorId您提供的数据 AgentCore 存储事件和记录，因此这通常适用于未来，而不是重写历史数据；为可能同时存在这两种方案的过渡期做好规划。
提示
您可以先在LOG_ONLY模式下附加策略并查看评估日志，在不影响实时流量的情况下验证这些方法中的任何一种。请参见为内存设置细粒度访问控制。
与其他访问控制选项的关系
策略引擎评估的 Cedar 策略是通过网关处理内存流量的身份感知按请求授权层。它们可以补充网关的其他访问控制选项，也可以与之结合使用：
-
网关拦截器允许您在代码中实现自定义授权逻辑。有关更多信息，请参阅亚马逊 Bedrock AgentCore Gateway 的Fine-grained 访问控制。
-
Resource-based 有关内存资源控制的策略，IAM 委托人（包括特定的网关）可以使用
aws:SourceArn和aws:PrincipalArn等条件密钥调用内存。有关更多信息，请参阅 Amazon Bedrock 的Resource-based 政策 AgentCore以及出站凭证模式如何影响内存访问控制。
