S3桶策略-获得隐式允许
在使用下面的桶策略时，我看到它按照预期限制PUT访问，但是允许对所创建的对象进行GET，即使不应该允许此操作。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPut",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<BUCKET>/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"<IP ADDRESS>"
]
}
}
}
]
}我可以使用curl将文件从<BUCKET>放到<IP ADDRESS>中，如下所示：
curl https://<BUCKET>.s3-<REGION>.amazonaws.com/ --upload-file test.txt文件上传成功，并显示在S3控制台中。由于某种原因，我现在可以从互联网上的anywhere获得该文件。
curl https://<BUCKET>.s3-<REGION>.amazonaws.com/test.txt -XGET这只适用于使用上述方法上载的文件。当在S3网络控制台上传文件时，我无法使用curl来获得它(访问被拒绝)。因此，我假设这是一个对象级别的权限问题。虽然我不明白为什么桶策略不会隐式地拒绝这种访问。
当查看控制台中的对象级权限时，通过控制台上传的文件(方法1)与从允许的<IP ADDRESS>上传的文件(方法2)之间的唯一区别是，方法2中的文件没有“所有者”、权限或元数据，而方法1文件具有所有这些。
此外，当尝试使用Lambda脚本(boto3 download_file())获取对象时，该脚本承担了完全访问桶的角色，但是对于方法2上传的对象，它失败了，尽管它成功地处理了方法1上传的对象。
回答 1
Stack Overflow用户
发布于 2016-08-22 03:06:44
发行摘要
总结这一问题：
- 您有允许匿名上传来自给定源IP地址的对象的策略。
- 通过身份验证的用户(特别是lambda函数采用的Iam角色)无法读取这些对象。
- 未经身份验证的用户可以从任何IP读取这些对象。
其他意见
- 未经身份验证的用户无法删除对象。
预期的结果是：
- 对象可以由未经身份验证的用户从已知的IP地址上载。
- 对象不允许未经身份验证的用户从任何IP地址下载。
- 对象可由经过身份验证的Iam用户检索。
根本原因
下面是正在发生的事情：
- 匿名用户上传对象。
1. The Anonymous user becomes the object _owner_
2. Verifiable by retrieving the object acl (do a GET request for the object with query string `?acl`) - you will receive:所有者ID是匿名用户的通用id --我在一些AWS论坛讨论中看到了相同的id。
- 作为对象所有者有以下影响：
- 匿名用户有FULL_CONTROL (参见上面的acl )
- 匿名用户无法删除--这似乎是不可更改的AWS总括规则--匿名用户永远不允许删除任何内容，即使他们拥有FULL_CONTROL。
- 但是，由于FULL_CONTROL，匿名用户可以将空对象放置在现有对象的顶部。
- 当桶包含一个用户拥有的对象，而用户不是存储桶帐户的一部分时：
- 桶所有者对对象没有权限(在acl中没有引用)
- 桶所有者无法读取对象。
- 桶所有者能够在桶列表操作中看到对象，这是由Bucket acl造成的。
- 水桶所有者能够删除对象--这是一条不能更改的总括规则--作为支付账单的人，您总是保留删除对象的权利--即使您无法阅读它。
分辨率
有一种方法可以实现您想要的结果--不幸的是，您必须引用特定Iam实体(用户、角色、组)的arn，您希望能够在桶acl中读取对象。
解决方案的关键要素是：
- 要求匿名用户授予桶所有者完全访问
- 这确保桶所有者和所有者帐户Iam用户不会被对象acl拒绝访问。
- 显式拒绝所有非指定用户/角色的用户的所有非放置访问权限。
- 这确保匿名用户无法读取对象
抽样政策：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "allow-anonymous-put",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<BUCKETNAME>/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "<IPADDRESS>"
},
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
},
{
"Sid": "deny-not-my-user-everything-else",
"Effect": "Deny",
"NotPrincipal": {
"AWS": "arn:aws:iam::<ACCOUNTNUMBER>:role/<ROLENAME>"
},
"NotAction": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::<BUCKETNAME>/*"
}
]
}第二个语句的关键是使用NotPrincipal和NotAction。
我已经在本地测试过这一点，但是只有在允许访问的常规Iam用户的情况下，才能进行测试，而不是使用假定角色的Lamba函数--但是主体应该保持不变。祝好运!
以下文章有助于理解正在发生的事情--它们各自呈现的场景相似，但与您的情况并不完全相同，但它们用来处理场景的方法却起到了主导作用：
- http://jayendrapatil.com/aws-s3-permisions/
- http://prettyplease.me/anonymous-s3-upload-with-full-owner-control/
- https://gist.github.com/jareware/d7a817a08e9eae51a7ea
https://stackoverflow.com/questions/39070512
复制相似问题
腾讯云开发者
