如何在向第三方授予对 Amazon 资源的访问权时使用外部 ID - Amazon Identity and Access Management
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

如何在向第三方授予对 Amazon 资源的访问权时使用外部 ID

有时,您需要向第三方提供对您的 Amazon 资源的访问权 (提供访问权)。此方案的一个重要方面是外部 ID,外部 ID 是一条可选信息,您可在 IAM 角色信任策略中使用该信息来指定谁能代入该角色。

重要

Amazon 不会将该外部 ID 作为秘密信息。您在 Amazon 中创建访问密钥对或密码这类秘密信息后,您无法再次查看它们。有权查看角色的任何人都可以看到该角色的外部 ID。

在您支持多个客户拥有不同 Amazon 账户的多租户环境中,我们建议每个 Amazon Web Services 账户 使用一个外部 ID。此 ID 应该是第三方生成的随机字符串。

要在代入角色时需要提供外部 ID 的第三方,请使用您选择的外部 ID 来更新角色的信任策略。

要在代入角色时提供外部 ID,请使用 Amazon CLI 或 Amazon API 来代入该角色。有关更多信息,请参阅 STS AssumeRole API 操作或 STS assume-role CLI 操作。

例如,假设您决定聘请一家名为 Example Corp 的第三方公司来监控您的 Amazon Web Services 账户 并帮助优化成本。为跟踪您的日常开支,Example Corp 需要访问您的 Amazon 资源。Example Corp 也可监控其他客户的很多其他 Amazon 账户。

请勿向 Example Corp 提供对您的 Amazon 账户中的 IAM 用户及其长期凭证的访问权限。请使用 IAM 角色 角色及其临时安全凭证。IAM 角色提供了一种机制,可允许第三方访问您的 Amazon 资源而无需共享长期凭证(例如,IAM 用户的访问密钥)。

您可使用 IAM 角色在您的 Amazon Web Services 账户 和 Example Corp 账户之间建立信任关系。建立这种关系后,Example Corp 账户的成员可以调用 Amazon Security Token Service AssumeRole API 以获取临时安全凭证。然后,Example Corp 成员可以使用这些凭证访问您的账户中的 Amazon 资源。

注意

有关可调用来获取临时安全凭证的 AssumeRole 和其他 Amazon API 操作的更多信息,请参阅请求临时安全凭证

以下是此方案的更多详细信息:

  1. 您聘请了 Example Corp,此公司将为您创建唯一客户标识符。他们为您提供此唯一客户 ID 及其 Amazon Web Services 账户 账号。您需要此信息来在下一步中创建 IAM 角色。

    注意

    Example Corp 可使用其想用于 ExternalId 的任何字符串值,只要该值对于每个客户来说都是唯一的。该值可以是客户账号,甚至可以是一个随机字符串,只要没有两个客户拥有相同的值即可。该值不是“机密的”。Example Corp 必须向每个客户提供 ExternalId 值。关键的一点是,该值必须由 Example Corp 生成,而不是其客户生成,从而确保每个外部 ID 是唯一的。

  2. 您登录到 Amazon 并创建 IAM 角色,该角色可向 Example Corp 提供对您的资源的访问权。与任何 IAM 角色类似,该角色具有两个策略:权限策略和信任策略。该角色的信任策略规定谁可担任该角色。在我们的示例方案中,该策略将 Example Corp 的 Amazon Web Services 账户 账号指定为 Principal。这允许来自此账户的身份担任该角色。此外,将 Condition 元素添加到信任策略。此 Condition 测试 ExternalId 上下文密钥,以确保它与 Example Corp 的唯一客户 ID 一致。例如:

    "Principal": {"AWS": "Example Corp's Amazon Web Services 账户 ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. 该角色的权限策略指定该角色允许某个人执行哪些操作。例如,您可以规定该角色允许某人仅管理您的 Amazon EC2 和 Amazon RDS 资源,但不能管理您的 IAM 用户或组。在我们的示例方案中,您使用权限策略为 Example Corp 授予您的账户中的所有资源的只读访问权限。

  4. 创建完角色后,您向 Example Corp 提供该角色的 Amazon Resource Name (ARN)。

  5. 当 Example Corp 需要访问您的 Amazon 资源时,该公司的某人可调用 Amazon sts:AssumeRole API。该调用包括要担任的角色的 ARN 以及与其客户 ID 对应的 ExternalId 参数。

如果发出请求的人使用的是 Example Corp 的 Amazon Web Services 账户,并且角色 ARN 和外部 ID 是正确的,则请求成功。然后,该请求提供临时安全凭证,Example Corp 可使用这些凭证访问您的角色允许访问的 Amazon 资源。

换句话说,当角色策略包括外部 ID 时,任何需要担任该角色的人都必须是该角色中的主体,还必须包括正确的外部 ID。

为什么要使用外部 ID?

抽象地说,外部 ID 允许正担任该角色的用户断言其运行于的环境。它还为账户所有者提供一种方法来允许仅在特定情况下担任该角色。外部 ID 的主要功能是解决并防止 混淆代理人问题

我何时应使用外部 ID?

在以下情况下使用外部 ID:

  • 您是 Amazon Web Services 账户 所有者并且已为将访问其他 Amazon Web Services 账户 以及您的账户的第三方配置角色。您应要求第三方提供其在担任您的角色时包含的外部 ID。然后,在您角色的信任策略中检查该外部 ID。这样做可确保外部方仅在代表您执行操作时才能担任您的角色。

  • 在前述情况下,您代表不同客户 (如 Example Corp) 担任角色。您应该为每个客户分配一个唯一的外部 ID 并指导他们将该外部 ID 添加到其角色的信任策略。然后,您必须确保在担任角色的请求中始终包含正确的外部 ID。

    您可能已为您的每个客户提供一个唯一标识符,而且此唯一 ID 足以用作外部 ID。该外部 ID 不是您要明确创建或分别跟踪所需的特殊值 (仅用于此目的)。

    您应始终在您的 AssumeRole API 调用中指定外部 ID。此外,在客户为您提供角色 ARN 时,请测试是否能在带有/不带正确外部 ID 的情况下担任该角色。如果可在没有正确外部 ID 的情况下担任角色,则不要在您的系统中存储该客户的角色 ARN。等待该客户将角色信任策略更新为要求提供正确的外部 ID。这样一来,您帮助您的客户执行了正确的操作,并帮助您和客户避免了混淆代理人问题。