我们需要创建一个允许访问我们客户端S3帐户中的存储桶的IAM用户(前提是他们允许我们访问这些存储桶)。
我们已在帐户中创建了一个IAM用户,其中包含以下内联政策:
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:PutObjectAcl",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:ListBucketMultipartUploads",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
}
]
}
除此之外,我们还会要求客户使用以下政策并将其应用到相关的存储桶中:
{
"Version": "2008-10-17",
"Id": "Policy1416999097026",
"Statement": [
{
"Sid": "Stmt1416998971331",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::229569340673:user/our-iam-user"
},
"Action": [
"s3:AbortMultipartUpload",
"s3:PutObjectAcl",
"s3:ListMultipartUploadParts",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::client-bucket-name/*"
},
{
"Sid": "Stmt1416999025675",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::229569340673:user/our-iam-user"
},
"Action": [
"s3:ListBucketMultipartUploads",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::client-bucket-name"
}
]
}
虽然这一切似乎都运行良好,但我们发现的一个主要问题是我们自己的内部内联策略似乎可以让我们的iam-user完全访问我们所有内部存储桶。
我们是否错误配置了某些内容,或者我们是否遗漏了其他显而易见的内容?
答案 0 :(得分:1)
根据AWS支持,这不是解决问题的正确方法: https://forums.aws.amazon.com/message.jspa?messageID=618606
我在这里复制他们的答案。
AWS:
您与IAM用户一起使用的政策授予对任何Amazon S3存储分区的访问权限。在这种情况下,这将包括您帐户中的任何S3存储桶以及帐户所有者已授予您用户访问权限的任何其他帐户中的任何存储桶。您希望更具体地了解您的IAM用户的政策。例如,以下策略将限制您的IAM用户访问单个存储桶。
如果用户需要访问多个存储桶,您还可以授予对存储桶阵列的访问权限。
我
不幸的是,在创建内联策略时,我们事先并不知道所有客户端的存储桶名称。随着越来越多的客户使用我们的服务,继续向内联策略添加新的客户端存储桶名称是不切实际的。
我想另一种选择是创建一个仅用于上述目的的新AWS账户 - 即该账户本身不拥有任何东西,并且只会用于上传到客户端存储桶。
这是否可以接受,或者我们还有其他选择吗?
AWS
拥有单独的AWS账户将提供明确的安全边界。请记住,如果您在该其他帐户中创建了一个存储桶,则在您授予对“arn:aws:s3 ::: *”的访问权限时,用户将继承对任何存储桶的访问权。
另一种方法是使用黑名单(注意上面提到的白名单是一种更好的做法)。
如您所见,第二个语句明确拒绝访问存储桶数组。这将覆盖第一个参数中的allow。这里的缺点是,默认情况下,用户将继承对任何新存储桶的访问权限。因此,您需要努力将新桶添加到黑名单中。这两种方法都要求您保持对策略的更改。因此,我建议您之前的策略(即白名单),您只允许访问用户需要的S3存储桶。
<强>结论强> 出于我们的目的,白名单/黑名单方法是不可接受的,因为我们不知道客户提供的所有桶。最后,我们采用了单个用户创建新AWS账户的路线,并且该用户没有自己的s3存储桶
答案 1 :(得分:-1)
您授予内部用户的策略允许此用户访问所列API的所有S3存储桶(您问题中的第一个策略)。这是不必要的,因为您的客户端的存储桶策略将授予您的用户访问客户端存储桶所需的权限。
要解决您的问题,请在允许的[资源]列表中删除用户策略 - 或 - 明确您的客户端存储桶,而不是使用“*”