View a markdown version of this page

Document-level 访问控制 - Amazon Bedrock

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Document-level 访问控制

SharePoint 数据源可选地支持文档级访问控制。启用后,Bedrock Managed Knowledge Base 会同步每次抓取 SharePoint 期间的访问控制列表 (ACL),并在查询时验证每个用户的权限,因此用户只能看到他们有权访问的文档的结果。 SharePoint有关所有连接器上的 ACL 感知概述,请参阅访问控制列表感知启用。

ACL 感知不是授权

Bedrock 管理知识库提供 ACL-aware 过滤功能,而不是安全边界。Bedrock Managed Knowledge Base 不对最终用户进行身份验证——您的应用程序负责对用户进行身份验证并传递经过验证的身份上下文。由于 Bedrock Managed Knowledge Base 无法验证您提供的用户上下文的真实性,因此此功能会根据您提供的身份筛选结果,但不构成真正的授权。在没有上游身份验证的情况下,您不得依赖此功能作为唯一的访问控制机制。

工作原理

当用户查询使用 ACL-enabled SharePoint 数据源的知识库时,Bedrock 管理知识库分两个阶段强制执行访问控制:

  • Pre-retrieval 过滤 — Bedrock Managed Knowledge Base 应用上次抓取 SharePoint 期间同步的访问控制列表,仅返回允许用户(或其群组)访问的候选文档。

  • Real-time 验证 — Bedrock Managed 知识库通过检查查询用户的当前访问权限来实时验证候选文档。 SharePoint响应中仅包含用户当前有权访问的文档。

这种两阶段方法提供了文档级访问控制,即使 SharePoint 权限在两次同步之间发生变化,也能保持最新状态。

爬行了什么

启用 ACL 后,Bedrock 托管知识库会从以下权限结构中抓取以下权限结构: SharePoint

  • Site-level 成员资格和角色分配

  • 文档库级别的权限

  • Item-level (文件和页面)权限,包括破坏继承的独特权限

  • 安全组成员资格,包括微软 Entra ID (Azure AD) 安全组、支持邮件的安全组和通讯组。嵌套(可传递)组成员资格也已解决。

在查询时,您需要传递用户的电子邮件地址(不是群组)。Bedrock Managed Knowledge Base 根据用户爬取的数据解析其群组成员资格,并在筛选结果时应用这些成员资格。有关身份模型的更多信息,请参阅访问控制列表感知启用。

启用 ACL 感知

要为 SharePoint 数据源启用 ACL 感知,aclEnabled请在true中设置为connectorParameters并使用ENTRA_ID_APP_ONLY身份验证类型。这种身份验证类型使用基于证书的应用程序权限,允许 Bedrock Managed Knowledge Base 抓取身份信息并在查询时验证文档访问权限。

重要

ACL 配置是永久性的。您无法在不支持 ACL 的情况下创建的数据源上启用 ACL,也无法在启用 ACL 后将其禁用。

您的 Entra ID 应用程序注册必须具有以下应用程序权限:

  • User.Read.All然后GroupMember.Read.All在 Microsoft Graph 上(用于身份爬取)

  • Sites.FullControl.All开 SharePoint启或授予每个站点Sites.Selected的权限(用于验证文档访问权限)

connectionConfiguration必须包含certificateS3Path指向 Amazon S3 中 PKCS #12 (.p12) 证书文件的指向。

注意

密钥中的certificatePassword字段是可选的。如果你省略它,Bedrock Managed Knowledge Base 会使用应用程序的客户端 ID 作为密码打开 PKCS #12 (.p12) 文件,因此证书必须是使用该密码创建的。我们建议您始终设置明确的高熵,certificatePassword以保护证书的静态私钥。

"connectorParameters": { "type": "SHAREPOINT", "version": "1", "aclEnabled": true, "connectionConfiguration": { "tenantId": "your-tenant-id", "authType": "ENTRA_ID_APP_ONLY", "secretArn": "arn:aws:secretsmanager:region:account-id:secret:secret-name", "certificateS3Path": { "s3BucketName": "your-certificate-bucket", "s3KeyName": "certs/certificate.p12" } }, "dataEntityConfiguration": { "siteUrls": [ "https://contoso.sharepoint.com/sites/engineering" ], "crawlFiles": true, "crawlPages": true } }
注意

ACL-enabled SharePoint 数据源不支持OAUTH2_APP身份验证类型。您必须使用 ENTRA_ID_APP_ONLY。

Real-time 访问验证

Bedrock Managed Knowledge Base 使用应用程序基于证书的权限(为抓取配置的ENTRA_ID_APP_ONLY应用程序注册) SharePoint 在查询时对每个候选文档进行验证。与委托用户登录流程不同,不需要每位用户的交互式登录或同意——验证通过Sites.FullControl.All或Sites.Selected权限使用相同的应用程序注册和证书来确认查询用户仍然可以访问每个文档。

验证配置

您可以独立于检索请求来验证您的 Entra 应用程序权限。执行以下每项检查:

  1. 微软图形(爬行):

    • 获取具有范围的应用程序令牌https://graph.microsoft.com/.default并确认roles索赔包括User.Read.All和GroupMember.Read.All。

    • 调用 Microsoft Graph 站点端点(例如,GET https://graph.microsoft.com/v1.0/sites/{site})并确认它返回该站点。

  2. SharePoint REST(实时验证):

    • 使用带作用域https://{tenant}.sharepoint.com/.default的证书客户端断言获取令牌。

    • 确认代币的roles声明包括 SharePoint Sites.FullControl.All(或Sites.Selected)权限。roles: null值表示缺少权限或管理员同意。

    • 致电GET https://{tenant}.sharepoint.com/_api/web并确认成功 (HTTP 200)。回复失败或未经授权意味着缺少 SharePoint 权限或管理员同意,这会导致所有文档都被拒绝。

问题排查

注意

ACL 配置错误不会在检索期间产生明显的错误。检索失败关闭:受影响的文档会被静默忽略,因此查询返回的结果较少或为零,而不是错误。使用前面的验证检查来诊断这些问题。

ACL-enabled SharePoint 症状、原因和修复方法
症状 可能原因 Fix
检索返回 0 个结果,但用户有访问权限 SharePoint。 缺少 SharePoint Sites.FullControl.All(或Sites.Selected)权限或管理员同意,因此 SharePoint REST 调用被拒绝,所有文档都被拒绝。 经管理员同意,授予 SharePoint Sites.FullControl.All权限(或Sites.Selected按站点授权)。由于这些应用程序凭证已缓存,因此请等待最多一小时让更改生效,或者向尚未查询的用户进行测试以尽快确认。
用户的访问权限已更改 SharePoint,但新结果并未立即反映出来。 Per-user 数据源和 Bedrock Managed Knowledge Base 之间的访问结果最终保持一致(通常在大约两分钟内),因此最近的访问权限更改可能不会立即反映出来。 在数据源反映更改后,等待大约两分钟,然后重试。
所有用户在先前工作后都将被拒绝。 证书已过期,或者管理员同意已被撤销。 在 Entra 应用程序注册和 Amazon S3 中续订证书,然后重新授予管理员同意。
尽管配置看起来正确,但抓取或同步失败。 缺少所需的微软 Graph 应用程序权限。 格兰特User.Read.All和GroupMember.Read.All.
证书密码或代币铸造错误。 .p12密码不匹配certificatePassword。 设置certificatePassword为用于创建.p12文件的密码。