使用 Athena 时是否可以基于 partition-Id 对 s3 进行细粒度访问控制

Question

我们将 S3 用于我们的数据湖，其中 customerId 作为 partitionId。 Athena 用于查询这个数据湖。

在 DDB 和 S3（使用 SDK）中查询数据时，我们使用细粒度的访问控制。

有没有办法使用 Athena 来确保在存储级别也施加细粒度的访问控制，而不是仅仅基于内存中的 customerId 进行过滤？

Answer 1

Athena 中的权限（假设您不使用 Lake Formation）是 Athena、Glue 和 S3 权限的组合。 S3 权限是最重要的权限，因为它们控制用户可以访问哪些数据。

如果您的数据按客户 ID 进行分区，则意味着每个客户的数据都位于 S3 上的不同前缀中。当您为用户创建 IAM 权限时，您将能够将该用户的权限限定为一个或多个前缀。

以下是仅在特定前缀中授予 GetObject 权限的 IAM 语句片段。

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": ["arn:aws:s3:::bucket_name/prefix_including_customer_id/*"]
}

Resource 值是一个数组，您可以指定多个前缀。

您还需要授予s3:ListBucket 权限。如果获取对象列表不敏感，您可以为整个存储桶授予此权限，否则您需要稍微不同的语句来将列表权限限制为相同的前缀：

{
  "Effect": "Allow",
  "Action": ["s3:ListBucket"],
  "Resource": ["arn:aws:s3:::bucket_name"],
  "Condition": {
    "StringLike": {
      "s3:prefix": ["prefix_including_customer_id/*"]
    }
  }
}

使用包含这些类型语句的策略，用户将只被允许读取他们有权访问的对象，并且尝试读取其他对象，例如运行SELECT * FROM customer_data 之类的查询将导致访问被拒绝错误。只有当他们运行一个查询来过滤与他们有权访问的 S3 前缀匹配的分区键时，查询才会成功。

用户仍然可以看到分区键的所有值（只是不能看到分区内的数据），这是不可避免的。