使用共用存取簽章 (SAS) 對 Azure 儲存體資源授與有限存取權

共用存取簽章 (SAS) 可提供您儲存體帳戶中資源的安全委派存取權。 使用 SAS 時，控制用戶端存取資料的方式更為精細。 例如：

• 用戶端可存取的資源。

• 用戶端的資源權限。

• SAS 的有效期間。

共用存取簽章的類型

Azure 儲存體支援三種類型的共用存取簽章：

• 使用者委派 SAS

• 服務 SAS

• 帳戶 SAS

使用者委派 SAS

使用者委派 SAS 會使用 Microsoft Entra 認證，以及透過為 SAS 指定的權限來加以保護。 使用者委派 SAS 僅適用於 Blob 儲存體。

如需使用者委派 SAS 的詳細資訊，請參閱建立使用者委派 SAS (REST API)。

服務 SAS

服務 SAS 會使用儲存體帳戶金鑰加以保護。 服務 SAS 僅會將存取權委派至其中一個 Azure 儲存體服務中的資源：Blob 儲存體、佇列儲存體、資料表儲存體或 Azure 檔案儲存體。

如需服務 SAS 的詳細資訊，請參閱建立服務 SAS (REST API)。

帳戶 SAS

帳戶 SAS 會使用儲存體帳戶金鑰加以保護。 帳戶 SAS 則將存取權限委派給一或多個儲存體服務的資源。 透過服務或使用者委派 SAS 提供的所有作業，也可透過帳戶 SAS 取得。

您也可以將存取權委派至下列各項：

• 服務層級的作業 (例如，Get/Set Service Properties 和 Get Service Stats 作業)。

• 服務 SAS 不允許讀取、寫入、刪除作業。

如需帳戶 SAS 的詳細資訊，請建立帳戶 SAS (REST API)。

共用存取簽章可以接受以下兩種格式其中之一：

• 臨機操作 SAS。 當您建立臨機操作 SAS 時，會在 SAS URI 中指定開始時間、到期時間和權限。 任何類型的 SAS 皆可以是臨機操作 SAS。

• 具有預存存取原則的服務 SAS。 預存存取原則會在資源容器中定義，其容器可以是 Blob 容器、資料表、佇列或檔案共用。 預存存取原則可以用來管理一或多個服務共用存取簽章的限制。 當您將服務 SAS 與預存存取原則建立關聯時，SAS 會繼承為該預存存取原則所定義的限制 (開始時間、過期時間和權限)。

共用存取簽章的運作方式

共用存取簽章是附加至 Azure 儲存體資源 URI 的權杖。 權杖包含特殊查詢參數集，指出用戶端如何存取資源。 其中一個查詢參數 (簽章) 是由 SAS 參數所建立，並以用來建立 SAS 的金鑰進行簽署。 Azure 儲存體會使用此簽章來授權對儲存體資源的存取。

SAS 簽章和授權

您可以使用使用者委派金鑰或儲存體帳戶金鑰 (共用金鑰) 來簽署 SAS 權杖。

使用使用者委派金鑰簽署 SAS 權杖

您可使用透過 Microsoft Entra 認證建立的使用者委派金鑰來簽署 SAS 權杖。 使用者委派 SAS 會使用使用者委派金鑰加以簽署。

若要取得金鑰並建立 SAS，必須將包含 Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey 動作的 Azure 角色指派給 Microsoft Entra 安全性主體。 如需詳細資訊，請參閱建立使用者委派 SAS (REST API)。

使用帳戶金鑰簽署 SAS 權杖

服務 SAS 和帳戶 SAS 都使用儲存體帳戶金鑰加以簽署。 若要建立使用帳戶金鑰簽署的 SAS，應用程式必須具備帳戶金鑰的存取權。

當要求包含 SAS 權杖時，則該要求會根據 SAS 權杖簽署的方式來獲得授權。 Azure 儲存體也會使用所用於建立 SAS 權杖的帳戶金鑰或認證，將存取權授與擁有 SAS 的用戶端。

下表摘要說明各類型 SAS 權杖的授權方式。

Microsoft 建議盡可能採用使用者委派 SAS 以獲得絕佳的安全性。

SAS 權杖

SAS 權杖是您在用戶端產生的字串，例如使用其中一個 Azure 儲存體用戶端程式庫。 Azure 儲存體不會以任何方式追蹤 SAS 權杖。 您可以在用戶端建立不限數量的 SAS 權杖。 建立 SAS 後，您可以將 SAS 散發至需要儲存體帳戶中資源存取權的用戶端應用程式。

用戶端應用程式會將 SAS 提供給 Azure 儲存體作為要求的一部分。 然後，服務會檢查 SAS 參數和簽章，以確認有效性。 如果服務確認簽章有效，則要求會獲得授權。 否則要求會遭到拒絕，並產生錯誤碼 403 (禁止)。

以下是服務 SAS URI 的範例，其中顯示資源 URI、分隔符號字元 ('?') 和 SAS 權杖。

使用共用存取簽章 (SAS) 的時機

使用 SAS，將儲存帳戶中資源的安全存取權授與任何不具備這些資源權限的用戶端。

SAS 很實用的一個常見案例，就是讓使用者在您的儲存體帳戶中讀取和寫入其資料的服務。 在儲存體帳戶儲存使用者資料的案例中，典型的設計模式有兩種：

1. 用戶端透過會執行驗證的前端 Proxy 服務來上傳與下載資料。 此前端 Proxy 服務允許商務規則的驗證。 但針對大量資料或大量交易，建立可調整以符合需求的服務可能會很昂貴或困難。

   

2. 輕量型服務可視需要驗證用戶端，然後產生 SAS。 用戶端應用程式收到 SAS 後，便可以直接存取儲存體帳戶。 存取權限是由 SAS 和 SAS 允許的間隔所定義。 SAS 可減輕透過前端 Proxy 服務路由所有資料的需求。

   

許多真實世界的服務可能會混合運用這兩種方法。 例如，某些資料可能要透過前端 Proxy 處理和驗證。 其他資料則是使用 SAS 直接儲存和/或讀取。

此外，在某些情況下，需要在複製作業中使用 SAS 來授權對來源物件的存取權：

• 當將 Blob 複製到位於不同儲存體帳戶的其他 Blob 時。

  您也可以選擇性地使用 SAS 來授權對目的地 Blob 的存取權。

• 當將檔案複製到位於不同儲存體帳戶的其他檔案時。

  您也可以選擇性地使用 SAS 來授權對目的地檔案的存取權。

• 當將 Blob 複製到檔案，或將檔案複製到 Blob 時。

  即使資源和目的地物件位於相同儲存體帳戶內，您仍必須使用 SAS。

使用 SAS 時的最佳做法

當您在應用程式中使用共用存取簽章時，您必須留意兩個潛在風險：

• 如果 SAS 洩漏出去，則取得該 SAS 的任何人都可以使用它，這有可能會洩露您的儲存體帳戶。

• 如果提供給用戶端應用程式的 SAS 已過期，且此應用程式無法從您的服務擷取新的 SAS，那麼該應用程式的功能可能會受到影響。

下列關於使用共用存取簽章的建議，將可協助您平衡這些風險：

• 一律使用 HTTPS 來建立或散佈 SAS。 如果透過 HTTP 傳遞 SAS 並遭到攔截，則攻擊者可執行中間人攻擊來讀取 SAS。 接著，攻擊者就可以如同使用者一樣使用該 SAS。 這可能會潛在侵害敏感性資料，或讓惡意使用者損毀資料。

• 盡可能使用使用者委派 SAS。 使用者委派 SAS 對服務 SAS 或帳戶 SAS 提供絕佳的安全性。 使用者委派 SAS 會使用 Microsoft Entra 認證加以保護，因此您不必以程式碼儲存帳戶金鑰。

• 具備可用於 SAS 的撤銷方案。 確定您已準備好在 SAS 遭到侵害時應對。

• 設定儲存體帳戶的 SAS 到期原則。 SAS 到期原則會指定 SAS 有效的建議間隔。 SAS 到期原則會套用至服務 SAS 或帳戶 SAS。 當使用者產生的服務 SAS 或帳戶 SAS 具有比建議間隔較長的有效間隔，則將會看到警告。 如果已啟用 Azure 監視器的 Azure 儲存體記錄，則會將項目寫入至 Azure 儲存體記錄。 若要深入了解，請參閱建立共用存取簽章的到期原則。

• 建立服務 SAS 的預存存取原則。 預存存取原則提供了撤銷服務 SAS 權限且無需重新產生儲存體帳戶金鑰的選項。 將到期日設在未來 (或無限) 的日期，並確定定期更新到期日以將到期日再往未來的日期移動。 每個容器都有五個預存存取原則的限制。

• 對於臨機操作 SAS、服務 SAS 或帳戶 SAS，請使用近期到期時間。 如此一來，即使 SAS 遭到入侵，亦僅會造成短期影響。 如果您無法參考預存存取原則，此做法格外重要。 短期到期時間也會限制可用的上傳時間，可寫入 blob 的資料量也會因此受限。

• 讓用戶端視需要自動更新 SAS。 用戶端應在到期日之前就更新 SAS，以便如果提供 SAS 的服務無法使用的話，還有時間可以進行重試。 在某些情況下，這可能並非必要。 例如，您可能想要將 SAS 用於立即、短期的少量作業。 這些作業預期會在到期期間內完成。 因此，您不需要更新 SAS。 不過，如果您有定期透過 SAS 做出要求的用戶端，則到期的可能性便有可能發生。

• 謹慎設定 SAS 開始時間。 如果您將 SAS 的開始時間設定為目前時間，則在前幾分鐘可能會間歇性發生失敗。 這是因為不同電腦的目前時間可能稍有不同 (稱為「時鐘誤差」)。 一般而言，請將開始時間設為至少 15 分鐘之前的時間。 或是不進行任何設定，這會針對所有案例立即生效。 同樣的道理通常亦適用於過期時間，請記住，您可針對任何要求保留前後多達 15 分鐘的時鐘誤差。 如果用戶端使用 2012-02-12 之前的 REST 版本，則不參照預存存取原則的 SAS 最大持續時間為 1 小時。 任何指定大於 1 小時長期的原則將會失敗。

• 請注意 SAS 日期時間的格式。 針對某些公用程式 (例如 AzCopy)，時間/日期值必須格式化為 '+%Y-%m-%dT%H:%M:%SZ'。 此格式特別包含秒數。

• 使用 SAS 授與最低可能權限。 安全性最佳做法是提供使用者最少可能資源的最低所需權限。 盡可能使用唯讀 SAS。 如果使用者僅需要單一物件的讀取存取權，則授與該單一物件的讀取存取權，而不是授與所有物件的讀取/寫入/刪除存取權。 這有助於減輕洩露 SAS 遭受的損害，因為當 SAS 落入攻擊者手中時，即無法發揮固有功能。

  沒有直接方法可識別哪些用戶端已存取資源。 不過，您可使用 SAS 中的唯一欄位 (已簽署 IP (sip)、已簽署開始 (st) 和已簽署到期 (se) 欄位) 以追蹤存取。 例如，您可產生唯一到期時間的 SAS 權杖，接著您可將其與核發該權杖的用戶端相關聯。

• 了解您帳戶的任何使用方式將會被收取費用，包括透過 SAS 的部分。 如果您提供 Blob 的寫入存取權，則使用者可能會選擇上傳 200 GB 的 Blob。 若您也同時提供使用者讀取存取權，則他們可能會選擇下載 10 次，而您便會產生 2TB 的出口成本。 同理，提供受限權限有助降低惡意使用者可能動作的風險。 使用短期 SAS 以降低此威脅 (但請注意結束時間的時鐘誤差)。

• 使用 SAS 驗證寫入資料。 當用戶端應用程式將資料寫入您的儲存體帳戶時，請留意該資料可能會造成問題。 如果您計劃驗證資料，請在寫入資料後和應用程式使用前執行驗證。 這麼一來，無論是透過正當管道取得 SAS 的使用者，還是濫用外洩 SAS 的攻擊者，都無法將損毀或惡意資料寫入您的帳戶。

• 了解不使用 SAS 的時機。 有時候，在儲存體帳戶中執行特定作業的相關風險可能大過使用 SAS 的好處。 針對這類作業，請在執行過商業規則確認、驗證和稽核後，建立寫入儲存體帳戶的中介層服務。 另外，有時候以其他方式管理存取權可能比較簡單。 例如，如果您想要讓容器中的所有 Blob 都可供公開讀取，則您可以將此容器設定為 [公用]，而不是將 SAS 提供給每個用戶端進行存取。

• 使用 Azure 監視器和 Azure 儲存體記錄來監視您的應用程式。 授權失敗可能會因 SAS 提供者服務中斷而發生。 這也可能是因為意外移除儲存的存取原則。 您可以使用 Azure 監視器和儲存體分析記錄，來觀察這些授權失敗類型的任何尖峰。 如需詳細資訊，請參閱 Azure 監視器中的 Azure 儲存體計量和 Azure 儲存體分析記錄。

• 設定儲存體帳戶的 SAS 到期原則。 建議的最佳做法是限制 SAS 的間隔，以防止遭到入侵。 透過設定儲存體帳戶的 SAS 到期原則，您可以在使用者建立服務 SAS 或帳戶 SAS 時，提供建議的到期上限。 如需詳細資訊，請參閱建立共用存取簽章的到期原則。

開始使用 SAS

若要開始使用共用存取簽章，請參閱下列每個 SAS 類型的文章。

使用者委派 SAS

• 使用 PowerShell 建立容器或 Blob 的使用者委派 SAS
• 使用 Azure CLI 建立容器或 Blob 的使用者委派 SAS
• 使用 .NET 建立容器或 Blob 的使用者委派 SAS

服務 SAS

• 使用 .NET 建立容器或 Blob 的服務 SAS

帳戶 SAS

• 使用 .NET 建立帳戶 SAS

下一步

• 使用共用存取簽章 (REST API) 來委派存取權
• 建立使用者委派 SAS (REST API)
• 建立服務 SAS (REST API)
• 建立帳戶 SAS (REST API)