跳到主要內容
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 整合示例。

要點與分析由自動化流程生成,可能有誤,請結合原始來源核實。