PAYATHON 2026

AWS SSO 能否管理未加入组织或分属不同组织的客户 AWS 账户？

技术老齐

结论

AWS SSO 已更名为 AWS IAM Identity Center。同一个 IAM Identity Center 组织实例只能通过原生 AWS 账户权限分配功能，管理其所在 AWS Organizations 组织内的账户。未加入任何组织或属于其他组织的客户账户，都不在这个管理范围内。官方说明

要在集中登录后访问多个独立客户账户，可以先通过自己的身份系统登录，再使用 AWS STS AssumeRole 获取各客户账户中 IAM 角色的临时凭证。客户账户可以保留原有组织归属，无须加入你的组织。

服务多个独立公司时，建议优先使用客户现有的身份管理方式；需要统一入口时，再配置跨账户角色。日常访问应逐步停止使用共享用户名、密码和长期访问密钥。

为什么独立账户也能启用 Identity Center，却不能这样统一管理？

IAM Identity Center 分为组织实例和账户实例，适用范围不同：

实例类型适用范围
Organization instance，组织实例支持所在组织内的 AWS 多账户访问管理
Account instance，账户实例用于单个账户中受支持的应用访问，不能替代组织实例提供 AWS 多账户权限分配

在每个独立客户账户里启用 account instance，无法将它们汇总到一个 AWS 账户访问门户。根据 AWS 官方说明，account instance 主要管理同一账户和区域内受支持应用的用户及组访问。账户实例说明

如何选择访问方式？

客户已有身份管理体系时，使用客户提供的个人身份

如果客户已经使用 IAM Identity Center 或其他身份提供商，应由客户为你开通个人访问权限，分配适当的角色或 permission set。

客户可以按自己的流程审批权限、记录操作，并在合作结束时撤销访问。你可能需要分别使用各客户的登录入口，但无须再保存他们的共享密码。

需要统一管理多个客户时，使用跨账户 IAM 角色

可以在自己控制的 AWS 账户中建立统一登录入口，例如使用自己组织的 IAM Identity Center。各客户在自己的账户中创建角色，并将你指定的源身份设为受信任身份。

访问步骤如下：

  1. 通过自己的身份系统登录。
  2. 获取自己账户中源角色的临时凭证。
  3. 调用 AssumeRole，切换到客户账户中的角色。
  4. 使用客户角色允许的权限执行操作。

跨账户角色不要求两个账户属于同一个组织。能否访问，取决于目标角色的信任策略、源身份的权限及相关策略限制。AWS 官方的第三方访问指南也采用这种授权方式。第三方账户访问指南

独立账户也可以直接配置与身份提供商的联合登录，但每个客户账户仍需单独建立信任关系并授予角色权限。

跨账户访问的配置示例

本例使用自己的 IAM Identity Center 登录，再通过 AWS CLI 访问客户账户。

假设：

  • 你的源账户 ID 是 111111111111。
  • 客户账户 ID 是 222222222222。
  • 源账户中已分配名为 ConsultantAccess 的 permission set。
  • 客户创建名为 ClientDeveloper 的 IAM 角色。

账户 ID、角色 ARN、区域和 External ID 均为示例值，部署前必须替换。

1. 客户创建目标角色并配置信任策略

以下策略仅信任指定的源角色，并要求请求携带匹配的 External ID：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/aws-reserved/sso.amazonaws.com/ap-southeast-1/AWSReservedSSO_ConsultantAccess_0123456789abcdef"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "7d2c91a8-4c38-4ec0-9dbb-83750b3ea210"
        }
      }
    }
  ]
}

Principal 必须填写源账户中实际存在的 IAM 角色 ARN。不要使用 GetCallerIdentity 返回的 arn:aws:sts::...:assumed-role/... 会话 ARN。

IAM Identity Center 生成的角色名称带有唯一后缀，路径也与其所在区域有关，应从 IAM 中复制实际 ARN。如果删除该 permission set 在源账户中的全部分配，之后重新分配时，角色 ARN 可能改变，届时需要同步更新客户的信任策略。角色 ARN 格式及变更说明

信任策略只决定谁能承担角色。客户还必须为 ClientDeveloper 附加权限策略，明确允许访问的资源和执行的操作。开发、只读检查和生产部署通常应分别授权。

2. 为源身份授予 sts:AssumeRole 权限

在源账户的 ConsultantAccess permission set 中加入以下权限，并将更新预置到源账户：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/ClientDeveloper"
    }
  ]
}

跨账户访问需要双方授权：目标角色必须信任源身份，源身份也必须有权对目标角色调用 AssumeRole。AssumeRole 权限说明

3. 配置 AWS CLI profile

使用 AWS CLI v2 配置源账户的 SSO profile：

aws configure sso --profile consultant

按照向导填写自己的登录入口和 IAM Identity Center 区域，选择源账户及 ConsultantAccess，完成 AWS CLI 的 Identity Center 登录配置。配置说明

然后在 ~/.aws/config 中追加客户 profile：

[profile client-a]
source_profile = consultant
role_arn = arn:aws:iam::222222222222:role/ClientDeveloper
external_id = 7d2c91a8-4c38-4ec0-9dbb-83750b3ea210
duration_seconds = 3600
region = ap-southeast-1

登录并检查当前身份：

aws sso login --profile consultant
aws sts get-caller-identity --profile client-a

调用成功后，确认返回的 Account 是客户账户 ID，Arn 对应客户的 ClientDeveloper 角色会话。

可以为其他客户分别配置 profile，指定各自的目标角色 ARN 和 External ID。AWS CLI 会根据 source_profile 调用 STS，无须在配置文件中保存客户的长期访问密钥。角色 profile 配置说明

控制台访问和 External ID 有什么限制？

如果主要通过浏览器访问，使用客户自己的 IAM Identity Center 或直接联合登录通常更方便。

AWS Management Console 也支持跨账户 Switch Role，但普通切换角色界面不能传递 ExternalId。上例中要求 External ID 的角色无法直接通过该界面切换，需要使用支持此参数的 CLI/API，或专门的联合登录实现。控制台切换角色限制

配置时，可以将人员访问与自动化服务访问分开：

  • 人员使用客户提供的联合身份或经客户审核的访问角色。
  • 代多个客户执行任务的服务使用独立角色，并为每个客户账户分配唯一 External ID。

External ID 主要用于防止 confused deputy problem，即共享服务被诱导访问错误客户的资源。它不是密码，也不能代替源身份认证、精确的信任策略或 MFA。服务端必须根据已验证的客户身份，选择对应的角色和 External ID。External ID 官方指南

管理独立客户账户时还应注意什么？

  • 客户应掌握账户的最终控制权。代客户创建账户前，应约定账户归属，并使用客户控制的邮箱、恢复渠道和账单资料。客户还需保留独立的管理员及应急访问能力。
  • 不要仅为方便登录，就把所有客户账户加入自己的 Organizations。组织归属还涉及账单和治理安排，应根据业务关系决定。
  • 每位工作人员都应使用可识别的个人身份，并启用 MFA。避免多人共用管理员用户，生产管理权限按需要单独授予。
  • 保留 CloudTrail 审计记录，将源身份、AssumeRole 事件和目标角色会话关联起来。合作结束时，应撤销信任和权限；需要立即终止访问时，还应处理已有会话。
  • 从一个角色再承担另一个角色属于 role chaining，这类会话最长为一小时。即使提高目标角色的最大会话时长，也不能突破该限制。会话时长说明
  • 遇到 AccessDenied 时，除了两侧角色策略，还需检查适用的 SCP、permissions boundary、资源策略及显式拒绝条件。

密码管理器仍可用于受控保存必要的应急凭据。日常人员访问应优先使用联合身份和临时凭证，这也符合 AWS 的 IAM 安全最佳实践。IAM 安全最佳实践

有哪些 AWS 官方资料值得参考？

Access to AWS accounts owned by third parties 与这个场景最直接相关，介绍了第三方角色授权和 External ID 的使用。

白皮书 Organizing Your AWS Environment Using Multiple Accounts 介绍账户隔离、组织结构和治理，主要面向企业自身的多账户环境。用于独立客户场景时，仍需保留客户之间的所有权与治理边界。

人员身份管理可参考 AWS Well-Architected Framework：身份验证，其中涵盖集中身份提供商、临时凭证和凭据审查等实践。

备注：内容仅供参考。