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

Article
12/15/2024

L’opération Set Container ACL définit les autorisations pour le conteneur spécifié. Les autorisations indiquent si les objets blob d’un conteneur sont accessibles publiquement.

À compter de la version 2009-09-19, les autorisations de conteneur fournissent les options suivantes pour gérer l’accès au conteneur :

accès en lecture public complet : conteneur et les données d’objet blob peuvent être lues via une demande anonyme. Les clients peuvent énumérer des objets blob au sein du conteneur via une requête anonyme, mais ne peuvent pas énumérer les conteneurs dans le compte de stockage.
accès en lecture public pour les objets blob uniquement : données d’objets blob au sein de ce conteneur peuvent être lues via une requête anonyme, mais les données de conteneur ne sont pas disponibles. Les clients ne peuvent pas énumérer les objets blob au sein du conteneur via une demande anonyme.
Aucun accès en lecture public : conteneur et les données d’objet blob ne peuvent être lues que par le propriétaire du compte.

Set Container ACL définit également une stratégie d’accès stockée à utiliser avec des signatures d’accès partagé. Pour plus d’informations, consultez Définir une stratégie d’accès stockée.

Tout accès public au conteneur est anonyme, tel qu’un accès via une signature d’accès partagé.

Demander

La requête Set Container ACL peut être construite comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez mon compte par le nom de votre compte de stockage :

Méthode	URI de requête	Version HTTP
`PUT`	`https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl`	HTTP/1.1

Demande de service de stockage émulée

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 du service Blob comme 127.0.0.1:10000, suivi du nom du compte de stockage émulé :

Méthode	URI de requête	Version HTTP
`PUT`	`http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&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 dans l’URI de requête :

Paramètre	Description
`timeout`	Optionnel. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de service Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

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-blob-public-access`	Optionnel. Spécifie si les données du conteneur sont accessibles publiquement et le niveau d’accès. Les valeurs possibles sont les suivantes : - `container`: spécifie un accès en lecture public complet pour les données de conteneur et d’objet blob. Les clients peuvent énumérer des objets blob au sein du conteneur via une requête anonyme, mais ne peuvent pas énumérer les conteneurs dans le compte de stockage. - `blob:` spécifie l’accès en lecture public pour les objets blob. Les données blob de ce conteneur peuvent être lues via une requête anonyme, mais les données de conteneur ne sont pas disponibles. Les clients ne peuvent pas énumérer les objets blob au sein du conteneur via une demande anonyme. Si cet en-tête n’est pas inclus dans la demande, les données de conteneur sont privées au propriétaire du compte. Notez que la définition de l’accès public pour un conteneur dans un compte de stockage Azure Premium n’est pas autorisée.
`x-ms-lease-id: <ID>`	Facultatif, version 2012-02-12 et ultérieure. S’il est spécifié, `Set Container ACL` réussit uniquement si le bail du conteneur est actif et correspond à cet ID. S’il n’y a pas de bail actif ou si l’ID ne correspond pas, 412 (Échec de la condition préalable) est retourné.
`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 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 Monitor Stockage Blob Azure.

Cette opération prend également en charge l’utilisation d’en-têtes conditionnels pour exécuter l’opération uniquement si une condition spécifiée est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de service Blob.

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 Container ACL.

L’élément SignedIdentifier inclut l’identificateur unique, tel que spécifié dans l’élément Id et 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.fffffffTZD

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 correspond à 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 fffffff représente la représentation en millisecondes à sept chiffres. Un indicateur d’heure T sépare les parties date et heure de la chaîne, et un 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.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
x-ms-blob-public-access: container  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</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 200 (OK).

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
`ETag`	ETag du conteneur. Si la version de la demande est 2011-08-18 ou ultérieure, la valeur ETag est placée entre guillemets.
`Last-Modified`	Retourne la date et l’heure de la dernière modification du conteneur. Le format de date suit RFC 1123. Pour plus d’informations, consultez Représenter les valeurs de date/heure dans les en-têtes. Toute opération qui modifie le conteneur ou ses propriétés ou métadonnées met à jour l’heure de dernière modification, y compris la définition des autorisations du conteneur. Les opérations sur les objets blob n’affectent pas l’heure de dernière modification du conteneur.
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée et peut être utilisée 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 service Blob 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 générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
`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 ne contient pas plus 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, il 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: Sun, 25 Sep 2011 22:42:55 GMT  
ETag: "0x8CB171613397EAB"  
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/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 Container ACL comme décrit ci-dessous.

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.

'ID Microsoft Entra (recommandé)
clé partagée

Stockage Azure prend en charge l’utilisation de l’ID Microsoft Entra pour autoriser les demandes aux données d’objet blob. Avec l’ID Microsoft Entra, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par l’ID Microsoft Entra pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une demande auprès du service Blob.

Pour en savoir plus sur l’autorisation à l’aide de l’ID Microsoft Entra, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Voici l’action RBAC nécessaire pour un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra pour appeler l’opération de Set Container ACL et le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/setAcl/action
rôle intégré le moins privilégié :propriétaire des données blob du stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour accéder aux données blob.

L’opération de Set Container ACL prend en charge d’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée pour la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande de refuser l’autorisation de clé partagée pour le compte de stockage si possible. Pour plus d’informations, consultez Empêcher l’autorisation avec lede clé partagée.

Remarques

Lorsque vous définissez des autorisations pour un conteneur, les autorisations existantes sont remplacées. Pour mettre à jour les autorisations du conteneur, appelez Get Container ACL pour extraire 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 Container ACL avec l’ensemble complet de données pour effectuer la mise à jour.

Activer l’accès public anonyme sur les données de conteneur

Pour activer l’accès en lecture publique anonyme sur les données de conteneur, appelez Set Container ACL avec l’en-tête x-ms-blob-public-access défini sur container ou blob. Pour désactiver l’accès anonyme, appelez Set Container ACL sans spécifier l’en-tête x-ms-blob-public-access.

Si vous définissez x-ms-blob-public-access sur blob, les clients peuvent appeler les opérations suivantes de manière anonyme :

obtenir d’objets blob
obtenir des propriétés d’objet blob
obtenir des métadonnées d’objet blob
Obtenir la liste de blocs (pour la liste de blocs validée uniquement)
obtenir des plages de pages

Si vous définissez x-ms-blob-public-access sur container, les clients peuvent appeler les opérations suivantes de manière anonyme :

Opérations d’accès aux objets blob répertoriées dans la section précédente.
obtenir des propriétés de conteneur
obtenir des métadonnées de conteneur
répertorier les objets blob

Établir des stratégies d’accès au niveau du conteneur

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 conteneur ou blob, vous pouvez spécifier tous ces paramètres dans la stratégie d’accès stockée et les omettre à partir de l’URL de la signature d’accès partagé. En procédant ainsi, vous pouvez modifier le comportement de la signature associée à tout moment ou le révoquer. Vous pouvez également spécifier un ou plusieurs paramètres de stratégie d’accès dans la stratégie d’accès stockée, et les autres sur l’URL. Enfin, vous pouvez spécifier tous les paramètres de 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, 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 requête échoue. De même, si un champ est spécifié à la fois dans l’URL de signature d’accès partagé et la stratégie d’accès stockée, la demande échoue avec le code d’état 400 (demande incorrecte).

Au plus, cinq stratégies d’accès distinctes peuvent être définies pour un seul conteneur à 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).

Une signature d’accès partagé peut être émise sur un conteneur ou un objet blob, que les données du conteneur soient disponibles pour l’accès en lecture anonyme. Une signature d’accès partagé fournit une plus grande mesure du contrôle sur la façon, le moment et l’accessibilité d’une ressource.

Note

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

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, directement via l’API REST Stockage Blob ou à partir d’une bibliothèque cliente Stockage Azure. Ces demandes accumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture s’accumulent dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour les requêtes Set Container ACL en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Définir la liste de contrôle d’accès du conteneur	Objet blob de blocs Premium Standard v2 à usage général	Autres opérations
Définir la liste de contrôle d’accès du conteneur	Standard v1 à usage général	Opérations d’écriture

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez tarification du Stockage Blob Azure.

Voir aussi

restreindre l’accès aux conteneurs et aux objets blob
Déléguer l’accès avec une signature d’accès partagé
Créer et utiliser une signature d’accès partagé
Définir une stratégie d’accès stockée
obtenir une liste de contrôle d’accès de conteneur
Autoriser les demandes adressées au stockage Azure
l’état et les codes d’erreur
codes d’erreur du service Blob

Partager via