适用于只能访问特定 S3 存储桶的 IAM 组的 AWS CloudFormation 模板

Question

here 已经提出了关于此主题的类似问题，但该帖子中的任何解决方案均不适合我，而且它已经很老了，这让我相信 AWS 中可能发生了一些变化，需要询问新问题。

基本上，我使用 CloudFormation 模板来定义具有内联策略的 IAM 组，以便其用户只能访问单个 S3 存储桶。根据链接的问题，我得到了以下模板（原始帖子使用 JSON，但我使用的是 YAML）：

BucketAccessGroup:
    Type: AWS::IAM::Group
    Properties:
      GroupName: my-bucket-admins
      Path: /my-bucket-admins/
      Policies:
      - PolicyName: MyBucketAccess
        PolicyDocument:
          Version: 2012-10-17
          Statement:
          -
            Effect: Allow
            Action: s3:*
            Resource:
            - arn:aws:s3:::my-bucket-name
            - arn:aws:s3:::my-bucket-name/*
          -
            Effect: Allow
            Action: s3:ListAllMyBuckets
            Resource: "*"

不幸的是，该组中的 IAM 用户不仅可以列出所有其他存储桶（控制台访问所需），还可以打开、修改和删除它们及其对象！显然这不是理想的行为！ AWS 是否发生了一些变化，导致该策略不再有效？策略在 CloudFormation 模板中的工作方式与其在其自身中的工作方式不同吗？任何帮助将不胜感激！

编辑：

正如@wjordan 的回答中所述，事实证明，另一个策略已经为该组提供了完整的 S3 权限。我正在添加 AWSLambdaFullAccess 托管策略，它意外地有一个允许 s3:* 行（我忽略了上面的代码 b/c，我认为它不相关！）。鉴于需要与该策略共存，这是我更新的 CF 模板，它按预期工作，而且更安全：

  BucketAccessGroup:
    Type: AWS::IAM::Group
    Properties:
      GroupName: my-bucket-admins
      ManagedPolicyArns: [ "arn:aws:iam::aws:policy/AWSLambdaFullAccess" ]
      Policies:
      - PolicyName: MyBucketAccess
        PolicyDocument:
          Version: 2012-10-17
          Statement:
          - # Prevent changing permissions in any way on the desired bucket
            Effect: Deny
            Action:
            - s3:DeleteBucket
            - s3:DeleteBucketPolicy
            - s3:PutBucketPolicy
            - s3:PutBucketAcl
            Resource:
            - arn:aws:s3:::my-bucket-name
            - arn:aws:s3:::my-bucket-name
          - # Prevent all S3 actions except listing buckets, on everything except the desired bucket (AWSLambdaFullAccess already allows s3:*)
            Effect: Deny
            NotAction: s3:ListAllMyBuckets
            NotResource:
            - arn:aws:s3:::my-bucket-name
            - arn:aws:s3:::my-bucket-name

Answer 1

对我来说，提供的政策看起来正确且没有过时。您确定有问题的 IAM 用户在指定的 AWS::IAM::Group 之外没有应用任何额外的组/策略来授予他们意外的权限？

确认这一点的一种方法是从头开始创建一个新的 IAM 用户并尝试在那里重现该问题。