AWS IAM 基于用户的策略 vs 基于资源的策略 vs 两者

Question

让我们假设一个基于用户的IAM 策略，即可以附加到用户、组或角色的IAM 策略。

假设一个可以完全访问 DynamoDB 表的程序：

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-west-2:123456789:table/Books"
  }
}

基于此策略，任何以某种方式最终将策略附加到他们的用户（例如通过承担角色或直接）都可以获得对该 DynamoDB 表的完全访问权限。

问题 1：是否值得在另一端（即 DynamoDB 表）制定基于资源的策略来补充基于用户的策略？

例子：

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:user/bob"},
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}

这里的动机是，先前的策略可能最终会意外地附加到某人，而使用基于资源的策略将确保只有用户Bob将被授予这些权限。

问题 2：使用更严格的资源策略是否 只是更好？

问题3：一般情况下，是否有采摘之间任何的最佳做法/模式基于用户的VS基于资源的策略（即支持服务基于资源的政策是）？

Answer 1

答案 0：DynamoDB 不支持基于资源的策略。

控制台 GUI 看起来很像，但 API 没有相应的操作。文档很清楚：http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html#access-control-manage-access-resource-based

答案 1：不要在同一资源上使用 IAM 和资源策略

访问控制的挑战是长期维护它：

• 必须正确、迅速地设置新员工的权限（他们想要工作！）
• 必须迅速取消离职者的权限（无论出于何种原因）
• 必须有人定期审查权限并批准它们

如果只需要寻找一个位置，那么上述所有 3 个任务都会容易得多。如果您想限制访问，请使用“效果”：“拒绝”。任何“意外分配”都会被审查发现。

答案 1b：

当然这取决于用例（例如4眼原则可以要求它）。有些权限无法在 IAM 中设置（例如“Everyone”），必须在资源上设置。或者，如果您销毁/重新创建资源，基于资源的权限就会消失。

答案 2：IAM 策略更易于管理

如果情况允许 IAM 和资源策略，它们具有相同的语法并且可以同样严格，至少在您的情况下是这样。假设所有其他条件相同，IAM 策略更容易管理。

答案 3：最佳实践

不幸的是，除了“最低权限”之外，我不知道 AWS 发布了最佳实践。对于 AWS 之外的其他权限，我建议您采用可维护性方面的最佳实践。