使用Amazon Verified Permissions和Amazon Bedrock代理设计安全的生成式AI应用工作流 | Amazon Web Services
亚马逊Bedrock代理启用生成式AI应用程序在各种公司系统和数据源上执行多步骤任务。它们协调并分析这些任务，并利用基础模型（FM）的推理能力将其分解为正确的逻辑序列。代理自动调用必要的API以与公司系统和流程交互，从而满足请求。在整个过程中，代理确定是否可以继续进行或是否需要额外的信息。
客户可以使用生成式AI构建创新应用亚马逊Bedrock代理智能编排其应用程序工作流的能力。在构建此类工作流时，客户难以应用细粒度的访问控制以确保应用程序的工作流程仅在其应用程序用户的权限范围内操作授权数据。根据用户上下文、角色、动作和资源条件来控制对资源的访问，在应用程序工作流中维护起来颇具挑战性，因为这需要在您的应用程序中硬编码多个规则或将这些规则外部化以构建自己的授权系统。
您可以集成现有的授权系统，而不是为您应用程序的工作流程构建自己的细粒度访问控制的授权系统。亚马逊验证权限将上下文感知的细粒度访问控制集成到代理的工作流程中。Verified Permissions 是一个可扩展的权限管理和授权服务，用于您构建的自定义应用程序。Verified Permissions 帮助开发人员通过外部化授权组件并集中管理策略来更快地构建安全的应用程序。
在这篇文章中，我们将演示如何使用经过验证的权限为一个生成式AI应用程序设计细粒度访问控制。该应用程序使用Amazon Bedrock Agents根据文本提示作为输入和输出来回答关于保险索赔系统中的保险索赔的问题。在我们的保险理赔系统用例中，有两种类型的用户：理赔管理员和理赔调整员。两者都可以列出未决的理赔案件，但只有一个能够查看理赔详情并进行修改。我们还展示了如何使用自定义属性（如用户的区域）限制权限以过滤保险索赔。在这篇文章中，术语区域不指代一个AWS 区域而是到业务定义的区域。
解决方案概述
在此解决方案设计中，我们假设客户有索赔记录在一個亚马逊 DynamoDB他们希望构建一个基于聊天的应用程序来回答关于索赔的常见问题。这个聊天助手将由理赔管理员和理赔调整员内部使用，以回答客户的问题。
以下是理赔团队需要执行的操作列表，以回答客户的问题：
- 显示我未关闭的索赔列表
- 显示输入索赔号的索赔详情
- 将输入的索赔号的状态更新为已关闭
客户对其声明系统有以下访问控制要求：
- 理赔管理员可以在不同地理区域列出理赔案件，但他们不能阅读个别理赔记录。
- 理赔调整员可以列出其所在地区的索赔，并可以阅读和更新分配给他们的索赔记录。然而，理赔调整员不能访问其他地区的索赔。
- 被放入一个组中亚马逊认知服务，他们的应用程序级别的权限在此设置和维护
- 客户希望使用Verified Permissions来外部化实体和记录级别的授权决策，而不将应用程序逻辑硬编码。
为了提升聊天助手的性能，客户使用了亚马逊Bedrock上的功能模块（FMs）。为了从索赔表中检索必要信息并动态调度请求，客户结合使用了亚马逊Bedrock代理以及已验证权限（Verified Permissions）来为代理的调用提供细粒度的授权。
构建具有细粒度访问控制的基于聊天的生成式AI索赔应用程序的应用架构如下图所示。
应用程序架构流程如下：
- 用户访问生成式AI索赔网页应用（App）。
- 该应用程序使用Amazon Cognito服务对用户进行身份验证，并颁发ID令牌和访问令牌。ID令牌包含用户的标识和自定义属性。
- 使用该应用程序，用户发送一个请求，要求“列出所有未结案件。”此请求与用户的ID令牌和访问令牌一起发送。应用程序调用Claims API Gateway API来运行案件代理，传递用户的请求和令牌。
- Claims API Gateway 运行自定义授权程序来验证访问令牌。
- 当访问令牌验证成功时，Claims API网关将用户请求发送到Claims代理。
- 声明代理通过传递用户请求和ID令牌来调用Amazon Bedrock代理。Amazon Bedrock代理被配置为使用Anthropic的Claude模型，并且通过声明代理助手来调用动作。AWS Lambda
- 亚马逊Bedrock代理使用链式思考提示，并在Claims Agent Helper的帮助下构建要运行的API操作列表。
- 索赔代理助手从Claims DB检索索赔记录，并构建一个索赔列表对象。在此示例中，我们在Lambda函数中提供了硬编码的示例，并且在提供的解决方案中没有添加DynamoDB。然而，我们提供架构中的组件以表示实际应用场景，在这些场景中数据存储在外围的Lambda之外。
- 声明代理助手从ID令牌中检索用户的元数据（即他们的姓名），构建Verified Permissions数据实体，并发起Verified Permissions授权请求。此请求包含主体（用户和角色）、操作（即ListClaim）和资源（Claim）。Verified Permissions根据Verified Permissions策略评估该请求，并返回允许或拒绝的决定。随后，声明代理助手基于该决定过滤声明。Verified Permissions具有“默认拒绝”功能，这意味着在没有明确允许的情况下，默认为隐式拒绝。如果涉及请求的相关策略中有明确的Deny，则Verified Permissions将拒绝该请求。
- 亚马逊Bedrock代理接收授权的断言列表，增强提示并将其发送到Claude模型以完成处理。代理将完成结果返回给用户。
细粒度访问控制流程
根据客户的身份访问控制要求，有三个细粒度的访问控制流程如以下系统序列图所示。
用例：索赔管理员可以在不同地区列出索赔事项
下图显示了索赔管理员如何在不同地区列出索赔。
以下图表描绘了声明管理员对索赔记录的细粒度访问是如何运行的。在该图中，注意到来自已验证权限的拒绝决定。这是因为在主体的角色不匹配的情况下。理赔调整员.
用例：理赔调整员可以查看他们负责的索赔案件
以下图表描绘了索赔调整员检索索赔详情的细粒度访问权限的运行方式。在此图中，请注意来自已验证权限的允许决定。这是因为主体的角色是理赔调整员资源所有者（即声明所有者）与用户主体匹配（即用户=alice）。
以下图表描绘了理赔调整员精细访问未结赔案的流程。在此图中，请注意来自已验证权限的允许决定。这是因为主体的组为ClaimsAdjuster，并且资源上的区域与主体的区域匹配。由于授权策略上此区域过滤器的结果，仅返回用户所在区域的未结赔案。已验证权限基于主体、操作和单个资源（即理赔记录）做出授权决策。因此，Lambda函数需要遍历未结赔案列表并进行一次是否有权限对于每个索赔记录的请求。如果这导致了性能问题，你可以使用批量授权检查API并发送多个授权请求在一次API调用中。
实体设计考虑因素
在设计细粒度的数据访问控制时，最佳实践是从应用程序的实体关系图（ERD）开始。对于我们的话务应用，用户将操作话务记录以检索话务记录列表、获取单个话务记录的详细信息或更新话务记录的状态。以下图表是在Verified Permissions中对此应用进行建模的ERD。使用Verified Permissions，您可以同时应用基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）。
这里是对将用于基于声明记录的RBAC和ABAC的每个实体和属性的简要描述。
- 申请表该应用程序是一款基于聊天的生成式AI应用，使用亚马逊Bedrock代理来理解问题并检索相关的索赔数据，以协助索赔管理员和理赔调整员。
- 声明– 该索赔代表存储在DynamoDB表中的保险理赔记录。理赔系统存储理赔记录，而聊天机器人应用程序允许用户检索和更新这些记录。
- 用户用户。
- 角色– 该角色代表用户在应用程序中的访问权限。以下是可用的角色列表：
- 理赔管理员– 可以列出不同地理区域的索赔记录，但不能阅读单个索赔记录
- 理赔调整员可以列出他们区域的索赔，并阅读和更新他们的索赔记录
角色通过Amazon Cognito和Verified Permissions进行管理。Cognito记录用户被分配的角色，并将此信息包含在令牌中。Verified Permissions记录该角色被允许执行的操作。细粒度的访问控制确保用户对其角色具有适当的权限，基于地理区域和用户组限制对敏感声明数据的访问。
细粒度授权：策略设计
无实际内容需要翻译 原文：The 翻译结果：The 说明：这里的"The"是一个英文冠词，在没有具体上下文的情况下，通常不进行直接翻译。如果要求确切翻译且需给出对应词汇，则保持原样输出。行动图表视图列出了类型的负责人你在策略存储中配置的行动他们有资格执行，并且的资源他们有资格执行操作。实体之间的连线表示你可以创建一个策略，允许某个主体在一个资源上执行某项操作。以下图示展示了Verified Permissions中我们保险索赔用例的动作图。用户主体将有权访问获取、列出和更新操作。资源是应用及其内部的索赔实体。此图生成了管理策略定义的基础架构。
用例：理赔管理员可以列出所有地区的索赔记录
一个政策是一个声明，要么允许要么禁止某事校长取一或多个动作在一张资源每个策略都是独立于其他策略进行评估的。以下代码示例展示了此用例的Verified Permissions策略。在此策略中，主体（即用户鲍勃）被分配了声明管理员的角色。
许可 (
主体在 avp::claim::app::Role::"ClaimsAdministrator" 中，
操作在 [
avp::claim::app::Action::"ListClaim"
] 中，
资源
);用例：理赔管理员无法访问理赔详细记录
本用例的Verified Permissions策略如下代码示例所示。使用明确的“禁止”策略是一种有效的实践。
禁止
主体在 avp::claim::app::Role::"ClaimsAdministrator"，
动作在 [
avp::claim::app::Action::"GetClaim"
]，
资源；用例：理赔调整员可以列出他们所在地区的理赔案件
本用例的Verified Permissions策略如下代码示例所示。在此策略中，主体（即用户Alice）被分配了理赔调整员的角色，并且他们的地区作为自定义属性传递到了ID令牌中。
许可 (
主体 in avp::claim::app::Role::"ClaimsAdjuster",
操作 in [
avp::claim::app::Action::"ListClaim"
],
资源
) 当 {
资源有所有者 &&
主体 == 资源.所有者 &&
主体有自定义属性 &&
主体.自定义属性有区域 &&
主体.自定义属性.区域 == 资源.区域
};用例：理赔调整员可以检索或更新他们自己的索赔案件
permit (
主体 in avp::claim::app::Role::"ClaimsAdjuster",
操作 in [
avp::claim::app::Action::"GetClaim",
avp::claim::app::Action::"UpdateClaim"
],
资源
) when {
主体 == 资源.owner &&
主体具有 custom &&
主体.custom 具有 region &&
主体.custom.region == 资源.region
};身份验证设计考虑因素
本用例中Amazon Cognito的配置遵循了标准配置工作流中包含的安全实践：强密码策略、多因素认证（MFA）和客户端密钥。在使用Amazon Cognito与Verified Permissions时，您的应用程序可以将用户池访问令牌或身份令牌传递给Verified Permissions以做出允许或拒绝的决定。Verified Permissions会根据存储在策略存储中的策略来评估用户的请求。
对于自定义属性，我们使用区域来限制理赔调整员可以看到哪些理赔案件，排除了在其所在地区以外的地区的理赔案件。我们还使用角色作为自定义属性，在传递给Amazon Bedrock代理的身份令牌中提供该信息。当用户在Cognito用户池中注册时，这些自定义属性将作为注册过程的一部分记录下来。
Amazon Cognito 通过与 Verified Permissions 集成实现身份源控制台中的部分。以下截图显示我们已将Cognito用户池连接到Amazon Verified Permissions策略存储。
细粒度授权：将ID令牌传递给Amazon Bedrock代理
当用户通过Cognito用户池认证后，会将ID令牌和访问令牌返回给客户端应用。在调用invoke_agent时，ID令牌将通过API网关和代理Lambda传递到SessionAttributes中。
# 调用代理API
response = bedrock_agent_runtime_client.invoke_agent(
…
sessionState={
'sessionAttributes': {
'authorization_header': '<AUTHORIZATION_HEADER>'
}
},
)然后从动作组Lambda函数中获取标头，并使用Verified Permissions验证用户对该所需操作的访问权限。
从事件中检索会话属性并使用它来验证操作
sessAttr = event.get("sessionAttributes")
auth, reason = verifyAccess(sessionAttributes, action_id)细粒度授权：与Amazon Bedrock代理集成
Cognito颁发的ID令牌包含用户的身份和自定义属性。此ID令牌传递给Amazon Bedrock代理，然后Agent Helper Lambda从代理的会话属性中检索该令牌。接着，Agent Helper Lambda从DynamoDB中获取开放声明记录，并构建Verified Permissions模式实体并调用isAuthorized API。
因为经过验证的权限资源在单条记录级别运行（即一个单独的声明记录），你需要遍历声明列表对象，并为授权决策调用 isAuthorized API，然后创建过滤后的声明列表。过滤后的声明列表随后会被返回给调用者。因此，理赔调整员只能看到他们所在地区的理赔情况，而理赔管理员可以看到所有地区的理赔情况。
亚马逊Bedrock代理随后使用此过滤后的索赔列表来完成用户列出索赔的请求。聊天应用程序只能访问用户有权查看的索赔记录，提供与亚马逊Bedrock代理工作流集成的细粒度访问控制。
开始入门
查看我们的代码开始使用Amazon Verified Permissions开发您的安全生成式AI应用程序。我们为您提供了一个实现本文所述架构的端到端实施方案以及一个可供您用来测试不同用户权限的演示UI。根据您的用例设置更新此示例，以实现与您的应用场景连接的生成式AI应用。
结论
在这篇文章中，我们讨论了在生成式AI应用程序中为代理工作流应用细粒度访问控制所面临的挑战。我们分享了一个构建示例聊天基础的生成式AI应用程序的应用架构，该应用程序使用Amazon Bedrock Agents来编排工作流，并通过Amazon Verified Permissions应用细粒度访问控制。我们讨论了如何通过基于角色的访问控制工作流设计来设计细粒度访问权限。如果您正在寻找一种可扩展且安全的方式来为您的生成式AI代理工作流应用细粒度权限，请尝试此解决方案并提供反馈。
关于作者
拉姆·维塔尔是一位AWS首席机器学习解决方案架构师。他在构建分布式、混合和云应用程序方面拥有超过30年的经验。他热衷于构建安全、可扩展且可靠的AI/ML和大数据解决方案，以帮助企业的客户在云端采用和优化过程中改善其业务成果。在他的业余时间，他会骑摩托车，并和他的三岁的 sheep-a-doodle（一种狗）一起散步！
萨曼莎·维拉托夫斯卡是一位AWS解决方案架构师。她拥有DevSecOps背景，热衷于指导组织走向安全的操作效率，并利用自动化的力量提供无缝的云体验。在业余时间，她通常通过音乐、文学或电影学习新知识。
安尼尔·纳迪敏蒂是一位在亚马逊 web 服务（AWS）担任高级解决方案架构师的专业人士，专长于赋能组织利用云计算和人工智能实现数字化转型和创新。他在设计可扩展的解决方案和实施数据驱动的战略方面的专业知识，使公司在当今快速变化的技术环境中能够不断创新并繁荣发展。
迈克尔·丹尼尔斯是一位AWS的AI/ML专家。他的专长在于构建和领导针对复杂商业问题的AI/ML及生成式AI解决方案，这一能力得益于他在德克萨斯大学获得的博士学位以及在乔治亚理工学院获得的计算机科学硕士学位（专注于机器学习）。他擅长应用前沿的云技术来创新、激发并转型行业领先组织，并且能够有效地与任何层级或规模的利益相关者进行沟通。在他的业余时间，你可以看到迈克尔滑雪或滑单板。
玛伊拉·拉迪拉·坦克是一位高级生成式AI数据科学家，就职于AWS。凭借机器学习背景，她拥有超过10年的经验，为各行各业的客户设计和构建AI应用程序。作为技术负责人，她帮助客户通过Amazon Bedrock上的生成式AI解决方案加速实现业务价值。在业余时间，Maira喜欢旅行、与她的猫玩耍以及在温暖的地方与家人共度时光。
暂无评论