如何基于亚马逊云科技账户、OU 或组织控制对亚马逊云科技资源的访问权限

Original URL: https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/

请注意：北京和宁夏区域不支持服务控制策略（SCP）。请参阅功能可用性和实现差异部分。

Amazon Identity and Access Management（IAM）最近推出了新的条件键，可以更轻松地控制对亚马逊云科技组织边界上的资源的访问权限。亚马逊云科技建议您随着工作负载的增长设置多个账户，而且您还可以使用多个账户来隔离具有特定安全要求的工作负载或应用程序。通过使用新条件，即 aws:ResourceOrgID、aws:ResourceOrgPaths 和 aws:ResourceAccount，即可基于亚马逊云科技资源的组织、组织单位（OU）或账户定义访问控制。使用这些条件可以更方便地要求主体（用户和角色）只能访问组织内部特定边界内的资源。您可以将新条件与其他 IAM 功能相结合，限制对不属于您组织的账户的访问，以及来自这些账户的访问。

这篇文章将帮助您开始使用新的条件键。我们将显示新条件键的详细信息，并根据以下场景演示详细示例。我们还将提供参考资料和链接，以帮助您更好地了解如何建立亚马逊云科技账户的访问控制范围。

考虑一种常见情况，即您想防止 Amazon Organizations 中的主体向不属于您组织的 Amazon Simple Storage Service（Amazon S3）存储桶中添加对象。为此，您可以配置 IAM policy 以拒绝对 S3 的操作，除非 aws:ResourceOrgID 与您唯一的组织 ID 匹配。由于该策略并非只适用于单个 S3 资源，而是适用于您的整个组织，因此您可以无视控制的资源数量，便捷地保持这种安全状况。新条件为您提供工具，用以为您的 IAM 主体创建安全基准，也助您避免对无法控制的账户的资源的意外访问。您可以通过为 IAM 主体附加此策略，以将此规则应用于单个用户或角色，也可以使用 Amazon Organizations 中的服务控制策略（SCP）在您的亚马逊云科技账户中广泛应用该规则。无论 IAM policy 或 S3 存储桶策略为其授予了何种其他权限，受此策略约束的 IAM 主体只能对组织内的存储桶和对象执行 S3 操作。

关于新条件键的详细信息

您可以使用 IAM policy 中的 aws:ResourceOrgID、aws:ResourceOrgPaths 和 aws:ResourceAccount 条件键来控制您的主体可以访问的资源。下表说明了新的条件键以及这些键可以采用的值。

条件键	说明	运算符	单值/多值	值
aws:ResourceOrgID	正在访问的资源的Amazon Organizations ID	所有字符串运算符	单值键	任何Amazon Organizations ID
aws:ResourceOrgPaths	正在访问的资源的组织路径	所有字符串运算符	多值键	Amazon Organizations ID 和组织单位 ID 的组织路径
aws:ResourceAccount	正在访问的资源的亚马逊云科技账户 ID	所有字符串运算符	单值键	任何亚马逊云科技账户 ID

请注意：在这三个键当中，只有 aws:ResourceOrgPaths 是多值条件键，而 aws:ResourceAccount 和 aws:ResourceOrgID 是单值键。有关如何使用多值键的信息，请参阅 IAM 文档中的使用多个键或值创建条件部分。

资源所有者键与主体所有者键的比较

新的 IAM 条件键补充了现有的主体条件键 aws:PrincipalAccount、aws:PrincipalOrgPaths 和 aws:PrincipalOrgID。主体条件键可帮助您定义允许哪些亚马逊云科技账户、组织单位（OU）和组织访问您的资源。有关主体条件的更多信息，请参阅亚马逊云科技安全博客上的使用 IAM 与 Amazon Organizations 中的账户组共享您的亚马逊云科技资源部分。

同时使用主体键和资源键可以帮助您为亚马逊云科技主体和资源建立权限防护机制，并在继续扩展时更轻松地将数据保留在您定义的组织边界内。例如，您可以定义基于身份的策略，防止您的 IAM 主体访问组织外部的资源（使用 aws:ResourceOrgID 条件）。接下来，您可以定义基于资源的策略，防止组织外部的 IAM 主体访问组织边界内的资源（使用 aws:PrincipalOrgID 条件）。两项策略的组合，可阻止对不属于您组织的亚马逊云科技账户的访问，亦可阻止来自这些账户的访问。在接下来的部分中，我们将介绍一个实例，说明如何在组织中配置基于身份的策略。要了解基于资源的策略，您可以参照亚马逊云科技安全博客上使用 IAM 主体组织轻松控制对亚马逊云科技资源的访问中的示例。

设置示例

在以下部分中，我们将展示每个新条件的 IAM policy 示例。要按照示例 1（使用 aws:ResourceAccount）进行操作，您只需要一个亚马逊云科技账户即可。

要按照示例 2（使用 aws:ResourceOrgPaths）和示例 3（使用 aws:ResourceOrgID）进行操作，您需要在 Amazon Organizations 中创建一个组织并至少创建一个 OU。这篇博客文章假设您已对 IAM 和 Amazon Organizations 中的基本概念有所了解。如果您在创建组织时需要帮助，或是想了解有关 Amazon Organizations 的更多信息，请访问文档中的 Amazon Organization 入门部分。

我应该使用哪种 IAM policy 类型？

您可以将以下示例作为基于身份的策略来实施，也可以在 Amazon Organizations 中管理的 SCP 中实施。如果您想为部分 IAM 主体建立边界，我们建议您使用基于身份的策略。如果您想为整个亚马逊云科技账户或为您的组织建立边界，我们建议您使用 SCP。由于 SCP 适用于整个亚马逊云科技账户，因此在将以下策略应用到您的组织时，应当保持谨慎，并对任何规则外的异常情况负责。这些规则可能是某些亚马逊云科技服务正常运行所必需的。

示例 1：将对亚马逊云科技资源的访问限制在特定的亚马逊云科技账户内

让我们来看一个限制单个亚马逊云科技账户边界访问的 IAM policy 示例。在此示例中，假设您在账户 222222222222 中有一个 IAM 主体，并且您想防止该主体访问该账户之外的 S3 对象。要实现这一效果，您可以附加以下 IAM policy。

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "DenyS3AccessOutsideMyBoundary",
        "Effect": "Deny",
        "Action": [
          “s3: *”
        ],
        "Resource": "*",
        "Condition": {
          "StringNotEquals": {
            "aws:ResourceAccount": [
              "222222222222"
            ]
          }
        }
      }
    ]
  }

注意：此策略并非旨在取代您现有的 IAM 访问控制，因为它不授予任何访问权限。相反，此策略可以充当您其他 IAM 权限的额外防护机制。无论通过其他 IAM policy 授予了何种权限，您都可以使用此类策略来防止主体访问任何您并不知晓或无法控制的亚马逊云科技账户。

此策略通过将 effect 设置为 “Deny”来阻止对 S3 操作的访问，除非正在访问的 S3 资源位于账户 222222222222 中。此策略可防止 S3 访问单个亚马逊云科技账户边界之外的其他账户。您可以使用此类策略，将 IAM 主体限制为只能访问存在于您信任的亚马逊云科技账户中的资源。如果您要实施示例中的此类策略，请将策略中的账户 ID 222222222222 替换为您自己的亚马逊云科技账户 ID。如果您想在保持此限制的同时，将策略应用于多个账户，您可以将账户 ID 替换为条件键 aws:PrincipalAccount，来要求主体和资源必须位于同一账户中（有关如何完成此操作的更多信息，请参阅本文中的示例 3）。

组织设置：欢迎加入 AnyCompany

在接下来的两个示例中，我们将使用在 Amazon Organizations 中创建的名为 AnyCompany 的示例组织。您可以创建一个类似的组织来直接使用这些示例，也可以调整示例策略以适应您自己的组织。图 1 显示了 AnyCompany 的组织结构。

图 1：AnyCompany 的组织结构

像所有组织一样，AnyCompany 有一个组织根账户。根账户下有三个 OU：媒体、体育和监管。在“体育” OU 下，还有三个 OU：棒球、篮球和足球。该组织的亚马逊云科技账户根据其业务目的分布于所有 OU 中。该组织总共有六个 OU。

示例 2：将对亚马逊云科技资源的访问限制在我的组织单位内

现在，您已经了解了 AnyCompany 组织的结构，让我们来看看另一个 IAM policy示例，您可以使用该策略将访问限制在组织的特定部分内。在此示例中，假设您要将 S3 对象访问限制在以下 AnyCompany 组织的 OU 内：

媒体

体育

棒球

篮球

足球

您无需在 IAM policy 中列出所有 OU，即可定义这些 OU 的边界。您可以利用该组织结构。棒球、篮球和足球 OU 共用一个父 OU，即体育 OU。您可以使用新的 aws:ResourceOrgPaths 键来阻止对除媒体 OU、运动 OU 及二者下任何 OU 以外部分的访问。下面是实现此效果的 IAM policy。

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "DenyS3AccessOutsideMyBoundary",
        "Effect": "Deny",
        "Action": [
          “s3: *”
        ],
        "Resource": "*",
        "Condition": {
          "ForAllValues:StringNotLike": {
            "aws:ResourceOrgPaths": [
              "o-acorg/r-acroot/ou-acroot-mediaou/",
              "o-acorg/r-acroot/ou-acroot-sportsou/*"
            ] 
          }
        }
      }
    ]
  }

注意：与前面的示例一样，此策略不授予任何访问权限。而是为您的其他 IAM 权限提供支持，防止您的主体访问 OU 定义边界以外的 S3 对象。如果您想要 IAM 主体始终遵守此规则，我们建议您将此策略应用为 SCP。在此示例中，我们将此策略附加到我们组织的根账户，将其应用于 AnyCompany 组织所有账户的所有主体。

除非正在访问的 S3 资源位于 AnyCompany 组织特定的 OU 中，否则该策略将拒绝对 S3 操作的访问。除 Condition 块外，此策略与示例 1 相同：该条件要求 aws:ResourceOrgPaths 包含列出的任何 OU 路径。由于 aws:ResourceOrgPaths 是多值条件，因此该策略使用 ForAllValues:StringNotLike 运算符将 aws:ResourceOrgPaths 的值与策略中的 OU 列表进行比较。

列表中的第一个 OU 路径是媒体 OU。第二个 OU 路径是体育 OU，但还会在路径末尾添加通配符 *。通配符 * 匹配任意字符组合，因此该条件与体育 OU 及其路径下的任何其他 OU 都相匹配。在 OU 路径中使用通配符可以隐式引用体育 OU 内的其他 OU，而无需将其在策略中明确列出。有关通配符的更多信息，请参阅 IAM 文档中的在资源 ARN 中使用通配符。

示例 3：将对亚马逊云科技资源的访问限制在我的组织内

最后，我们通过一个简单示例，来看看如何在整个组织层面定义边界。此用例与前两个示例（对 S3 对象访问进行限制）相同，但范围限制在了组织层面，而不是账户或 OU 的集合。

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "DenyS3AccessOutsideMyBoundary",
        "Effect": "Deny",
        "Action": [
          “s3: *”
        ],
        "Resource": "arn:aws:s3:::*/*",
        "Condition": {
          "StringNotEquals": {
            "aws:ResourceOrgID": "${aws:PrincipalOrgID}"
          }
        }
      }
    ]
  }

注意：与前面的示例一样，此策略不授予任何访问权限。而是为您的其他 IAM 权限提供支持，防止您的主体访问组织外部的 S3 对象，无论该主体的其他访问权限如何。如果您想要 IAM 主体始终遵守此规则，我们建议您将此策略应用为 SCP。与前面的示例一样，我们将此策略附加到本组织的根账户，将其应用到 AnyCompany 组织中的所有账户。

除非正在访问的 S3 资源与访问该资源的 IAM 主体位于同一组织中，否则该策略将拒绝对 S3 操作的访问。除 Condition 块外，该策略与示例 1 相同：该条件要求 aws:ResourceOrgID 与 aws:PrincipalOrgID 必须彼此相等。根据此要求，提出请求的主体与正在访问的资源必须位于同一组织中。此策略也适用于在策略生效后创建的 S3 资源，因此可以轻松保持所有资源处于相同的安全状况。

有关 aws:PrincipalOrgID 的更多信息，请参阅 IAM 文档中的 Amazon 全局条件上下文密钥。

了解详情

在本篇文章中，我们探讨了新的条件，并通过几个示例，展示了如何限制 S3 对象访问边界以外的账户、OU 或组织。这些工具不仅适用于 S3：您还可以使用这些新的条件来帮助您保护亚马逊云科技上的各项服务和操作。

亚马逊AWS官方博客