本頁是否能提供幫助?
您對此內容的意見反應十分重要。 請告訴我們您的想法。
其他意見反應?
剩餘 1500 個字元
Azure 儲存體服務的驗證

Azure 儲存體服務的驗證

更新日期: 2015年5月

除非是針對公開存取或簽署存取的 Blob 或容器資源,否則對儲存體服務所提出的每一項要求都必須經過驗證。

Important重要事項
Microsoft Azure 儲存體服務支援 HTTP 和 HTTPS,但強烈建議使用 HTTPS。

Blob、佇列、表格及檔案服務對 2009-09-19 版及更新版本 (針對 Blob、佇列和表格服務) 以及 2014-02-14 版及更新版本 (針對檔案服務) 支援下列共用金鑰驗證:

  • Blob、佇列和檔案服務的共用金鑰。使用共用金鑰驗證配置對 Blob、佇列和檔案服務提出要求。2009-09-19 版及更新版本的共用金鑰驗證支援增強型簽章字串以增強安全性,您必須更新服務才能使用此增強型簽章進行驗證。

  • 表格服務的共用金鑰。 使用共用金鑰驗證配置,針對使用 REST API 的表格服務提出要求。2009-09-19 版及更新版本表格服務的共用金鑰驗證,使用與舊版表格服務相同的簽章字串。

  • 共用金鑰 Lite。使用共用金鑰 Lite 驗證配置,針對 Blob、佇列、表格和檔案服務提出要求。

    若為 2009-09-19 版及更新版本的 Blob 和佇列服務,共用金鑰 Lite 驗證支援使用的簽章字串,與舊版 Blob 和佇列服務中的共用金鑰所支援之簽章字串相同。因此,您可以使用共用金鑰 Lite 對 Blob 和佇列服務提出要求,而不需要更新您的簽章字串。

驗證要求需要兩個標頭:Datex-ms-date 標頭,以及 Authorization 標頭。下列各節說明如何建構這些標頭。

note附註
設定容器的權限即可將容器或 Blob 設為公開存取。如需詳細資訊,請參閱Managing Access to Containers and Blobs。透過共用存取簽章,可將容器、Blob、佇列或表格用於簽署存取;共用存取簽章會透過不同的機制進行驗證。如需詳細資訊,請參閱以共用存取簽章委派存取

所有經過驗證的要求都必須包含要求的國際標準時間 (UTC) 之時間戳記。您可以使用 x-ms-date 標頭或標準 HTTP/HTTPS Date 標頭以指定時間戳記。如果在要求中同時指定這兩個標頭,則會使用 x-ms-date 的值做為要求的建立時間。

儲存體服務會確保要求從提出到送抵服務的時間不超過 15 分鐘。如此可防止特定安全性攻擊,包括重新執行攻擊。當此檢查失敗時,伺服器會傳回回應碼 403 (禁止)。

note附註
由於某些 HTTP 用戶端程式庫和 Proxy 會自動設定 x-ms-date 標頭,讓開發人員沒機會為了將標頭加入經驗證的要求而讀取標頭值,因此提供 Date 標頭。如果設定 x-ms-date,請使用 Date 標頭的空值建構簽章。

經過驗證的要求必須包含 Authorization 標頭。如果未包含此標頭,則要求為匿名,而且只有針對標示為公開存取的容器或 Blob,或是針對已提供共用存取簽章來進行委派存取的容器、Blob、佇列或資料表,才會成功。

若要驗證要求,您必須使用帳戶 (提出要求者) 的金鑰簽署要求,並以簽章做為要求的一部分傳遞。

Authorization 標頭的格式如下:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

其中 SharedKeySharedKeyLite 是授權配置的名稱,AccountName 是要求資源的帳戶名稱,而 Signature 是雜湊式訊息驗證碼 (Hash-based Message Authentication Code,HMAC),此驗證碼從要求建構而來,並使用 SHA256 演算法計算,然後使用 Base64 編碼方式進行編碼。

note附註
如果可以公開存取資源,則可要求位於不同帳戶下的資源。

下列各節說明如何建構 Authorization 標頭。

簽章字串的建構方式取決於您進行驗證的服務和版本,以及您使用的驗證配置。建構簽章字串時,請注意下列事項:

  • 字串的 VERB 部分為 HTTP 動詞命令 (例如 GET 或 PUT),且必須使用大寫。

  • 若為 Blob、佇列和檔案服務的共用金鑰驗證,包含在簽章字串中的每個標頭只能出現一次。如有任何重複的標頭,服務會傳回狀態碼 400 (不正確的要求)。

  • 所有標準 HTTP 標頭的值必須依照簽章格式中所示的順序加入字串,但不包括標頭名稱。這些標頭若未指定為要求的一部分,則為空白,在此情況下,只有新行字元是必要項目。

  • 如果 x-ms-date 標頭已指定,不論是否在要求中指定 Date 標頭,都可以將其忽略,並直接為簽章字串的 Date 部分指定空行。在此情況下,請依照建構 CanonicalizedHeaders 項目一節中的指示加入 x-ms-date 標頭。

    請注意,您可同時指定 x-ms-dateDate,在此情況下,服務會使用 x-ms-date 的值。

  • 如果未指定 x-ms-date 標頭,請在簽章字串中指定 Date 標頭,但不包括標頭名稱。

  • 在簽章字串中,所有顯示的新行字元 (\n) 都是必要項目。

  • 簽章字串包含正式標頭和正式資源字串。標準化這些字串,可使其成為 Azure 儲存體可辨識的標準格式。如需組成部分簽章字串之 CanonicalizedHeadersCanonicalizedResource 字串建構的詳細資訊,請參閱本主題後的適當章節。

若要對 2009-09-19 版及更新版本的 Blob 或佇列服務,或 2014-02-14 版及更新版本的檔案服務提出要求的共用金鑰簽章字串進行編碼,請使用下列格式:

StringToSign = VERB + "\n" +
               Content-Encoding + "\n" +
               Content-Language + "\n" +
               Content-Length + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               If-Modified-Since + "\n" +
               If-Match + "\n" +
               If-None-Match + "\n" +
               If-Unmodified-Since + "\n" +
               Range + "\n" +
               CanonicalizedHeaders + 
               CanonicalizedResource;

下列範例顯示 取得 Blob 作業的簽章字串。請注意,在沒有標頭值的地方只會指定新行字元。

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/ mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

將此程式碼逐行細分會顯示相同字串的每個部分:


GET\n /*HTTP Verb*/
\n    /*Content-Encoding*/
\n    /*Content-Language*/
\n    /*Content-Length*/
\n    /*Content-MD5*/
\n    /*Content-Type*/
\n    /*Date*/
\n    /*If-Modified-Since */
\n    /*If-Match*/
\n    /*If-None-Match*/
\n    /*If-Unmodified-Since*/
\n    /*Range*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

下一步,使用 HMAC-SHA256 演算法將此字串編碼,以覆寫 UTF-8 編碼的簽章字串,然後建構 Authorization 標頭,再將標頭加入要求。下列範例顯示相同作業的 Authorization 標頭:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

請注意,為了搭配使用 2009-09-19 版及更新版本的 Blob 和佇列服務與共用金鑰驗證,您必須更新程式碼才能使用此增強型簽章字串。

如果您想盡可能在最少變更的情況下,將您的程式碼移轉至 2009-09-19 版及更新版本的 Blob 和佇列服務,您可以修改現有的 Authorization 標頭,改為使用共用金鑰 Lite,而不是共用金鑰。若為 2009-09-19 版之前的 Blob 和佇列服務版本,共用金鑰 Lite 所需的簽章格式與共用金鑰所需的簽章格式完全相同。

Important重要事項
如果您要在已啟用讀取權限異地複寫 (RA-GRS) 的儲存體帳戶中存取次要位置,請勿在授權標頭中包含 -secondary 指定。對於授權目的,帳戶名稱一律是主要位置的名稱,即使是次要存取也一樣。

如果您的表格服務使用 REST API 提出要求,則必須使用共用金鑰驗證對服務所發出的要求進行驗證。針對表格服務所使用的共用金鑰簽章字串之格式,在所有版本中完全相同。

請注意,對表格服務所提出之要求的共用金鑰簽章字串,與對 Blob 或佇列服務所提出之要求的共用金鑰簽章字串稍有不同,差異在於前者不會包含字串的 CanonicalizedHeaders 部分。此外,在此情況下的 Date 標頭永遠不會是空白,即使要求設定 x-ms-date 標頭亦然。如果要求設定 x-ms-date,也會使用該值做為 Date 標頭的值。

針對使用 REST API 對表格服務提出要求的簽章字串,若要將其編碼,請使用下列格式:

StringToSign = VERB + "\n" + 
               Content-MD5 + "\n" + 
               Content-Type + "\n" +
               Date + "\n" +
               CanonicalizedResource;

note附註
從 2009-09-19 版開始,表格服務要求所有 REST 呼叫都需包含 DataServiceVersionMaxDataServiceVersion 標頭。如需詳細資訊,請參閱設定 OData Data Service 版本標頭

您可以使用共用金鑰 Lite 驗證,對 2009-09-19 版及更新版本的 Blob 和佇列服務,以及 2014-02-14 版及更新版本的檔案服務所提出的要求進行驗證。

若為 2009-09-19 版之前的 Blob 和佇列服務版本,共用金鑰 Lite 的簽章字串會與共用金鑰驗證所需的簽章字串完全相同。因此,如果您想在最少變更的情況下,將您的程式碼移轉至 2009-09-19 版的 Blob 和佇列服務,您可以修改程式碼以使用共用金鑰 Lite,而不需要變更簽章字串本身。請注意,如果使用共用金鑰 Lite,則無法取得搭配使用 2009-09-19 版及更新版本與共用金鑰所提供的增強型安全性功能。

若要對 Blob 或佇列服務提出要求的簽章字串進行編碼,請使用下列格式:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               CanonicalizedHeaders + 
               CanonicalizedResource;

下列範例顯示 放置 Blob 作業的簽章字串。請注意,Content-MD5 標頭行是空白的。字串中顯示的標頭是名稱/值組,可指定新 Blob 的自訂中繼資料值。

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

下一步,使用 HMAC-SHA256 演算法將此字串編碼,以覆寫 UTF-8 編碼的簽章字串,然後建構 Authorization 標頭,再將標頭加入要求。下列範例顯示相同作業的 Authorization 標頭:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

您可以使用共用金鑰 Lite 驗證,對針對任何版本的表格服務所提出的要求進行驗證。

若要使用共用金鑰 Lite 對針對表格服務所提出之要求的簽章字串進行編碼,請使用下面格式:

StringToSign = Date + "\n" 
               CanonicalizedResource

下列範例顯示 建立資料表 作業的簽章字串。

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

下一步,使用 HMAC-SHA256 演算法將此字串編碼,然後建構 Authorization 標頭,再將標頭加入要求。下列範例顯示相同作業的 Authorization 標頭:

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

若要建構簽章字串的 CanonicalizedHeaders 部分,請遵循下列步驟:

  1. 擷取開頭為 x-ms- 的所有資源標頭,包括 x-ms-date 標頭。

  2. 將每個 HTTP 標頭名稱轉換成小寫。

  3. 以辭典編纂順序,依標頭名稱將標頭排序,採用遞增順序。每個標頭在字串中只能出現一次。

    note附註
    詞彙編纂順序不一定會與傳統的字母順序一致。

  4. 以單一空格取代任何分行空格,將字串展開。

  5. 修剪標頭中冒號兩旁的空格。

  6. 最後,將新行字元附加至產生清單中的每個正式標頭。將此清單中的所有標頭串連成單一字串,以建構 CanonicalizedHeaders 字串。

下列範例顯示標準化的標頭字串:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

簽章字串的 CanonicalizedResource 部分代表此要求以儲存體服務資源為目標。從資源的 URI 衍生之 CanonicalizedResource 字串的任何部分,都應該以其在 URI 中的相同方式進行編碼。

CanonicalizedResource 字串支援兩種格式:

  • 支援 2009-09-19 版及更新版本 Blob 和佇列服務,以及 2014-02-14 版及更新版本的檔案服務之共用金鑰驗證的格式。

  • 支援所有版本的表格服務之共用金鑰和共用金鑰 Lite,以及 2009-09-19 版及更新版本 Blob 和佇列服務之共用金鑰 Lite 的格式。此格式與舊版儲存體服務所使用的格式完全相同。

若要針對您所存取的資料建構之 URI 的協助,請參閱下列主題:

Important重要事項
如果儲存體帳戶以讀取權限異地複寫 (RA-GRS) 進行複寫,而且您要存取次要位置中的資源,請勿在 CanonicalizedResource 字串中包含 –secondary 指定。用於 CanonicalizedResource 字串 URI 中的資源 URI 應該是主要位置之資源的 URI。

note附註
如果您要對儲存體模擬器進行驗證,帳戶名稱會在 CanonicalizedResource 字串中出現兩次。這在預料之中。如果您要對 Azure 儲存體服務進行驗證,帳戶名稱只會在 CanonicalizedResource 字串中出現一次。

2009-09-19 及更新版本的共用金鑰格式

此格式支援 2009-09-19 版及更新版本 Blob 和佇列服務,以及 2014-02-14 版及更新版本的檔案服務之共用金鑰驗證。請依下列方式,以此格式建構 CanonicalizedResource 字串:

  1. 以空白字串 ("") 開頭並附加正斜線 (/),後面接著擁有存取資源的帳戶名稱。

  2. 附加資源的編碼 URI 路徑,不包括任何查詢參數。

  3. 在資源名稱後面附加新行字元 (\n)。

  4. 擷取資源 URI 中的所有查詢參數,包括 comp 參數 (如果存在)。

  5. 將所有參數名稱轉換成小寫。

  6. 以辭典編纂順序,依參數名稱將查詢參數排序,採用遞增順序。

  7. 將每個查詢參數名稱和值進行 URL 解碼。

  8. 以下列格式將每個查詢參數名稱和值附加至字串,並確保名稱和值之間包含冒號 (:):

    parameter-name:parameter-value

  9. 如果查詢參數包含多個值,請依辭典編纂順序將所有的值排序,然後將這些值加入逗號分隔清單中:

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

  10. 在每個名稱/值組後面附加新行字元 (\n)。

請注意下列建構正式資源字串的規則:

  • 避免在查詢參數值中使用新行字元 (\n)。如果必須使用,請確定不會影響正式資源字串的格式。

  • 避免在查詢參數值中使用逗號。

下列是一些範例,顯示簽章字串的 CanonicalizedResource 部分,其建構來源可能是給定的要求 URI:


Get Container Metadata
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata 
CanonicalizedResource:
    /myaccount/mycontainer\ncomp:metadata\nrestype:container

List Blobs operation:
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs
CanonicalizedResource:
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container

Get Blob operation against a resource in the secondary location:
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob
CanonicalizedResource:
    /myaccount/mycontainer/myblob


2009-09-19 版及更新版本共用金鑰 Lite 和表格服務格式

此格式支援所有版本表格服務的共用金鑰和共用金鑰 Lite,以及 2009-09-19 版及更新版本 Blob 和佇列服務,與 2014-02-14 版及更新版本檔案服務的共用金鑰 Lite。此格式與舊版儲存體服務所使用的格式完全相同。請依下列方式,以此格式建構 CanonicalizedResource 字串:

  1. 以空白字串 ("") 開頭並附加正斜線 (/),後面接著擁有存取資源的帳戶名稱。

  2. 附加資源的編碼 URI 路徑。如果要求 URI 指向某個資源元件,請附加適當的查詢字串。查詢字串應該包含問號和 comp 參數 (例如 ?comp=metadata)。查詢字串中不應該包含其他參數。

若要對簽章進行編碼,請對 UTF-8 編碼的簽章字串呼叫 HMAC-SHA256 演算法,並將結果編碼為 Base64。請使用下列格式 (顯示為虛擬程式碼):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

另請參閱

顯示:
© 2015 Microsoft