在亚马逊云科技中授予跨账户访问权限的四种方法

随着您的亚马逊网络服务 (亚马逊云科技) 环境的发展，您可能需要授予跨账户访问资源的权限。这可能是出于各种原因，例如启用跨多个亚马逊云科技账户的集中操作、在组织内的团队或项目之间共享资源，或者与第三方服务集成。但是，授予跨账户访问权限需要仔细考虑您的安全性、可用性和可管理性要求。

在这篇博客文章中，我们探讨了使用基于资源的策略授予跨账户访问权限的四种不同方法。每种方法都有其独特的权衡取舍，优秀选择取决于您的特定要求和用例。

评估授予跨账户访问权限的不同技术

跨账户访问由 Amazon Identity and Access Management (IAM) 中基于身份的策略和基于资源的策略授予。基于身份的策略附加到 IAM 角色，而基于资源的策略则附加到诸如亚马逊简单存储服务 (Amazon S3) 存储桶和亚马逊云科技密钥管理服务 (Amazon KMS) 密钥等资源。基于资源的策略要求您指定一个或多个允许访问资源的委托人（IAM 用户或角色）。

您选择如何在基于资源的策略中指定委托人会影响解决方案的保密性和可用性的某些方面。了解这种影响并为您的用例做出正确的权衡是本文的重点。

示例场景

假设您的亚马逊云科技账户（账户 A）中有一个 S3 存储桶，需要由另一个亚马逊云科技账户（账户 B）中的不同委托人访问该存储桶。在本场景中，我们假设账户 B 中的委托人在其基于身份的策略中拥有对 S3 的必要访问权限，我们将重点在账户 A 中制定基于资源的策略。虽然此处介绍的方法使用 Amazon S3，但所讨论的概念适用于支持基于资源的策略的所有亚马逊云科技服务。在以下各节中，我们将介绍在这种情况下授予跨账户访问权限的四种不同方法，并讨论每种方法的权衡利弊。

方法 1：使用基于资源的策略的 Principal 元素授予对特定 IAM 角色的访问权限

在此示例中，您使用 S3 存储桶策略授予对账户 B 中特定 IAM 角色 (RoleFromAccountB) 的访问权限，方法是在账户 A 的策略Principal元素中指定 IAM 角色的亚马逊资源名称 (ARN)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoleInThePrincipalElement",
      "Principal": {
        "亚马逊云科技": "arn:aws:iam::111122223333:role/RoleFromAccountB"
      },
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-account-a/*"
    }
  ]
}

使用此存储桶策略，如果账户 B 中的某人删除或重新创建了该角色 (RoleFromAccountB)，则该角色将无法再访问该amzn-s3-demo-bucket-account-a存储桶，即使使用相同的名称重新创建该角色也是如此。原因是，当您保存此策略时，角色 ARN 会映射到角色的唯一 ID，如下所示：AROADBQP57FF2AEXAMPLE。如果您在删除基于资源的策略引用的角色后查看这些策略，则会在这些策略的Principal元素中看到角色标识符。

这种行为是故意的。基于资源的策略仅允许您在创建策略时设置为委托人的角色的特定实例。如果您删除角色，但忘记更新基于资源的策略以移除该角色，这有助于防止意外访问您的资源。这种行为还可能导致可用性风险，因为角色 (RoleFromAccountB) 在重新创建时将具有新的唯一 ID，并且将无法再访问存储桶。重新创建角色的原因有很多，包括在使用基础设施等工具即代码时意外创建角色。

在以下情况下，您可以考虑选择此方法：

您拥有账户 A 和账户 B 中的角色，可以控制这些角色的创建和删除。
您希望在删除指定角色 (RoleFromAccountB) 后，账户 A 中的基于资源的策略停止授予访问权限。
如果删除角色 (RoleFromAccountB)，则应优先考虑细粒度访问控制，而不是潜在的可用性问题。

方法 2：使用基于资源的策略的 Principal 元素授予账户访问权限

在此示例中，您在基于资源的策略的Principal元素中向特定账户授予访问权限。账户 A 的这一基于资源的策略允许账户 B 中的任何用户或角色拥有基于身份的策略，该策略授予他们读取对象的权限。

注意：可以在Principal元素"Principal": {"亚马逊云科技": "arn:aws:iam::111122223333:root"}中使用"Principal": {"亚马逊云科技": "111122223333"}或。它们是等效的，长格式 ARN 不代表 root 用户。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccountInThePrincipalElement",
      "Principal": {
        "亚马逊云科技": "111122223333"
      },
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-account-a/*"
    }
  ]
}

这种基于资源的策略有助于避免方法 1 中讨论的潜在可用性问题。如果在账户 B 中重新创建了需要访问存储桶的角色，则在重新创建该角色后，该角色仍将具有访问权限。这是因为您没有在Principal元素中指定角色，而是指定帐户。如果您使用方法 2，则必须能够轻松地将访问控制决策委托给该账户的所有者。

这种方法明确将访问控制决策委托给其他账户（账户 B）中的 IAM。如果基于身份的政策允许，账户 B 中的委托人可以访问此存储桶。

在以下情况下，您可以考虑选择此方法：

您需要向账户 B 中的许多委托人授予访问权限。
您想在委托人所在的账户（账户 B）中委托访问决定。
与精细的访问控制相比，您优先考虑易于管理和可用性。

方法 3：使用亚马逊云科技: PrincipalARN 条件向特定 IAM 角色授予访问权限

此方法在方法 2 的基础上进行了扩展，并添加了仅向特定 IAM 角色授予访问权限的条件。与方法 2 类似，您使用账号作为Principal元素的值，但也可以使用aws:PrincipalArn条件键来限制账户 B 中的特定委托人的访问权限。

亚马逊云科技: PrincipalARN 条件密钥是一个全局条件密钥，它将提出请求的委托人的 ARN 与您在策略中指定的 ARN 进行比较。对于 IAM 角色，请求上下文返回角色的 ARN，而不是担任该角色的用户的 ARN。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccountInPrincipalAndRoleInPrincipalArn",
      "Principal": {
        "亚马逊云科技": "111122223333"
      },
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-account-a/*",
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::111122223333:role/RoleFromAccountB"
        }
      }
    }
  ]
}

此策略具有与方法 2 中的政策相同的可用性优势：对该资源的访问权限将在角色重现后生效。这是因为只有在Principal元素中使用角色时，角色才会转换为其唯一标识符。在条件中使用时，它不会转换为唯一标识符。如果账户 B 中的角色 (RoleFromAccountB) 是意外或故意地重新创建的，则该策略将继续授予访问权限，因为该角色与账户 A 中基于资源的策略的条件密钥中指定的角色 ARN 相匹配。因此，方法 3 提供了一种兼顾可用性和安全性的方法。

在以下情况下，您可以考虑选择此方法：

如果重新创建aws:PrincipalArn条件密钥中指定的角色 (RoleFromAccountB)，此政策将继续向该角色授予访问权限，您对此感到满意。
您不拥有您授予访问权限的账户 B，也无法控制何时可以重新创建该角色。
您需要在可用性和机密性之间取得平衡。

方法 4：向整个 Amazon Organizations 组织授予访问权限

此方法侧重于不同的用例，不能替代前面列出的方法。如果您想与整个组织共享资源（在本示例中为 S3 存储桶），但不想与组织之外的任何人共享，请使用此方法。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessToAnEntireOrganization",
      "Principal": {
        "亚马逊云科技": "*"
      },
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-account-a/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgId": "o-12345"
        },
        "StringNotEquals": {
          "aws:PrincipalAccount": "${aws:ResourceAccount}"
        }
      }
    }
  ]
}

无法使用基于资源的策略的Principal元素来指定组织，因此您必须使用亚马逊云科技: PrincipalorGID 条件密钥来限制对特定组织的访问权限。在此策略中，您在Principal元素中指定通配符，表示任何人都可以访问存储桶。然后，该条件将 “任何人” 简化为仅属于指定组织并拥有允许他们访问的基于身份的策略的亚马逊云科技账户委托人。

然后，您可以使用策略变量添加一个额外的条件块，将aws:PrincipalAccount条件密钥与亚马逊云科技: ResourceAccount 条件密钥进行比较。这个额外的条件区块是可选的，它将拥有存储桶的账户（账户 A）排除在允许语句之外。之所以使用这个额外的条件区块，是因为账户 A 中的委托人仍然需要在其基于身份的策略中使用允许声明才能访问此存储桶。如果您选择排除此aws:PrincipalAccount比较，则账户 A 中的委托人无需在基于身份的政策中明确显示允许声明即可访问存储桶。策略评估逻辑仅要求基于身份的策略或基于资源的策略（但不能两者兼而有之），以便在委托人和资源位于同一个账户中时允许请求。

在以下情况下，您可以考虑选择此方法：