Partager via


Définir la liste de contrôle d’accès de table

L’opération Set Table ACL définit les stratégies d’accès stockées pour la table qui peuvent être utilisées avec des signatures d’accès partagé. Pour plus d’informations, consultez Définir une stratégie d’accès stockée.

Note

L’opération Set Table ACL est disponible dans la version 2012-02-12 et ultérieure.

Note

Une liste de contrôle d’accès (ACL) est une liste d’entrées de contrôle d’accès (ACL). Chaque ACE d’une liste de contrôle d’accès identifie un de fiduciaire et spécifie les droits d’accès autorisés, refusés ou audités pour ce fiduciaire. Pour plus d’informations, consultez listes de contrôle d’accès.

Demander

Vous pouvez construire la requête Set Table ACL comme suit. Nous vous recommandons HTTPS. Remplacez mon compte par le nom de votre compte de stockage.

Méthode URI de requête Version HTTP
PUT https://myaccount.table.core.windows.net/mytable?comp=acl HTTP/1.1

URI du service de stockage émulé

Lorsque vous effectuez une requête sur le service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port Stockage Table Azure comme 127.0.0.1:10002. Ajoutez ensuite le nom du compte de stockage émulé.

Méthode URI de requête Version HTTP
PUT http://127.0.0.1:10002/devstoreaccount1/mytable?comp=acl HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite pour le développement Azure Storage local.

Paramètres d’URI

Vous pouvez spécifier les paramètres supplémentaires suivants sur l’URI de requête :

Paramètre Description
timeout Optionnel. Exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations stockage table.

En-têtes de requête

Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs :

En-tête de requête Description
Authorization Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les demandes vers le stockage Azure.
Date ou x-ms-date Obligatoire. Spécifie le temps universel coordonné (UTC) de la requête. Pour plus d’informations, consultez Autoriser les demandes vers le stockage Azure.
x-ms-version Optionnel. Spécifie la version de l’opération à utiliser pour cette requête. Pour plus d’informations, consultez Contrôle de version pour les services stockage Azure.
x-ms-client-request-id Optionnel. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (KiB) enregistrée dans les journaux Storage Analytics lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes reçues par le serveur.

Corps de la demande

Pour spécifier une stratégie d’accès stockée, fournissez un identificateur unique et une stratégie d’accès dans le corps de la demande pour l’opération de Set Table ACL.

L’élément SignedIdentifier inclut l’identificateur unique, tel que spécifié dans l’élément Id. SignedIdentifier inclut également les détails de la stratégie d’accès, comme spécifié dans l’élément AccessPolicy. La longueur maximale de l’identificateur unique est de 64 caractères.

Les champs Start et Expiry doivent être exprimés en temps UTC et doivent respecter un format ISO 8061 valide. Les formats ISO 8061 pris en charge sont les suivants :

  • YYYY-MM-DD

  • YYYY-MM-DDThh:mmTZD

  • YYYY-MM-DDThh:mm:ssTZD

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

Pour la partie date de ces formats, YYYY est une représentation d’année à quatre chiffres, MM est une représentation de mois à deux chiffres et DD est une représentation de jour à deux chiffres. Pour la partie de temps, hh est la représentation horaire en notation de 24 heures, mm est la représentation de minute à deux chiffres, ss est la deuxième représentation à deux chiffres et ffffff est la représentation en millisecondes à six chiffres. L’indicateur d’heure T sépare les parties date et heure de la chaîne. L’indicateur de fuseau horaire TZD spécifie un fuseau horaire.

<?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>  
  

Exemple de requête

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>  
  

Réponse

La réponse inclut un code d’état HTTP et un ensemble d’en-têtes de réponse.

Code d’état

Une opération réussie retourne le code d’état 204 (aucun contenu).

Pour plus d’informations sur les codes d’état, consultez Les codes d’état et d’erreur.

En-têtes de réponse

La réponse de cette opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification de protocole HTTP/1.1.

En-tête de réponse Description
x-ms-request-id Identifie de manière unique la demande qui a été effectuée. Vous pouvez également l’utiliser pour résoudre les problèmes de la demande. Pour plus d’informations, consultez Résoudre les problèmes d’opérations d’API.
x-ms-version Indique la version du stockage table utilisée pour exécuter la requête. Cet en-tête est retourné pour les requêtes effectuées sur la version 2009-09-19 et ultérieures.
Date Valeur de date/heure UTC qui indique l’heure à laquelle le service a envoyé la réponse.
x-ms-client-request-id Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id, si elle est présente dans la requête et que la valeur est au maximum de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la requête, cet en-tête ne sera pas présent dans la réponse.

Exemple de réponse

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  
  

Autorisation

L’autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Vous pouvez autoriser l’opération de Set Table ACL à l’aide de l’ID Microsoft Entra ou de la clé partagée.

Pour autoriser l’opération de Set Table ACL à l’aide de l’ID Microsoft Entra, le principal de sécurité a besoin d’un rôle RBAC Azure personnalisé qui inclut l’action RBAC suivante : Microsoft.Storage/storageAccounts/tableServices/tables/setAcl/action.

Important

Microsoft recommande d’utiliser l’ID Microsoft Entra avec des identités managées pour autoriser les demandes adressées au stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Remarques

Lorsque vous définissez des autorisations pour une table, les autorisations existantes sont remplacées. Pour mettre à jour les autorisations de la table, appelez obtenir une liste de contrôle d’accès de table pour extraire toutes les stratégies d’accès associées à la table. Modifiez la stratégie d’accès que vous souhaitez modifier, puis appelez Set Table ACL avec l’ensemble complet de données pour effectuer la mise à jour.

Établissement de stratégies d’accès stockées

Une stratégie d’accès stockée peut spécifier l’heure de début, l’heure d’expiration et les autorisations pour les signatures d’accès partagé auxquelles il est associé. Selon la façon dont vous souhaitez contrôler l’accès à votre ressource de partage ou de fichier, vous pouvez :

  • Spécifiez tous ces paramètres dans la stratégie d’accès stockée et omettez-les de l’URL de la signature d’accès partagé. Cela vous permet de modifier le comportement de la signature associée ou de le révoquer à tout moment.
  • Spécifiez un ou plusieurs paramètres de stratégie d’accès dans la stratégie d’accès stockée et spécifiez les autres paramètres sur l’URL.
  • Spécifiez tous les paramètres sur l’URL. Dans ce cas, vous pouvez utiliser la stratégie d’accès stockée pour révoquer la signature, mais pas pour modifier son comportement.

Pour plus d’informations sur l’établissement de stratégies d’accès, consultez Définir une stratégie d’accès stockée.

Ensemble, la signature d’accès partagé et la stratégie d’accès stockée doivent inclure tous les champs requis pour autoriser la signature. Si des champs obligatoires sont manquants, la demande échoue. De même, si un champ est spécifié à la fois dans l’URL de signature d’accès partagé et dans la stratégie d’accès stockée, la demande échoue avec le code d’état 400 (demande incorrecte). Pour plus d’informations sur les champs qui composent une signature d’accès partagé, consultez Créer une SAP de service.

Vous pouvez définir un maximum de cinq stratégies d’accès distinctes pour une table à tout moment. Si plus de cinq stratégies d’accès sont passées dans le corps de la demande, le service retourne le code d’état 400 (requête incorrecte).

Note

Lorsque vous établissez une stratégie d’accès stockée sur une table, la prise en compte peut prendre jusqu’à 30 secondes. Pendant cet intervalle, une signature d’accès partagé associée à la stratégie d’accès stockée échoue avec le code d’état 403 (Interdit), jusqu’à ce que la stratégie d’accès devienne active.

Voir aussi

Définir une stratégie d’accès stockée
Créer et utiliser une signature d’accès partagé
Déléguer l’accès avec une signature d’accès partagé
obtenir une liste de contrôle d’accès de table
Autoriser les demandes adressées au stockage Azure
l’état et les codes d’erreur