Cloud CDN 提供三種方式，協助您控管快取內容的存取權：
- 已簽署的網址可讓您在需要授權的要求中，透過 Google Cloud遍布全球的快取提供回應。凡是知道已簽署網址的使用者，都能在有限時間內存取該資源。
- 已簽署的 Cookie 也可讓您在有限時間內存取資源。當您需要為每位使用者簽署數十或數百個網址時，這類工具就很實用。
- 私人來源驗證可讓您限制 Amazon Simple Storage Service (Amazon S3) 值區或其他相容物件儲存庫的連線，並防止使用者直接存取這些值區。
經簽署的網址
已簽署網址可提供有限的權限和時間來提出要求。
用途
在某些情況下，您可能不想要求使用者擁有 Google 帳戶才能存取 Cloud CDN 內容，但仍希望使用應用程式專屬邏輯來控制存取權。
一般來說，要解決這類用途，您可以將已簽署的網址提供給使用者，讓使用者在限定時間內讀取該資源。建立已簽署網址時，您需要指定到期時間。任何人只要知道網址，就可以存取該資源，直到網址過期或用於簽署網址的金鑰輪替為止。
在下列情況下使用已簽署的網址：
限制存取個別檔案的權限，例如安裝下載檔案。
為不支援 Cookie 的用戶端應用程式提供服務。
已簽署網址的運作方式
已簽署網址可以提供用戶端暫時性的私人資源存取權限，而不必取得額外授權。因此，系統會雜湊處理要求的特定元素，並利用您產生的高強度隨機金鑰來進行加密簽署。
當要求使用您提供的已簽署網址時，系統會將該要求視為已授權接收要求的內容。當 Cloud CDN 收到已啟用服務的無效簽名要求時，系統會拒絕該要求，並不會將要求傳送至後端進行處理。
在一般情況下，取得該項已簽署網址的所有人皆可自由使用該網址。不過，已簽署網址通常只供提供網址的用戶端使用。為降低網址遭其他客戶使用風險，已簽署網址會在您指定的時間到期。如要儘可能降低已簽署網址遭到散布的風險，建議您將其到期日設為較早的日期。
如何簽署網址
簽署網址之前，您可以在後端服務及/或後端值區中建立一或多組加密金鑰。接著，您可以使用 Google Cloud CLI 或自己的程式碼，為網址簽署並以加密編譯方式產生雜湊值。
處理已簽署的網址
在後端啟用已簽署的網址處理程序之後，Cloud CDN 會對包含已簽署網址的要求進行特殊處理。具體來說，系統會將包含 Signature 查詢參數的要求視為已經過簽署。收到這類要求後，Cloud CDN 會驗證以下項目：
- HTTP 方法為
GET、HEAD、OPTIONS或TRACE。 Expires參數設為未來的時間。- 要求的簽章與使用命名金鑰所計算的簽章相符。
如果這些檢查中有任何一個失敗，系統就會傳送 403 Forbidden 回應。否則，要求會代理至後端，或從快取提供。OPTIONS 和 TRACE 要求一律會直接轉送至後端，不會從快取提供。針對特定基礎網址 (即 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，可提供有限的權限和時間，用於要求一組檔案。
用途
在下列情況下使用已簽署的 Cookie：
提供多個受限制檔案的存取權。
避免變更目前的網址。
避免每次更新授權存取內容時，都需要更新網址。
使用 HLS 和 DASH 串流媒體
如果您使用 HTTP 即時串流 (HLS) 或基於 HTTP 的動態自動調整串流 (DASH) 通訊協定提供影片和音訊內容，通常會產生資訊清單，其中包含影片和音訊片段的網址清單。您可能會為每個區段建立多個例項，以便向用戶端提供不同的編碼 (編解碼、位元率、解析度)。
雖然您可以使用 Cloud CDN 的已簽署網址來簽署及授權存取這些網址，但根據每位使用者動態產生所有可能組合會造成負擔，並增加來源負載和應用程式複雜度。
已簽署的 Cookie 就是為瞭解決這個問題。您可以為使用者提供已簽署的 Cookie，授權使用者存取符合政策 (網址前置字串和到期日) 的任何內容，而不需要個別產生或簽署媒體資訊清單。您可以在內建應用程式的頁面導覽或其他背景機制中，透過 JavaScript fetch() API 定期重新整理使用者存取權。您也可以透過重新整理使用者存取權的功能，設定較短的到期時間，讓使用者更難分享受保護的內容。
您可以將這些 Cookie 發給使用多個瀏覽器用戶端和其他 HTTP 用戶端的使用者，例如 Google 的 ExoPlayer 和 iOS 的 AVPlayer。
二進位檔下載 (遊戲)
與媒體串流類似，如果您提供遊戲用戶端下載項目，可以將數 GB 的大型修補程式或遊戲資料分割成較小的區塊，以支援更精細的快取、無效化和並行作業。
這些區塊通常會列在資訊清單中。您可以使用已簽署的 Cookie，只將這些下載項目的存取權授予已驗證的使用者，而不需要修改資訊清單，且 (與已簽署的網址一樣) 不必放棄 Cloud CDN 快取的優點。
已簽署 Cookie 的運作方式
設定及發出已簽署的 Cookie 需要三個步驟：
- 為指定的後端服務建立簽署金鑰。
- 使用允許的網址前置字元、到期日、金鑰名稱和加密簽章建立 Cookie 值。
- 在應用程式程式碼中發出 Cookie。
當這些已簽署的 Cookie 與要求一併提供時，Cloud CDN 會驗證這些 Cookie。
您可以防止使用者在使用 Cloud Storage 值區時規避經簽署的 Cookie 控管機制。如要這麼做，請移除 allUsers 角色，並授予 Cloud CDN 服務帳戶對值區的讀取權限，藉此限制對基礎值區的存取權。
同樣地，您的虛擬機器 (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 要求不同的費用。不過，失敗 (已拒絕) 的要求 (例如簽章已過期或無效) 仍會產生快取查詢費用。
後續步驟
- 如要瞭解其他最佳做法，請參閱「網頁安全性最佳做法」。