エクスポート (0) 印刷
すべて展開
このトピックはまだ評価されていません - このトピックを評価する

Windows Azure ストレージ サービスの認証

更新日: 2014年4月

パブリック アクセスまたは署名されたアクセスで使用できるようになっている BLOB またはコンテナー リソースに対する要求を除き、ストレージ サービスに対して行われるすべての要求は認証を受ける必要があります。

Important重要
Windows Azure ストレージ サービスは HTTP と HTTPS の両方をサポートしていますが、HTTPS の使用をお勧めします。

バージョン 2009-09-19 以降、BLOB、キュー、テーブルの各サービスは、次の共有キー認証スキームをサポートします。

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

  • テーブル サービスに対する共有キー。REST API を使用してテーブル サービスに要求を行うには、共有キー認証スキームを使用します。バージョン 2009-09-19 でのテーブル サービスの共有キー認証では、以前のバージョンのテーブル サービスと同じ署名文字列が使用されます。

  • 共有キー Lite。BLOB、キュー、およびテーブル サービスに対して要求を行うには、共有キー Lite 認証スキームを使用します。

    バージョン 2009-09-19 の BLOB およびキュー サービスの場合、共有キー Lite 認証は、以前のバージョンの BLOB およびキュー サービスで共有キーに対してサポートされていたものと同じ署名文字列の使用をサポートします。したがって、共有キー Lite を使用すると、署名文字列を更新しないで BLOB およびキュー サービスに対する要求を行うことができます。

認証された要求で必要なヘッダーは、Date または x-ms-date ヘッダーと、Authorization ヘッダーの 2 つです。以下のセクションでは、これらのヘッダーの作成方法について説明します。

noteメモ
コンテナーのアクセス許可を設定することにより、BLOB リソースをパブリック アクセスで使用できるようにすることができます。BLOB は、共有アクセス署名による署名されたアクセスで使用できる場合があります。共有アクセス署名は、別のメカニズムを使用して認証されます。詳細については、「Windows Azure ストレージ リソースへのアクセスの管理」を参照してください。

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

ストレージ サービスは、要求がサービスに到着した時刻によって、要求が作成されてから 15 分以上経過していないことを確認します。これにより、再生攻撃などの特定のセキュリティ攻撃を防ぎます。この検査で問題があると、サーバーは応答コード 403 (Forbidden) を返します。

noteメモ
x-ms-date ヘッダーが提供されているのは、一部の HTTP クライアント ライブラリおよびプロキシでは Date ヘッダーが自動的に設定され、開発者が認証された要求に含めるためにヘッダーの値を読み取ることができないためです。x-ms-date を設定する場合は、Date ヘッダーについては空の値で署名を作成します。

認証された要求には、Authorization ヘッダーが含まれる必要があります。このヘッダーが含まれない場合、要求は匿名になり、パブリック アクセス用または共有アクセス署名で署名されたアクセス用として指定されている BLOB コンテナーに対してのみ成功します。パブリック アクセスおよび署名されたアクセスのどちらも、テーブルおよびキューに対しては許可されません。

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

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

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

SharedKey または SharedKeyLite は、認証スキームの名前です。AccountName は、リソースを要求しているアカウントの名前です。Signature は、要求から作成され、SHA256 アルゴリズムを使用して計算された後、Base64 エンコーディングを使用してエンコードされた、Hash-based Message Authentication Code (HMAC) です。

noteメモ
パブリック アクセスが可能なリソースの場合、異なるアカウントの下にあるリソースを要求できます。

以下のセクションでは、Authorization ヘッダーの作成方法について説明します。

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

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

  • BLOB およびキュー サービスの共有キー認証の場合、署名文字列では各ヘッダーが 1 回だけ出現できます。いずれかのヘッダーが重複している場合、サービスはステータス コード 400 (Bad Request) を返します。

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

  • x-ms-date ヘッダーが指定されている場合、Date ヘッダーは要求で指定されているかどうかにかかわらず無視でき、署名文字列の Date 部分には単に空の行を指定できます。この場合は、「CanonicalizedHeaders 要素の作成」セクションの説明に従って x-ms-date ヘッダーを追加します。

    x-ms-date ヘッダーと Date ヘッダーを両方指定してもかまいません。この場合、サービスは x-ms-date の値を使用します。

  • x-ms-date ヘッダーを指定しない場合は、Date ヘッダーを署名文字列で指定します (ヘッダー名は含めません)。

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

  • 署名文字列を構成する CanonicalizedHeaders および CanonicalizedResource 文字列の作成の詳細については、後の該当するセクションを参照してください。

2009-09-19 バージョン以降の BLOB またはキュー サービスに対する要求の共有キー署名文字列をエンコードするには、次の形式を使用します。

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;

次の例は、Get Blob (REST API) 操作の署名文字列を示しています。ヘッダー値がない場所では、改行文字だけを指定することに注意してください。

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

同じ文字列の各部分を 1 行ごとに分解すると次のようになります。


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*/

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

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

2009-09-19 バージョンの BLOB およびキュー サービスで共有キー認証を使用するには、この拡張された署名文字列を使用するようにコードを更新する必要があることに注意してください。

コードを最小限の変更で 2009-09-19 バージョンの BLOB およびキュー サービスに移行したい場合は、共有キーではなく共有キー Lite を使用するように既存の Authorization ヘッダーを変更できます。共有キー Lite 認証で必要な署名形式は、2009-09-19 より前のバージョンの BLOB およびキュー サービスで共有キーに対して必要な形式と同じです。

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

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

REST API を使用して行われるテーブル サービスに対する要求の署名文字列をエンコードするには、次の形式を使用します。

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

noteメモ
バージョン 2009-09-19 以降のテーブル サービスでは、すべての REST 呼び出しに DataServiceVersion および MaxDataServiceVersion ヘッダーを含める必要があります。詳細については、「OData Data Service のバージョン ヘッダーの設定」を参照してください。

2009-09-19 バージョンの BLOB およびキュー サービスに対して行う要求の認証には、共有キー Lite 認証を使用できます。

共有キー Lite 認証の署名文字列は、2009-09-19 より前のバージョンの BLOB サービスやキュー サービスで共有キー認証に対して必要となる署名文字列と同じです。したがって、コードを最小限の変更で 2009-09-19 バージョンの BLOB サービスおよびキュー サービスに移行するには、署名文字列自体を変更することなく、共有キー Lite を使用するようにコードを変更できます。共有キー Lite を使用すると、2009-09-19 バージョンの API で共有キーを使用することにより提供される拡張セキュリティ機能を利用できないことに注意してください。

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

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

次の例は、Put Blob (REST API) 操作の署名文字列を示しています。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=

すべてのバージョンのテーブル サービスに対して行う要求の認証には、共有キー Lite 認証を使用できます。

共有キー Lite を使用して行われるテーブル サービスに対する要求の署名文字列をエンコードするには、次の形式を使用します。

StringToSign = Date + "\n" 
               CanonicalizedResource

次の例は、Create Table (REST API) 操作の署名文字列を示しています。

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 つのスペースに置き換えて文字列を展開します。

  5. ヘッダーのコロンの前後にある空白文字を除去します。

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

署名文字列の CanonicalizedResource 部分は、要求の対象であるストレージ サービス リソースを表します。リソースの URI から抽出される CanonicalizedResource 文字列のすべての部分は、URI の場合と同じように正確にエンコードする必要があります。

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

  • 2009-09-19 バージョンの BLOB およびキュー サービスの共有キー認証をサポートする形式。

  • すべてのバージョンのテーブル サービスの共有キーおよび共有キー Lite、および 2009-09-19 バージョンの BLOB およびキュー サービスの共有キー Lite をサポートする形式。この形式は、以前のバージョンのストレージ サービスで使用されているものと同じです。

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

noteメモ
ストレージ エミュレーターに対して認証を行う場合は、CanonicalizedResource 文字列にアカウント名が 2 回含まれます。これは予期されることです。Windows Azure ストレージ サービスに対して認証を行う場合は、アカウント名は CanonicalizedResource 文字列に 1 回だけ含まれます。

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

この形式は、2009-09-19 バージョンの BLOB およびキュー サービスの共有キー認証をサポートします。この形式の CanonicalizedResource 文字列は次のように作成します。

  1. 先頭に空の文字列 ("")、次にスラッシュ (/)、次にアクセス対象のリソースを所有しているアカウントの名前を追加します。

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

  3. comp パラメーターが存在する場合はそれも含めて、リソース URI に対するすべてのクエリ パラメーターを取得します。

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

  5. クエリ パラメーターをパラメーター名のアルファベット順に並べ替えます。

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

  7. 各クエリ パラメーターの名前と値を次の形式で文字列に追加します。名前と値の間にコロン (:) を必ず追加します。

    parameter-name:parameter-value

  8. クエリ パラメーターに複数の値がある場合は、すべての値を辞書順に並べ替えて、コンマ区切りのリストとして追加します。

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

  9. 名前と値の各ペアの後に改行文字 (\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

2009-09-19 の共有キー Lite およびテーブル サービスの形式

この形式は、すべてのバージョンのテーブル サービスの共有キーおよび共有キー Lite、および 2009-09-19 バージョンの BLOB およびキュー サービスの共有キー Lite をサポートします。この形式は、以前のバージョンのストレージ サービスで使用されているものと同じです。この形式の CanonicalizedResource 文字列は次のように作成します。

  1. 先頭に空の文字列 ("")、次にスラッシュ (/)、次にアクセス対象のリソースを所有しているアカウントの名前を追加します。

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

署名をエンコードするには、UTF-8 でエンコードされた署名文字列に対して HMAC-SHA256 アルゴリズムを呼び出し、結果を Base64 としてエンコードします。次の形式を使用します (擬似コードとして示されています)。

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

関連項目

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft. All rights reserved.