共有 ACL の設定

共有 ACL の設定操作では、共有アクセス署名で使用する格納されたアクセス ポリシーを設定します。 アクセス ポリシーの設定の詳細については、「共有アクセス署名 (SAS) を使用してAzure Storage リソースへの制限付きアクセスを許可する」を参照してください。

プロトコルの可用性

有効なファイル共有プロトコル 利用可能
SMB Yes
NFS No

Request

共有 ACL の設定要求は、次のように構成できます。 HTTPS が推奨されます。 myaccount はストレージ アカウントの名前に置き換えます。

Method 要求 URI HTTP バージョン
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1

URI パラメーター

次の追加パラメーターを要求の URI で指定できます。

パラメーター 説明
timeout 省略可能。 timeout パラメーターは、秒単位で表されます。 詳細については、「 ファイル サービス操作のタイムアウトの設定」を参照してください。

要求ヘッダー

必須要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

要求ヘッダー 説明
Authorization 必須です。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storage要求を承認する」を参照してください。
Date または x-ms-date 必須です。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage要求を承認する」を参照してください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 この操作は、バージョン 2015-02-21 以降でのみ使用できます。

詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
x-ms-client-request-id 省略可能。 ストレージ分析ログが有効になっているときに分析ログに記録される 1 KiB 文字の制限を持つクライアント生成の不透明な値を提供します。 クライアント側のアクティビティをサーバーが受信した要求と関連付けるには、このヘッダーを使用することが強く推奨されます。 詳細については、「 Azure Blob Storage の監視」を参照してください。
x-ms-lease-id:<ID> コピー先のファイル共有にアクティブなリースがある場合に必要です。 バージョン 2020-02-10 以降で使用できます。 要求にリース ID が含まれていないか、リース ID が無効な場合、操作はステータス コード 412 (Precondition Failed) で失敗します。

このヘッダーが指定されていて、コピー先のファイル共有に現在アクティブなリースがない場合、状態コード 412 (前提条件が失敗) でも操作は失敗します。

要求本文

格納されているアクセス ポリシーを指定するには、 共有 ACL の設定 操作の要求本文に一意の識別子とアクセス ポリシーを指定します。

SignedIdentifier 要素には、Id 要素で指定されている一意の識別子と、AccessPolicy 要素で指定されたアクセス ポリシーの詳細が含まれます。 一意識別子の最大長は 64 文字です。

[開始] フィールドと [有効期限] フィールドは UTC 時刻で表す必要があり、有効な ISO 8061 形式に準拠している必要があります。 サポートされている ISO 8061 形式は次のとおりです。

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.fffffffTZD

これらの形式の日付部分では、YYYY は 4 桁の年表現、MM は 2 桁の月表現、DD は 2 桁の日付表現です。 時間部分では、hh は 24 時間表記の時間表現、mm は 2 桁の分表現、ss は 2 桁の秒表現、fffffff は 7 桁のミリ秒表現です。 時間指定子 T は文字列の日付部分と時間部分を分離し、タイム ゾーン指定子 TZD はタイム ゾーンを指定します。

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  

要求のサンプル

Request Syntax:  
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2015-07-01T08:49:37.0000000Z</Start>  
      <Expiry>2015-07-02T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

status code

操作に成功すると、状態コード 200 (OK) が返されます。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれています。 応答に追加の標準 HTTP ヘッダーが含まれる場合もあります。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています

応答ヘッダー 説明
ETag コンテナーが最後に更新された日時を返します。 日付形式は RFC 1123 に従います。 詳細については、「 ヘッダー内のDate-Time値の表現」を参照してください。
Last-Modified 共有またはそのプロパティまたはメタデータを変更する操作は、ファイルのアクセス許可の設定を含め、最後に変更された時刻を更新します。 ファイルに対する操作は、共有の最終更新時刻に影響しません。
x-ms-request-id このヘッダーは要求を一意に識別するので、要求のトラブルシューティングに使用できます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version 要求の実行に使用するファイル サービスのバージョンを示します。
Date または x-ms-date サービスによって生成される、応答の開始時刻を示す UTC 日付/時刻値。
x-ms-client-request-id このヘッダーは、要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、値が最大 1024 の ASCII 文字で表示される場合、ヘッダーの値 x-ms-client-request-id と等しくなります。 ヘッダーが x-ms-client-request-id 要求に存在しない場合、このヘッダーは応答に存在しません。

応答のサンプル

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: <date>  
ETag: "0x8CB171613397EAB"  
Last-Modified: <date>  
x-ms-version: 2015-02-21  
Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0  

承認

この操作を呼び出すことができるのはアカウント所有者のみです。

解説

共有に対するアクセス許可を設定して共有リソースをパブリック アクセスに使用できる、または共有内のリソースに対して共有アクセス署名を発行した場合を除き、アカウント所有者のみが特定の共有内のリソースにアクセスできます。

コンテナーのアクセス許可を設定すると、既存のアクセス許可が置換されます。 コンテナーのアクセス許可を更新するには、 Get Share ACL を呼び出して、コンテナーに関連付けられているすべてのアクセス ポリシーをフェッチし、変更するアクセス ポリシーを変更してから、完全なデータ セットで 共有 ACL の設定 を呼び出して更新を実行します。

共有レベルのアクセス ポリシーの確立

格納されているアクセス ポリシーでは、関連付けられている共有アクセス署名の開始時刻、有効期限、およびアクセス許可を指定できます。 共有リソースまたはファイル リソースへのアクセスを制御する方法に応じて、格納されているアクセス ポリシー内でこれらのパラメーターをすべて指定し、共有アクセス署名の URL からそれらを省略できます。 これにより、関連付けられた署名の動作をいつでも変更または取り消しできます。 また、保存されているアクセス ポリシー内で 1 つ以上のアクセス ポリシー パラメーターを指定し、残りのパラメーターを URL で指定することもできます。 すべてのパラメーターを URL で指定することもできます。 この場合、保存されているアクセス ポリシーを使用して署名を取り消すことができますが、署名の動作を変更することはできません。 アクセス ポリシーの設定の詳細については、「共有アクセス署名 (SAS) を使用してAzure Storage リソースへの制限付きアクセスを許可する」を参照してください。

共有アクセス署名と格納されているアクセス ポリシーを組み合わせて、署名を承認するために必要なすべてのフィールドを含める必要があります。 必須フィールドが欠落している場合、要求は失敗します。 同様に、共有アクセス署名 URL と格納されているアクセス ポリシーの両方でフィールドが指定されている場合、要求は状態コード 400 (Bad Request) で失敗します。 Shared Access Signature を構成するフィールドの詳細については、「Shared Access Signature の使用」を参照してください。

特定の共有に対して、最大 5 つの個別のアクセス ポリシーをいつでも設定できます。 5 つを超えるアクセス ポリシーが要求本文で渡された場合、サービスはステータス コード 400 (Bad Request) を返します。

コンテナー データが匿名読み取りアクセスに使用できるかどうかに関係なく、共有またはファイルに対して共有アクセス署名を発行できます。 共有アクセス署名は、リソースがいつ、どのように、だれに対してアクセス可能かを制御する優れた手段の 1 つです。

共有スナップショットに対してアクセス ポリシーを設定または取得することはできません。 アクセス ポリシーを設定しようとすると、サービスは状態コード 400 (InvalidQueryParameterValue) を返します。

注意

コンテナーに格納されているアクセス ポリシーを確立すると、有効になるまでに最大 30 秒かかる場合があります。 その間、アクセス ポリシーがアクティブになるまでは、保存されているアクセス ポリシーに関連付けられている共有アクセス署名は、ステータス コード 403 (Forbidden) が返されて失敗します。

関連項目

共有 (ファイル サービス) での操作