Amazon s3 AWS政策评估

我有一个IAM角色要附加到microservice，以便基于用户代理限制S3文件夹访问。microservice父帐户和bucket所有者相同

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-test/service/${aws:useragent}/*"
            ]
        },
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::bucket-test"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "service/${aws:useragent}/*"
                    ]
                }
            }
        }
    ]
}

同一个S3 bucket具有默认ACL，其中帐户对对象和权限具有R/W权限

考虑到ACL和IAM策略，我不理解该策略的评估结果。例如，具有上述角色的用户使用用户代理

micro-a

向

bucket test/service/micro-b/new\u object

发出

put\u object

请求。这是明确的还是隐含的否定？为什么？

基于：

当发出请求时，AWS服务决定是允许还是拒绝给定的请求。评估逻辑遵循以下规则：

默认情况下，所有请求都被拒绝。（一般而言，提出的请求 为帐户中的资源使用帐户凭据是 始终允许。）

显式的“允许”将覆盖此默认值

显式拒绝覆盖任何允许

现在如果我们看看：

效果–当用户请求允许或拒绝特定操作时会产生什么效果。 如果未显式授予（允许）资源访问权限，则访问将被隐式拒绝。您还可以显式拒绝对资源的访问，您可以这样做，以确保用户无法访问该资源，即使不同的策略授予访问权限

现在指定：

访问策略语言允许您在授予权限时指定条件。条件元素（或条件块）用于指定策略生效时的条件

从这三部分，特别是最后一部分，我们可以说您的案例是“条件允许”，因为“条件元素”允许您指定策略生效时的条件，而您的策略中的条件是“允许”

编辑： 这里是AWS上另一个有趣的博客

每当AWS主体向S3发出请求时，授权决策取决于所有应用的IAM策略、S3 bucket策略和S3 ACL的联合

根据最小特权原则，决策默认 否认和明确否认总是胜过允许。例如，如果 IAM策略授予对对象的访问权限，即S3 bucket策略 拒绝对该对象的访问，并且不存在S3 ACL，则将拒绝访问 被拒绝。类似地，如果没有方法指定允许，则 默认情况下，请求将被拒绝。仅当没有方法指定拒绝时 并且一个或多个方法指定允许请求的方法

---

我看过那些文件了。仍然不能回答这是一个明确的/隐含的否定，还是允许以及为什么。一个政策从来都不是一个隐含的东西。根据定义，政策总是明确的。对所有策略进行评估。如果有另一个策略允许此策略允许的内容的超集，则此策略没有任何作用。唯一隐式的是默认的隐式拒绝，它存在于没有适用的显式允许的情况下。