在亚马逊云科技上建立数据边界：仅允许可信身份访问公司数据

正如之前一篇博客文章《在亚马逊云科技上建立数据边界：仅允许来自我组织的可信资源》中所述，您可使用 Amazon Web Services 提供的一组功能实现数据边界，以此协助防止意外访问。公司希望防止的一种意外访问是非公司用户访问公司数据。Amazon Identity and Access Management（IAM）提供的各种特性和功能可帮助您在 Amazon Web Services 中实现这一目标，同时通过身份边界促进创新和敏捷性。在这篇博客文章中，我将概述身份边界旨在解决的一些安全风险、策略示例，以及建立边界的实施指导。

身份边界是一组粗粒度的预防性控制措施，有助于实现以下目标：

只有可信身份可访问我的资源
我的网络中仅允许可信身份

可信身份包括属于公司的 IAM 主体，通常由 Amazon Organizations 组织表示。在 Amazon Web Services 中，IAM 主体是指可以请求对 Amazon Web Services 资源执行操作的个人或应用程序。在某些情况下，Amazon Web Services 服务会使用不属于组织的身份代表您执行操作。在针对公司和您使用 Amazon Web Services 服务的情况创建可信身份定义时，您应同时考虑这两种类型的数据访问模式。所有其他身份均视为不可信，除非提供明确的例外，否则这些身份不应具备访问权限。

身份边界解决的安全风险

身份边界有助于解决多种安全风险，包括以下风险。

由于配置错误而导致的意外数据泄露。某些 Amazon Web Services 服务支持基于资源的 IAM 策略，您可以使用这些策略向主体（包括组织外部的主体）授予对其所附加资源执行操作的权限。虽然这可让开发人员根据其应用程序要求配置基于资源的策略，但即使开发人员授予对您资源（例如 Amazon Simple Storage Service（Amazon S3）存储桶）的广泛访问权限，您也应确保禁止不可信身份访问这些资源。图 1 说明您希望防止的访问模式示例 — 具体而言就是组织外部的主体通过非公司 Amazon Web Services 账户、本地网络或互联网访问您的 S3 存储桶。

图 1：组织外部的身份意外访问您的 S3 存储桶

通过非公司凭证意外披露数据。一些 Amazon Web Services 服务，例如 Amazon Elastic Compute Cloud（Amazon EC2）和 Amazon Lambda，可让您使用自己选择的 IAM 凭证运行代码。与开发人员可能有权访问物理和虚拟服务器的本地环境类似，存在的风险是开发人员可能会将个人 IAM 凭证带入公司网络，并尝试将公司数据转移到个人 Amazon Web Services 资源。例如，图 2 说明一些意外访问模式，即使用 Amazon Web Services Organizations 组织外部的身份将数据从本地网络或 VPC 传输到非公司 Amazon Web Services 账户中的 S3 存储桶。

图 2：组织外部的身份从您的网络进行意外访问

实施身份边界

在使用预防性控制措施实施身份边界之前，您需要制定相应方法评估主体是否可信，并在多账户 Amazon Web Services 环境中有效地进行此评估。IAM 策略可让您使用如下 IAM 条件键，根据 IAM 主体是属于特定账户还是组织来控制访问权限：

aws:PrincipalOrgID 条件键提供一种简洁的方式来引用属于特定组织的所有 IAM 主体。还有类似的条件键，例如 aws:PrincipalOrgPaths和 aws:PrincipalAccount，可让您定义不同的信任粒度。
aws:PrincipalIsAWSService 条件键提供一种在使用 Amazon Web Services 服务主体代表您访问资源时引用这些主体的方式。例如，当您创建以 S3 存储桶为目标的流日志时，VPC 流日志使用不属于您组织的服务主体 logs.amazonaws.com 将日志发布到 Amazon S3。

在身份外围环境中，有两种类型的 IAM 策略可以帮助您确保由可信身份调用 Amazon Web Services 资源：

基于资源的策略– 附加到资源的策略。有关支持基于资源的策略的服务列表，请参阅与 IAM 搭配使用的 Amazon Web Services 服务。
VPC 端点策略– 附加到 VPC 端点的策略。有关支持 VPC 端点和 VPC 端点策略的服务列表，请参阅与 Amazon PrivateLink 集成的 Amazon Web Services 服务。

使用刚才列出的 IAM 条件键和策略类型，您现在可以实施身份边界。下表说明身份边界目标与可用于实现这些目标的 Amazon Web Services 功能之间的关系。

数据边界	控制目标	实施方式	主要 IAM 功能
身份	只有可信身份可访问我的资源。	基于资源的策略	aws:PrincipalOrgID aws:PrincipalIsAWSService
身份	我的网络仅允许可信身份。	VPC 端点策略	aws:PrincipalOrgID aws:PrincipalIsAWSService

接下来了解如何使用这些功能降低意外访问数据的风险。

只有可信身份可访问我的资源

基于资源的策略可让您指定谁有权访问资源及其可以执行哪些操作。基于资源的策略还可让您应用身份边界控制，以降低由于配置错误而导致的意外数据披露风险。以下是针对 S3 存储桶的基于资源的策略示例，该策略仅限可信身份访问存储桶。请务必用自己的相应信息替换 <DOC-EXAMPLE-MY-BUCKET> 和 <MY-ORG-ID>。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceIdentityPerimeter",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<DOC-EXAMPLE-MY-BUCKET>",
        "arn:aws:s3:::<DOC-EXAMPLE-MY-BUCKET>/*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "<MY-ORG-ID>"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

上述策略中的 Deny 语句有两个条件键，这两个条件都必须解析为 true 才能调用 Deny 效果。这意味着，除非由组织内的 IAM 主体（带有 aws:PrincipalOrgID 的StringNotEqualsIfExists）或服务主体（带有 aws:PrincipalIsAWSService 的 BoolIfExists）执行，否则该策略将拒绝任何 S3 操作。请注意，默认情况下，Amazon Web Services 资源上基于资源的策略不允许在账户之外进行访问。因此，为了让其他账户或 Amazon Web Services 服务能够直接访问您的资源，您需要在前面的策略中添加相应的 Allow 语句来明确授予访问权限。

某些 Amazon Web Services 资源允许通过使用 Amazon Resource Access Manager（RAM）进行共享。在 RAM 中创建资源共享时，应选择仅允许与组织中的主体共享，以协助防止不可信身份的访问。除了身份边界的主要功能外，您还应使用 Amazon Organizations 服务控制策略（SCP）中的 ram:RequestedAllowsExternalPrincipals 条件键，指定不能创建或修改资源共享以允许与不可信身份共享。有关 SCP 示例，请参阅《Amazon RAM 用户指南》中的 Amazon Organizations 和 Amazon RAM 服务控制策略示例。

我的网络中仅允许可信身份

从本地网络或 VPC 访问 Amazon Web Services 服务时，您可以使用公有服务端点，或者使用 VPC 端点连接到支持的 Amazon Web Services 服务。VPC 端点可让您应用身份边界控制措施，以缓解通过非公司凭证意外披露数据的风险。以下是 VPC 端点策略的示例，该策略允许访问所有操作，但限制仅由可信身份访问。将 <MY-ORG-ID> 替换为您的信息。

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

与基于资源的策略示例相反，上述策略使用 Allow 语句强制执行身份边界。这是因为 VPC 端点策略不授予任何权限，但定义通过端点允许的最大访问权限。开发人员将使用基于身份或基于资源的策略来授予其应用程序所需的权限。在此示例中，我们使用两条语句在两种场景中调用 Allow 效果：如果操作由属于您组织的 IAM 主体（AllowRequestsByOrgsIdentities 语句中带有 aws:PrincipalOrgID 的 StringEquals）执行，或者如果操作由服务主体（AllowRequestsByAWSServicePrincipals 语句中带有 aws:PrincipalIsAWSService 的 Bool）执行。在此案例中，我们未在条件运算符的末尾使用 IfExists，因为我们希望只有在请求中存在指定的键时，条件元素的评估结果才为 true。

需要注意的是，要将 VPC 端点策略应用于源自本地环境的请求，您需要通过 Amazon Direct Connect 配置面向 Amazon Web Services 的私有连接。

扩展身份边界

在某些情况下，您可能希望向组织外部的主体授予资源的访问权限。例如，您可能在 Amazon S3 存储桶中托管一个数据集，您的业务合作伙伴可以从自己的 Amazon Web Services 账户访问该数据集。为了支持这种访问模式，您可以在策略中使用 aws:PrincipalAccount 条件键将第三方账户身份作为可信身份包括在内。以下基于资源的策略示例显示了该方法。将 <DOC-EXAMPLE-MY-BUCKET>、<MY-ORG-ID>、<THIRD-PARTY-ACCOUNT-A> 和 <THIRD-PARTY-ACCOUNT-B> 替换为您的信息。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceIdentityPerimeter",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<DOC-EXAMPLE-MY-BUCKET>",
        "arn:aws:s3:::<DOC-EXAMPLE-MY-BUCKET>/*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "<MY-ORG-ID>",
          "aws:PrincipalAccount": [
            "<THIRD-PARTY-ACCOUNT-A>",
            "<THIRD-PARTY-ACCOUNT-B>"
          ]
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

上述策略向 StringNotEqualsIfExists 运算符添加 aws:PrincipalAccount 条件键。现在，您拥有包含三个条件键的 Deny 语句，其中所有三个条件都必须解析为 true 才能调用 Deny 效果。因此，除非由属于您组织的 IAM 主体（带有 aws:PrincipalOrgID 的 StringNotEqualsIfExists）、属于指定第三方账户的 IAM 主体（带有 aws:PrincipalAccount 的 StringNotEqualsIfExists）或服务主体（带有 aws:PrincipalIsAWSService 的 BoolIfExists）执行，否则该策略拒绝任何 S3 操作。

在某些情况下，您可能还要从自己的网络向组织外部的身份授予访问权限。例如，您的应用程序可能使用第三方生成的预签名 Amazon S3 URL 向第三方 S3 存储桶上传对象或从中下载对象。生成预签名 URL 的主体将属于第三方 Amazon Web Services 账户。与前面讨论的 S3 存储桶策略类似，您可以在 VPC 端点策略中使用 aws:PrincipalAccount 条件键扩展身份边界以包括属于可信第三方账户的身份。

此外，一些 Amazon Web Services 服务会通过您的 VPC 端点向 Amazon Web Services 拥有的资源发出未经身份验证的请求。此类模式的一个示例是 Kernel Live Patching on Amazon Linux 2，它可让您对正在运行的 Linux 内核应用安全漏洞和关键错误补丁。Amazon EC2 在未经身份验证的情况下调用 Amazon S3，从 Amazon EC2 服务拥有的 S3 存储桶上托管的 Amazon Linux 存储库下载软件包。要将此访问模式包含到身份边界定义中，可以在 VPC 端点策略中选择允许对 Amazon Web Services 拥有的资源进行未经身份验证的 API 调用。

以下示例 VPC 端点策略演示如何扩展身份边界，以包括对 Amazon Linux 存储库和第三方拥有的 Amazon S3 存储桶的访问权限。将 <MY-ORG-ID>、<REGION>、<ACTION>、<THIRD-PARTY-ACCOUNT-A> 和 <THIRD-PARTY-BUCKET-ARN> 替换为您的信息。

{
 "Version": "2012-10-17", 
 "Statement": [
    {
      "Sid": "AllowRequestsByOrgsIdentities",
      "Effect": "Allow",    
      "Principal": {
        "AWS": "*"
      },
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "<MY-ORG-ID>"
        }
      }
    },
    {
      "Sid": "AllowRequestsByAWSServicePrincipals",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        }
      }
    },
    {
      "Sid": "AllowUnauthenticatedRequestsToAWSResources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::packages.<REGION>.amazonaws.com/*",
        "arn:aws:s3:::repo.<REGION>.amazonaws.com/*",
        "arn:aws:s3:::amazonlinux.<REGION>.amazonaws.com/*",
        "arn:aws:s3:::amazonlinux-2-repos-<REGION>/*"
      ]
    },
    {
      "Sid": "AllowRequestsByThirdPartyIdentitiesToThirdPartyResources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "<ACTION>",
      "Resource": "<THIRD-PARTY-BUCKET-ARN>",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": [
            "<THIRD-PARTY-ACCOUNT-A>"
          ]
        }
      }
    }
  ]
}

上述示例向 VPC 端点策略添加两条新语句。AllowUnauthenticatedRequestsToAWSResources 语句允许对托管 Amazon Linux 存储库的存储桶执行 s3:GetObject 操作。AllowRequestsByThirdPartyIdentitiesToThirdPartyResources 语句允许属于第三方账户的主体（带有 aws:PrincipalAccount 的 StringEquals）对第三方实体拥有的资源执行操作。

请注意，身份边界控制措施并不能消除额外网络保护的需求，例如确保私有 EC2 实例或数据库不会因为安全组权限过于宽松而无意中暴露在互联网中。

除了身份边界建立的预防性控制措施之外，我们还建议您配置 Amazon Identity and Access Management Access Analyzer。IAM Access Analyzer 通过监控应用于受支持资源的策略，帮助您识别对资源和数据的意外访问。您可以查看 IAM Access Analyzer 的调查结果，以确定与不属于 Amazon Organizations 组织的主体共享的资源。您还应考虑启用 Amazon GuardDuty 来检测可能导致数据意外披露的错误配置或对资源的异常访问。GuardDuty 使用威胁情报、机器学习和异常检测来分析来自 Amazon Web Services 账户中各种来源的数据。您可以查看 GuardDuty 的调查结果，识别 Amazon Web Services 环境中的意外活动或潜在的恶意活动，例如以前没有调用 S3 API 历史记录的 IAM 主体。

IAM 策略示例

此 Amazon Web Services git 存储库包含策略示例，这些示例说明如何为各种 Amazon Web Services 服务和操作实施身份边界控制。策略示例并不代表有效数据访问模式的完整列表，并且仅供参考。它们旨在让您根据自己的环境需求进行定制和扩展。在生产环境中实施所提供的示例策略之前，请务必对其进行全面测试。

大规模部署身份边界

如前所述，您可以将身份边界实施为粗粒度的预防性控制措施。通常，需要使用 VPC 端点策略对每个 VPC 实施这些控制措施，以及对支持基于资源的策略的所有资源实施这些控制措施。这些控制措施的有效性取决于它们能否随环境扩展并适应环境的动态性质。

用于部署身份边界控制措施的方法将取决于用于创建和管理 Amazon Web Services 账户的部署机制。

由于开发人员将定期创建 S3 存储桶和 Amazon KMS 密钥等资源，因此在创建这些资源或更改其策略时，您可能需要实施自动化以强制执行身份边界控制措施。一种选择是使用自定义 Amazon Config 规则。或者，可以选择通过 Amazon Service Catalog 或 CI/CD 管道强制部署资源。借助 Amazon Web Services Services Catalog 方法，您可以在集中控制的产品中内置身份边界控制措施，供开发人员在其账户中部署。使用 CI/CD 管道方法时，管道可以内置合规性检查，从而在部署期间强制执行身份边界控制措施。也可以使用 Amazon CloudFormation，通过 CI/CD 管道部署资源。

无论选择哪种部署工具，身份边界控制措施以及适用于多账户环境的其他基准安全控制措施都应包含在您的账户配置流程中。您还应定期审核身份边界配置，以及在组织变革时进行审核，组织变革可能会导致身份边界控制措施的修改（例如，禁用第三方集成）。使您的身份边界控制措施保持最新状态将有助于确保这些控制措施得到持续执行，并有助于在整个账户生命周期内防止意外访问。

总结

在这篇博客文章中，您了解了定义和实施身份边界所需的基本要素，包括可用于开始定义适用于环境和控制目标的防护机制的示例策略。

Original URL: https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/

亚马逊AWS官方博客