产品AWS Machine Learning·原文 2026年9月17日本站收录 2026年9月18日

AWS发布Amazon Quick上MCP工具的四层授权拦截方案

AWS官方博客给出一个可操作的方案:在Amazon Bedrock AgentCore Gateway上挂一个Lambda请求拦截器,按顺序检查OIDC JWT中的MFA、国家、用户组和工具权限四项声明,让已登录不再等于已授权。

AI解读:这条新闻的核心不是Amazon Quick多了什么按钮,而是AWS给MCP工具调用补了一套“门禁系统”。以前SSO登录只证明你是谁,不证明你能调哪个工具、改哪些数据。现在拦截器会按顺序核对JWT里的声明,任何一道门没过就返回 403,请求不会到达工具和数据。

真正受影响的,是把敏感数据源通过MCP接到Amazon Quick的团队。对金融、医疗、政府这类需要合规审计的组织,最有用的两个数字是:核心RBAC和工具权限检查始终开启,MFA和国家地理限制可以用环境变量单独开关。这意味着一个部署只要RBAC加地理围栏,实际只激活三道门,而不是被强制全开。

它解决的具体问题是“一个配置过宽的令牌可以摸到超出角色的工具”。方案把每次MCP调用都当成访问事件,在业务逻辑运行前用单个Lambda REQUEST拦截器评估四道门,通过后每次变更还会写入不可变审计记录。限制也很清楚:身份端演示用的是Microsoft Entra ID,其他OIDC身份提供商的配置步骤会不同;而且博文假设AWS侧资源,包括网关、拦截器Lambda、工具Lambda和DynamoDB表都已经部署好了。

普通开发者不用急着照做。但如果你的团队已经在Amazon Quick里连了MCP工具,并且审计时被问过“谁能调用这个工具、从哪调用、能改什么”,这篇博文给的就是一个可以按合规要求逐项开启的模板。

一个细节值得留意:MFA真正的执行点在Entra ID签发令牌之前,拦截器里的amr声明检查是第二道确认;博文明确说Gate 1是唯一在拦截器外执行的检查。所以别误以为把开关打开就万事大吉,令牌怎么签发同样关键。

AWS机器学习博客发布了一篇实施指南,主题是为Amazon Quick上的Model Context Protocol(MCP)工具调用提供纵深防御授权。文章由Anneline Sibanda撰写,方案是在Amazon Bedrock AgentCore Gateway上附加单个AWS Lambda REQUEST拦截器,按固定顺序评估OpenID Connect(OIDC)JSON Web Token(JWT)中的声明。

按照文章的说法,每次MCP工具调用都是一个访问事件,除了有效的令牌之外,还可能在工具和参数级别需要授权。没有细粒度控制时,一个配置过宽的权限可能绕过组织为合规目的所需的访问要求。

方案包含四道门:MFA验证、国家地理围栏(ctry声明)、组到角色的映射(groups声明)以及工具权限检查。其中第二、三、四道门由拦截器处理,Gate 1(MFA)由身份提供方在签发令牌前执行。

Gate 3和Gate 4是核心授权层,始终激活;MFA和地理围栏是条件门,可通过环境变量禁用或省略。文章给出的例子是:一个只需要RBAC和地理围栏的部署会激活三道门,需要更细粒度控制的部署可以四道全开。

身份提供方在本文中是Microsoft Entra ID。文章假设AWS侧组件——包括网关、拦截器Lambda函数、工具Lambda函数和Amazon DynamoDB表——已经部署完成,博文聚焦身份与授权配置。

验证部分要求准备至少三个不同组成员的测试用户,以不同角色登录来验证允许路径和受限路径。拦截器评估所有四道门后才运行业务逻辑,未通过的门会以 403 拒绝请求,请求不会到达工具或其数据;每次通过的变更都会写入不可变审计记录。

四道门各自检查什么、什么时候激活

文章列出四道门的顺序和激活条件。Gate 1是MFA验证,由身份提供方在签发令牌前执行,依赖Conditional Access Policy;设置REQUIRE_MFA会在拦截器内额外检查amr声明,前提是身份提供方在令牌里记录了MFA证据。文章解释两个机制配合:策略把未验证的调用者挡在外面,声明检查在请求路径中确认令牌带有证据。

Gate 2是国家地理围栏,读取ctry声明,在REQUIRE_COUNTRY=true时生效,用于限制从非批准国家的访问。Gate 3是组RBAC,读取groups声明,把组成员映射到reader、author或admin策略,始终激活。Gate 4是工具权限,通过策略允许列表验证请求的工具是否存在于匹配的策略中,也始终激活。

  • Gate 1:MFA验证,JWT声明由IdP强制,Conditional Access Policy;REQUIRE_MFA开启拦截器内的amr检查
  • Gate 2:国家地理围栏,读取ctry声明,REQUIRE_COUNTRY=true时激活
  • Gate 3:组RBAC,读取groups声明,映射到reader、author、admin策略,始终激活
  • Gate 4:工具权限,策略允许列表验证工具存在,始终激活

示例场景和配置步骤

文章的虚构示例是AnyCompany Global Services,一家在Amazon DynamoDB上维护多租户风险登记表、通过Amazon Quick上的MCP工具访问的企业。要求包括:每次工具调用来自已通过MFA的认证调用者;来自非批准国家的调用者被拒绝;RBAC强制读写边界,reader只能查询风险,不能创建、更新或删除,admin可以绕过条件门;每次变更产生不可变审计记录。

配置在Microsoft Entra ID侧进行。资源应用(AnyCompany-MCP-Authorization)通过Microsoft Graph API设置identifierUris为网关URL,并将requestedAccessTokenVersion设为 2。资源应用暴露四个委托作用域:mcp、mcp:stream、stream、invoke。客户端应用(AnyCompany-Quick-MCP-Client)配置重定向URI为https://us-east-1.quicksight.aws.amazon.com/sn/oauthcallback,并被授予资源应用的invoke委托权限。

令牌配置包括添加groups声明(安全组,访问令牌中用Group ID格式)以及ctry和email可选声明。创建三个安全组:Risk-Register-Readers、Risk-Register-Authors、Risk-Register-Admins。Conditional Access Policy针对资源应用要求多重身份验证。

文章说明Amazon Quick使用PKCE和RFC 8707 Resource Indicators,令牌交换时把AgentCore Gateway URL作为resource参数发送。当资源由URL标识时,Entra ID要求客户端和资源分别注册为独立应用。拦截器读取的环境变量包括READERS_GROUP_ID、AUTHORS_GROUP_ID、ADMINS_GROUP_ID、REQUIRE_COUNTRY等。

文章还提到Conditional Access Policies需要Microsoft Entra ID P1或P2许可证,创建应用注册和策略需要Global Administrator或Application Administrator角色。配置步骤中应用ID URI通过Microsoft Graph API设置,因为它是完整URL。

  • 资源应用:AnyCompany-MCP-Authorization,identifierUris设为网关URL,access token版本设为 2.0
  • 暴露作用域:mcp、mcp:stream、stream、invoke
  • 客户端应用:AnyCompany-Quick-MCP-Client,重定向URI为QuickSight OAuth回调地址,授予invoke委托权限
  • 安全组:Risk-Register-Readers、Risk-Register-Authors、Risk-Register-Admins
  • 授权声明:groups(Group ID格式)、ctry、email可选声明
  • 合规前提:Conditional Access Policies需要Entra ID P1或P2许可证

适用条件和明确限制

文章明确该模式适用于需要为合规审计提供细粒度访问控制的金融服务、医疗和政府组织。拦截器在业务逻辑运行前评估全部四道门,失败返回 403,不触及工具或数据。

文章也说明适用范围和前提:博文使用Microsoft Entra ID作为身份提供方,但授权模式适用于符合OIDC的身份提供方,配置步骤因提供方而异。文章假设AWS侧组件已经部署,部署这些资源不在本文范围内。

关于作用域的说明:博客提到Amazon Quick是OAuth客户端并在内部管理PKCE、刷新令牌和用户会话,因此在资源应用上不需要请求offline_access或Microsoft Graph的openid/profile作用域。另外,Step 2的说明指出Add a scope如果报告Application ID URI未设置,需要确认通过Graph API设置的identifierUris已生效。

文章的核心主张是这种模式提供可审计、可组合的安全层,位于用户自然语言请求和业务逻辑之间。所有关于工具调用被拒绝或审计记录的说法,均来自这篇AWS博客的实施说明,并非独立测试结果。

  • 拦截器在业务逻辑前评估四道门,失败以 403 拒绝,不触及工具或数据
  • Gate 3和Gate 4始终激活;Gate 1和Gate 2可通过环境变量关闭或省略
  • 身份提供方配置因供应商而异;本文以Entra ID为例
  • 需预先部署网关、拦截器Lambda、工具Lambda和DynamoDB表
  • 每次通过的变更写入不可变审计记录

信息来源