銷售: 1-800-867-1380

Windows Azure 儲存體服務的驗證

更新日期: 2014年11月

除非是針對公開存取或簽署存取的 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 設為公開存取。如需詳細資訊,請參閱管理 Azure 儲存體資源的存取。透過共用存取簽章,可將容器、Blob、佇列或表格用於簽署存取;共用存取簽章會透過不同的機制進行驗證。如需詳細資訊,請參閱以共用存取簽章委派存取 (REST 應用程式開發介面)

所有經過驗證的要求都必須包含要求的國際標準時間 (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) 都是必要項目。

  • 如需組成部分簽章字串之 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 (REST 應用程式開發介面) 作業的簽章字串。請注意,在沒有標頭值的地方只會指定新行字元。

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/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/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 所需的簽章格式與共用金鑰所需的簽章格式完全相同。

如果您的表格服務使用 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 版 API 與共用金鑰所提供的增強型安全性功能。

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

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

下列範例顯示 放置 Blob (REST 應用程式開發介面) 作業的簽章字串。請注意,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

下列範例顯示 建立資料表 (REST 應用程式開發介面) 作業的簽章字串。

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. 以辭典編纂順序,依標頭名稱將標頭排序,採用遞增順序。請注意,每個標頭在字串中只能出現一次。

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

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

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

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

CanonicalizedResource 字串支援兩種格式:

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

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

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

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

2009-09-19 版共用金鑰格式

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

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

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

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

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

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

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

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

    parameter-name:parameter-value

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

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

  9. 在每個名稱/值組之後附加新行字元 (\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

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)))

另請參閱

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見
顯示:
© 2014 Microsoft