Amazon S3桶及对象公访问限制策略问题排查

一、首个S3桶策略失效的核心原因 #

你的第一个桶策略存在JSON语法错误，这直接导致整个策略被AWS忽略，完全无法生效。看策略代码里的这段：

}, { "Sid": "DenyPublicReadGrant", ... } },, { "Sid": "DenyPublicListACL", ... }

在DenyPublicReadGrant这个Statement结束后，多了一个额外的逗号（},, {），属于无效JSON格式。AWS对桶策略的语法要求严格，任何语法错误都会让整个策略不被应用，自然无法阻止你设置公开访问权限。

除了语法错误，第一个策略还存在覆盖场景不全的问题：

• 它只针对通过x-amz-acl头设置的公开ACL，没有阻止通过S3控制台的公共访问权限设置（比如关闭"阻止公有访问"的四个开关）来开放桶——不过这类设置需要用IAM策略或组织SCP来限制，桶策略本身无法管控。
• 没有阻止用户添加允许公共访问的桶策略语句（比如直接给Principal: "*"加允许权限），这类操作需要用IAM策略限制s3:PutBucketPolicy动作。

二、资源数组顺序的影响 #

你问到S3桶策略中Resource数组的顺序是否重要——实际上它不影响权限评估逻辑。AWS会评估所有匹配请求资源的Statement，不管数组里的顺序如何。拒绝语句（Deny）永远优先于允许语句（Allow），资源的排列顺序不会改变匹配结果。

不过需要注意：如果Resource包含通配符（比如arn:aws:s3:::ironman111/*），它会匹配所有子对象，但顺序不影响哪个Resource先被匹配，AWS会检查所有符合条件的Resource对应的Statement。

三、后续IAM策略的问题及修复 #

你添加的IAM策略无法阻止创建公开桶，原因有两个：

1. s3:CreateBucket动作在请求时不会携带s3:x-amz-acl请求头，所以你的Condition对这个动作完全无效，永远不会触发拒绝。
2. 它只覆盖了通过PutBucketAcl设置公开ACL的场景，没有阻止用户在创建桶后通过控制台修改公共访问设置（比如关闭阻止公开访问的开关）。

要有效阻止桶被设为公开，你可以调整IAM策略覆盖更多场景：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPublicBucketCreationAndModification",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketAcl",
        "s3:PutBucketPolicy",
        "s3:PutPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "Or": [
          {
            "StringEquals": {
              "s3:x-amz-acl": [
                "public-read",
                "public-read-write",
                "authenticated-read"
              ]
            }
          },
          {
            "StringLike": {
              "s3:RequestPolicy": "*Principal:*\"*\"*"
            }
          },
          {
            "BoolIfExists": {
              "s3:BlockPublicAcls": "false"
            }
          }
        ]
      }
    }
  ]
}

这个策略做了这些改进：

• 包含了修改公共访问设置的s3:PutPublicAccessBlock动作，阻止用户关闭阻止公开访问的核心开关。
• 阻止添加包含公共Principal的桶策略（通过s3:RequestPolicy检查）。
• 移除了无效的CreateBucket关联——因为创建桶本身无法直接设置公开状态，重点管控后续的权限修改动作。

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