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 值，之后再傳送內容。