共有キーを使用して承認する

ストレージ サービスに対して行われたすべての要求は、パブリックまたは署名されたアクセスで使用できる BLOB またはコンテナー リソースに対する要求でない限り、承認する必要があります。 要求を承認する 1 つのオプションは、この記事で説明する共有キーを使用することです。

BLOB、キュー、テーブル、およびファイル サービスでは、バージョン 2009-09-19 以降 (BLOB、キュー、および Table サービス) とバージョン 2014-02-14 以降 (ファイル サービスの場合) に対して、次の共有キー承認スキームがサポートされています。

• BLOB、キュー、およびファイル サービスの共有キー。 共有キー承認スキームを使用して、BLOB、キュー、およびファイル サービスに対して要求を行います。 バージョン 2009-09-19 以降の共有キー承認では、セキュリティ強化のための拡張署名文字列がサポートされており、この拡張署名を使用して承認するようにサービスを更新する必要があります。

• Table Service の共有キー。 共有キー承認スキームを使用して、REST API を使用して Table service に対して要求を行います。 バージョン 2009-09-19 以降の Table Service の共有キー承認では、Table Service の以前のバージョンと同じ署名文字列が使用されます。

• 共有キー ライト。 共有キー ライト承認スキームを使用して、BLOB、キュー、テーブル、およびファイル サービスに対して要求を行います。 共有キー ライトは、Premium ページ BLOB ではサポートされていません。

  Blob および Queue サービスのバージョン 2009-09-19 以降では、Shared Key Lite 承認では、以前のバージョンの BLOB およびキュー サービスで共有キーに対してサポートされていたのと同じ署名文字列の使用がサポートされています。 そのため、Shared Key Lite を使用して、署名文字列を更新せずに BLOB サービスと Queue サービスに対して要求を行うことができます。

承認された要求には、Date または x-ms-date ヘッダーと Authorization ヘッダーの 2 つのヘッダーが必要です。 次のセクションでは、これらのヘッダーを構築する方法について説明します。

Date ヘッダーの指定

承認されたすべての要求には、要求の協定世界時 (UTC) タイムスタンプを含める必要があります。 タイムスタンプは、x-ms-date ヘッダーまたは標準の HTTP/HTTPS Date ヘッダーで指定できます。 要求で両方のヘッダーが指定されている場合、x-ms-date の値が要求の作成時として使用されます。

ストレージ サービスは、要求がサービスに到達するまでに 15 分を超えないことを確認します。 これにより、リプレイ攻撃を含む特定のセキュリティ攻撃から保護されます。 このチェックが失敗すると、サーバーは応答コード 403 (禁止) を返します。

Authorization ヘッダーの指定

承認された要求には、Authorization ヘッダーを含める必要があります。 このヘッダーが含まれていない場合、要求は匿名であり、パブリック アクセスとしてマークされているコンテナーまたは BLOB、または委任されたアクセス用に共有アクセス署名が提供されているコンテナー、BLOB、キュー、またはテーブルに対してのみ成功します。

要求を承認するには、要求を行っているアカウントのキーを使用して要求に署名し、要求の一部としてその署名を渡す必要があります。

Authorization ヘッダーの形式は次のとおりです。

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

ここで、SharedKey または SharedKeyLite は承認スキームの名前、AccountName はリソースを要求するアカウントの名前、Signature は要求から構築され、SHA256 アルゴリズムを使用して計算され、Base64 エンコードを使用してエンコードされたハッシュベースのメッセージ認証コード (HMAC) です。

次のセクションでは、Authorization ヘッダーを構築する方法について説明します。

署名文字列の構築

署名文字列を作成する方法は、承認対象のサービスとバージョン、および使用している承認スキームによって異なります。 署名文字列を作成するときは、次の点に注意してください。

• 文字列の VERB 部分は、GET や PUT などの HTTP 動詞であり、大文字である必要があります。

• BLOB、Queue、および File サービスの共有キー承認の場合、署名文字列に含まれる各ヘッダーは 1 回だけ表示できます。 ヘッダーが重複している場合、サービスは状態コード 400 (無効な要求) を返します。

• すべての標準 HTTP ヘッダーの値は、ヘッダー名を指定せずに、署名形式で示されている順序で文字列に含まれている必要があります。 これらのヘッダーは、要求の一部として指定されていない場合は空にすることができます。その場合は、改行文字のみが必要です。

• x-ms-date ヘッダーが指定されている場合は、要求で指定されているかどうかに関係なく、Date ヘッダーを無視し、署名文字列の Date 部分に空の行を指定するだけです。 この場合は、「 ヘッダーを追加するための正規化されたヘッダー文字列の構築」セクションの の手順に従います。

  x-ms-date と Dateの両方を指定できます。この場合、サービスは x-ms-dateの値を使用します。

• x-ms-date ヘッダーが指定されていない場合は、ヘッダー名を含めずに、署名文字列に Date ヘッダーを指定します。

• 表示されるすべての改行文字 (\n) は、署名文字列内で必要です。

• 署名文字列には、正規化されたヘッダーと正規化されたリソース文字列が含まれます。 これらの文字列を正規化すると、Azure Storage によって認識される標準形式に変換されます。 署名文字列の一部を構成する CanonicalizedHeaders 文字列と CanonicalizedResource 文字列の構築の詳細については、このトピックの後半の該当するセクションを参照してください。

BLOB、キュー、およびファイル サービス (共有キーの承認)

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:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20  

この行ごとに分割すると、同じ文字列の各部分が表示されます。

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\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:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/  

次に、UTF-8 でエンコードされた署名文字列に対して HMAC-SHA256 アルゴリズムを使用してこの文字列をエンコードし、Authorization ヘッダーを構築し、要求にヘッダーを追加します。 次の例は、同じ操作の Authorization ヘッダーを示しています。

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

バージョン 2009-09-19 以降の BLOB およびキュー サービスで共有キー承認を使用するには、この拡張署名文字列を使用するようにコードを更新する必要があります。

可能な限り少ない変更で BLOB サービスとキュー サービスのバージョン 2009-09-19 以降にコードを移行する場合は、共有キーではなく共有キー ライトを使用するように既存の Authorization ヘッダーを変更できます。 Shared Key Lite で必要な署名形式は、2009-09-19 より前のバージョンの BLOB およびキュー サービスによって共有キーに必要な署名形式と同じです。

バージョン 2014-02-14 以前の Content-Length ヘッダー

バージョン 2014-02-14 以前を使用している場合、Content-Length が 0 の場合は、StringToSign の Content-Length 部分を 0に設定します。 通常、これは空の文字列になります。

たとえば、次の要求の場合、Content-Length ヘッダーの値は、0 の場合でも StringToSign に含まれます。

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

StringToSign は次のように構築されます。

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

2014-02-14 以降のバージョンでは、StringToSign には Content-Lengthの空の文字列が含まれている必要があります。

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Table service (共有キーの承認)

サービスが REST API を使用して要求を行っている場合は、共有キー承認を使用して Table サービスに対して行われた要求を承認する必要があります。 Table Service に対する共有キーの署名文字列の形式は、すべてのバージョンで同じです。

Table Service に対する要求の共有キー署名文字列は、BLOB または Queue サービスに対する要求の場合と若干異なります。文字列の CanonicalizedHeaders 部分は含まれません。 さらに、この場合の Date ヘッダーは、要求が x-ms-date ヘッダーを設定した場合でも空ではありません。 要求で x-ms-dateが設定されている場合、その値は Date ヘッダーの値にも使用されます。

REST API を使用して行われた Table service に対する要求の署名文字列をエンコードするには、次の形式を使用します。

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

BLOB、キュー、およびファイル サービス (共有キー ライト承認)

Shared Key Lite 承認を使用して、2009-09-19 バージョン以降の BLOB サービスとキュー サービス、およびバージョン 2014-02-14 以降のファイル サービスに対して行われた要求を承認できます。 共有キー ライトは、Premium ページ BLOB ではサポートされていません。

Shared Key Lite の署名文字列は、2009-09-19 より前のバージョンの BLOB およびキュー サービスで共有キーの承認に必要な署名文字列と同じです。 そのため、Blob サービスと Queue サービスのバージョン 2009-09-19 への変更の数が最も少ないコードを移行する場合は、署名文字列自体を変更せずに、Shared Key Lite を使用するようにコードを変更できます。 Shared Key Lite を使用すると、バージョン 2009-09-19 以降の共有キーを使用して提供される強化されたセキュリティ機能を利用できなくなります。

BLOB または Queue サービスに対する要求の署名文字列をエンコードするには、次の形式を使用します。

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

次の例は、Put 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  

次に、UTF-8 でエンコードされた署名文字列に対して HMAC-SHA256 アルゴリズムを使用してこの文字列をエンコードし、Authorization ヘッダーを構築し、要求にヘッダーを追加します。 次の例は、同じ操作の Authorization ヘッダーを示しています。

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Table service (Shared Key Lite 承認)

Shared Key Lite 承認を使用して、Table Service の任意のバージョンに対して行われた要求を承認できます。

Shared Key Lite を使用して Table Service に対する要求の署名文字列をエンコードするには、次の形式を使用します。

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-date ヘッダーを含め、x-ms-で始まるリソースのすべてのヘッダーを取得します。

2. 各 HTTP ヘッダー名を小文字に変換します。

3. ヘッダーをヘッダー名で昇順に構文的に並べ替えます。 各ヘッダーは、文字列内で 1 回だけ表示できます。

   手記

   辞書の順序付け は、常に従来のアルファベット順と一致するとは限りません。

4. ヘッダー値内の線形空白を 1 つのスペースに置き換えます。

線形空白には、復帰/改行 (CRLF)、スペース、タブが含まれます。 詳細については、RFC 2616 セクション 4.2 を参照してください。 引用符で囲まれた文字列内の空白文字は置き換えないでください。

1. ヘッダー内のコロンの周囲の空白をトリミングします。

2. 最後に、結果のリスト内の正規化された各ヘッダーに改行文字を追加します。 このリスト内のすべてのヘッダーを 1 つの文字列に連結して、CanonicalizedHeaders 文字列を構築します。

正規化されたヘッダー文字列の例を次に示します。

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

正規化されたリソース文字列の構築

署名文字列の CanonicalizedResource 部分は、要求の対象となるストレージ サービス リソースを表します。 リソースの URI から派生した CanonicalizedResource 文字列の任意の部分は、URI とまったく同じようにエンコードする必要があります。

CanonicalizedResource 文字列には、次の 2 つの形式がサポートされています。

• Blob および Queue サービスのバージョン 2009-09-19 以降、およびファイル サービスのバージョン 2014-02-14 以降の共有キー承認をサポートする形式。

• Table サービスのすべてのバージョンで共有キーと共有キー ライトをサポートする形式。BLOB およびキュー サービスのバージョン 2009-09-19 以降では共有キー ライトをサポートします。 この形式は、以前のバージョンのストレージ サービスで使用される形式と同じです。

アクセスするリソースの URI の構築については、次のいずれかのトピックを参照してください。

• BLOB サービス: コンテナー、BLOB、およびメタデータ の名前付けと参照の

• Queue service: Addressing Queue Service Resources

• Table service: Addressing Table Service Resources

• ファイル サービス: 共有、ディレクトリ、ファイル、メタデータ の名前付けと参照の

2009-09-19 以降の共有キー形式

この形式では、2009-09-19 バージョン以降の BLOB サービスとキュー サービス、および 2014-02-14 バージョン以降のファイル サービスの共有キー承認がサポートされます。 次のように、この形式で CanonicalizedResource 文字列を構築します。

1. 空の文字列 ("") で始まり、スラッシュ (/) の後に、アクセスするリソースを所有するアカウントの名前を追加します。

2. クエリ パラメーターを指定せずに、リソースのエンコードされた URI パスを追加します。

3. リソース URI に対するすべてのクエリ パラメーター (存在する場合は comp パラメーターを含む) を取得します。

4. すべてのパラメーター名を小文字に変換します。

5. クエリ パラメーターをパラメーター名で昇順に構文的に並べ替えます。

6. 各クエリ パラメーターの名前と値を URL デコードします。

7. 各名前と値のペアの前に改行文字 (\n) を含めます。

8. 各クエリ パラメーターの名前と値を次の形式で文字列に追加し、名前と値の間にコロン (:)を含めるようにします。

   parameter-name:parameter-value

9. クエリ パラメーターに複数の値がある場合は、すべての値を辞書形式で並べ替え、コンマ区切りリストに含めます。

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

正規化されたリソース文字列を構築するための次の規則に注意してください。

• クエリ パラメーターの値に改行文字 (\n) を使用しないでください。 使用する必要がある場合は、正規化されたリソース文字列の形式に影響を与えないことを確認します。

• クエリ パラメーター値にはコンマを使用しないでください。

指定された要求 URI から構築できるため、署名文字列の CanonicalizedResource 部分を示す例をいくつか次に示します。

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 以降の共有キー ライトと Table Service 形式

この形式では、Table Service のすべてのバージョンで共有キーと共有キー Lite がサポートされ、Blob および Queue サービスのバージョン 2009-09-19 以降、およびファイル サービスのバージョン 2014-02-14 以降の共有キー Lite がサポートされます。 この形式は、以前のバージョンのストレージ サービスで使用される形式と同じです。 次のように、この形式で CanonicalizedResource 文字列を構築します。

1. 空の文字列 ("") で始まり、スラッシュ (/) の後に、アクセスするリソースを所有するアカウントの名前を追加します。

2. リソースのエンコードされた URI パスを追加します。 要求 URI がリソースのコンポーネントをアドレス指定する場合は、適切なクエリ文字列を追加します。 クエリ文字列には、疑問符と comp パラメーター (たとえば、?comp=metadata) を含める必要があります。 クエリ文字列に他のパラメーターを含める必要はありません。

署名のエンコード

署名をエンコードするには、UTF-8 でエンコードされた署名文字列で HMAC-SHA256 アルゴリズムを呼び出し、結果を Base64 としてエンコードします。 また、ストレージ アカウント キーを Base64 デコードする必要があることに注意してください。 次の形式を使用します (擬似コードとして表示)。

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))  

関連項目

• Blob Service REST API の
• キュー サービス REST API の
• Table Service REST API の
• Storage Services REST