跳到主要内容
AI News HubLIVE
站内改写3 分钟阅读

使用 Amazon Bedrock AgentCore Identity 保护 Amazon ECS 上的 AI 智能体安全

文章摘要

本文介绍了如何使用 Amazon Bedrock AgentCore Identity 作为独立服务,在 Amazon ECS 上安全地实现 AI 智能体的 OAuth 2.0 授权码授权流程(三腿 OAuth),包括安全会话绑定、作用域令牌以及工作负载与会话绑定服务的分离。

来源AWS Machine Learning Blog作者: Julian Grüber
使用 Amazon Bedrock AgentCore Identity 保护 Amazon ECS 上的 AI 智能体安全
报告错误

纠错通道尚未开通,可先复制下方文章信息留存。

查看更正说明
直接读正文

在生产环境中,AI 智能体需要安全地访问外部服务。Amazon Bedrock AgentCore Identity 作为一项独立服务,可保护您的 AI 智能体访问外部服务,无论它们运行在 Amazon ECS、Amazon EKS、AWS Lambda 还是本地环境中。

本文聚焦于在 Amazon ECS 上实现授权码授权(三腿 OAuth),并附带安全的会话绑定和作用域令牌。此前有一篇文章介绍了 AgentCore Identity 的凭证管理,而本文则解决了在计算环境(如 ECS)上运行智能体时的两个关键问题:如何构建应用程序拥有的会话绑定端点,以及如何管理工作负载访问令牌的生命周期。

该解决方案使用了 OAuth 2.0(RFC 6749)和 OpenID Connect(OIDC)。OIDC 用于用户身份验证(确认用户身份),OAuth 2.0 用于授权用户操作(确定用户可执行的操作)。本文重点介绍用于用户委托访问的授权码授权流程:用户通过身份提供商进行身份验证并授予同意,然后应用程序将授权码交换为作用域访问令牌,Amazon Bedrock AgentCore Identity 将其安全地存储在令牌保管库中。由于每个令牌都绑定到特定的用户身份并具有明确的同意记录,该解决方案维护了一个从用户身份验证到智能体操作的可审计链。

授权码授权适用于代表用户行动的智能体工作负载,因为它提供了用户行动前的同意、会话绑定(验证发起授权请求的用户与授予同意的用户是同一人)以及作用域委托(将智能体的权限限制在用户批准的范围内)。

解决方案概述

本文的架构图展示了 AgentCore Identity 如何在 Amazon ECS 上保护自托管 AI 智能体。该方案在 ECS 上部署了两个服务:智能体工作负载(运行 AI 智能体并处理用户请求)和会话绑定服务(处理 OAuth 回调以将用户会话与第三方访问令牌关联)。两者都使用 Amazon Bedrock AgentCore Identity 通过 OIDC 进行入站身份验证,并代表用户授权出站操作。

入站身份验证和流量路由通过 Amazon Application Load Balancer (ALB) 进行,ALB 内置 OIDC 身份验证流程,并将用户声明以 JWT 格式注入 x-amzn-oidc-data 头中。智能体工作负载使用 FastAPI 服务器,通过 Strands Agents 构建智能体,并调用 Amazon Bedrock 上的大语言模型(LLM)。当智能体需要代表用户在 GitHub 等第三方服务上执行操作时,它会通过 AgentCore Identity 请求 OAuth 访问令牌。如果不存在有效令牌,AgentCore Identity 会启动授权码授权流程,提示用户授权。用户授权后,会话绑定服务通过 AgentCore Identity 完成 OAuth 流程,将授权与正确的用户会话绑定。

会话绑定

会话绑定可防御两种安全威胁:跨站请求伪造(CSRF)和浏览器交换攻击。CSRF 中,攻击者试图将自己的 OAuth 令牌绑定到受害者的身份,导致受害者的智能体无意中访问攻击者的资源。浏览器交换攻击中,攻击者诱骗受害者代表其同意,将受害者的 OAuth 令牌绑定到攻击者的身份,使攻击者直接访问受害者的资源。会话绑定通过确保智能体工作负载处的用户 ID 与会话绑定服务处的用户 ID 一致(两者均通过身份验证链加密验证)来防止这两种攻击。

为什么使用 GetWorkloadAccessTokenForUserId

推荐的工作负载访问令牌获取 API 是 GetWorkloadAccessTokenForJWT,但由于 AWS ALB 与 Microsoft Entra ID 的兼容性问题,本文使用 GetWorkloadAccessTokenForUserId。因为 ALB 的 OIDC 握手需要访问令牌作用域为 Microsoft Graph,而 GetWorkloadAccessTokenForJWT 要求 JWT 的 aud 声明与您的应用程序匹配,这无法同时满足。因此,该方案使用 ALB 签名的 JWT 中的 sub 声明来提取用户 ID,然后调用 GetWorkloadAccessTokenForUserId。

实现要点

文章提供了完整的代码示例,包括获取工作负载访问令牌、请求 OAuth 访问令牌以及完成 OAuth 会话绑定的具体实现。关键设计选择包括:使用 Pydantic BaseModel 作为工具返回类型(Strands 自动派生描述)、类型一致的错误处理(当需要授权时引发 AuthorizationRequiredError)以及每个工具声明所需的最小 OAuth 作用域(遵循最小权限原则)。

结论

通过本文,您学习了如何使用 Amazon Bedrock AgentCore Identity 保护 Amazon ECS 上的 AI 智能体。入站身份验证通过 OIDC 验证用户身份,出站身份验证通过 OAuth 2.0 和会话绑定实现,将会话绑定与智能体工作负载分离可实现独立扩展并防御攻击。该模式适用于 ECS、EKS、Lambda 或外部 AWS 环境,并可扩展至 GitHub、Jira、Salesforce 或 Google Calendar 等支持 OAuth 2.0 的服务。

展开要点与分析

文章情报

工程师进阶

要点

  • Amazon Bedrock AgentCore Identity 可保护 AI 智能体对外部服务的访问,支持 ECS、EKS、Lambda 等平台。
  • 实现了授权码授权流程(OAuth 2.0),包含安全的会话绑定和用户作用域令牌。
  • 将智能体工作负载与会话绑定服务分离,可独立扩展并防御 CSRF 和浏览器交换攻击。
  • 提供了完整的 AWS 架构实现,包括 ALB 身份验证、AgentCore Identity API 调用和 GitHub 集成示例。

要点与分析由自动化流程生成,可能有误,请结合原始来源核实。