驗證內容

Cloud CDN 提供以下三種方式，協助您控管快取內容的存取權：

  • 「已簽署的網址」可讓您在要求必須取得授權時，透過 Google Cloud遍布全球的快取提供回應。凡是知道已簽署網址的使用者，都能在有限時間內存取資源。
  • 「已簽署的 Cookie」也能讓您限時存取資源。在需要為每位使用者簽署數十或數百個網址時，這類機制就非常實用。
  • 「私人來源驗證」可讓您限制與 Amazon Simple Storage Service (Amazon S3) 儲存貯體或其他相容物件儲存庫的連線，防止使用者直接存取這些儲存庫。

已簽署的網址

已簽署的網址可提供有限權限，允許使用者在時限內提出要求。

用途

某些情況下，您可能不想規定使用者必須擁有 Google 帳戶才能存取 Cloud CDN 內容，但仍希望使用應用程式專屬邏輯控制存取權。

一般的因應方法是，將已簽署的網址提供給使用者，讓使用者能在有限時間內讀取該資源。建立已簽署的網址時需指定到期時間。任何人只要知道網址，就可以存取該資源，直到網址過期或用於簽署網址的金鑰輪替為止。

下列情況適合使用已簽署的網址：

  • 限制個別檔案的存取權，例如安裝下載檔案。

  • 為不支援 Cookie 的用戶端應用程式使用者提供服務。

已簽署網址的運作方式

已簽署網址可提供用戶端暫時性的私人資源存取權限，不必取得額外授權。為此，系統會雜湊處理要求的特定元素，並利用您產生的高強度隨機金鑰來進行加密簽署。

如果要求使用了您提供的已簽署網址，系統就會將該要求視為已取得授權，可以接收所要求的內容。當 Cloud CDN 收到已啟用服務的要求，但含有錯誤簽名時，系統會拒絕該要求，並且不會將要求傳送至後端進行處理。

在一般情況下，取得該項已簽署網址的所有人皆可自由使用該網址。不過，已簽署網址通常僅供收到該網址的用戶端使用。為降低其他用戶端使用這個網址的風險，已簽署網址會在您指定的時間過後失效。如要盡可能降低已簽署網址遭到散布的風險，建議將其到期日設為較早的日期。

如何簽署網址

簽署網址之前，可以在後端服務及/或後端 bucket 中建立一或多組加密編譯金鑰。接著，就能使用 Google Cloud CLI 或自己的程式碼，簽署網址並進行加密雜湊處理。

處理已簽署的網址

在後端啟用已簽署網址的處理程序之後，Cloud CDN 會對包含已簽署網址的要求進行特殊處理。具體來說，系統會將包含 Signature 查詢參數的要求視為已經過簽署。Cloud CDN 在收到這類要求後，會驗證下列資訊：

  • HTTP 方法為 GET、HEAD、OPTIONS 或 TRACE。
  • Expires 參數已設為未來時間。
  • 要求的簽名與使用命名金鑰運算得出的簽名一致。

如果這些檢查中有任何一項不符，系統會提供 403 Forbidden 回應。若是順利完成所有檢查項目，要求會經由 Proxy 傳送至後端或從快取提供。OPTIONS 和 TRACE 要求一律會經由 Proxy 直接傳送至後端，不會從快取提供。特定基準網址 (即 Expires 參數之前的部分) 的所有有效已簽署要求，都會共用相同的快取項目。已簽署和未簽署要求的回應則不會共用快取項目。系統會快取並提供回應，直到您設定的到期時間為止。

需要已簽署要求的內容通常會使用 Cache-Control 標頭來標示為不可快取。為了使這類物件與 Cloud CDN 相容，但不進行後端變更，Cloud CDN 可以在回覆包含有效已簽署網址的要求時覆寫 Cache-Control 標頭。這樣一來，Cloud CDN 就會將該項內容視為可快取項目，並使用 Cloud CDN 設定中的 max-age 參數。不過請注意，系統提供的回應中仍會包含後端產生的 Cache-Control 標頭。

您可依據需求發布從 gcloud CLI 傳回的網址，或透過自訂程式碼產生的網址。建議僅簽署 HTTPS 網址，因為 HTTPS 提供的安全傳輸方式可避免已簽署網址的簽名元件遭到攔截。同樣地，也建議透過安全傳輸通訊協定 (例如 TLS/HTTPS) 發布已簽署的網址。

如需瞭解如何搭配 Cloud CDN 使用已簽署網址，請參閱「使用已簽署的網址」。

已簽署的 Cookie

已簽署的 Cookie 可提供有限的權限和時間，對一組檔案提出要求。

用途

下列情況適合使用已簽署的 Cookie：

  • 提供多個受限制檔案的存取權。

  • 避免變更目前的網址。

  • 避免每次重新授權存取內容時，都要更新網址。

使用 HTTP 即時串流和 DASH 串流處理媒體

如果您透過 HTTP 即時串流 (HLS) 或基於 HTTP 的動態自動調整串流 (DASH) 通訊協定，提供影片和音訊內容，通常會產生資訊清單，其中包含影片和音訊片段的網址清單。您可能會為每個區段建立多個執行個體，向用戶端提供不同的編碼 (轉碼器、位元率、解析度)。

雖然可以使用 Cloud CDN 的已簽署網址來簽署及授權存取這些網址，但根據每位使用者動態產生所有可能的組合會造成負擔，並增加來源負載和應用程式複雜度。

已簽署的 Cookie 主要用來解決這個問題。您可以將已簽署的 Cookie 提供給使用者，授權對方存取符合政策 (網址前置字元和到期日) 的任何內容，而不需個別產生或簽署媒體資訊清單。您也可以在內建應用程式的頁面導覽或其他背景機制中，透過 JavaScript fetch() API 定期重新整理使用者存取權。這還能讓您設定較短的到期時間，確保使用者更難分享受保護的內容。

您可以將這些 Cookie 發給使用多個瀏覽器用戶端，以及其他 HTTP 發話用戶端 (例如 Google 的 ExoPlayer 和 iOS 的 AVPlayer) 的使用者。

二進位檔下載 (遊戲)

與媒體串流類似，如果提供遊戲用戶端下載內容，則可將數 GB 的大型修補程式或遊戲資料分割成較小區塊，支援更精細的快取、撤銷和並行作業。

這些區塊通常會列在資訊清單中。您可以使用已簽署的 Cookie，僅將這些下載內容的存取權授予通過驗證的使用者，而不需要修改資訊清單，且 (與已簽署的網址一樣) 不必放棄Cloud CDN 快取帶來的優勢。

已簽署 Cookie 的運作方式

設定及發布已簽署的 Cookie 需要三個步驟：

  1. 為指定的後端服務建立簽署金鑰。
  2. 使用允許的網址前置字元、到期日、金鑰名稱和加密編譯簽章建立 Cookie 值。
  3. 在應用程式程式碼中簽發 Cookie。

當已簽署的 Cookie 與要求一同發送時，Cloud CDN 會驗證這些 Cookie。

您可以防止使用者在使用 Cloud Storage bucket 時，規避已簽署的 Cookie 控管機制。如要這麼做，請移除 allUsers 角色，並授予 Cloud CDN 服務帳戶對 bucket 的讀取權限，藉此限制對基礎 bucket 的存取權。

同樣地，虛擬機器 (VM) 執行個體應在處理每個已簽署的要求時，都能驗證簽章。

如需瞭解如何搭配 Cloud CDN 使用已簽署 Cookie，請參閱「使用已簽署的 Cookie」。

私人來源驗證

Cloud CDN 透過私人來源驗證，可長期存取私人 Amazon S3 儲存貯體或相容的物件儲存庫。這樣一來，Cloud CDN 就能提供這些來源的內容，無需使用公開讀取權限。

私人來源驗證是面向來源，而已簽署的網址和已簽署的 Cookie 則是面向用戶端。您可為相同內容同時啟用這兩項功能。私人來源驗證限制非 CDN 存取來源和內容，已簽署的網址和 Cookie 則控管哪些使用者能存取 Cloud CDN。

私人來源驗證適用於具備全域外部/傳統版應用程式負載平衡器的 Cloud CDN。

如需瞭解如何搭配 Cloud CDN 使用私人來源驗證，請參閱「設定私人來源驗證」。

注意事項和限制

  • 對於已簽署的 Cookie，請自行負責確保符合所需的任何同意聲明和隱私權規定。簽署的 Cookie 由您核發及管理，而非 Google。

  • 如果同時使用已簽署的網址和已簽署的 Cookie 控管同一檔案的存取權，且檢視者使用已簽署的網址要求檔案，Cloud CDN 只會根據已簽署的網址，判斷是否要將檔案傳回給檢視者。只有在網址未經簽署時，Cloud CDN 才會考慮已簽署的 Cookie。

  • 若已為服務設定已簽署的要求，且網址含有 Signature 查詢參數，Cloud CDN 會嘗試將網址解讀為已簽署的網址。如果 Cloud CDN 嘗試將網址看做已簽署的網址，但這並非您的本意，則該網址可能不是有效的已簽署網址，因此會遭 Cloud CDN 拒絕。

  • 根據 RFC 6265，瀏覽器和其他用戶端通常會強制規定 Cookie 大小上限 (每個 Cookie 4 KB)，以及每個網域的總數上限 (50 個)。請考量從網域傳送的 Cookie 酬載總量。

  • 適用 Cloud CDN 限制和規定，包括每個後端最多三個已簽署的要求金鑰。

  • 簽署的要求與現有 Cloud CDN 要求的收費方式相同。不過，如果要求失敗 (遭拒)，例如簽名過期或無效，仍會產生快取查詢費用。

後續步驟