关于 Amazon S3 的访问权限以及存储桶策略

简介

本文主要通过演示 Amazon S3 如何防盗链(Hotlinking)来解释 Amazon S3 的访问权限以及存储桶策略和策略评估逻辑。

使用 Amazon S3 作为网站的外链资源存储服务器是有诸多好处的,但是也有不好的方面,比如很容易因为请求数和带宽使用过大而导致账单猛增,这就不得不提“防盗链”。

策略的写法

网上搜索一下,有很多 Amazon S3 “防盗链”的办法(本文以“图片”来代指存储桶中的对象),不过基本上都是靠增加存储桶策略(bucket policy)。最典型的一个存储桶策略代码如下:

{
  "Version":"2012-10-17",
  "Id":"PreventHotLinking",
  "Statement":[
    {
      "Sid":"Allow get requests originated from www.example.com and example.com",
      "Effect":"Allow",
      "Principal":"*",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::examplebucket/*",
      "Condition":{
        "StringLike":{"aws:Referer":["http://www.example.com/*","http://example.com/*"]}
      }
    }
  ]
}

它还有一个相反写法的,如下,上面的使用的是 “Allow”,下面这个使用的 “Deny”,这两个策略乍一看效果好像应该一样,其实他们的效果是不一样的,通俗的说,下面这个策略 “更严格”,或者理解成它的权限设定 “更窄”。具体后面说明。

{
  "Version":"2012-10-17",
  "Id":"PreventHotLinking",
  "Statement":[
    {
      "Sid":"Allow get requests originated from www.example.com and example.com",
      "Effect":"Allow",
      "Principal":"*",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::examplebucket/*",
      "Condition":{
        "StringLike":{"aws:Referer":["http://www.example.com/*","http://example.com/*"]}
      }
    }
  ]
}

策略(Policy)的写法,可以参考 Amazon 官方文档:IAM Policy Elements Reference ,文档讲的非常详细,而且有多种语言的版本。在此,只放一张简单的策略结构演示图:

AccessPolicyLanguage_General_Policy_Structure.diagram

多数情况下,上面这个策略就足够了,可以起到防盗链的作用。如果别人把你的图片盗链到他的网站,那么网页请求的 Referer 就会是他的网址,而我们的策略是只允许自己的网址,所以除了自己网址外的所有请求都会是“403 Forbidden”。另外需要注意一点,策略的 “Version” 部分,网上的多数教程都是 “2008-10-17”,这是旧版本的,目前最新的是 “2012-10-17”

上面这个策略多数情况是可以的,但是还有不管用的时候。如果存储桶中的某个图片有它自己的 ACL (Access Control List) 设置,允许外部打开或下载这个图片,如下图所示,那么虽然上面的策略设置了只允许指定域名,但是外界依然可以随意访问这个图片。

单独的 ACL (Access Control List) 设置

这也就是网上好多人提问的“为什么我设置了存储桶策略但是依然无法防盗链”的原因。

ACL

ACL 是 IAM (Identity and Access Management) 还没出来之前 Amazon S3 所使用的一种访问控制机制,它可以针对存储桶中个别的对象来单独设置不一样的权限,这点是比较有用的。

如果你的存储桶里的所有图片都像上面这样,有其自己的 ACL 并且设置成了所有人可以打开和下载,那要怎么更改策略才能把这个所有人可以访问的设定覆盖掉呢?(当然也可以手动或者使用脚本或程序来自动批量修改图片的 ACL,但是无论手动或者自动修改,在图片数量比较多的情况下都很劳民伤财

前面提到了,策略一个是 “Allow” 写法,一个是 “Deny” 写法,如果我们使用 “Deny” 写法的话,因为 “Deny” 的优先级,可以达到覆盖 ACL 设定的的效果。

策略评估逻辑

这里提到了“优先级”,是不太正规的说法,官方说法是 IAM 策略评估逻辑,具体可以参考 Amazon 官方文档:IAM Policy Evaluation Logic

官方文档里说的非常详细,在此我着重说两点。

  1. 策略评估逻辑所遵循的规则:

    • 默认的,所有请求都被拒绝。(通常,始终允许使用账户证书创建的访问该账户资源的请求。)
    • 显式允许(explicit allow)可以覆盖默认设置。(官方翻译成“显式”,我感觉还是使用“明确的”这个意思好理解)
    • 显式拒绝(explicit deny)将覆盖任何允许。

    策略的评估(evaluate)顺序对评估结果有任何影响。所有策略被评估后的最终结果是,这个请求要么被允许要么被拒绝。

    下面这个流程图比较有助于理解:

    AccessPolicyLanguageEvaluationFlow.diagram

  2. 默认情况下的“拒绝”和“显式拒绝”(明确的“拒绝”)的区别

    默认的“拒绝”是可以被“显式允许”(明确的“允许”)所覆盖的,但是“显示拒绝”(明确的“拒绝”)是无法被覆盖掉的。

    看图最好理解了:

    AccessPolicyLanguageAllowOverride.diagram

    情景1里的请求因为对不上 Policy A1,所以被默认拒绝了,但是因为 Policy B 有一个明确的允许,所以这个允许把默认的拒绝覆盖掉了,最终结果是允许。

    情景2里的请求因为有一个明确的拒绝 Policy A2,所以即使再有允许或者其他情况都不管用了,这一个明确的拒绝直接可以导致结果也是拒绝。

更加安全的防盗链策略

理解了策略评估逻辑,前面的问题就很容易解决了,我们只需要添加一个 “显示拒绝”的策略就可以把图片的ACL覆盖掉(官方说法是“取代”) 了,这个官方文档有明确的说明,下面是官方文档的截图:

Explicit deny supersedes ACL

所以,我们把“显示允许”和“显示拒绝”两个声明合并到一块,最后的策略如下:

{
  "Version": "2012-10-17",
  "Id": "PreventHotLinking",
  "Statement": [
    {
      "Sid": "Allow get requests referred by www.mysite.com and mysite.com",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::examplebucket/*",
      "Condition": {
        "StringLike": {"aws:Referer": ["http://www.example.com/*","http://example.com/*"]}
      }
    },
    {
      "Sid": "Explicit deny to ensure requests are allowed only from specific referer.",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::examplebucket/*",
      "Condition": {
        "StringNotLike": {"aws:Referer": ["http://www.example.com/*","http://example.com/*"]}
      }
    }
  ]
}

这种 “Allow” 加 “Deny” 的策略与前面那个只有 “Allow” 的相比更加安全,所以推荐这种写法,防盗链而且更安全。

遇到的问题

但是我在使用过程中还遇到两个问题,在这里记录下,如果有网友也遇到过类似问题,说不定可以参考。

问题一

由于我使用的网站程序需要在没有 HTTP referer 的情况下也可以访问和下载图片,所以上面这个策略是不行的,因为它同样会禁掉 HTTP referer 为空值的访问。怎么办呢,我试过好些个的声明(statement)写法,都不行,最后甚至绝望了想干脆列举一些常见的域名后缀,把这些后缀禁掉,至于 referer 为空的就不管了,全部允许。

后来在查找资料的时候恍然大悟,既然一个策略可以并列放着多个声明(statement),那是不是条件(condition)也可以包含多个判断呢,再搜索一下,果然可以,官网示例就有这么写的。

根据官方文档,条件元素(condition)下面可以包括多个判断(可以理解为子条件),这些个子条件合并到一起类似一个“逻辑与”(logic AND),只有当请求符合每个子条件,这个总的条件才为真,才会执行声明中的 “Allow” 或者 “Deny”。

所以就有了下面的这种策略写法:

{
  "Version": "2012-10-17",
  "Id": "PreventHotLinking",
  "Statement": [
    {
      "Sid": "Explicit deny",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::examplebucket/*",
      "Condition": {
        "StringNotLike": {
          "aws:Referer": [
            "http://www.example.com/*",
            "http://example.com/*",
          ]
        },
        "NotIpAddress": {"aws:SourceIp": "133.166.199.211/32"}
      }
    }
  ]
}

其实就是多加了一条 IP 地址的判断,配合 referer,以缩小范围,因为声明是 “Deny”,满足条件的范围小了,相当于禁掉的范围更大了,正好解决问题一。

问题二

使用了上面的策略,可以满足我的网站的要求了,测试了一下(Chrome 浏览器下)没有问题。可是我在 Firefox 浏览器下测试的时候又发现了一个问题,Firefox 的 HTTP referer 里的网址是不带斜杠(“/”)的,不知道是不是特殊情况,如果这样的话,前面这些策略里网址的写法就需要修改,比如把 "http://blog.zmr.xyz/*" 改成 "http://blog.zmr.xyz*" ,否则在 Firefox 下可能该被拒绝的请求却被允许了,反之亦是。

Firefox 浏览器下的 Referer 值