Amazon Quick 新增四种自动化用户级自定义权限的方法，避免留下访问缺口

尽管企业创建和管理用户的方式各不相同，Amazon Quick 现已提供四种模式，可自动化管理 Amazon Quick 的用户级自定义权限。AWS 于 2026 年 9 月 9 日发布了这项指南；随着 Quick 的 AI 功能不断扩展，手动分配权限已越来越难以长期维持。

关键变化不在于新增一个权限界面。AWS 将自定义权限配置文件连接到用户生命周期中的四个不同节点：注册、默认分配、群组成员关系变更和追溯性修复。

这为安全团队带来了一种值得关注的张力。广泛适用的默认设置能立即提供保护，却无法表达所有业务规则。按用户自动化带来更高精度，但也引入了事件处理、冲突解决、监控和恢复工作。

随着分析平台吸收生成式 AI 与工作流功能，Microsoft Power BI 和 Salesforce Tableau 也面临类似的整体治理压力。不过，AWS 正围绕分层配置文件构建其方案，这些配置文件可以随用户在不同 Quick 角色和群组之间流转。

Amazon Quick 的权限模型有哪些变化

AWS 已将自定义权限转变为生命周期控制机制，而不再只是管理员在入职后分配的配置文件。

自定义权限允许管理员为选定用户启用或禁用特定的 Quick 功能。一名财务分析师可以创建报告，但失去导出底层数据的权限。外部合作伙伴则可以查看仪表板，却无权使用共享控制功能。

这些配置文件并不替代身份验证或常规资源授权。它们构成了另一层控制机制，用于决定已验证身份的用户可以访问哪些产品功能。

随着 Amazon Quick 超越传统商业智能范畴，这一区别愈发重要。该平台现已包括 AI 辅助创作、代理、流程、知识库、连接器、应用程序和生成式商业智能功能。

因此，像 AUTHOR 这样的角色，对用户完整风险状况的说明已不如过去充分。两位作者可以拥有相同角色，却需要对导出、共享、AI 功能或数据连接实施截然不同的访问控制。

AWS 的新指南围绕四种运营场景组织自动化。第一种是在基于 API 的注册过程中附加配置文件。第二种是不维护单独的自动化流程，直接应用账户或角色默认设置。

第三种通过 Amazon EventBridge 和 AWS Lambda 响应群组成员关系事件。第四种则更新那些在组织引入自动化控制之前就已存在的用户。

这四种方法并非可以相互替代的部署选项。它们覆盖身份生命周期中的不同节点，成熟的环境往往会组合使用其中多种方法。

层级结构决定了这些组合如何运作。用户级设置会覆盖角色级设置，而角色级设置会覆盖账户级默认设置。

这一顺序让管理员能够建立限制性的基础框架，同时提供受控例外。它也带来了治理责任，因为单个用户级分配可能会取代从更广泛层级继承的保护措施。

时机同样值得关注。8 月 19 日，AWS 还宣布对自定义权限配置文件中的 AI 能力类别采用默认拒绝策略。

该设置会阻止受影响用户使用新发布的 AI 功能，直到管理员明确允许为止。此前，新功能会在发布时立即可用，迫使安全团队事后响应。

自动化指南补全了这一控制体系的另一部分。默认拒绝为未来功能定义了更安全的姿态；生命周期自动化则决定了哪些人在何时获得各类权限姿态。

AWS 建议先从账户或角色默认设置开始，再构建条件事件处理。这一建议揭示了核心问题：最安全的控制，是例外工作流运行之前就已生效的控制。

为什么账户和角色默认设置最具安全价值

最简单的模式能够弥合最大的访问缺口，因为它会在管理员完成每位用户分类之前生效。

账户级选项使用 UpdateAccountCustomPermission API。它为没有明确用户或角色分配的用户建立后备配置文件，包括通过即时预配创建的用户。

即时预配会在联邦用户首次访问服务时创建账户。它减少了手动入职流程，但也可能产生一个阶段：基于群组的业务上下文尚未补齐。

账户默认设置覆盖了这一阶段。每位尚未分类的人员都会先遵循组织可接受的最低限制，而不是对新引入功能继承不受限制的访问权限。

角色级选项使用 UpdateRoleCustomPermission。管理员可以为命名空间内的读者、作者、管理员及对应专业角色设置不同默认值。

角色默认设置适合其主要策略差异已遵循岗位能力划分的组织。作者由于需要创建内容，可能获得一种配置文件；读者主要消费内容，因此获得另一种配置文件。

AWS 将账户、角色和用户分配描述为三级层级结构。管理员配置文档确认，用户级配置文件的优先级高于更广泛的默认设置。

这一层级将基线治理与例外情况分离。安全团队可以在整个账户范围内限制某项能力，针对某个角色细化策略，并为特定用户授予另一种配置文件。

同一结构也限制了运营复杂度。对于统一适用于每位作者或每位账户用户的规则，企业无需为此建立 Lambda 函数。

当安全审查速度慢于产品交付时，默认设置尤其相关。企业可以立即阻止一类新的 AI 功能，对其进行评估，并在审批后允许选定能力。

AWS 举例称，企业可能会对新的生成式商业智能功能和连接器审查 60 至 90 天。这些数字说明的是策略窗口，并非服务要求。

即使不考虑示例中的规模，其基本观点依然成立。功能发布日期很少会与组织的隐私评估、供应商审查或内部变更流程恰好同步。

因此，广泛的默认设置会以积极的方式推动安全团队调整工作方法。他们必须先定义最低权限姿态，再设计例外，而不是将每位新用户视为一张孤立工单。

它们也会推动希望更快获得访问权限的产品负责人。这些负责人需要建立可重复的审批路径，因为默认策略如今会在不确定期间倾向于限制。

不过，默认设置无法识别每一种业务上下文。不同部门的两位作者可以拥有相同的 Quick 角色，却面对不同的数据导出、资产共享和 AI 工具要求。

这正是广泛保护的边界。一旦策略取决于部门、客户权益、地域或审批状态，管理员就需要更精确的信号。

如何为 Amazon Quick 自动化用户级自定义权限

这四种模式构成一套控制序列：尽早分配、安全地设定默认值、根据上下文响应，并修复历史覆盖范围。

最直接的模式适用于组织通过自定义门户或预配脚本控制用户创建的情况。RegisterUser 请求可在创建账户时接受 CustomPermissionsName 值。

AWS CLI 通过 --custom-permissions-name 参数公开该值。这使目标配置文件能够直接附加给用户，无需等待其他事件或定期协调。

该模式适合嵌入式分析提供商及其他在注册时已知客户权益的软件服务。服务可以将该权益映射到既有权限配置文件。

例如，某提供商可能会为客户协议未涵盖这些能力的用户限制分页报告或生成式功能。该决策在既有预配路径中完成。

由于不需要 EventBridge 规则或 Lambda 函数，这种方法的活动面最小。它的弱点也同样明确：仅当组织端到端控制注册流程时才有效。

联邦式入职使这一假设变得复杂。身份系统可能会在组织解析出部门、群组或策略属性之前创建 Quick 用户。

账户和角色默认设置通过设定基线来处理这种不确定性。它们需要更少的自定义基础设施，并覆盖所有缺少更高优先级分配的现有和未来用户。

条件规则需要第三种模式。AWS 的设计会监控由 AWS CloudTrail 捕获的群组成员关系活动，通过 EventBridge 路由匹配事件，并调用 Lambda。

对于原生 Quick 群组，当有人加入时，CloudTrail 会记录 CreateGroupMembership；当有人离开时，则记录 DeleteGroupMembership。IAM Identity Center 使用 AddMemberToGroup 和 RemoveMemberFromGroup。

EventBridge 会筛选这些记录。Lambda 会提取账户、命名空间、用户、操作和目标群组，然后调用相应的 Quick API。

当成员新增事件匹配已配置群组时，Lambda 会调用 UpdateUserCustomPermission。用户权限 API允许为该用户指定一个自定义权限配置文件名称。

当该人员离开受监控群组时，Lambda 会调用 DeleteUserCustomPermission。移除明确分配后，用户将恢复适用的角色或账户默认设置。

这种移除行为至关重要。若自动化仅在成员加入时授予或限制访问权限，随着员工调岗，过时的分配将不断累积。

AWS 为这种事件驱动架构提供了 CloudFormation 模板。该堆栈包括 EventBridge 规则、Lambda 函数、执行角色和所需的策略资源。

该堆栈必须与 Quick 订阅部署在同一 AWS Region。EventBridge 会在配置的 Region 内捕获相关服务事件，因此部署区域不匹配可能导致错过预期活动。

在已发布的设计中，每次部署仅面向一个原生 Quick 群组或一个 IAM Identity Center 群组。若要监控两种群组来源，则需要分别部署堆栈。

权限配置文件必须已存在。自动化负责分配配置文件，但不会定义其能力设置，也不会决定组织策略。

第四种模式处理的是在事件驱动自动化出现前就已加入的人员。未来的成员关系事件无法修复其相关群组分配在数月前就已发生的用户。

AWS 提供了一种 Python 批处理方法，调用 ListGroupMemberships，遍历返回的用户，并为每位用户应用 UpdateUserCustomPermission。

分页是最容易被忽略的细节。ListGroupMemberships 每次响应最多返回 100 名成员，因此脚本必须继续使用 NextToken。

如果没有这一闭环，团队可能会报告迁移成功，但实际上除了第一页之外的所有成员都未发生变化。大型群组会让这种失败既有可能发生，也难以察觉。

示例脚本会将更新失败记录到 CSV 文件中，供后续跟进。管理员还可以调用 DescribeUser 并检查 CustomPermissionsName，以验证单个用户的分配情况。

这些模式结合起来，可自动化 Amazon Quick 的用户级自定义权限管理，同时不假定每个组织都拥有相同的身份架构。正确的组合取决于可靠的策略上下文在何时可用。

基于群组的精细控制带来了新的治理问题

事件驱动的权限管理减少了重复性工作，但也将风险转移到事件传递、群组质量和冲突解决上。

AWS 的基于群组设计是最灵活的模式，因为它可以向具有相同 Quick 角色的用户应用不同的权限配置文件。但这种灵活性也带来了最大的运营负担。

CloudTrail 必须在正确的区域捕获预期事件。EventBridge 规则必须匹配实际的事件结构。Lambda 需要具备足够的权限、错误处理、日志记录和重试机制。

执行角色本身也应遵循最小权限原则。AWS 列出了用于更新、删除、描述和管理用户分配的 Quick 操作；如果涉及 Identity Center 集成，还包括 Identity Store 的读取权限。

服务授权至关重要，因为自动化能够更改一个账户内用户的功能权限。Quick 授权参考将 UpdateUserCustomPermission 归类为针对用户资源的写入操作。

因此，Lambda 是一个拥有特权的策略执行组件，而不只是集成胶水。团队应像审查其他访问控制基础设施一样谨慎地审查其代码和执行角色的变更。

群组准确性带来了另一项风险。事件驱动系统会忠实地应用映射至某个群组的策略，即使底层成员关系有误也是如此。

因此，过期的部门群组可能导致技术上成功、但在组织层面错误的分配。自动化能够减少人工执行错误，却无法保证源数据正确。

多个群组成员关系带来了最棘手的未决问题。Quick 每位用户只支持一个自定义权限配置文件，而一个人可能属于多个预期配置文件不同的群组。

AWS 示例并未针对这种情况实现自动冲突解决。组织必须决定哪个配置文件优先，并在其 Lambda 逻辑中编码这一选择。

“最严格者优先”策略符合最小权限原则，但可能阻碍合理的工作。优先级列表更灵活，但需要指定负责人并建立成文的例外处理流程。

该层级关系还带来另一项考量。由群组触发的用户配置文件会覆盖角色和账户默认设置，即使该显式配置文件的限制性低于继承的基线。

因此，团队应将用户级配置文件视为完整的策略结果。不要假设账户默认设置仍会保护例外设计中未涵盖的功能。

AWS 的事件模式也是响应式的。新的联合身份用户可能会在管理员将其加入适当群组之前就已存在。

AWS 明确建议使用限制性账户或角色默认设置来覆盖这一预配窗口。之后的群组事件再进一步细化用户权限。

这种关系使默认设置和事件形成互补。默认设置保护未知状态，而群组自动化会在完成分类后应用已知上下文。

组织应监控 Lambda 调用失败、未匹配事件以及意外的权限变更。CloudWatch 告警可以识别执行失败，但团队还需要业务层面的核对机制。

将权威群组与已分配配置文件进行定期比较，可提供第二道检查。它能够发现遗漏事件、手动覆盖、群组重命名，以及在预期工作流之外被更改的配置文件。

批处理脚本可支持这类核对，尽管 AWS 主要将其脚本用于初始修复。相同的分页和验证原则同样适用于定期审计。

目前也尚无第三方证据表明这些模式在复杂生产环境中的表现。相关指导刚刚推出，其最大规模数据均以说明性场景呈现。

这并不意味着该架构无效。它意味着买方应在自身的身份流量条件下验证交付延迟、API 节流、重试行为和冲突规则。

安全团队接下来应关注什么

下一项考验在于，组织能否将这些组件转变为可审计的策略系统，而非一组脚本。

第一个信号是限制性账户默认设置与群组自动化的采用情况。仅使用成员关系事件的部署方案，在完成分类之前仍会保留一个风险窗口。

更广泛地采用默认拒绝策略，将强化 AWS 的生命周期模型。这将表明企业希望新的 AI 功能先进入审核，而非自动开放。

第二个信号是对群组级自定义权限分配的原生支持。AWS 表示，目前没有可将自定义权限配置文件直接分配给群组的 API。

这一缺口解释了 CloudTrail、EventBridge 和 Lambda 架构的存在。原生群组分配能够减少基础设施，同时让管理员拥有更清晰的位置来定义优先级。

这类功能也需要冲突语义。AWS 必须说明，当同一个人属于映射至不同配置文件的多个群组时会发生什么。

如果原生支持在没有确定性优先级的情况下推出，它只会转移问题而非解决问题。如果 AWS 增加明确的优先级规则，事件驱动的变通方案就会变得不那么必要。

第三个信号是真实部署的证据。团队应关注涵盖大规模身份用户群体中的分配延迟、故障恢复、API 限制和核对机制的公开数据。

当前指导包含涉及 50,000、125,000 以及超过 200,000 名用户的示例。AWS 将它们作为说明设计要求的场景，而非测得的客户结果。

生产证据将增强或削弱采用这一架构的理由。企业规模下可靠的事件处理将验证其分层设计。

频繁遗漏事件或复杂的冲突处理，则会促使组织转向计划性核对或集中式身份治理。

现在实施该模型的管理员应从清单盘点开始。他们需要列出每一个自定义配置文件、其负责人、受影响的功能、分配范围以及获批的例外路径。

随后，他们应建立最严格但仍可用的账户默认设置。在岗位职能形成一致差异的情况下，角色级配置文件可进一步细化这一基线。

直接注册分配应仅限于拥有可靠授权数据的预配系统。基于群组的 Lambda 逻辑只应处理广泛默认设置无法表达的规则。

在团队信任未来事件之前，现有用户需要完成一次完整的批处理。迁移过程应记录成功情况、保留失败记录，并在分页完成后验证分配结果。

管理员还应测试移除操作，而不仅是添加操作。用户离开群组后，必须恢复为预期的账户或角色配置文件，不能保留过时的覆盖设置。

这一更广泛的经验不仅适用于 Amazon Quick。AI 功能增加了隐藏在熟悉角色中的能力数量，使静态角色名称会随着时间推移变得不那么具有说明性。

产品团队希望新工具能够快速可用。安全团队则需要时间评估数据流动、共享行为、模型访问和连接器权限。

Amazon Quick 的解决方案是分层执行，而不是单一策略机制。广泛的默认设置奠定安全基础，注册和群组事件则加入用户特定的上下文。

对于记录这些决策的团队，可搜索的技术知识库可以关联配置文件定义、审批记录、事件说明和操作流程。

实际的下一步，是针对一个受控群组测试一个限制性配置文件。在扩大覆盖范围之前，验证注册、添加、移除、分页、失败日志记录和回退行为。

你们当前的流程能否准确说明每位 Quick 用户获得哪个配置文件、该配置文件为何优先，以及自动化失败时会发生什么？如果不能，请将这四种模式用作控制地图。从基线开始，弥合历史缺口，并仅在业务上下文确有需要时加入事件驱动的例外。