【问题标题】:Group-based Access to S3 Buckets对 S3 存储桶的基于组的访问
【发布时间】:2021-03-09 17:01:24
【问题描述】:

TL;DR:我需要在 S3 中构建我的数据架构,以使我在 S3 存储桶配额范围内(截至 2020 年 11 月,默认情况下最大为 100 个存储桶),但同时限制对文件的访问为不同的组,并进一步限制子组之间的访问。是否有实现此目的的程序化解决方案?

我正在开发一款应用,需要根据组织身份/组/角色来限制对组织存储文件和内容的访问。但是,在该组织内,需要基于子组的进一步访问限制。下面举例说明。

所需用例

宠物用户都是宠物,只是宠物的种类不同。它们的品种进一步区分。我不希望猫能够访问任何其他宠物类型的文件,它们只能访问猫目录/存储桶。此外,特定于品种的文件夹应该只能由该品种的成员访问。

示例:虎斑猫可以访问Cats/Cats/TabbyCats,但不能访问Dogs/Cats/CalicoCats

问题

在此示例中,宠物类型远远超过 100 种。因此,它们将超过 S3 中的 100 个存储桶配额。我认为每种宠物类型都有自己的桶是不可行的。报价可以增加到 1000,但这会产生额外的成本,并且对于我的应用程序而言仍然不能很好地扩展。

此外,截至 2020 年 11 月,Cognito 用户池被限制为 10,000 个组/用户池。虽然这看起来很多,但它并不适用于用例。以下是我想到的排列及其各自的问题(我省略了与已经提到的具有相同问题的排列过于相似的排列):

  • 2 组,{宠物类型}/{宠物品种},带有 1 个桶/宠物类型 - 示例:DogWeenie Dog 组。 Dog 组授予对Dog/ 的访问权限,Weenie Dog 授予对Dog/WeenieDog 的访问权限,并附加了授予对各个存储桶/目录的访问权限的 IAM 角色。 这可能是可扩展性最低的排列。它将快速消耗组每个用户池配额以及存储桶配额。

  • 1 个组,{Pet Breed},存储桶根据应用资源分类 - 示例:Weenie Dog 组授予对 {Bucket}/Dog/{Bucket}/Dog/WeenieDog 的访问权限。 此解决方案修复了存储桶配额问题但不能解决 Cognito 用户组的可扩展性问题。

问题

如何向某些用户组授予对 S3 中不同存储桶或目录的编程访问权限?该解决方案不一定要特别涉及 Cognito 用户组/IAM,我对其他人开放,因为 Cognito 用户组/IAM 不能很好地扩展。是否有任何程序化解决方案?

咨询的其他资源

Restricting S3 resources based on a user's group - 非常适用于我的用例,但仍未解决

我在这里看到的其他问题尚未解决或已过时。

【问题讨论】:

  • 您是否尝试过 IAM Role Policy 和 S3 Policy 中的语句条件
  • @MahdiRidho 我已经考虑过这一点,但不知道如何根据自定义 Cognito 属性创建条件。组和对象标签不能很好地适应我的预期用途。您对我如何使用这些有什么想法吗?
  • 如果您为用户角色实现具有联合身份的 sdk,我可以回答并给出一个示例案例。我们将组从 cognito 用户池映射到身份池,然后将策略条件设置为前缀为 identity_group/identity_id -> ${cognito-identity.amazonaws.com:aud}/${cognito-identity.amazonaws.com:子}

标签: amazon-web-services amazon-s3 amazon-cognito


【解决方案1】:

我看到两个选项:

  1. 使用 aws 策略
  2. 自定义授权

使用 AWS 策略

有一种方法可以根据资源前缀或资源标签来允许/拒绝对 S3 资源的访问。因此,您可以使用单个存储桶,只需使用身份属性或对象标签(例如允许的组列表)构建对象键前缀。

优势 - 此选项看起来更简单,因为仅使用原生 aws 功能,您不需要任何其他组件。并且授权本身是由 aws 执行的。可能适用于简单的规则。

但是 - 解决方案可能非常僵化 - 一旦针对特定的要求、约束和假设集构建,新的要求可能会完全破坏已实施的逻辑。我认为将语义放入标识符(授权放入 s3 前缀)是一种不好的做法

是否有实现此目的的程序化解决方案?

  1. 自定义授权

您可以实现自定义授权组件。

基本上,您可以实现一个逻辑,该逻辑基于请求者身份和被请求对象将决定用户是否有权访问所请求的对象,然后返回一个预签名的 url(或不返回)。在这里,您将细粒度的授权逻辑置于策略之外。 lambda 函数的用例。

缺点是您必须实施和维护额外的决策组件。

优势在于更大的控制力和灵活性——它也可以使用资源或身份标记或 S3 前缀,但如果授权要求发生变化,则无需更改对象存储或应用程序本身。并且只使用更灵活的东西(例如策略不支持的 authz 逻辑,具有 ACL 对象的数据库,..)

云解决方案中最常见和最严重的漏洞之一是过于开放或错误实施的用户定义策略。因此,如果可以,请保持政策简单有效。

【讨论】:

  • 这是一个很好的回应。我同意第一个选项对于数据结构是刚性的,因此是不可取的。我想澄清一下我理解第二种解决方案,因为基于以下理解我非常喜欢它:使用 AWS API (gql/REST),我可以使用自定义授权方查询 Lambda 函数,该授权方充当网守和排序帽子用户可以或不能访问哪些文件?其次,如果这是正确的,我会根据每个用户拥有的必需的自定义用户池属性拒绝/接受用户访问吗?还是有更好的方式拒绝/接受访问?
猜你喜欢
  • 2018-02-11
  • 1970-01-01
  • 1970-01-01
  • 2020-01-14
  • 2014-10-21
  • 1970-01-01
  • 2018-08-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多