Question

我们假设基于用户的 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 ：一般情况下，基于用户的与基于资源的政策之间是否存在选择的最佳做法/模式（适用于支持基于资源的策略的服务是什么？

Answer 1

所有问题的答案都是取决于

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

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

但是要上传/更改内容，最好通过IAM政策..

简单来说，在提供来自某些用户/外部系统/用户管理的实例的访问时，以及在AWS托管服务之间提供访问权限使用资源策略时，最好使用IAM策略。

Answer 2

这取决于您是在同一个aws帐户中还是跨帐户请求进行请求。

在同一个AWS账户中，这意味着您的用户属于拥有资源（S3，SQS，SNS等）的AWS账户，您可以具有基于身份的（用户，组，角色）或基于资源的策略（ SQS，SNS，S3，API网关）。参考：https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow

但是，当您将访问权限委派给其他AWS账户时。可能会有所不同。对于API网关，例如，您需要来自基于身份的角色和基于资源的显式允许。

来源：API Gateway Authorization Flow

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

2 个答案: