使用基于资源的策略简化跨账户访问控制的 Amazon DynamoDB 数据库博客

使用基于资源的策略简化Amazon DynamoDB的跨账户访问控制

关键要点

Amazon DynamoDB 是一种无服务器、NoSQL 的全托管数据库服务，能够在任何规模下提供单秒级毫秒延迟。客户越来越多地采用 工作负载隔离策略 来降低安全威胁，同时减轻与 DynamoDB 相关工作负载的合规性要求的复杂度。然而，实施工作负载隔离策略通常需要使用 IAM 身份策略进行跨账户和跨区域对 DynamoDB 资源的访问，这无疑增加了管理和应用的复杂性。客户经常要求我们简化资源访问控制，尤其是在跨账户访问 DynamoDB 资源的情况下。

今天，我们很高兴地宣布 DynamoDB 现已支持基于资源的策略。通过该策略，您可以指定哪些 AWS 身份与访问管理IAM 用户或服务可以访问资源，以及他们可以在其上执行的操作。基于资源的策略可以附加到 DynamoDB 表、索引或流上。使用基于资源的策略的重要好处之一是简化了跨账户访问控制，从而便于与其他 AWS 帐户的 IAM 实体共享资源。

基于资源的策略还支持与 IAM 访问分析器 和 阻止公共访问BPA 功能的集成。IAM 访问分析器可以报告跨账户对资源的访问，以防止策略中出现意外的外部访问定义。此外，BPA 有助于阻止对您的 DynamoDB 表、索引和流的公共访问，并在创建和修改资源based 策略的工作流中自动启用。

在本文中，我们将探讨四种不同的 DynamoDB 授权场景，以及如何实施基于资源的策略来解决它们。

解决方案概述

在这个例子中，我们将探讨基于资源的策略相比于基于身份的策略如何简化跨账户访问控制。假设您有一个多租户应用程序，需要访问一个中央表，以运行每个租户的核心业务逻辑。每个租户Alfa、Bravo 和 Charlie将基础架构部署在自己的 AWS 账户中。我们将首先看一个基于身份的策略的解决方案，然后是一个基于资源的策略的解决方案。

在 DynamoDB 不支持基于资源的策略之前，使用基于身份的策略是唯一的管理访问控制的方法。下图展示了使用基于身份的策略从每个租户读取中央账户信息所需的步骤。

给予 Alfa 租户访问权限的步骤如下：

由于租户 Bravo 和 Charlie 也需要访问中央表，因此您需要重复这两次步骤。

以下是 Lambda 函数的代码示例：

pythonimport boto3

使用 STS 假设在步骤 2 创建的角色。

stsclient = boto3client(sts)stssession = stsclientassumerole(RoleArn=arnawsiamrole/DynamoDBFullAccessFortenantalfa RoleSessionName=testdynamodbsession)

获取在中央账户中启动客户端所需的安全凭证

KEYID = stssession[Credentials][AccessKeyId]ACCESSKEY = stssession[Credentials][SecretAccessKey]TOKEN = stssession[Credentials][SessionToken]REGION =

在中央账户中从租户 Alfa、Bravo 和 Charlie 初始化 boto3 客户端

dynamodbclient = boto3client(dynamodb regionname=REGION awsaccesskeyid=KEYID awssecretaccesskey=ACCESSKEY awssessiontoken=TOKEN)

def lambdahandler(event context) data = dynamodbclientgetitem( TableName=rbaccentraltable Key={PK{Sfoo} SK{Sbar}} ) return data

随着基于资源的策略的引入，您可以为每个资源定义访问控制，例如 DynamoDB 表、索引或流。使用这种方法，您可以避免为每个租户的账户创建和管理账户角色的麻烦，而是实现表级别的集中访问控制，使安全控制更加简单。您可以通过 AWS 命令行界面 (AWS CLI)、AWS 管理控制台、AWS SDK 或 AWS CloudFormation 附加基于资源的策略。

下图展示了使用基于资源的策略进行访问控制的简化架构。

对于使用资源基于策略添加 Alfa、Bravo 和 Charlie 的步骤如下：

使用基于资源的策略，您只需在中央账户中创建一个角色来控制表的访问。更少的策略简化了您对表的访问管理，减少与基于身份的访问相比所需的角色和策略数量。在这个例子中，使用 1 个基于资源的策略与 3 个基于身份的策略和 3 个角色的区别明显。

您可以使用以下代码在 Alfa 账户中创建 Lambda 函数：

pythonimport boto3

dynamodbclient = boto3client(dynamodb)

def lambdahandler(event context) response = dynamodbclientgetitem( TableName=arnawsdynamodbtable/rbaccentraltable Key={PK{Sfoo} SK{Sbar}} ) return response

当您需要在 DynamoDB API 操作中跨账户或跨区域访问 DynamoDB 资源时，需在 API 调用中指定表的完整 ARN，而不是仅仅表名。然而，如果您只提供表名，SDK 会假设您想要访问与 Lambda 函数运行所在的账户和区域相同的资源。

您也可以看到代码复杂性的不同，因为您不需要假设身份基于角色来获取来自 DynamoDB 表的信息；您只需要修改代码以外部方式访问资源。如您所见，从另一个账户访问资源时所需的权限复杂性显著降低，从而提高了管理资源访问控制的效率。

策略示例

使用基于资源的策略，您现在可以指定想要提供访问权限的 IAM 主体，并可以选择以下表中列出的任意一种。

每当您同时使用基于身份的策略和基于资源的策略时，聚合权限将根据 策略评估逻辑 进行评估。在大多数情况下，将适用以下评估逻辑：

您可以配置两种类型的基于资源的策略，一种用于表，另一种用于活动流。请注意，如果您没有启用 Amazon DynamoDB Streams，则您仅会在 DynamoDB 控制台中看到表的基于资源的策略，如下图所示。

让我们看看一些附加到 DynamoDB 表的基于资源的策略示例。

示例 1 为特定用户授予表权限

下面的基于资源的策略附加到 DynamoDB 表 rbaccentraltable，为 IAM 用户 foo 和 foobar 授予 GetItem 操作的权限：

json{ Version 20121017 Statement [ { Sid Statement1 Effect Allow Principal { AWS [ arnawsiam111122223333user/foo arnawsiam111122223333user/foobar ] } Action dynamodbGetItem Resource arnawsdynamodbuseast1444455556666table/rbaccentraltable } ]}

示例 2 为管理员角色授予读取 DynamoDB 流的访问权限

下面的基于资源的策略附加到 DynamoDB 流 20240111T163551514，为管理员角色授予执行 DescribeStream、GetRecords 和 GetShardIterator 动作的权限：

json{ Version 20121017 Statement [ { Sid Statement2 Effect Allow Principal { AWS arnawsiam111122223333role/Admin } Action [ dynamodbDescribeStream dynamodbGetRecords dynamodbGetShardIterator ] Resource arnawsdynamodbuseast1444455556666table/rbaccentraltable/stream/20240111T163551514 } ]}

示例 3 对查询操作为特定用户提供细粒度访问控制

您可以为来自跨账户 IAM 身份的访问 DynamoDB 资源指定权限。例如，您可能需要来自可信账户的用户访问您表的内容，条件是他们只访问特定的项目和这些项目中的特定属性。以下策略允许来自受信 AWS 账户 ID 111111111111 的用户 foo 通过 Query API 访问账户 222222222222 中的表数据。策略确保用户只能访问前缀为 ProductCatalog 的项目，并且用户只能检索属性 ProductName、Inventory 和 DueDate，而不能检索其他属性：

json{ Sid Statement3 Effect Allow Principal { AWS arnawsiam111111111111user/foo } Action dynamodbQuery Resource arnawsdynamodbuseast1222222222222table/rbaccentraltable Condition { ForAllValuesStringEquals { dynamodbLeadingKeys ProductCatalog dynamodbAttributes [ProductName Inventory DueDate] } StringEqualsIfExists { dynamodbReturnValues [NONE UPDATEOLD UPDATENEW] dynamodbSelect SPECIFICATTRIBUTES } }}

示例 4 根据源 IP 地址或 VPC 端点向管理员角色授予对表的完全访问权限

您可以应用条件来限制源 IP 地址、VPC 和 VPC 端点。您可以根据请求的源地址指定权限。例如，您可能希望允许用户仅在特定 IP 来源例如企业 VPN 端点时才能访问 DynamoDB 资源。在 Condition 语句中指定这些 IP 地址：

json{ Sid Statement4 Effect Allow Principal { AWS arnawsiam111122223333role/Admin } Action dynamodb Resource arnawsdynamodbuseast1444455556666table/rbaccentraltable Condition { IpAddress { awsSourceIp [542401430/24 2001DB812345678/64] } }}

您还可以拒绝对 DynamoDB 的所有访问，除了源来自特定 VPC 端点的情况下：

json{ Sid Statement5 Effect Deny Principal { AWS arnawsiam111122223333role/Admin } Action dynamodb Resource arnawsdynamodbuseast1444455556666table/rbaccentraltable Condition { StringNotEquals { awsSourceVpce vpce1a2b3c4d} }}

结论

在本文中，我们展示了如何通过 DynamoDB 的基于资源的策略简化多个团队或应用程序在共享资源时的跨账户访问。使用基于资源的策略不会产生额外的费用，您可以通过 AWS 控制台、AWS API、AWS CLI、AWS SDK 或 AWS CloudFormation 开始使用。要了解更多信息，请参阅 使用基于资源的策略与 DynamoDB。

关于作者

Esteban Serna 是高级 DynamoDB 解决方案架构师。他在过去 15 年里一直从事数据库工作，帮助客户选择与其需求相匹配的架构。在大学毕业后，他负责在多个分布位置部署支持呼叫中心所需的基础设施。当 NoSQL 数据库被引入时，他便对其产生了兴趣，并决定专注于此，因为集中计算已不再是常态。如今，Esteban 专注于帮助客户设计需要单秒级毫秒延迟的大规模分布式应用程序，这些应用程序使用 DynamoDB。有人说他是一本开卷书，并热衷于与他人分享知识。

Ashwin Venkatesh 是亚马逊网络服务AWS中 Amazon DynamoDB 的高级产品经理，工作地点在加利福尼亚州圣克拉拉。在产品管理和技术领域拥有 25 年以上的经验，Ashwin 热衷于