DynamoDB访问控制模型及应用访问权限配置疑问

我完全懂这种从MySQL的传统用户权限逻辑切换到DynamoDB时的困惑——两者的权限设计思路确实差得挺远！让我一步步帮你理清：

核心差异：MySQL vs DynamoDB权限模型 #

MySQL是数据库层面的用户+权限：你在数据库内创建用户，直接给这个用户分配表级别的读写权限，应用用这个用户的账号密码登录。

而DynamoDB是基于AWS IAM（身份访问管理）的全局权限模型：所有访问DynamoDB的请求都要经过IAM的身份验证和授权，不存在“数据库内用户”这一说——你需要给应用关联一个IAM身份（用户或角色），然后通过IAM策略来定义这个身份能访问哪些DynamoDB资源、能执行哪些操作。

给Node应用配置DynamoDB访问权限的正确步骤 #

你想要的“登录权限”其实就是给应用分配一个仅能访问目标表的IAM身份，具体步骤如下：

1. 创建专用IAM身份

   • 推荐用IAM角色（如果你的Node应用部署在AWS托管服务上，比如Lambda、ECS、EC2）：角色可以让应用自动获取临时凭证，不用硬编码密钥，更安全。
   • 如果是本地或第三方服务器部署，用IAM用户：记得不要给这个用户附加任何管理员权限，只保留必要的DynamoDB访问权限。

2. 附加最小权限的IAM策略
   给这个IAM身份绑定一个仅允许访问目标表的策略，只包含应用需要的操作（比如读、写、更新），绝对不要给全表/全DynamoDB权限。示例策略如下：

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "dynamodb:GetItem",
           "dynamodb:PutItem",
           "dynamodb:UpdateItem",
           "dynamodb:DeleteItem"
         ],
         "Resource": "arn:aws:dynamodb:你的区域:你的账号ID:table/你的表名"
       }
     ]
   }
   

   替换里面的区域、账号ID和表名即可。

3. 让Node应用获取凭证

   • 如果是AWS托管服务：直接给服务关联创建好的IAM角色，AWS SDK会自动从环境中获取临时凭证，无需手动配置。
   • 如果是本地/第三方服务器：给IAM用户生成Access Key和Secret Key，然后通过环境变量（比如AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY）传给Node应用，绝对不要硬编码到代码里！

关于策略管控的疑问：谁能创建全权限策略？ #

你担心“任何人都能创建访问所有表的策略”，其实AWS IAM本身有严格的管控机制：

• 默认情况下，只有拥有iam:CreatePolicy、iam:AttachPolicy等IAM管理权限的用户（比如管理员）才能创建和附加策略，普通用户没有这些权限。
• 你可以通过**权限边界（Permission Boundaries）**限制用户能创建的策略范围，比如只允许用户创建访问特定DynamoDB表的策略。
• 还可以用IAM组来统一管理用户权限，避免单个用户拥有过高权限；同时开启CloudTrail审计所有IAM操作，谁创建了什么策略、什么时候操作的都能追溯。
• AWS的Access Analyzer还能自动检测过度宽松的策略，帮你及时修正权限问题。

为什么DynamoDB表页面的Access Control标签不是给IAM用户的？ #

那个标签是用于**联合身份（比如Facebook/Google登录的终端用户）**的细粒度访问控制，属于AWS Cognito联合身份的范畴，和给后端应用用的IAM权限完全是两回事，你不用在那里配置。

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