有效管理访问权限是维护 Amazon Quick 安全且协作环境的重要方面。Quick 支持多种用户管理选项，旨在适应各种身份类型和组织需求。您可以通过 Quick Identity 原生地预置用户，或通过 AWS IAM Identity Center 或 Active Directory 等企业身份提供商进行管理。这些系统允许根据工作职能和安全要求分配和分组 Admin、Author 和 Reader 等用户角色。当团队成员加入、变更角色或离开组织时，管理员必须确保过渡平稳进行，不中断业务工作流或造成安全漏洞。
定期访问审查对于维护 Quick 环境的安全非常重要。计划每月或每季度对用户角色进行审计，以确认每个人都拥有适当的权限。当团队成员的职责发生变化时，应主动转让其仪表板和分析的所有权，以防止产生孤立资源。这一做法在 AWS Well-Architected Framework中有所推荐，有助于为业务关键型可视化保持连续性。
在本文中，我们聚焦一个具体但重要的用户生命周期任务：降级用户角色。
为什么要降级？
最小权限原则非常适用于 Quick 管理。用户应仅拥有其特定工作职能所需的访问权限。降级用户角色是执行最小权限的关键部分。当用户的职责不再需要创作或管理能力时，应相应降低其角色，以最大限度地减少安全攻击面。
Quick 的定价也是基于角色的：Author 和 Admin 按每用户固定月费付费，而 Reader 则采用基于会话的定价。对于被预置为 Author 却只消费仪表板的用户，组织可以通过将其调整为 Reader 角色来大幅降低成本。有关当前定价详情，请参阅 Amazon Quick 定价页面.
要获得超越 Amazon Quick 内置角色的更精细控制，可考虑将角色分配与 Custom Permissions相结合，以限制角色层级内的特定能力。Amazon Quick 与 AWS Identity and Access Management (IAM) 的集成为基本角色系统提供了额外的权限边界。
本文的范围
尽管具体步骤取决于用户身份类型，但本文主要针对 Amazon Quick Identity 用户（也称为 Quick 托管用户）。通过 IAM Identity Center 或 Active Directory 进行身份验证的用户的角色变更通常通过其外部身份提供商的组映射来管理。如果您的环境使用 IAM Identity Center，角色降级可通过将用户从一个 IdC 组移动到另一个组来处理（例如，从 Quick-Admins 组移动到 Quick-Readers 组）。无需分步降级序列。
尽管 Amazon Quick 控制台并未为所有角色转换提供直接降级路径（具体而言，您无法通过控制台界面直接从 Admin 降级为 Reader，或从 Author 降级为 Reader），但存在两种可靠的解决方案：手动删除并重建的方法，以及使用 AWS Command Line Interface (AWS CLI) 的方法。我们将逐步介绍这两种技术，帮助您在团队发展过程中保持适当的访问管理。
先决条件
在开始之前，请确保您拥有一个具有 Amazon Quick 管理员访问权限的有效 AWS 账户。如果您计划使用 CLI 方法，您需要在您的机器上 安装并配置 AWS CLI 。准备一份需要变更角色的用户列表也很有帮助。
了解 Amazon Quick 角色
Amazon Quick 提供两个订阅层级，具有不同的角色集：
| 订阅 | 角色 | 功能 |
| Amazon Quick Enterprise | Admin Pro、Author Pro、Reader Pro | 完整 BI + AI 功能（agents、topics、Q&A、stories、生成式摘要） |
| Amazon Quick Sight （仅 BI） | 管理员、作者、读者 | 传统 BI 的创建与使用 |
控制台没有提供从任何作者层级直接降级到任何读者层级的方法。 update-user API 也实施同样的限制，会以“你不能降级用户角色”的错误拒绝直接降级。
以下截图显示了 Amazon Quick Suite 用户管理页面，控制台没有提供直接将用户从作者层级降级到读者层级的控制选项。这说明了为什么需要本文中的方法。
图 1：Amazon Quick Suite 用户管理页面
CLI 逐级降级方法对 仅 BI 的旧版角色 （管理员、作者、读者）可以可靠地工作，遵循以下顺序：
管理员 > 作者 > 受限读者 > 读者
同样的顺序也适用于 Pro 用户，只要中间步骤使用旧版角色。例如，Author Pro > Author > Restricted Reader > Reader Pro 可以成功完成。
进行更改前的重要注意事项
通过任一方法实施角色更改时，有几点重要因素需要牢记。首先，在进行更改之前，请验证您列表中的所有用户当前是否为 Admin 或 Author 用户。尝试降级已具有较低权限的用户可能会导致错误。即使使用 CLI 方法，资源所有权问题仍然适用。被降级的用户将无法再编辑他们以前拥有的资源。对于使用 CLI 方法的较大型组织，请考虑从 CSV 文件加载用户电子邮件地址，而不是将其硬编码。如果您使用 AWS CloudShell 而非本地 CLI 安装，则可以省略 AWS Region 指定，因为 AWS CloudShell 会自动使用您当前的控制台 Region 上下文。
转让资产所有权（请先执行此操作）
在删除用户之前，必须确保其拥有的任何资产（例如仪表板、数据集和分析）都已妥善重新分配。这可以防止中断并避免留下孤立的资源。如果该用户是 Author，请验证其是否拥有任何数据集或仪表板，并按照此处描述的相同资产重新分配步骤操作。在 Amazon Quick 中处理资产所有权转让有三种主要方式。
选项 1：主动将所有权转让给另一位管理员
最可控的方法是在删除用户之前手动重新分配所有权。为此，请进入 Quick 中的每个资产，选择 Share，并指定另一位管理员作为共同所有者。使用此方法，您可以准确确定由谁接管每个资源，这对于高影响的仪表板或数据集尤其有用。虽然这在大型环境中可能很耗时，但它使您能够灵活地根据团队的结构和职责分配资产。
以下屏幕截图显示了资产的 Share 对话框，您可以在其中添加另一位管理员作为共同所有者，以便在删除原始用户之前完成所有权转让。
图 2：将资产所有权转让给另一位用户
选项 2：使用 Admin 页面上的 Amazon Quick 批量资产转让功能
如果该用户拥有许多资产，手动方法可能效率低下。在这种情况下，您可以使用 Quick 的 Admin 部分中提供的 Manage assets 功能。借助此工具，管理员可以执行批量所有权转让，或一次更新多个资产的共享权限。它显著简化了重新分配流程，特别是在用户离职或管理组织变更时。有关如何使用此功能的更多详细信息，请参阅官方 Managing assets in Amazon Quick 文档。
选项 3：与 Quick 用户组共享资产
另一种有效的策略是与用户组共享资产。对于 Quick Identity 用户，您可以创建一个 Quick 组，添加相关团队成员，并与该组（而不是个人用户）共享仪表板或数据集。如果您的账户集成了 IAM Identity Center 或 Active Directory，则等效的组会在这些系统中创建和管理，并且 Quick 会使用这些外部组（而非 Quick 管理的组）进行访问控制。这样，即使删除了特定用户，对共享资源的访问仍然保持不变。这是一种具有弹性的方法，可减少将来重新分配所有权的需要，并有助于在动态团队中保持一致的访问权限。
手动方法：删除并重新创建用户
虽然不是最有效的方法，但对于无法使用 CLI 的环境来说，手动删除并重新创建是一种可选方案。此方法涉及完全删除管理员用户，然后以 reader 权限重新创建该用户。将 Author 降级为 Reader 时也适用同样的手动方法，尽管通常在资产所有权方面的复杂问题较少。
由于此方法需要先删除用户账户，然后再以较低角色重新创建它，因此必须仔细准备，以避免丢失宝贵资源并中断工作流程。请确保在继续之前已完成上一节中描述的资产所有权转让。
步骤 1：删除管理员用户
转让所有资源的所有权后，登录 AWS Management Console 并导航到 Amazon Quick 服务。从那里，选择您的个人资料图标，然后选择 Manage Quick，接着选择 Manage users。找到您想要降级的管理员用户后，选择其姓名旁边的删除图标，并在出现提示时确认删除。这会完全移除他们对系统的当前访问权限。
如果您事先没有转让所有资源，Quick 会显示一个所有权转让对话框。该对话框提示您选择另一位管理员来接收该用户所有资源的所有权。从列表中选择一位合适的管理员，然后通过选择以下选项确认转让： 删除并转移。这种内置的转移机制有助于防止资源孤立，但会将所有内容转移给单一管理员。如需更细粒度的控制，请使用前面提到的主动方法，将资源有策略地分配给不同的团队成员。
如果你跳过了主动转移，下图所示的删除对话框可让你在该账户被移除前，将该用户的所有资源重新分配给单一管理员。
图3：用户删除期间的内置资源转移
步骤2：以Reader角色重新创建用户
成功删除用户后，请留在“用户”页面并选择 邀请用户。输入用户的电子邮件地址并选择 读者 从可用选项中选择角色。发送邀请，允许用户以其新的、限制更多的权限重新加入 Quick。
步骤 3:验证角色更改
用户接受邀请后:
- 确认其权限已更新为 读者.
- 验证他们只能查看仪表板和报表。
- 确认他们无法修改或创建内容。
CLI 方法：角色降级过渡（推荐）
如果您更倾向于使用 AWS CLI 或 AWS CloudShell，可以通过编程方式更改用户的角色。由于 Quick 要求角色更改按特定顺序进行，您无法从任意 Admin 直接切换到任意 Reader。相反，您必须经过中间角色逐步过渡。
重要说明
- 替换
<your-account-id>以及您的 AWS 账户 ID。 - 替换
<user-name>带有该用户的用户名。 - 替换
<user-email>以及用户的电子邮件地址。 - 如果您在 CloudShell 之外使用 AWS CLI，请指定
--region参数。 - 该
--role该值必须与 API 角色名称完全一致（参见上表）。
示例：旧版路径（Admin 到 Reader）
第1步： 将角色从管理员（Admin）更改为作者（Author）：
aws quicksight update-user \
--aws-account-id <your-account-id> \
--user-name <user-name> \
--namespace default \
--email <user-email> \
--role AUTHOR第2步： 将角色从 Author 更新为 Restricted Reader：
aws quicksight update-user \
--aws-account-id <your-account-id> \
--user-name <user-name> \
--namespace default \
--email <user-email> \
--role RESTRICTED_READER步骤 3: 将角色从受限读者更改为读者：
aws quicksight update-user \
--aws-account-id <your-account-id> \
--user-name <user-name> \
--namespace default \
--email <user-email> \
--role READER降级之后：审查限制配置文件与自定义权限
角色变更不会自动调整限制配置文件（Limit Profiles）或自定义权限配置文件。二者独立于用户的角色持久存在，任何降级后你都应审查它们。
- 限制配置文件（Limit Profiles） 控制每用户在索引存储和代理小时数等资源上的上限。如果被降级用户此前分配的是适合其原先 Admin 或 Author 角色的配置文件，请重新分配适合 Reader 的限制配置文件，以避免过度分配资源。详情请参见 Limit Profiles 文档 。
- 自定义权限（Custom Permissions） 限制角色层级内的特定能力。分配给 Author 的配置文件在 Reader 上可能不会按预期表现。你可以在最后的 CLI 步骤中取消应用它（使用
--unapply-custom-permissions），或分配一个专为 Reader 层级设计的配置文件。
更新多个用户的脚本
使用以下脚本来更新多个用户。
#!/bin/bash
# Define AWS account details
AWS_ACCOUNT_ID="<your-account-id>"
REGION="<your-region>"
# Load users from file (format: username,email per line)
# Lines starting with # are treated as comments
INPUT_FILE="users_to_downgrade.txt"
while IFS=',' read -r username email; do
# Skip comments and empty lines
[[ "$username" =~ ^#.*$ || -z "$username" ]] && continue
echo "Processing user: $username"
# Role transition stages
for ROLE in AUTHOR RESTRICTED_READER READER; do
RESULT=$(aws quicksight update-user \
--aws-account-id "$AWS_ACCOUNT_ID" \
--user-name "$username" \
--namespace default \
--email "$email" \
--role "$ROLE" \
--region "$REGION" 2>&1)
if [ $? -ne 0 ]; then
echo " ERROR at $ROLE: $RESULT"
break
fi
echo " Transitioned to $ROLE"
sleep 3
done
echo "Role update completed for $username."
done < "$INPUT_FILE"
echo "All user role updates processed!"脚本功能
此脚本执行以下操作：
- 从外部文件读取用户名和电子邮件地址（支持以 # 开头的注释）。
- 分三个阶段更新角色：Admin > Author > Restricted Reader > Reader。
- 错误处理会在任何步骤失败时停止该用户的角色转换。
- sleep 命令用于留出时间让更改生效。
运行脚本时需要注意的几点：
- 在运行前确认用户当前是 Admin 或 Author 用户。
- 请使用实际的 Quick 用户名，在联合身份环境中它可能与电子邮件前缀不同。
- 在 AWS CloudShell 中无需指定 Region。
- 您可以修改该脚本，以便从以下内容的 CSV 导出文件中加载用户：
list-users.
用户访问管理的最佳实践
为确保您的 Quick 环境安全且井然有序，请遵循以下最佳实践：
- 定期审查用户角色（每月或每季度审计）。
- 在更改角色之前转移资源所有权。
- 遵循最小权限原则。
- 使用 Custom Permissions 配置文件在角色层级内实现细粒度控制。
- 与群组而非个人共享资源，以增强韧性。
- 使用 AWS Identity and Access Management 作为额外的权限边界。
清理
完成用户角色更改后：
- 删除任何测试用户。
- 确认没有残留的非预期资源。
- 删除临时的 CLI 脚本或用户列表文件。
- 再次核对最终的用户权限。
结论
在这篇文章中，我们探讨了在 Amazon Quick 中降级用户角色的两种方法：手动删除并重新创建，以及灵活的 AWS CLI 方法。这些策略可帮助您高效且安全地管理团队访问权限。
对于使用 IAM Identity Center 的环境，角色更改通过 IdC 群组重新分配来管理，无需本文所述的逐级降级步骤。如需额外的治理控制，请探索 Custom Permissions 以实现功能级别的限制，以及 Restricted Folders 以实现内容级别的隔离。
相关资源
- Managing User Access in Amazon Quick
- Managing Assets in Amazon Quick
- Custom Permissions Profiles
- AWS IAM Best Practices
- AWS Business Intelligence Blog
我们很想了解您在用户管理方面的经验。您的组织如何处理 Quick Suite 中的角色转换？您是否开发了自定义脚本或流程来简化这些更改？欢迎在评论中分享您的想法和遇到的挑战。