次の方法で共有

テーブル ACL の設定

  • [アーティクル]

Set Table ACL 操作では、共有アクセス署名で使用できるテーブルの格納されたアクセス ポリシーを設定します。 詳細については、「保存されているアクセス ポリシーを定義する」を参照してください。

手記

Set Table ACL 操作は、バージョン 2012-02-12 以降で使用できます。

手記

アクセス制御リスト (ACL) は、アクセス制御エントリ (ACE) の一覧です。 ACL 内の各 ACE は、トラスティ を識別し、そのトラスティに対して許可、拒否、または監査 アクセス権を指定します。 詳細については、「アクセス制御リスト」を参照してください。

依頼

Set Table ACL 要求は次のように構築できます。 HTTPS をお勧めします。 myaccount ストレージ アカウントの名前に置き換えます。

方式 要求 URI HTTP バージョン
PUT https://myaccount.table.core.windows.net/mytable?comp=acl HTTP/1.1

エミュレートされたストレージ サービス URI

エミュレートされたストレージ サービスに対して要求を行うときは、エミュレーターホスト名と Azure Table Storage ポートを 127.0.0.1:10002として指定します。 次に、エミュレートされたストレージ アカウント名を追加します。

方式 要求 URI HTTP バージョン
PUT http://127.0.0.1:10002/devstoreaccount1/mytable?comp=acl HTTP/1.1

詳細については、「ローカルの Azure Storage 開発に Azurite エミュレーターを使用する」を参照してください。

URI パラメーター

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

パラメーター 形容
timeout 随意。 秒単位で表されます。 詳細については、「Table Storage 操作のタイムアウトの設定」を参照してください。

要求ヘッダー

次の表では、必須および省略可能な要求ヘッダーについて説明します。

要求ヘッダー 形容
Authorization 必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。
Date または x-ms-date 必須。 要求の世界協定時刻 (UTC) を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。
x-ms-version 随意。 この要求に使用する操作のバージョンを指定します。 詳細については、Azure Storage サービスのバージョン管理の に関するページを参照してください。
x-ms-client-request-id 随意。 ログ記録の構成時に Storage Analytics ログに記録される 1 kibibyte (KiB) 文字の制限を持つ、クライアント生成の不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティと、サーバーが受信する要求を関連付けすることを強くお勧めします。

要求本文

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

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

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

  • YYYY-MM-DD

  • YYYY-MM-DDThh:mmTZD

  • YYYY-MM-DDThh:mm:ssTZD

  • YYYY-MM-DDThh:mm:ss.ffffffTZD

これらの形式の日付部分では、YYYY は 4 桁の年表現、MM は 2 桁の月表現、DD は 2 桁の日表現です。 時刻部分の場合、hh は 24 時間表記の時間表現、mm は 2 桁の分表現、ss は 2 桁の秒表現、ffffff は 6 桁のミリ秒表現です。 時刻指定子 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.table.core.windows.net/mytable?comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2013-08-15  
x-ms-date: Mon, 25 Nov 2013 00:42:49 GMT  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2013-11-26T08:49:37.0000000Z</Start>  
      <Expiry>2013-11-27T08:49:37.0000000Z</Expiry>  
      <Permission>raud</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

応答

応答には、HTTP 状態コードと一連の応答ヘッダーが含まれます。

状態コード

操作が成功すると、状態コード 204 (コンテンツなし) が返されます。

状態コードの詳細については、「状態コードとエラー コードを参照してください。

応答ヘッダー

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

応答ヘッダー 形容
x-ms-request-id 行われた要求を一意に識別します。 要求のトラブルシューティングにも使用できます。 詳細については、「API 操作のトラブルシューティング」を参照してください。
x-ms-version 要求の実行に使用される Table Storage のバージョンを示します。 このヘッダーは、バージョン 2009-09-19 以降に対して行われた要求に対して返されます。
Date サービスが応答を送信した時刻を示す UTC 日付/時刻値。
x-ms-client-request-id 要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、値が最大 1,024 文字表示される ASCII 文字である場合、x-ms-client-request-id ヘッダーの値と等しくなります。 x-ms-client-request-id ヘッダーが要求に存在しない場合、このヘッダーは応答に存在しません。

応答のサンプル

Response Status:  
HTTP/1.1 204 No Content  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Mon, 25 Nov 2013 22:42:55 GMT  
x-ms-version: 2013-08-15  
Server: Windows-Azure-Table/1.0 Microsoft-HTTPAPI/2.0

認可

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 Microsoft Entra ID または共有キーを使用して、Set Table ACL 操作を承認できます。

Microsoft Entra ID を使用して Set Table ACL 操作を承認するには、セキュリティ プリンシパルには、次の RBAC アクションを含むカスタム Azure RBAC ロールが必要です:Microsoft.Storage/storageAccounts/tableServices/tables/setAcl/action。

大事な

Microsoft では、マネージド ID で Microsoft Entra ID を使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra ID は、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

備考

テーブルのアクセス許可を設定すると、既存のアクセス許可が置き換えられます。 テーブルのアクセス許可を更新するには、テーブルの ACL の取得 呼び出して、テーブルに関連付けられているすべてのアクセス ポリシーをフェッチします。 変更するアクセス ポリシーを変更し、データの完全なセットで Set Table ACL を呼び出して更新を実行します。

保存されているアクセス ポリシーの確立

保存されているアクセス ポリシーでは、関連付けられている共有アクセス署名の開始時刻、有効期限、アクセス許可を指定できます。 共有またはファイル リソースへのアクセスを制御する方法に応じて、次のことができます。

  • 保存されているアクセス ポリシー内でこれらのパラメーターをすべて指定し、共有アクセス署名の URL からそれらを省略します。 これにより、関連付けられている署名の動作を変更したり、いつでも取り消したりできます。
  • 保存されているアクセス ポリシー内の 1 つ以上のアクセス ポリシー パラメーターを指定し、URL に他のパラメーターを指定します。
  • URL のすべてのパラメーターを指定します。 この場合、保存されているアクセス ポリシーを使用して署名を取り消すことができますが、動作を変更することはできません。

アクセス ポリシーの確立の詳細については、「保存されているアクセス ポリシーを定義する」を参照してください。

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

テーブルには、いつでも最大 5 つの個別のアクセス ポリシーを設定できます。 要求本文で 5 つ以上のアクセス ポリシーが渡された場合、サービスは状態コード 400 (無効な要求) を返します。

手記

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

関連項目

保存されているアクセス ポリシー を定義する
Shared Access Signature を作成して使用する
Shared Access Signature を使用してアクセスを委任する
テーブル ACL を取得する
Azure Storage への要求を承認する
状態とエラー コードの