AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

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

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

重要

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

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

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

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

注意

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

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

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

    注意

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

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

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

  4. 创建完角色后,您向 Example Corp 提供该角色的 Amazon 资源名称 (ARN)。

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

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

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

为什么需要使用外部 ID?

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

混淆代理人问题

为了继续上一个示例,Example Corp 需要访问您的 AWS 账户中的某些资源。但除了您之外,Example Corp 还有许多其他客户,因此它需要一种方法来访问每个客户的 AWS 资源。Example Corp 请求来自每个客户的角色 ARN,而不是要求其客户提供其 AWS 账户访问密钥 (这些密钥是永不应共享的机密信息)。但是,另一个 Example Corp 客户可能能够猜测或获取您的角色 ARN。该客户可通过 Example Corp 使用您的角色 ARN 来获取对您的 AWS 资源的访问权限。这种形式的权限提升称为“混淆代理人”问题。

下图阐明了混淆代理人问题。

 混淆代理人问题的描述。

此图假定:

  • AWS1 是您的 AWS 账户。

  • AWS1:ExampleRole 是您账户中的一个角色。此角色的信任策略通过将 Example Corp 的 AWS 账户指定为可代入该角色的账户来信任 Example Corp。

将发生以下情况:

  1. 在您开始使用 Example Corp 的服务时,您将向 Example Corp 提供 AWS1:ExampleRole 的 ARN.

  2. Example Corp 使用该角色 ARN 获取临时安全凭证以访问您的 AWS 账户中的资源。这样一来,您将信任 Example Corp 作为可代表您执行操作的“代理人”。

  3. 另一个 AWS 客户也开始使用 Example Corp 的服务,而且此客户还为 Example Corp 提供了 AWS1:ExampleRole 的 ARN 以供其使用。另一个客户可能已了解或猜到已不是机密信息的 AWS1:ExampleRole

  4. 当另一个客户要求 Example Corp 访问 (它声称的) 其账户中的 AWS 资源时,Example Corp 使用 AWS1:ExampleRole 访问您的账户中的资源.

这就是其他客户可对您的资源进行未授权访问的方式。由于此客户能够诱使 Example Corp 无意中操作您的资源,因此 Example Corp 现在是一个“混淆代理人”。

外部 ID 如何防止责任混淆问题?

您通过在角色的信任策略中包含 ExternalID 条件检查来解决混淆代理人问题。“代理人”公司会将每个客户的唯一外部 ID 值插入 AWS 凭证的请求中。该外部 ID 是一个客户 ID 值,该值在 Example Corp 的客户中必须唯一,且不受 Example Corp 客户的控制。这就是您从 Example Corp 获取该 ID 且不能自行提供该 ID 的原因。这有助于防止一个客户成功模仿另一个客户。Example Corp 始终插入客户的已分配外部 ID,因此您绝不会看到来自 Example Corp 的带有您的外部 ID 以外的任何外部 ID 的请求。

在我们的方案中,假设 Example Corp 为您提供的唯一标识符是“12345”,而为另一个客户提供的标识符是“67890”。这些标识符已针对此方案进行简化。通常,这些标识符为 GUID。假定这些标识符在 Example Corp 的客户之间是唯一的,它们将是用于外部 ID 的有意义的值。

Example Corp 将向您提供外部 ID 值“12345”。然后,您必须将一个 Condition 元素添加到角色的信任策略,该策略要求 sts:ExternalID 值为 12345,如下所示:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "12345"}} } }

此策略中的 Condition 元素允许 Example Corp 仅在 AssumeRole API 调用包括外部 ID 值“12345”时担任该角色。Example Corp 确保,只要它代表客户代入角色,就会始终在 AssumeRole 调用中包括客户的外部 ID。即使另一个客户向 Example Corp 提供您的 ARN,也无法控制 Example Corp 包括在其发送给 AWS 的请求中的外部 ID。这有助于防止未经授权的客户获取对您的资源的访问权限,如下图所示。

 如何缓解混淆代理人问题。
  1. 和之前一样,在您开始使用 Example Corp 的服务时,您将向 Example Corp 提供 AWS1:ExampleRole 的 ARN。

  2. 在 Example Corp 使用该角色 ARN 来担任角色 AWS1:ExampleRole 时,Example Corp 将在 AssumeRole API 调用中包含您的外部 ID (“12345”)。该外部 ID 与角色的信任策略匹配,因此 AssumeRole API 调用将成功,并且 Example Corp 将获取用于访问您的 AWS 账户中的资源的临时安全凭证。

  3. 另一个 AWS 客户也开始使用 Example Corp 的服务,而且如之前一样,此客户还为 Example Corp 提供了 AWS1:ExampleRole 的 ARN 以供其使用。

  4. 但这一次,在 Example Corp 尝试担任角色 AWS1:ExampleRole 时,它提供了与其他客户关联的外部 ID (“67890”)。该其他客户无法更改此外部 ID。Example Corp 这样做是因为另一个客户请求使用该角色,因此“67890”表示 Example Corp 正在其中操作的环境。因为您已将具有您自己的外部 ID (“12345”) 的条件添加到 AWS1:ExampleRole 的信任策略,所以 AssumeRole API 调用将失败。该其他客户不能对您的账户中的资源进行未经授权的访问 (由图中的红色“X”表示)。

该外部 ID 帮助阻止任何其他客户诱使 Example Corp 无意中访问您的资源 - 它缓解了混淆代理人问题。

我何时应使用外部 ID?

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

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

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

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

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