OSS+CDN的资费和安全-编程知识

文章目录

- 花费
- - OSS
  - CDN
  - OSS + CDN
- 安全
- - OSS
  - - 防盗链
    - 跨域设置CORS
    - 数据加密
  - CDN
  - - 防盗链
    - URL鉴权
    - Cookie鉴权
    - 远程鉴权
    - IP黑白名单
    - UA黑白名单
  - 回源服务
  - - 自定义私有参数
    - IP黑白名单
    - 数据加密

花费

OSS

存储费用：0.12元/GB/月
下行流量费用：0.5元/GB
请求费用：0.01元/10000次

CDN

下行流量费用：0.24元/GB（梯度计费，用的越多越便宜）
静态HTTPS请求数：0.05元/万次

OSS + CDN

CDN流出流量：由CDN收取费用：0.24元/GB
CDN回源流出流量：由OSS收取费用：0.15元/GB
请求费用：由OSS收取费用：0.01元/万次

安全

OSS

防盗链

防盗链通过设置Referer列表（包括白名单Referer和黑名单Referer）以及是否允许空Referer的方式，限制您Bucket内资源的访问来源，避免Bucket内的资源被其他人盗用。

开启防盗链后，OSS会根据请求Header中的Referer地址判断访问来源的方式，确定是否允许当前请求。具体流程如下图所示。

在这里插入图片描述

判断请求Referer是否为空。
- 如果请求Referer为空，则查看是否允许空Referer。
  - 如果允许空Referer，则请求被允许。
  - 如果不允许空Referer，且白名单Referer列表为空，则请求被允许。
  - 如果不允许空Referer，且白名单Referer列表不为空，则请求被拒绝。
- 如果请求Referer不为空，则执行步骤2。
判断黑名单Referer列表是否为空。
- 如果黑名单Referer列表为空，且白名单Referer列表为空，则请求被允许。
- 如果黑名单Referer列表为空，且白名单Referer列表不为空，则跳过步骤3，执行步骤4。
- 如果黑名单Referer列表不为空，则执行步骤3。
遍历黑名单Referer列表。
- 如果黑名单Referer列表存在匹配条目，则请求被拒绝。
- 如果黑名单Referer列表不存在匹配条目，则执行步骤4。
遍历白名单Referer列表。
- 如果白名单Referer列表存在匹配条目，则请求被允许。
- 如果白名单Referer列表不存在匹配条目，则请求被拒绝。

跨域设置CORS

同源检测 跨域访问是浏览器出于安全考虑而设置的一个限制，即同源策略，是用于隔离潜在恶意文件的关键安全机制。当A、B两个网站属于不同域时，来自于A网站页面中的JavaScript代码访问B网站时，浏览器会拒绝该访问。

同协议、同域名（或IP）以及同端口视为同域。两个页面的协议、域名和端口（如果指定了端口）相同，则视为同源。下表给出了相对http://www.aliyun.com/org/test.html的同源检测示例：

URL	访问是否成功	原因
http://www.aliyun.com/org/other.html	是	协议、域名、端口相同
http://www.aliyun.com/org/internal/page.html	是	协议、域名、端口相同
https://www.aliyun.com/page.html	否	协议不同（HTTPS）
http://www.aliyun.com:22/dir/page.html	否	端口不同（22）
http://help.aliyun.com/dir/other.html	否	域名不同

从上表中可以看出，协议、域名或者端口不同的情况下，浏览器会拒绝该来源的访问。如果要允许这些来源的访问，需要设置跨域规则。

数据加密

CDN

防盗链

配置访问请求来源的域名（即Referer黑名单和白名单），实现对访客身份的识别和过滤，限制访问CDN资源的用户，禁止其他网站引用您的资源链接。

URL鉴权

URL鉴权是指用户按照指定的签名方式对于特定的URL增加鉴权认证，您可以通过自行配置校验鉴权URL中的加密串和时间戳，保护用户站点的资源不被非法站点下载盗用。URL鉴权比Referer防盗链安全性更高，适合于安全密级较高的文件。

源站应用服务器：根据鉴权URL生成规则（包括鉴权算法、密钥）生成鉴权URL返回给客户端。
客户端：发起资源请求，并发送鉴权URL给CDN节点进行验证。
CDN节点：对鉴权URL中的鉴权信息（鉴权字符串、时间戳等）进行验证。

示例

1.应用服务器生成如下的URL

原始URL：http://aaa.example.com/video/test.flv

加鉴权后URL：http://cdn.com/video/test.flv?Signature=hmac(timestamp,md5(filePath),key)&Expires=xxxx

Expires为将来的某个时间

filePath : /video/test.flv

2.CDN查看传入的timestamp看是否是超过30min。

3.CDN按相同的hmac校验是否篡改。

要把key和可支持的过期时间在CDN提前配置好。

Cookie鉴权

签名 Cookie 提供有限的权限和时间用于向一组文件发出请求。

下列情况下，可以使用签名 Cookie：

您需要提供对多个受限文件的访问权限。
您不想更改当前网址。
您不希望在每次刷新授权时要更新网址后才能访问内容。

要是客户禁用cookie或不支持cookie的设备就拉了

配置和发布签名 Cookie 的过程分为三个步骤：

源站应用服务器：给指定Domain生成鉴权Cookie返回给客户端。
- Cookie 值: 网址前缀、过期时间、键名称和加密签名
客户端：发起资源请求，并发送URL给CDN节点进行验证。
CDN节点：对鉴权Cookie中的鉴权信息（鉴权字符串、时间戳等）进行验证。

示例Cookie:

// 一体
Set-Cookie: Cloud-CDN-Cookie=URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv:Expires=1566268009:KeyName=mySigningKey:Signature=0W2xlMlQykL2TG59UZnnHzkxoaw=; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; Secure; HttpOnly
// 分开
Set-Cookie: 
CloudFront-Expires=date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC); 
Domain=optional domain name; 
Path=/optional directory path; 
Secure; 
HttpOnlySet-Cookie: 
CloudFront-Signature=hashed and signed version of the policy statement; 
Domain=optional domain name; 
Path=/optional directory path; 
Secure; 
HttpOnlySet-Cookie: 
CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
Domain=optional domain name; 
Path=/optional directory path; 
Secure; 
HttpOnly

Cookie 中的 Domain 和 Path 属性决定了客户端是否将 Cookie 发送到 Cloud CDN。

明确设置 Domain 和 Path 属性，以匹配您希望从中传送受保护内容的网域和路径前缀，这可能与签发 Cookie 的网域和路径不同（分别是 example.com 与 media.example.com，或者分别是 /browse 与 /videos）。

对于同一个 Domain 和 Path，请确保您只有一个具有指定名称的 Cookie。

请确保您未签发有冲突的 Cookie，否则可能导致无法在其他浏览器会话（窗口或标签页）中访问内容。

在适用的情况下设置 Secure 和 HttpOnly 标志。 Secure 可确保仅通过 HTTPS 连接发送 Cookie。HttpOnly 会禁止 JavaScript 使用 Cookie。

Cookie 特性 Expires 和 Max-Age 是可选的。如果您省略这些特性，则 Cookie 会在浏览器会话（标签页或窗口）存在期间保持存在。

注意：此处提及的 Expires 属性是出现在 Cookie 值之外的属性（如果有）。请勿将此属性与 Cookie 值中必需的 Expires 参数混淆。Cookie 值中包含的 Expires 参数指定 Cloud CDN 允许用户访问受保护内容的时间限制。此时间限制与 Cookie 的有效期无关。

在缓存填充或缓存未命中时，签名 Cookie 会传递到后端服务中定义的源站。请确保首先验证每个请求的签名 Cookie 值，之后再传送内容。