AWS 为 Amazon Quick 与 Bedrock Knowledge Bases 加入实时 ACL 校验，解决 RAG 权限过期问题
来源AWS Machine Learning查看原文
速览
- RAG 权限控制从「同步副本」转向「查询时向权威源实时核对」
- 两阶段设计兼顾性能与安全：缓存 ACL 做初筛，实时 API 做终审
- 实时校验只针对候选文档，避免对全量索引逐条调用 API 的高成本
- 权限撤销可秒级生效，消除同步周期内的安全窗口
- 数据源权限模型变化不再依赖连接器更新即可保持正确
- Mondelēz International 超 35,000 员工跨四区域部署，是规模化落地案例
- 该能力由 AWS 产品经理从 0 到 1 推动，属于官方产品能力而非第三方方案
AWS 在官方博客中介绍了 Amazon Quick 与 Amazon Bedrock Knowledge Bases 的实时访问控制方案。企业用 RAG 从 SharePoint、Google Drive、Confluence 等知识源取数时，传统做法是把数据源的 ACL 通过连接器周期性同步到索引里，再在查询时按用户过滤。AWS 指出这种做法有三个根本缺陷：AI 系统本身不是权限的权威来源、同步间隔内权限会过期、数据源权限模型变化会导致映射失效。为此 AWS 在原有的预检索 ACL 过滤之上，增加了一层实时校验：查询时直接调用数据源 API 核对权限。以 Google Drive 为例，系统先用索引中已有的 ACL 做语义检索筛出候选文档，再用管理员提供的服务账号凭据通过 impersonation 生成用户级访问令牌，调用 Google Drive API 逐个校验候选文档，未授权的文档被剔除，只有通过校验的片段才会作为上下文传给 LLM。AWS 称该方案带来三项收益：权限始终最新、可放心扩大知识库覆盖范围、无需操心同步频率。Mondelēz International 已在四个区域为超过 35,000 名员工部署 Amazon Quick。
关键事实
- AWS 在 Amazon Quick 与 Amazon Bedrock Knowledge Bases 上实现了实时 ACL 校验，作为原有预检索 ACL 过滤之上的额外安全层
- 传统 replicate-and-filter 方案依赖连接器周期性同步 ACL 到索引，AWS 指出其存在三个问题：AI 系统非权限权威来源、同步间隔内权限过期、数据源权限能力演进导致映射失效
- Confluence 等数据源在群组成员变更时不会发出事件，事件驱动的更新方式无法通用
- 两阶段流程：Stage 1 用索引中已存的 ACL 做语义检索筛出候选文档；Stage 2 通过 Google Drive API 实时校验候选文档
- 实时校验使用管理员提供的服务账号凭据，通过 impersonation 生成用户级访问令牌
- 只有通过校验的文档片段才会作为上下文传给 LLM
本站视角
这件事直接影响三类人。第一类是正在用 Amazon Quick 或 Bedrock Knowledge Bases 搭建企业内部问答的团队，尤其是金融、医药、制造这类对信息隔离有硬性合规要求的行业——Mondelēz International 的案例说明这套方案已经能支撑数万人规模的部署，采购时可以把「实时 ACL 校验」列为评估项。第二类是自建 RAG 的工程团队，包括国内做企业知识库和 Agent 的厂商：AWS 把问题拆成「预检索过滤 + 查询时回源校验」两阶段，这个架构可以直接借鉴，核心洞察是不要试图在索引里维护一份完美的权限副本，而是承认副本必然过期，用实时校验兜底。第三类是做数据连接器和权限同步的中间件厂商，如果实时校验成为主流，纯做 ACL 同步映射的价值会被压缩，需要往权限策略编排、审计和合规报告方向迁移。 我们的判断是：这是实质性的架构改进，而非营销包装。RAG 权限过期是真实存在的安全漏洞，AWS 把「AI 系统不是权限权威源」这一点明确写出来，等于承认了此前行业通行做法的结构性缺陷。两阶段设计也显示出工程上的克制——没有对全量索引做实时校验，而是只校验候选文档，说明团队清楚 API 调用的成本边界。 需要指出的是，这篇博客是 AWS 官方产品说明，作者即该功能的推动者，收益描述带有明显的产品立场。文中没有给出任何量化指标：实时校验增加多少延迟、Google Drive API 的调用配额如何、候选文档规模多大时成本会失控、除 Google Drive 外其他数据源的实时校验是否同样可用，这些关键工程细节都未披露。Mondelēz International 的引语来自客户，但只谈评估信心，没有给出部署后的实际效果数据。对打算采用的团队来说，建议先在自己的数据源和权限复杂度下做延迟与配额的压力测试，再决定是否把实时校验作为默认链路。
背景与影响
企业把 RAG 接入 SharePoint、Google Drive、Confluence 这类内部知识源时，最大的障碍不是检索质量而是权限。这些系统的权限模型各不相同，包含继承层级、群组成员、条件访问策略和拒绝规则，跨几十个连接器做精确映射本身就容易出错。更麻烦的是权限是动态的：员工离职、转岗、被移出项目组，权限随时变化，而连接器同步通常是按需或按客户定义的周期运行，中间存在时间差。AWS 这次的做法是把权限判断的最终裁决权交还给数据源本身，AI 系统只做初筛和缓存。这意味着 RAG 的权限架构从「复制一份权限快照」变成「每次查询都回源确认」。对正在自建 RAG 的团队来说，这个思路值得参考：与其追求把 ACL 映射做到完美，不如在检索链路上加一道轻量的实时校验，把正确性责任交还给权威源。需要观察的是，实时校验会引入额外的 API 调用延迟和配额消耗，AWS 通过只校验候选文档来控制成本，但候选集大小的调优、各数据源 API 的限流策略、以及跨区域部署时的调用延迟，都会影响实际体验。此外，这篇博客本质是 AWS 的产品能力说明，性能与安全收益的表述来自 AWS 自身，缺少第三方独立验证。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。