通过Route53 A记录通过查询字符串访问私有内容到s3存储桶

时间:2013-07-31 04:41:28

标签: php amazon-web-services amazon-s3 amazon-route53

我正在尝试使用具有指定生存时间的查询字符串限制访问存储在S3存储桶中的文件资源(如此处所述http://birkoff.net/blog/amazon-s3-query-string-authentication-using-php/)到我的存储桶的别名。 例如在Route53中,我有一个Alias类型的A记录, securefiles.mysite.com 指向S3 Alias securefiles.mysite.com.s3-website-ap-southeast-2.amazonaws.com < /强>

对于使用标准S3地址寻址的文件,这非常有效: 的 securefiles.mysite.com.s3-ap-southeast-2.amazonaws.com/privateresource.png?biglongquerystring 要么 的 securefiles.mysite.com.s3.amazonaws.com/privateresource.png?biglongquerystring 但是当我尝试使用较短的 securefiles.mysite.com/privateresource.png?biglongquerystring 链接它时,它会失败并显示403拒绝访问的消息。

为了便于调查,我编辑了存储桶策略以允许所有用户访问所有存储桶资源

{
"Version": "2008-10-17",
"Statement": [
    {
        "Sid": "PublicReadGetObject",
        "Effect": "Allow",
        "Principal": {
            "AWS": "*"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::securefiles.mysite.com/*"
    }
]

}

查询字符串现在适用于较短的地址,但不再受到保护,因为所有用户现在都可以访问。

我还尝试“不启用网站托管”到我的存储桶,这对于完整的S3地址再次正常工作, securefiles.mysite.com.s3.amazonaws.com/privateresource.png? biglongquerystring  但是在解决较短的 securefiles.mysite.com/privateresource.png?biglongquerystring

时遇到404 NoSuchWebsiteConfiguration失败了

关于如何安全地将S3存储桶中的文件从Route53 A记录解析到我的S3存储桶别名的任何想法?

1 个答案:

答案 0 :(得分:0)

我执行了以下任务:

  • 在Amazon S3中创建了一个名为images.my-domain.com
  • 的存储桶
  • 将文件上传到存储桶
  • 在亚马逊Route 53中创建了一个记录集(记录,别名=是,别名目标= s3-website-ap-southeast-2.amazonaws.com - 是的,我也在悉尼)

测试1 - 直接访问:点击Amazon S3中的对象链接(s3-ap-southeast-2.amazonaws.com/images.my-domain.com/picture.jpg)按预期返回AccessDenied,因为该对象没有权限。

测试2 - 直接预签名网址:在S3中的对象上使用Pre-Signed URL(通过BucketExplorer创建)(使用正常的S3网址)成功提供了访问权限对象。这是可以预期的。

测试3 - 别名访问:访问Amazon S3中的对象链接,但将其更改为直接使用域名(images.my-domain.com/picture.jpg)按预期返回AccessDenied。< / p>

测试4 - 使用预签名网址进行别名访问:通过带有预签名网址 的静态网站网址进行访问。这与您遇到的问题一致。

因此,我同意似乎不可能将预签名URL与Route 53别名一起用于静态S3网站。

然后我使用Amazon S3静态网站URL进一步测试:

Tst 5 - 带有预签名网址的S3静态网站网址:此测试尝试通过静态网站网址(images.my-domain.com.s3-website-ap-southeast-2.amazonaws.com/picture.jpg)和签名访问私人文件。这也返回了AccessDenied

因此,问题似乎与Route 53 URL无关。相反,预先签名的网址似乎无法通过静态网站网址工作。由于Route 53使用静态URL,因此也失败。