用 Amazon Quick MCP 连接器与 Amazon Bedrock AgentCore 安全接入企业应用
内容提要
文章介绍通过 Amazon Quick MCP 连接器与 Bedrock AgentCore Gateway 安全接入企业应用的四种方案，核心是分别管理用户登录、连接器访问 Gateway、Gateway 访问业务系统三条信任边界。方案一采用 Cognito 服务身份；方案二混合 Basic 认证与 Entra ID 应用身份；方案三通过 Entra ID OBO 传递用户身份；方案四经 PrivateLink 私网访问。企业可按需组合，兼顾安全与合规。
延伸解读
三条信任边界是方案选型的核心框架
文章反复强调，用户登录 Quick、连接器访问 Gateway、Gateway 访问业务系统是三条独立的信任边界，SSO 登录不会自动把用户身份透传到后端。这一区分直接决定了四种方案的差异：方案一和方案二在 Gateway 入站使用 Cognito 服务身份，方案三改用 Entra ID 授权码流程以传递用户身份；方案四则只替换网络路径，身份机制与方案一相同。读者在评估自身场景时，应先明确每条边界分别由谁认证、用什么凭据，而不是把整条链路当作一个黑盒。
方案二展示了新旧系统并存的务实做法
方案二针对订单系统只认 Basic 认证、库存系统已接入 Entra ID 应用身份的现实，在同一个 Gateway 下为不同 target 分别配置出站凭据，老系统无需改造即可接入。文章特别指出，订单链路中 REST API 路由使用 AuthorizationType=NONE，由 Gateway 注入 Basic 凭据，订单函数必须自行校验用户名和密码；库存链路则要求业务函数只信任已验证的 JWT claims，不从请求头、查询参数或工具参数中获取身份。这种“一个 target 一种方式”的设计，是三条边界独
方案三需区分委托权限与业务角色
当不同用户需要看到不同范围的数据时，方案三通过 Entra ID 授权码流程获取用户令牌，再由 Gateway 以 OBO 为每个下游 API 换取代表该用户的令牌。文章明确区分了两类校验：Orders.Read、Inventory.Read 是 delegated permissions（scope），表示允许 Gateway 代表用户访问资源；OrdersReader、InventoryReader 是资源 API 定义并分配给用户的 app roles，表示用户是否具备业务访问资格。两者分别校验、不能互相替代
方案四的私网收口存在授权服务器限制
方案四在方案一身份机制之上，将 MCP 流量经 Quick VPC 连接和 Gateway PrivateLink 走内网，业务 Lambda 放入 VPC，实现网络与身份双重收口。但文章指出一个实际限制：本方案授权服务器为 Cognito，其 domain OAuth endpoint、managed login 和 hosted UI 不支持通过 PrivateLink 访问，cognito-idp interface endpoint 也不接收 user-pool domain 请求，因此 /oauth2/t
Q&A
Amazon Quick 通过 MCP 连接器访问企业应用时，需要分别管理哪几条信任边界？
需要分别管理三条独立的信任边界：用户登录 Quick（由 Entra ID SSO 负责）、连接器访问 Gateway（入站认证，可用 Cognito client credentials 或 Entra ID authorization code flow）、Gateway 访问业务系统（出站认证，可用 IAM、Basic 认证、Entra ID 应用身份或用户委托）。三条边界需分别配置身份与权限。
如果后端业务系统不需要区分用户身份，应该选择哪种接入方案？
选择方案一：以 Cognito 服务身份调用 Lambda 工具。连接器通过 Cognito client credentials flow 获取 token，Gateway 验证后用自己的 execution role 调用业务函数，后端无需实现认证鉴权逻辑。这是最简单、运维成本最低的起点方案。
企业同时有只支持 Basic 认证的老系统和用 Entra ID 应用身份的新 API，如何接入 Quick？
采用方案二：Gateway 入站认证保持 Cognito client credentials 不变，出站则为每个 target 单独配置凭据——老系统走 Basic 认证（由 credential provider 注入 Authorization 头，函数自行校验用户名密码），新 API 走 Entra ID 应用身份（校验 JWT claims 中的 tid、azp/appid、roles）。新旧系统可在同一 Gateway 下共存。
需要根据用户角色控制数据访问范围时，如何把用户身份传递到后端业务系统？
采用方案三：Gateway 入站改用 Entra ID authorization code flow 获取用户 access token，再通过 On-Behalf-Of（OBO）流程为每个下游 API 换取代表该用户的 token。下游 API 分别校验 delegated scope（如 Orders.Read）和用户 app role（如 OrdersReader），两者不能互相替代。
合规要求业务系统只能内网访问，Quick 到 Gateway 的流量如何不走公网？
采用方案四：MCP 流量通过 Quick VPC 连接和 Gateway PrivateLink（interface VPC endpoint）走内网，业务 Lambda 部署在 VPC 内。但 OAuth token 请求因 Cognito domain 不支持 PrivateLink 仍走公网；若授权服务器提供可从 VPC 访问的 OAuth endpoint，则可将 auth 流量也收进私网。
四种接入方案可以组合使用吗？落地时应该遵循什么原则？
可以按业务需求自由组合。多数团队可从方案一起步，再按需叠加：下游认证复杂引入方案二，需按人授权引入方案三，有内网合规要求引入方案四。无论选哪种，都应分别设计“用户登录 Quick”“连接器访问 Gateway”“Gateway 访问业务系统”三条信任边界，使 AI 调用与企业既有身份、权限和网络策略保持一致。
