首页 文章

AWS IAM基于用户的策略与基于资源的策略相比

提问于
浏览
1

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

假设一个提供对DynamoDB表的完全访问权限:

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

根据此策略,任何以某种方式结束附加到其上的策略的用户(通过假设某个角色或直接作为例子)都可以完全访问该DynamoDB表 .

Question 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授予这些权限 .

Question 2 :使用更严格的资源政策 only 可能更好吗?

Question 3 :通常,是否有基于用户和基于资源的策略之间选择的最佳实践/模式(对于支持基于资源的策略的服务)?

2 回答

  • 0

    答案0:DynamoDB不支持基于资源的策略 .

    Console GUI看起来像它,但API没有操作 . 文档很清楚:http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html#access-control-manage-access-resource-based

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

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

    • 必须正确快速地设置新员工的权限(他们希望工作!)

    • 必须迅速删除离职者的许可(无论出于何种原因)

    • 有人必须定期检查权限并批准它们

    如果只有一个位置可供查找,则上述所有3个任务都要容易得多 . 如果要限制访问,请使用“效果”:“拒绝” . 审查将 grab 任何“意外转让” .
    答案1b:
    当然这取决于用例(例如4眼原则可以要求它) . 并且某些权限无法在IAM中设置(例如“Everyone”)并且必须在资源上设置 . 或者,如果销毁/重新创建资源,则基于资源的权限将消失 .

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

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

    答案3:最佳做法

    不幸的是,我不知道AWS发布的最佳实践,当然除了“最小权限” . 我建议您在可维护性方面采用最佳实践,以及AWS之外的其他权限 .

  • 0

    你所有问题的答案都是 it depends

    IAM策略和资源策略同样重要取决于用例 .

    假设您想要为AWS托管服务提供权限,例如提供对 Cloud 端的权限以读取s3存储桶..最好使用资源策略...

    但是对于上传/更改内容,最好通过IAM政策..

    简单来说,最好在从一些用户/外部系统/用户管理的实例提供访问时使用IAM策略,并在AWS托管服务之间提供访问使用资源策略 .

相关问题