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

  • Article

L’opération Set Share ACL définit une stratégie d’accès stockée à utiliser avec des signatures d’accès partagé. Pour plus d’informations sur la définition de stratégies d’accès, consultez Accorder un accès limité aux ressources stockage Azure à l’aide de signatures d’accès partagé.

Disponibilité du protocole

Protocole de partage de fichiers activé Disponible
SMB Oui
NFS Non

Requête

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

Méthode URI de demande Version HTTP
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1

Paramètres URI

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

Paramètre Description
timeout facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’expiration pour les opérations Azure Files.

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 requêtes auprès du Stockage Azure.
Date ou x-ms-date Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Cette opération est disponible uniquement dans les versions 2015-02-21 et ultérieures.

Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft 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 (Kio) enregistrée dans les journaux d’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. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.
x-ms-lease-id:<ID> Obligatoire si le partage de fichiers de destination a un bail actif. Disponible pour les versions 2020-02-10 et ultérieures. Si la demande n’inclut pas l’ID de bail ou s’il n’est pas valide, l’opération échoue avec status code 412 (Échec de la condition préalable).

Si cet en-tête est spécifié et que le partage de fichiers de destination n’a pas de bail actif, l’opération échoue avec status code 412 (Échec de la condition préalable).

Corps de la demande

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

L’élément SignedIdentifier inclut l’identificateur unique, comme 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 heures UTC et doivent être dans 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.fffffffTZD

Pour la partie date de ces formats, YYYY est une représentation de l'année à quatre chiffres, MM est une représentation du mois à deux chiffres et DD est une représentation du jour à deux chiffres. Pour la partie heure, hh est la représentation de l'heure au format 24 heures, mm est la représentation des minutes à deux chiffres, ss est la représentation des secondes à deux chiffres et fffffff est la représentation des millisecondes à sept chiffres. L’indicateur T d’heure 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.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

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 envoie le code d'état 200 (OK).

En-têtes de réponse

La réponse de l'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 du protocole HTTP/1.1.

En-tête de réponse Description
ETag Retourne la date et l’heure de la dernière modification du conteneur. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représentation des valeurs de date/heure dans les en-têtes.
Last-Modified Toute opération qui modifie le partage, ses propriétés ou métadonnées met à jour l’heure de la dernière modification, y compris la définition des autorisations du fichier. Les opérations sur les fichiers n’affectent pas l’heure de dernière modification du partage.
x-ms-request-id Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour la résolution des problèmes de la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
x-ms-version Indique la version de Azure Files utilisée pour exécuter la demande.
Date ou x-ms-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 , s’il est présent 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 demande, cet en-tête ne sera pas présent dans la réponse.

Exemple de réponse

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

Autorisation

Seul le propriétaire du compte peut appeler cette opération.

Notes

Seul le propriétaire du compte peut accéder aux ressources d’un partage particulier, sauf si l’une des conditions suivantes est vraie :

  • Le propriétaire a spécifié que les ressources de partage sont disponibles pour l’accès public en définissant les autorisations sur le partage.
  • Le propriétaire a émis une signature d’accès partagé pour une ressource dans le partage.

Lorsque vous définissez des autorisations pour un conteneur, les autorisations existantes sont remplacées. Pour mettre à jour les autorisations du conteneur, appelez Get Share ACL pour récupérer toutes les stratégies d’accès associées au conteneur. Modifiez la stratégie d’accès que vous souhaitez modifier, puis appelez Set Share ACL avec l’ensemble complet de données pour effectuer la mise à jour.

Établissement de stratégies d’accès au niveau du partage

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 elle est associée. 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 la 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, puis 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 la définition des stratégies d’accès, consultez Accorder un accès limité aux ressources stockage Azure à l’aide de signatures d’accès partagé.

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 les champs obligatoires sont manquants, la demande échoue. De même, si un champ est spécifié dans l'URL de la signature d'accès partagé et dans la stratégie d'accès stockée, la demande échoue avec le code d'état 400 (Requête incorrecte). Pour plus d’informations sur les champs qui composent une signature d’accès partagé, consultez Utiliser une signature d’accès partagé.

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

Une signature d’accès partagé peut être émise sur un partage ou un fichier, que les données du conteneur soient ou non disponibles pour l’accès en lecture anonyme. Une signature d’accès partagé permet de mieux contrôler comment, quand et à qui une ressource est rendue accessible.

Vous ne pouvez pas définir ou récupérer une stratégie d’accès pour un partage instantané. Si vous essayez de définir une stratégie d’accès, le service retourne status code 400 (InvalidQueryParameterValue).

Notes

Lorsque vous établissez une stratégie d’accès stockée sur un conteneur, l’application 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 status code 403 (Interdit), jusqu’à ce que la stratégie d’accès soit active.

Voir aussi

Opérations sur les ressources FileShare (Azure Files)