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

共用存取簽章 (SAS) 可提供您儲存體帳戶中資源的安全委派存取權。 您可以藉由 SAS 精確控制用戶端存取資料的方式。 例如:

  • 用戶端可能存取資源的內容。

  • 用戶端具有這些資源的權限。

  • SAS 的有效時間長度。

共用存取簽章的類型

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

  • 使用者委派 SAS

  • 服務 SAS

  • 帳戶 SAS

使用者委派 SAS

使用者委派 SAS 會使用 Azure Active Directory (Azure AD) 認證,以及透過為 SAS 指定的權限來加以保護。 使用者委派 SAS 僅適用於 Blob 儲存體。

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

服務 SAS

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

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

帳戶 SAS

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

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

  • 服務層級的作業 (例如,Get/Set Service PropertiesGet Service Stats 作業)。

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

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

注意

Microsoft 建議您的安全性最佳做法是盡可能使用 Azure AD 認證,而不是使用帳戶金鑰,因為後者可能更容易遭到盜用。 當您的應用程式設計需要共用存取簽章以取得 Blob 儲存體的存取權時,請使用 Azure AD 認證建立使用者委派 SAS 以獲得較佳的安全性。 如需詳細資訊,請參閱授權存取 Azure 儲存體中的資料

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

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

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

注意

使用者委派 SAS 或帳戶 SAS 必須是臨機操作 SAS。 使用者委派 SAS 或帳戶 SAS 不支援預存存取原則。

共用存取簽章的運作方式

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

注意

您無法稽核 SAS 權杖的產生。 任何具備產生 SAS 權杖的使用者皆可以使用帳戶金鑰或透過 Azure 角色指派來稽查,而無須通知儲存體帳戶的擁有者。 請注意限制允許使用者產生 SAS 權杖的權限。 若要防止使用者針對 Blob 和佇列工作負載,產生使用帳戶金鑰簽署的 SAS,則您可以不允許儲存體帳戶的共用金鑰存取權。 如需詳細資訊,請參閱使用共用金鑰來防止授權

SAS 簽章和授權

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

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

您可以使用透過 Azure Active Directory (Azure AD) 認證建立的使用者委派金鑰來簽署 SAS 權杖。 使用者委派 SAS 會使用使用者委派金鑰加以簽署。

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

使用帳戶金鑰簽署 SAS 權杖

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

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

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

SAS 類型 授權類型
使用者委派 SAS (僅限 Blob 儲存體) Azure AD
服務 SAS 共用金鑰
帳戶 SAS 共用金鑰

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

SAS 權杖

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

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

以下是服務 SAS URI 的範例,其中顯示資源 URI 與 SAS 權杖。 由於 SAS 權杖包含 URI 查詢字串,因此必須先將資源 URI 的後面加上問號,然後再接上 SAS 權杖:

服務 SAS URI 的元件

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

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

證明 SAS 非常有用的一個常見案例,就是使用者在您的儲存體帳戶中讀取和寫入自己的資料。 在儲存體帳戶儲存使用者資料的案例中,典型的設計模式有兩種:

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

    案例圖表︰前端 Proxy 服務

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

    案例圖表︰SAS 提供者服務

許多實際服務可能會混合運用這兩種方法。 例如,某些資料可能要透過前端 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 會使用 Azure AD 認證加以保護,因此您不必以代碼儲存儲存體金鑰。

  • 具備可用於 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 中的唯一欄位、簽署的 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 時,提供建議的到期上限。 如需詳細資訊,請參閱 建立共用存取簽章的到期原則

注意

儲存體不會追蹤儲存體帳戶所產生的共用存取簽章數目,且沒有 API 可以提供相關詳細資料。 如果需要了解儲存體帳戶所產生的共用存取簽章數目,則您必須手動追蹤數目。

開始使用 SAS

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

使用者委派 SAS

服務 SAS

帳戶 SAS

下一步