资源控制策略 (RCP) – AWS Organizations 中的一种新型授权策略介绍

我很高兴向大家介绍资源控制策略 (RCP)，这是 AWS Organizations 新推出的一种授权管理策略，有助于在组织范围内设定资源的最大可用权限。该策略是一种预防性控制手段，可帮助您在 AWS 环境中建立数据边界，并限制对资源的大规模外部访问。RCP 在组织内部集中执行，这给中央治理和安全团队吃了颗定心丸，让他们确信对 AWS 账户内资源的访问符合组织的访问控制准则。

RCP 在所有商业 AWS 区域都可用，并且在启动时支持以下服务：Amazon Simple Storage Service (Amazon S3)、AWS Security Token Service (AWS STS)、AWS Key Management Service (AWS KMS)、Amazon Simple Queue Service (Amazon SQS) 和 AWS Secrets Manager.

启用和使用 RCP 不收取额外费用。

它们与服务控制策略 (SCP) 有何不同？

虽然性质相似，但 RCP 是对服务控制策略 (SCP) 的补充，它们各自独立运作。

服务控制策略 (SCP) 允许您限制向组织内的主体授予的权限，例如 AWS Identity and Access Management（IAM）角色。通过在组织内部集中限制这些权限，您可以限制对 AWS 服务、特定资源的访问，甚至限制主体在什么条件下可以跨多个 AWS 账户提出请求。

另一方面，RCP 使您能够限制对组织内资源的权限授予。由于您在组织内部集中实施 RCP，因此可以对多个 AWS 账户的资源实施统一的访问控制。例如，您可以限制对账户中的 S3 存储桶的访问权限，确保只有组织内的主体能够访问。不管谁发起 API 请求，在访问资源时都会评估 RCP。

请记住，SCP 和 RCP 不授予任何权限。它们仅设置组织中的主体和资源可用的最大权限。您还是需要通过合适的 IAM 策略，比如基于身份的策略或者基于资源的策略，来授权相应权限。

SCP 和 RCP 的配额完全相互独立。每个 RCP 最多可以包含 5,120 个字符。您最多可以将五个 RCP 连接到组织的根、每个组织部门和账户，并且您最多可以在一个组织中创建和存储 1000 个 RCP。

如何开始使用

要开始使用 RCP，您必须先启用它们。您可以使用组织控制台、AWS SDK 或 AWS 命令行界面（AWS CLI）来执行此操作。确保您使用的是组织管理账户或代理管理员账户，因为只有这些账户才有权限启用或禁用策略类型。

确保使用的组织具有“所有功能”选项。如果您使用的是“整合账单功能”模式，则需要先迁移到使用所有功能，然后才能启用 RCP。

对于控制台用户，请先前往组织控制台。选择策略，您应该会看到启用资源控制策略的选项。

在 AWS Organizations 控制台中启用 RCP

启用 RCP 后，您会发现在资源控制策略页面上，现在有一项名为 RCPFullAWSAccess 的新策略可供使用。这是一项 AWS 托管式策略，会自动创建并连接到组织中的每个实体，包括根、每个组织部门和 AWS 账户。

该策略允许所有主体对组织的资源执行任何操作，这意味着在您开始创建和连接自己的 RCP 之前，所有现有的 IAM 权限都将继续按照原来的方式运行。

详细介绍如下：

{
  "Version": "2012-10-17",
  "Statement": [
    { 
        "Effect": "Allow",
        "Principal": "*",
        "Action": "*",
        "Resource": "*" 
    }
  ]
}

创建 RCP

现在，我们准备创建第一个 RCP！我们来看一个示例。

默认情况下，AWS 资源不允许外部主体访问；资源所有者需要通过设置策略来明确授权这种访问权限。开发人员可以根据应用的具体需求灵活配置基于资源的策略，而 RCP 则让中央 IT 团队能够保持对其组织中资源的有效权限的控制。这样就能确保即便开发人员赋予了广泛的访问权限，外部身份仍然会根据组织的安全要求受到访问限制。

我们来创建一个 RCP，用以限制对 S3 存储桶的访问，确保只有组织内的主体能够访问它们。

在资源控制策略页面上，选择创建策略，这会跳转到一个页面，让您可以编写新的策略。

我将此策略命名为 EnforceOrgIdentities。建议您输入一个清晰的描述，这样别人一看就能明白这项策略的作用，并进行适当的标记。

在下一部分中，您可以编辑策略声明。我用自己的策略模板替换了预填充的策略模板：

以下是完整的 JSON 策略文档：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceOrgIdentities",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "[MY ORG ID]"
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        }
    ]
}

让我们逐步分析一下：

Version – 这是 IAM 策略的标准和必备元素。AWS 保持向后兼容性，因此使用最新版本（当前为 2012-10-17）不会破坏现有策略，同时还让您能够使用新功能。

Statement – 可以包含一个或多个声明对象的数组。在这些声明对象中，每个对象都定义了一个权限或一组权限。

Sid – 这是一个可选字段，有助于策略管理和故障排除。在此 JSON 策略文档的范围内，它必须是唯一的。

Effect – 您可能还记得，在默认情况下，我们有一个 RCP，它允许访问组织中每个实体的每个 AWS 主体、操作和资源。因此，您应该使用 Deny 来应用限制。

Principal – 对于 RCP，此字段必须始终设置为"*"。如果您希望此策略仅适用于特定主体，请使用“条件”字段。

Action – 指定此策略适用的 AWS 服务和操作。在这种情况下，如果与 Amazon S3 的交互不符合访问控制准则，我们就会拒绝这些交互。

Resource – 指定 RCP 适用的资源。

Condition – 条件集合，将被用来评估条件，确定是否应将策略应用于每个请求。

务必记住，要应用 RCP，所有的条件都必须评估为“true”。在本例中，我们应用了两个条件：

1.请求是由外部主体提出的？

"StringNotEqualsIfExists": 
 { 
   "aws:PrincipalOrgID": "[MY ORG ID]" 
 }

此条件首先检查请求中是否存在密钥 aws:PrincipalOrgID。如果不存在，则此条件评估为“true”，无需进一步评估。

如果存在，则将该值与组织 ID 进行比较。如果值相同，则条件就评估为“false”，也就是说 RCP 不会被应用，因为所有的条件都必须评估为“true”。这是我们预期的行为，因为我们不希望阻止组织内部主体的访问。

但是，如果该值与组织 ID 不匹配，则表示该请求是由组织外部的主体提出的。此条件评估为“true”，也就是说只要第二个条件的评估也为“true”，就仍有可能应用 RCP。

2.请求是否来自 AWS 服务？

"BoolIfExists": 
   { 
     "aws:PrincipalIsAWSService": "false"
   }

此条件测试请求是否包含一个名为 aws:PrincipalIsAWSService 的特殊键，该键会自动添加到所有签名 API 请求的请求上下文中，当请求来自 AWS CloudTrail 等 AWS 服务并将事件写入 S3 存储桶时，该键会被设置为“true”。如果该键不存在，则此条件评估为true。

如果该键存在，则它会将值与语句中声明的值进行比较。在本例中，我们要测试的是值是否等于 false。如果是，我们将返回 true，因为这意味着该请求不是由 AWS 服务发起的，仍然可能是组织外部的人发出的。否则，我们将返回 false。

换句话说，如果请求不是来自组织内部的主体，也不是来自 AWS 服务，则对 S3 存储桶的访问将被拒绝。

此策略只是一个示例，您应根据自己独特的业务和安全目标进行调整。比如，您可能希望自定义此策略，以便允许业务合作伙伴访问 AWS 服务，或者限制他们对 AWS 服务的访问权限，确保他们只能代表您访问您的资源。如需了解详情，请参阅在 AWS 上建立数据边界：仅允许可信身份访问公司数据。

连接 RCP

连接 RCP 的过程与 SCP 类似。如前所述，您可以将其连接到组织的根、组织部门或组织内的特定 AWS 账户。

连接 RCP 后，对受影响的 AWS 资源的访问请求必须遵守 RCP 限制。我们建议您在大规模推行 RCP 之前，全面测试 RCP 对账户资源的影响。首先，您可以将 RCP 连接到个人测试账户或测试组织部门。

观看实际操作

我已经创建并连接到 RCP，现在准备开始实际操作！假设开发人员将基于资源的策略应用到组织中的 S3 存储桶上，并且明确赋予外部账户中身份的访问权限：

RCP 不会阻止用户保存权限比 RCP 允许的更大的基于资源的策略。但如前所述，RCP 将作为授权流程的一部分予以评估，因此外部身份的请求无论如何都会被拒绝。

我们可以通过用这个外部账户尝试访问存储桶来验证这一点，这次使用 AWS CLI：


$ aws s3api get-object —bucket 123124ffeiufskdjfgbwer \
  --key sensitivefile.txt \
  --region us-east-1 local_file

调用 GetObject 操作时发生错误 (AccessDenied)：访问被拒绝

在您的环境中扩展 RCP 的部署

到目前为止，我们已经了解了如何使用控制台管理 RCP。但是，对于大规模的控制管理，您应该考虑将它们配置为基础设施即代码，并确保它们已集成到现有的持续集成和持续交付 (CI/CD) 管道和流程中。

如果您使用 AWS Control Tower，除了基于 SCP 的控制外，还可以部署基于 RCP 的控件。例如，您可以使用 AWS Control Tower 部署一个 RCP，类似于前面示例中创建的 RCP，它可以防止外部主体访问组织中的 S3 存储桶。这样可以确保 RCP 始终一致地应用于托管账户中的资源，从而大规模地简化和集中访问控制治理。

此外，与 SCP 类似，AWS Control Tower 还支持对 RCP 的偏离检测。如果您在 AWS Control Tower 之外修改或移除 RCP，就会收到偏离通知，并得到相应的补救措施。

结论

资源控制策略 (RCP) 对组织中 AWS 资源可用的最大权限进行集中管理。与 SCP 一起，RCP 有助于在整个 AWS 环境中集中建立数据边界，防止大规模意外访问。SCP 和 RCP 是独立的控制措施，可以实现不同的安全目标。您可以选择单独启用 SCP 或者 RCP，也可以同时采用这两种策略，以建立全面的安全基准，作为深度防御安全模型的一部分。

如需了解更多信息，请参阅 AWS Organizations 用户指南中的资源控制策略 (RCP)。

Matheus Guimaraes | @codingmatheus

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

亚马逊AWS官方博客