Loading...
在本文中,我们将介绍如何利用 Amazon Verified Permissions 和 Amazon Bedrock Agents 设计安全的生成性 AI 应用工作流。这些工具能帮助应用程序在确保资源访问的同时,从各种公司系统中提取和分析数据。
客户可以利用 Amazon Bedrock Agents 的能力,智能地协作应用程序工作流。然而,在构建这些工作流时,客户可能面临使用细粒度访问控制的挑战,确保应用程序的工作流仅在用户授权的数据上操作。
相较于自建授权系统,客户可以将 Amazon Verified Permissions 集成到工作流中,应用上下文感知的细粒度访问控制,避免硬编码多条规则。
我们将展示如何使用 Verified Permissions 为一个生成性 AI 应用设计细粒度访问控制,该应用利用 Amazon Bedrock Agents 回答关于保险索赔的问题。
本解决方案假设客户在 Amazon DynamoDB 表中存储索赔记录,并希望构建一个聊天式应用来解答关于索赔的常见问题。该聊天助手将被索赔管理员和调整员内部使用。
以下是索赔团队需要执行的操作列表:
显示我所有的开放索赔显示输入索赔编号的索赔详细信息更新输入索赔编号的状态为“已关闭”客户对索赔系统的访问控制需求如下:
极光加速官网入口索赔管理员可以跨不同地理区域列出索赔,但无法读取单个索赔记录。索赔调整员可以列出所在区域的索赔,并且可以读取和更新分配给他们的索赔记录,无法访问其他区域的索赔。为了提高聊天助手的性能,客户利用 Amazon Bedrock 提供的基础模型。在获取所需的信息和动态协调请求时,客户结合使用 Amazon Bedrock Agents 和 Verified Permissions 来提供细粒度的授权。
以下是构建细粒度访问控制的聊天式生成性 AI 索赔应用的架构图。
根据客户的访问控制要求,我们有三个细粒度的访问控制流程,如下所示的系统序列图。
以下图显示了索赔管理员如何列出跨区域的索赔。
以下图展示了索赔调整员的细粒度访问如何运行以检索索赔详细信息。
在设计细粒度数据访问控制时,最佳实践是从应用程序的实体关系图ERD开始。以下是该应用程序的 ERD,用户将在索赔记录上操作以检索和更新索赔记录。
以下是与索赔记录相关的每个实体和属性的简要说明:
应用程序 这是一个基于聊天的生成性 AI 应用程序,使用 Amazon Bedrock Agents 理解问题并检索相关的索赔数据。索赔 代表存储在 DynamoDB 表中的保险索赔记录。用户 表示应用程序的用户。角色 用户在应用程序中的访问角色。政策是一个声明,允许或禁止主体在某个资源上执行一个或多个操作。以下是针对我们的保险索赔用例的政策示例。
plaintextpermit ( principal in avpclaimappRoleClaimsAdministrator action in [ avpclaimappActionListClaim ] resource)
针对本用例的 Amazon Cognito 配置遵循安全实践,包括强密码政策、多因素认证MFA和客户端密钥。使用 Amazon Cognito 和 Verified Permissions 时,应用程序可以向 Verified Permissions 传递用户池访问或身份验证令牌,以做出允许或拒绝的决策。
当用户通过 Cognito 用户池进行身份验证时,会返回 ID 令牌和访问令牌。ID 令牌将通过 API 网关和代理 Lambda 传递。
pythonresponse = bedrockagentruntimeclientinvokeagent( sessionState={ sessionAttributes { authorizationheader ltAUTHORIZATIONHEADERgt } })
查看我们的代码,以开始开发安全的生成性 AI 应用程序。我们提供了本文描述的架构的端到端实现。
本文讨论了在生成性 AI 应用程序的代理工作流中应用细粒度访问控制的挑战。我们分享了构建聊天式生成性 AI 应用程序的架构,并介绍了如何通过基于角色的访问控制工作流设计细粒度访问权限。如果您正在寻找一种可扩展和安全的方法来将细粒度权限应用于您的生成性 AI 代理工作流,请尝试这个解决方案并留下反馈。