2015-04-21 69 views
2

我们需要创建一个允许我们在客户的S3账户中访问存储区的IAM用户(前提是他们允许我们访问这些存储区)。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用户所有我们自己的内部桶。

我们是否错配了某些东西,或者我们在这里丢失了其他明显的东西?

+0

如果外部账户授予您账户中特定IAM用户的权限,第一项政策似乎不必要你能删除它并确认吗? –

回答

1

根据AWS支持,这是不正确的方式解决问题: https://forums.aws.amazon.com/message.jspa?messageID=618606

我在这里复制他们的答案。

AWS:

您与您的IAM用户访问权限授予任何亚马逊S3存储使用策略。在这种情况下,这将包括您帐户中的任何S3存储桶以及帐户所有者授予您用户访问权限的任何其他帐户中的任何存储桶。您需要更加具体地了解您的IAM用户的政策。例如,以下策略将限制您的IAM用户访问单个存储桶。

如果用户需要访问多个存储桶,也可以授予对存储桶数组的访问权限。

不幸的是,我们不事先知道所有客户的名字桶时,我们创建内嵌政策。随着我们越来越多的客户加入我们的服务,不断增加新的客户端存储桶名称到内联策略中是不切实际的。

我想另一个选择是创建仅用于上述目的的新的AWS账户 - 即此帐户本身并不拥有任何东西,并且将只被用于上传到客户端的桶。

这是可以接受的,还是有任何其他替代选择对我们开放吗?

AWS

拥有一个独立的AWS账户将提供明确的安全边界。请记住,如果您曾在其他帐户中创建存储桶,则如果您授予对“arn:aws:s3 ::: *”的访问权限,用户将继承对任何存储桶的访问权限。

另一种方法是使用黑名单(注意上面建议的白名单是一种更好的做法)。

正如你所看到的,第二条语句显式拒绝访问一个桶数组。这将覆盖第一个语句中的允许。这里的缺点是默认情况下用户会继承对任何新桶的访问。因此,您需要努力将新桶添加到黑名单。无论采用哪种方法,都需要您保持对政策的更改。因此,我推荐我以前的策略(又名白名单),只允许用户访问S3存储桶。

结论 对于我们而言,在白名单/黑名单的做法是不能接受的,因为我们不认为会被我们的客户提供所有的桶之前知道。最后,我们开始创建一个用户的新AWS账户,并且该用户没有自己的s3存储桶

0

您授予内部用户的策略给该用户所有的S3存储接入上市的API(你的问题的第一个策略)。这是不必要的,因为您的客户端存储桶策略会授予您的用户访问客户端存储桶所需的特权。

解决您的问题,删除用户策略 - 或 - 明确您的客户在允许[资源]清单斗,而不是使用“*”