在亚马逊云科技上建立数据边界：仅允许来自我组织的可信资源

在 Amazon Web Services 上存储和处理数据的公司希望防止将这些数据传输到公司控制范围之外的地点或从这些地点传入数据。这是为了支持安全策略，例如防止数据丢失，或者遵守各种监管和隐私协议规定的条款和条件。在 Amazon Web Services 上，资源边界是一组 Amazon Identity and Access Management（IAM）特性和功能，可以使用这些特性和功能构建针对意外数据传输的深度防御防护。在“在 Amazon Web Services 上建立数据边界”系列的第三篇博客文章中，我们回顾了定义资源边界时的优势和实施注意事项。

资源边界是 Amazon Web Services 上数据边界框架中的三种边界之一，具有以下两点控制目标：

我的身份仅可访问可信资源 – 这有助于确保属于您 Amazon Organizations 组织的 IAM 主体只能访问您信任的资源。
只能从我的网络访问可信资源 – 这有助于确保只有您信任的资源才能通过预期的网络进行访问，无论是哪个主体正在执行 API 调用。

可信资源是 Amazon Web Services 资源，例如 Amazon Simple Storage Service（Amazon S3）存储桶和对象或 Amazon Simple Notification Service（Amazon SNS）主题，这些资源归您的组织所有，您可以在其中存储和处理数据。此外，您的身份或代表您行事的 Amazon Web Services 服务可能需要访问组织外部的资源。在定义资源边界时，您需要考虑这些访问模式。

资源边界解决的安全风险

资源边界有助于解决三个主要安全风险。

通过使用公司凭证意外披露数据 — 您的开发人员可能拥有不属于您组织的个人 Amazon Web Services 账户。在该账户中，他们可以使用基于资源的策略配置资源，该策略允许其企业凭证与资源交互。例如，他们可以编写 S3 存储桶策略，使其可使用公司凭证上传对象。这可能会让开发人员有意或无意地将数据从您的企业环境（本地网络或虚拟私有云（VPC））转移到他们的个人账户。在推进最低权限旅程期间，无论附加到您 IAM 主体的基于身份的策略授予的权限如何，都应确保禁止访问不受信任的资源。图 1 说明一种意外访问模式，其中您的员工使用组织中的身份将数据从本地或 Amazon Web Services 环境转移到非公司 Amazon Web Services 账户中的 S3 存储桶。

图 1：您的身份意外将数据传输到组织外部的 S3 存储桶

通过使用非公司凭证意外披露数据 — 开发人员可能会将个人 IAM 凭证引入公司网络，并试图将公司数据转移到个人的 Amazon Web Services 资源。我们在之前的一篇博客文章中讨论了这一安全风险：在 Amazon Web Services 上建立数据边界：仅允许可信身份访问公司数据。在此文章中，我们描述了如何使用 aws:PrincipalOrgID 条件键来防止使用非公司凭证将数据转移到不可信的位置。在此文章中，我们将向您展示如何实施资源边界控制措施，以此作为一种深度防御方法来缓解这种风险。

意外数据渗透 — 在某些情况下，开发人员可能会使用商业数据集、工具或软件开始解决方案开发流程，并决定从存储库（例如托管在公有 S3 存储桶上的存储库）中复制这些数据集、工具或软件。这可能会将恶意组件引入公司环境、本地网络或 VPC。建立资源边界以仅允许从您的网络访问可信资源，这样有助于缓解这种风险。图 2 说明具有公司凭证的员工从组织外部的 S3 存储桶下载资产的访问模式。

图 2：意外数据渗透

实施资源边界

要实现资源边界控制目标，您可以使用以下 Amazon Web Services 策略类型在 Amazon Web Services 环境中实施防护机制：

服务控制策略（SCP） – 用于集中管理和设置 IAM 主体最大可用权限的组织策略。SCP 可帮助您确保自身的账户符合组织的访问控制指导方针。在资源边界环境中，您将使用 SCP 来帮助防止属于您组织的 Amazon Web Services 主体访问不受信任的资源。
VPC 端点策略 – 一种基于 IAM 资源的策略，其附加到 VPC 端点，用于控制可通过 VPC 端点访问哪些主体、操作和资源。在资源边界环境中，VPC 端点策略用于验证主体尝试访问的资源是否属于您的组织。

用于限制组织中资源访问的条件键是 aws:ResourceOrgID。您可以在 SCP 或 VPC 端点策略中设置此条件键。下表总结控制目标与用于实施资源边界的 Amazon Web Services 功能之间的关系。

控制目标	实施方式	主要 IAM 功能
我的身份仅可访问可信资源	SCP	aws:ResourceOrgID
仅可从我的网络访问可信资源	VPC 端点策略	aws:ResourceOrgID

在下一节中，您将学习如何使用上表中列出的 IAM 功能来实现资源边界的每个控制目标。

我的身份仅可访问可信资源

以下是 SCP 的示例，该示例限制所有操作仅可处理属于您组织的资源。将 <MY-ORG-ID> 替换为您的信息。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceResourcePerimeter",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:ResourceOrgID": "<MY-ORG-ID>"
        }
      }
    }
  ]
}

在本策略中，请注意使用了否定条件键 StringNotEqualsIfExists。这意味着，如果正在访问的资源的组织标识符与策略中指定的标识符不同，则此条件的求值结果将为 true，并且该策略将拒绝 API 调用。这也意味着，如果正在访问的资源属于独立账户，而该账户不属于组织，则此策略将拒绝 API 调用。Deny 语句中的否定条件运算符意味着，如果请求中不存在条件键，则条件的计算结果仍然为 true；但是，作为最佳实践，我在 StringNotEquals 运算符的末尾添加 IfExists，以清楚地表达策略中的意图。

请注意，要允许特定账户获得权限，组织层次结构的每个级别都必须存在允许访问的语句。

仅可从我的网络访问可信资源

您可以将我们刚刚回顾的 SCP 与 VPC 端点策略中的 aws:PrincipalOrgID 结合使用以实现这一目标，如在 Amazon Web Services 上建立数据边界：仅允许可信身份访问公司数据博客文章中所示。但是，作为深度防御措施，您也可以在 VPC 端点策略中使用 aws:ResourceOrgID，在网络上应用资源边界控制。

以下是 VPC 端点策略的示例，该策略允许访问所有操作，但仅限访问属于您组织的可信资源和身份。将 <MY-ORG-ID> 替换为您的信息。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowRequestsByOrgsIdentitiesToOrgsResources",
			"Effect": "Allow",
			"Principal": {
				"AWS": "*"
			},
			"Action": "*",
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"aws:PrincipalOrgID": "<MY-ORG-ID>",
					"aws:ResourceOrgID": "<MY-ORG-ID>"
				}
			}
		}
	]
}

上述的 VPC 端点策略使用 StringEquals 条件运算符。要调用 Allow 效果，进行 API 调用的主体和其尝试访问的资源都必须属于您的组织。与我们之前查看的 SCP 示例相比，您使用此策略的意图有所不同 — 您希望确保只有在请求中存在指定条件键时，Allow 条件才会求值为 true。此外，只要主体的请求流经 VPC 端点，VPC 端点策略就适用于这些主体。

在 VPC 端点策略中，您未授予权限；相反，您定义通过网络的最大允许访问权限。因此，此策略使用 Allow 效果。

扩展您的资源边界

前两项策略可协助确保您的身份和网络只能用于访问属于您组织的 Amazon Web Services 资源。但是，公司可能会要求您扩展资源边界，将 Amazon Web Services 拥有的资源也包括在内 — 这些资源不属于您的组织，并且由您的主体或代表您行事的 Amazon Web Services 服务访问。例如，如果您在环境中使用 Amazon Service Catalog，则该服务会创建并使用服务拥有的 Amazon S3 存储桶来存储产品。为了让开发人员能够成功预置 Amazon Service Catalog 产品，您的资源边界需要考虑这种访问模式。以下语句显示如何说明服务目录访问模式。将 <MY-ORG-ID> 替换为您的信息。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceResourcePerimeter",
      "Effect": "Deny",
      "NotAction": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:ResourceOrgID": "<MY-ORG-ID>"
        }
      }
    },
    {
      "Sid": "ExtendResourcePerimeter",
      "Effect": "Deny",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:ResourceOrgID": "<MY-ORG-ID>"
        },
        "ForAllValues:StringNotEquals": {
          "aws:CalledVia": [
            "servicecatalog.amazonaws.com"
          ]
        }
      }
    }
  ]
}

请注意，SCP 中的 EnforceResourcePerimeter 语句已修改，将 s3:GetObject、s3:PutObject 和 s3:PutObjectAcl 操作排除在其效果之外（NotAction 元素）。这是因为这些操作由 Service Catalog 执行以访问服务拥有的 S3 存储桶。然后，这些操作在 ExtendResourcePerimeter 语句中受到限制，该语句包括两个否定的条件键。第二条语句拒绝前面提到的 S3 操作，除非正在访问的资源属于您的组织（带有 aws:ResourceOrgID 的 StringNotEqualsIfExists），或者这些操作由 Service Catalog 代表您执行（带有 aws:CalledVia 的 ForAllValues:StringNotEquals）。aws:CalledVia 条件键将策略中指定的服务与使用主体凭证代表 IAM 主体提出请求的服务进行比较。就 Service Catalog 而言，启动产品的主体的凭证用于访问 Service Catalog 所拥有的 S3 存储桶。

必须强调的是，在之前的策略中，我们故意不使用 aws:ViaAWSService 条件键。这是因为当您扩展资源边界时，我们建议您将访问权限制为仅调用正在使用的服务访问的存储桶。

您可能还需要扩展资源边界以包括合作伙伴的第三方资源。例如，您可能正在与业务合作伙伴合作，这些合作伙伴要求您的主体向属于其账户的 S3 存储桶上传或下载数据。在这种情况下，您可以使用资源边界策略中的 aws:ResourceAccount 条件键来指定属于可信第三方账户的资源。

以下 SCP 示例说明 Service Catalog 和第三方合作伙伴资源的访问权限。将 <MY-ORG-ID> 和 <THIRD-PARTY-ACCOUNT> 替换为您的信息。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceResourcePerimeter",
      "Effect": "Deny",
      "NotAction": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:ResourceOrgID": "<MY-ORG-ID>"
        }
      }
    },
    {
      "Sid": "ExtendResourcePerimeter",
      "Effect": "Deny",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:ResourceOrgID": "<MY-ORG-ID>",
          "aws:ResourceAccount": "<THIRD-PARTY-ACCOUNT>"
        },
        "ForAllValues:StringNotEquals": {
          "aws:CalledVia": [
            "servicecatalog.amazonaws.com"
          ]
        }
      }
    }
  ]
}

为了说明对可信第三方账户资源的访问权限，ExtendResourcePerimeter 语句中的条件 StringNotEqualsIfExists 现在还包含条件键 aws:ResourceAccount。现在，第二条语句拒绝前面提到的 S3 操作，除非正在访问的资源属于您的组织（带有 aws:ResourceOrgID 的 StringNotEqualsIfExists）、可信的第三方账户（带有 aws:ResourceAccount 的 StringNotEqualsIfExists），或者这些操作由 Service Catalog 代表您执行（带有 aws:CalledVia 的 ForAllValues:StringNotEquals）。

下一个策略示例演示如何扩展您的资源边界，以允许通过您控制的网络访问由可信第三方拥有的资源。如果在您的 VPC 或本地中运行的应用程序需要能够访问在业务合作伙伴 Amazon Web Services 账户中创建和维护的数据集，则需要如此操作。与 SCP 示例类似，您可以在 VPC 端点策略中使用 aws:ResourceAccount 条件键来说明这种访问模式。将 <MY-ORG-ID>、<THIRD-PARTY-ACCOUNT> 和 <THIRD-PARTY-RESOURCE-ARN> 替换为您的信息。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRequestsByOrgsIdentitiesToOrgsResources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "<MY-ORG-ID>",
          "aws:ResourceOrgID": "<MY-ORG-ID>"
        }
      }
    },
    {
      "Sid": "AllowRequestsByOrgsIdentitiesToThirdPartyResources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "<THIRD-PARTY-RESOURCE-ARN>"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "<MY-ORG-ID>",
          "aws:ResourceAccount": [
            "<THIRD-PARTY-ACCOUNT>"
          ]
        }
      }
    }
  ]
}

已更新 VPC 端点策略中的第二条语句 AllowRequestsByOrgsIdentitiesToThirdPartyResources 允许属于您组织的主体（带有 aws:PrincipalOrgID 的 StringEquals）对可信的第三方资源（带有 aws:ResourceAccount 的 StringEquals）执行 s3:GetObject、s3:PutObject 和 s3:PutObjectAcl 操作。

请注意，您无需修改 VPC 端点策略即可支持前面讨论的 Service Catalog 操作。这是因为 Service Catalog 代表您对 Amazon S3 的调用源自 Service Catalog 服务网络，并且不会遍历您的 VPC 端点。但是，在定义可信资源时，应考虑类似于 Service Catalog 示例的访问模式。要了解具有相似访问模式的服务，请参阅本文章后面的 IAM 策略示例部分。

大规模部署资源边界

有关大规模部署数据边界的建议，请参阅在 Amazon Web Services 上建立数据边界：仅允许可信身份访问公司数据博客文章。标题为大规模部署身份边界的部分详细介绍如何为您的组织实现这一目标。

IAM 策略示例

我们的 GitHub 存储库包含策略示例，这些示例说明如何对各种 Amazon Web Services 服务实施边界控制措施。存储库中的策略示例仅供参考。您需要对其进行量身定制，以满足您的 Amazon Web Services 环境的特定需求。

总结

在这篇博客文章中，您了解了资源边界、边界实现的控制目标，以及如何编写 SCP 和 VPC 端点策略来帮助组织实现这些目标。您还学习了如何扩展边界，将 Amazon Web Services 服务拥有的资源和第三方合作伙伴拥有的资源包括在内。

Original URL: https://thinkwithwp.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-resources-from-my-organization/

亚马逊AWS官方博客