セールス: 1-800-867-1380
この記事は機械翻訳されたものです。 記事の文章にポインターを重ねると、原文のテキストが表示されます。
訳文
原文

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

 

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

System_CAPS_important重要

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

バージョン 2009-09-19 以降 (BLOB、キュー、テーブルの各サービス) と 2014-02-14 以降 (ファイル サービス) の場合、BLOB、キュー、テーブル、ファイルの各サービスは次の共有キー認証スキームをサポートします。

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

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

  • 共有キー Lite。共有キー Lite 認証スキームを使用すると、Blob、キュー、テーブル、およびファイル サービスに対して要求を作成できます。

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

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

System_CAPS_noteメモ

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

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

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

System_CAPS_noteメモ

x-ms-date いくつかの HTTP クライアント ライブラリおよびプロキシが自動的に設定されるため、ヘッダーが指定されて、 Date ヘッダーでは、開発者は、認証された要求に含めるためにその値を読み取る機会が得られないとします。 設定した場合 x-ms-date, 、空の値で署名の作成、 Date ヘッダーです。

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

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

形式、 Authorization ヘッダーを次に示します。

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

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

System_CAPS_noteメモ

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

次のセクションでは、作成する方法を説明する、 Authorization ヘッダーです。

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

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

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

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

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

    両方のオプションを使用可能なことに注意してください。 x-ms-dateDateこの例では、サービスの値を使用する x-ms-dateです。

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

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

  • 署名文字列には、正規化されたヘッダーと、正規化されたリソース文字列が含まれます。 これらの文字列を正規化することで、文字列は Azure Storage で認識される標準形式になります。 構築の詳細については、 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;

次の例では、署名文字列を Get 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

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


GET\n /*HTTP Verb*/ \n    /*Content-Encoding*/ \n    /*Content-Language*/ \n    /*Content-Length (include value 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: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*/

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

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

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

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

System_CAPS_important重要

読み取りアクセス geo レプリケーション (RA-GRS) が有効になっているストレージ アカウントに、2 次拠点にアクセスする場合は含まれません、 -secondary 承認ヘッダーに指定します。 認証目的のために、第 2 アクセスであっても、アカウント名は常に第 1 の場所の名前になります。

バージョンは 2015年-02-21 を使用する場合またはそれ以上、 Content-Length 0 の場合は、設定、 Content-Length の一部では、 StringToSign 空の文字列にします。

たとえば、次の要求の値、 Content-Length からヘッダーを省略すると、 StringToSign 0 であるとします。

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

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

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

一方 2015年-02-21 以前のバージョンで、 StringToSign の値 0 を含める必要があります Content-Length:

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:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

テーブル サービスで要求に 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;

System_CAPS_noteメモ

バージョン 2009年-09-19 以降では、テーブル サービスに必要なすべての REST 呼び出しが含まれている、 DataServiceVersionMaxDataServiceVersion ヘッダーです。 参照してください OData Data Service のバージョン ヘッダーの設定 の詳細。

バージョン 2009-09-19 以降の BLOB サービスとキュー サービスとバージョン 2014-02-14 以降のファイル サービスに対して行う要求の認証には、共有キー Lite 認証を使用できます。

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

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

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 エンコード署名文字列に対する hmac-sha256 アルゴリズムを使用してこの文字列をエンコード、構築、 Authorization ヘッダー、要求にヘッダーを追加するとします。 次の例は、 Authorization 同じ操作用のヘッダー。

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

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

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

StringToSign = Date + "\n" CanonicalizedResource

次の例では、署名文字列を Create Table 操作します。

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. ヘッダーをヘッダー名のアルファベット順に並べ替えます。 各ヘッダーは文字列内に 1 回だけ出現できます。

    System_CAPS_noteメモ

    辞書式順序 従来のアルファベット順の順序を常に一致可能性があります。

  4. 改行空白文字を 1 つのスペースに置き換えて文字列を展開します。

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

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

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

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

CanonicalizedResource 署名文字列の一部が、要求の対象となる記憶域サービスのリソースを表します。 任意の部分、 CanonicalizedResource URI と正確には、リソースの URI から派生した文字列をエンコードする必要があります。

サポートされている 2 つの形式がある、 CanonicalizedResource 文字列。

  • バージョン 2009-09-19 以降の BLOB サービスとキュー サービスとバージョン 2014-02-14 以降のファイル サービスの共有キー認証をサポートする形式。

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

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

System_CAPS_important重要

読み取りアクセス geo レプリケーション (RA-GRS) と、ストレージ アカウントがレプリケートされる、2 次拠点のリソースにアクセスする場合は含まれません、 –secondary 内の指定、 CanonicalizedResource 文字列。 使用される URI のリソース、 CanonicalizedResource 文字列 URI は、プライマリの場所にリソースの URI をする必要があります。

System_CAPS_noteメモ

ストレージ エミュレーターに対して認証を行う場合、アカウント名が 2 回含ま、 CanonicalizedResource 文字列。 これは予期されることです。 Azure ストレージ サービスに対して認証を行う場合、アカウント名に 1 回だけに表示されます、 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)))
表示:
© 2016 Microsoft