如何为多角色多环境场景构建S3存储桶访问控制架构？

一、存储结构优化建议 #

你的初步分层思路是可行的，建议细化为标准化路径，便于后续权限配置和维护：

• 公开资源路径：s3://<你的桶名>/<env>/<user-id>/assets/（存放头像等公共数据）
• 私密文档路径：s3://<你的桶名>/<env>/<user-id>/generated_docs/（存放用户私密生成文档）
  其中<env>为dev/test/prod，<user-id>用内部系统的唯一用户标识（避免用户名重复或变更的问题）。

二、权限控制实现方案 #

核心采用IAM联合身份认证+基于属性的访问控制（ABAC）+S3桶策略的组合，避免直接创建大量IAM用户，同时满足角色权限需求：

1. 身份基础配置 #

不要为每个用户创建AWS IAM用户，而是通过企业内部身份系统（如AD、内部SSO）以SAML或OIDC方式联合到AWS，用户用内部账号登录后获取临时AWS凭证，所有权限基于用户的内部身份属性（如user-id、role、team-id）配置。

2. 分角色权限策略 #

• ROLE_USER：仅允许访问自身目录下的资源
  策略示例（通过user-id属性限制）：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["s3:GetObject", "s3:PutObject"],
        "Resource": [
          "arn:aws:s3:::<你的桶名>/*/${user-id}/assets/*",
          "arn:aws:s3:::<你的桶名>/*/${user-id}/generated_docs/*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": "arn:aws:s3:::<你的桶名>",
        "Condition": {
          "StringLike": {
            "s3:prefix": ["*/${user-id}/assets/*", "*/${user-id}/generated_docs/*"]
          }
        }
      }
    ]
  }
  

• ROLE_TEAMLEAD：允许访问自身及团队所有成员的私密文档，同时可访问自身公开资源
  基于team-id属性实现，策略示例：

  {
    "Version": "2012-10-17",
    "Statement": [
      // 自身资源权限
      {
        "Effect": "Allow",
        "Action": ["s3:GetObject", "s3:PutObject"],
        "Resource": [
          "arn:aws:s3:::<你的桶名>/*/${user-id}/assets/*",
          "arn:aws:s3:::<你的桶名>/*/${user-id}/generated_docs/*"
        ]
      },
      // 团队成员私密文档权限
      {
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::<你的桶名>/*/*/generated_docs/*",
        "Condition": {
          "StringEquals": {
            "s3:ResourceTag/team-id": "${team-id}"
          }
        }
      },
      // 列表权限
      {
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": "arn:aws:s3:::<你的桶名>",
        "Condition": {
          "StringLike": {
            "s3:prefix": ["*/${user-id}/*", "*/*/generated_docs/*"]
          },
          "StringEquals": {
            "s3:ResourceTag/team-id": "${team-id}"
          }
        }
      }
    ]
  }
  

  注：需提前为每个用户目录添加team-id标签，用户转组时只需更新标签即可。

• ROLE_ADMIN：允许访问所有环境下的所有资源
  策略示例：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::<你的桶名>",
          "arn:aws:s3:::<你的桶名>/*"
        ]
      }
    ]
  }
  

三、疑问解答 #

1. 创建用户组是否合理？ #

非常合理，这是降低权限维护成本的关键方案：

• 结合team-id属性或IAM用户组，团队负责人变更时，只需调整用户组的负责人权限或更新用户的team-id属性，无需修改大量IAM策略；
• 用户转组时，仅需更新其team-id标签或用户组归属，权限会自动生效，操作效率极高。

2. 为每位用户创建AWS账户是否合理？ #

完全不合理，原因如下：

• 管理成本极高：80个IAM用户的密钥轮换、权限变更、身份生命周期管理会消耗大量运维精力；
• 安全性差：IAM用户的长期密钥存在泄露风险，而联合身份认证使用临时凭证，安全性更高；
• 扩展性差：后续用户增长时，IAM用户的数量限制和管理复杂度会呈指数级上升。

四、参考资料 #

• AWS基于属性的访问控制（ABAC）最佳实践
• S3存储桶权限设计指南
• AWS联合身份认证（SAML/OIDC）实施文档

内容的提问来源于stack exchange，提问作者Adrian