本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
访问控制列表感知启用
Bedrock Managed Knowledge Base 支持ACL-aware 检索，即能够根据从连接的数据源中抓取的文档级访问控制列表 (ACL) 筛选查询结果。在数据源上启用 ACL 感知后，Bedrock Managed Knowledge Base 会在文档内容旁边提取权限（允许的用户、被拒绝的用户、允许的群组、被拒绝的群组）。在查询时，您提供用户上下文，Bedrock Managed 知识库仅返回允许用户访问的文档。有关用于在检索时传递用户上下文的请求语法，请参阅ACL-aware 在托管知识库上检索。
ACL 感知不是授权
Bedrock 托管知识库提供ACL-aware 筛选功能，而不是安全边界。Bedrock Managed Knowledge Base 不对最终用户进行身份验证——您的应用程序负责对用户进行身份验证并传递经过验证的身份上下文。由于 Bedrock Managed Knowledge Base 无法验证您提供的用户上下文的真实性，因此此功能会根据您提供的身份筛选结果，但并不构成真正的授权。如果没有上游身份验证，则不得依赖此功能作为唯一的访问控制机制。
ACL-aware 检索的工作原理
ACL-aware 检索分两个阶段运行：
-
Pre-retrieval 筛选-在摄取期间，Bedrock 托管知识库会从数据源中抓取文档权限。在查询时，Bedrock Managed Knowledge Base 使用您提供的用户上下文来筛选搜索结果，仅返回用户（或其群组）出现在允许列表中而未出现在拒绝列表中的文档。
-
Real-time ACL 验证 — 对于支持 ACL 验证的连接器（SharePoint、 OneDrive、Google 云端硬盘、Confluence），Bedrock 托管知识库会实时调用数据源，以验证用户是否仍然可以访问每个返回的文档。这会捕获两次同步之间发生的权限更改。S3 和自定义连接器不支持实时验证，因为它们的 ACL 元数据是由客户通过配置文件提供的，而不是从实时权限系统中抓取的。
这两个阶段使用相同的评估逻辑：如果用户同时出现在文档的允许列表和拒绝列表中，则访问将被拒绝。始终拒绝覆盖允许。
身份模型
Bedrock 托管知识库使用电子邮件作为 ACL 匹配的通用用户标识符。用户始终通过其通用电子邮件进行识别，您在用户上下文中传递的电子邮件必须与每个连接的数据源中与用户关联的电子邮件完全匹配。没有别名解析或跨身份提供者映射。相比之下，群组是通过源连接器所代表的方式（群组名称、群组 ID 或其他标识符）来标识的，并与从该数据源中搜寻的群组成员资格进行匹配。
群组成员资格是从数据源解析的。在摄取期间，Bedrock Managed Knowledge Base 会从每个数据源中抓取群组成员资格，并将其存储在内部。在查询时，Bedrock Managed Knowledge Base 会根据这些抓取的数据自动解析用户属于哪些群组。
注意
群组成员资格与上次同步一样新鲜。直到下一个摄取任务完成后，同步之间的权限更改才会反映出来。对于支持实时 ACL 验证的连接器，此检查会捕获自上次同步以来发生的权限更改。
连接器支持矩阵
并非所有连接器都支持 ACL 感知。下表显示了哪些连接器支持检索前筛选和实时 ACL 验证。
| Connector | Pre-retrieval 过滤 | Real-time ACL | 注意 |
|---|---|---|---|
| SharePoint | 支持 | 支持 | 使用应用程序级权限 (2LO)。需要ENTRA_ID_APP_ONLY身份验证类型。 |
| OneDrive | 支持 | 支持 | 使用应用程序级权限 (2LO)。需要ENTRA_APP_ID身份验证类型。 |
| Google Drive | 支持 | 支持 | 使用全域授权 (2LO)。需要SERVICE_ACCOUNT身份验证类型。 |
| Confluence | 支持 | 支持 | 使用管理员 API 令牌进行实时检查。需要BASIC身份验证类型。 |
| Amazon S3 | 支持 | 不支持 | ACL 通过客户在 Amazon S3 中提供的 ACL 配置文件定义。由于客户提供的元数据文件是真实来源，因此无法进行实时验证。 |
| 自定义 | 支持 | 不支持 | ACL 通过客户提供的元数据定义。由于客户提供的元数据是真实来源，因此无法进行实时验证。 |
| 网络爬虫 | 不支持 | N/A | Web 内容没有权限模型。无法为此连接器启用 ACL 感知。 |
有关特定于连接器的 ACL 配置的详细信息，请参阅：
失败行为
ACL-aware 检索失败已关闭。如果 ACL 评估管道的任何部分遇到错误（群组解析失败、实时验证超时或内部服务错误），Bedrock Managed Knowledge Base 不会返回受影响的文档。暂时性故障永远不会导致文档返回给未经授权的用户。
出现 ACL 故障时，响应可能包含零个结果或结果少于预期。错误响应表示 ACL 解析失败，因此您可以将其与未真正匹配任何文档的查询区分开来。
您的责任
由于 Bedrock Managed Knowledge Base 提供 ACL-aware 筛选而不是完整的授权解决方案，因此您应对以下内容负责：
-
对最终用户进行身份验证-在将用户的身份传递给 Bedrock 托管知识库之前，您必须在应用程序中对其进行身份验证。Bedrock 托管知识库无法验证您提供的用户上下文是否真实。
-
一致的电子邮件身份-您传递的电子邮件地址必须与每个连接的数据源中使用的电子邮件地址相匹配。如果不同系统的电子邮件不同，则 ACL 匹配会静默失败，并且用户不会收到来自该数据源的结果。
-
电子邮件生命周期管理-如果电子邮件地址被重新分配给其他人（例如，在员工离职后），则在将身份传递给 Bedrock Managed Knowledge Base 之前，您必须检测到这一点。 Real-time ACL 验证可以作为支持它的连接器的安全网，但不能替代适当的身份生命周期管理。