Créer une SAP de service

  • Article

Important

Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes sur les données d’objet blob, de file d’attente et de table, chaque fois que possible. L’autorisation avec des identités Microsoft Entra ID et managées offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée. Pour plus d’informations, consultez Autoriser avec Microsoft Entra ID. Pour en savoir plus sur les identités managées, consultez Que sont les identités managées pour les ressources Azure.

Pour les ressources hébergées en dehors d’Azure, telles que les applications locales, vous pouvez utiliser des identités managées via Azure Arc. Par exemple, les applications s’exécutant sur des serveurs avec Azure Arc peuvent utiliser des identités managées pour se connecter aux services Azure. Pour plus d’informations, consultez S’authentifier auprès de ressources Azure avec des serveurs avec Azure Arc.

Pour les scénarios où des signatures d’accès partagé (SAP) sont utilisées, Microsoft recommande d’utiliser une sap de délégation d’utilisateur. Une sap de délégation d’utilisateur est sécurisée avec Microsoft Entra informations d’identification au lieu de la clé de compte. Pour en savoir plus sur les signatures d’accès partagé, consultez Create une sap de délégation d’utilisateur.

Une signature d’accès partagé (SAP) de service délègue l’accès à une ressource dans un seul des services de stockage : Stockage Blob Azure, Stockage File d’attente Azure, Stockage Table Azure ou Azure Files. L’URI d’une sap de niveau de service se compose de l’URI à la ressource pour laquelle la SAP déléguera l’accès, suivi du jeton SAP.

Le jeton SAP est la chaîne de requête qui inclut toutes les informations requises pour autoriser une demande. Le jeton spécifie la ressource à laquelle un client peut accéder, les autorisations accordées et la période pendant laquelle la signature est valide.

Une sap peut également spécifier l’adresse IP ou la plage d’adresses prises en charge à partir de laquelle les demandes peuvent provenir, le protocole pris en charge avec lequel une demande peut être effectuée ou un identificateur de stratégie d’accès facultatif associé à la demande.

Enfin, chaque jeton SAP comprend une signature.

Attention

Les signatures d’accès partagé sont des clés qui accordent des autorisations aux ressources de stockage, et vous devez les protéger comme vous le feriez pour une clé de compte. Il est important de protéger une SAP contre toute utilisation malveillante ou involontaire. Faites preuve de discrétion lors de la distribution d’une SAP et mettez en place un plan de révocation d’une SAS compromis. Les opérations qui utilisent des signatures d’accès partagé doivent être effectuées uniquement sur une connexion HTTPS, et les URI SAS doivent être distribués uniquement sur une connexion sécurisée, telle que HTTPS.

Autoriser une sap de service

Vous sécurisez une sap de compte à l’aide d’une clé de compte de stockage. Lorsque vous créez une SAP de compte, votre application cliente doit posséder la clé de compte.

Pour utiliser Microsoft Entra informations d’identification afin de sécuriser une sap pour un conteneur ou un objet blob, créez une sap de délégation d’utilisateur.

Prise en charge des SAS de service pour l’accès limité à l’annuaire

Une sap de service prend en charge l’étendue du répertoire (sr=d) lorsque la version d’autorisation (sv) est 2020-02-10 ou ultérieure et qu’un espace de noms hiérarchique est activé. La sémantique de l’étendue du répertoire (sr=d) est similaire à celle de l’étendue du conteneur (sr=c), sauf que l’accès est limité à un répertoire et à tous les fichiers et sous-répertoires qu’il contient. Lorsque sr=d est spécifié, le paramètre de sdd requête est également requis.

Le format chaîne à signer pour la version d’autorisation 2020-02-10 est inchangé.

Construire une sap de service

L’image suivante représente les parties de l’URI de signature d’accès partagé. Les pièces requises s’affichent en orange. Les champs qui composent le jeton SAP sont décrits dans les sections suivantes.

Diagramme des éléments de paramètre d’une URL de signature d’accès partagé.

Les sections suivantes décrivent comment spécifier les paramètres qui composent le jeton SAP de service.

Spécifier le signedVersion champ

Le signedVersion champ (sv) contient la version de service de la signature d’accès partagé. Cette valeur spécifie la version de l’autorisation de clé partagée utilisée par cette signature d’accès partagé (dans le signature champ). La valeur spécifie également la version du service pour les demandes effectuées avec cette signature d’accès partagé.

Pour plus d’informations sur la version utilisée lorsque vous exécutez des demandes via une signature d’accès partagé, consultez Gestion de version pour les services stockage Azure.

Pour plus d’informations sur la façon dont ce paramètre affecte l’autorisation des demandes effectuées avec une signature d’accès partagé, consultez Déléguer l’accès avec une signature d’accès partagé.

Nom du champ Paramètre de requête. Description
signedVersion sv Obligatoire. Pris en charge dans les versions 2012-02-12 et ultérieures. Version du service de stockage à utiliser pour autoriser et gérer les demandes que vous effectuez avec cette signature d’accès partagé. Pour plus d’informations, consultez Gestion des versions pour les services stockage Azure.

Déterminer la version d’une requête SAP héritée

Dans les scénarios hérités où signedVersion n’est pas utilisé, Stockage Blob applique des règles pour déterminer la version. Pour plus d’informations sur ces règles, consultez Gestion de version pour les services stockage Azure.

Important

Le logiciel client peut rencontrer un comportement de protocole inattendu lorsque vous utilisez un URI de signature d’accès partagé qui utilise une version de service de stockage plus récente que le logiciel client. Le code qui construit des URI de signature d’accès partagé doit s’appuyer sur des versions comprises par le logiciel client qui effectue des demandes de service de stockage.

Spécifier la ressource signée (Stockage Blob uniquement)

Le champ obligatoire signedResource (sr) spécifie les ressources accessibles via la signature d’accès partagé. Le tableau suivant décrit comment faire référence à une ressource d’objet blob ou de conteneur dans le jeton SAP.

Ressource Valeur du paramètre Versions prises en charge Description
Objet blob b Tous Octroie l’accès au contenu et aux métadonnées de l’objet blob.
Version de blob Bv 2018-11-09 et versions ultérieures Octroie l’accès au contenu et aux métadonnées de la version de l’objet blob, mais pas à l’objet blob de base.
Instantané d’objet blob bs 2018-11-09 et versions ultérieures Octroie l’accès au contenu et aux métadonnées de l’objet blob instantané, mais pas à l’objet blob de base.
Conteneur c Tous Octroie l’accès au contenu et aux métadonnées de n’importe quel objet blob dans le conteneur, ainsi qu’à la liste des objets blob dans le conteneur.
Répertoire d 2020-02-10 et versions ultérieures Octroie l’accès au contenu et aux métadonnées de tout objet blob dans le répertoire, ainsi qu’à la liste des objets blob dans le répertoire, dans un compte de stockage avec un espace de noms hiérarchique activé. Si un répertoire est spécifié pour le signedResource champ, le signedDirectoryDepth paramètre (sdd) est également requis. Un répertoire est toujours imbriqué dans un conteneur.

Spécifier la ressource signée (Azure Files)

SaS est pris en charge pour Azure Files version 2015-02-21 et ultérieure.

Le champ signedResource spécifie les ressources accessibles via la signature d'accès partagé. Le tableau suivant décrit comment faire référence à une ressource de fichier ou de partage sur l’URI.

Nom du champ Paramètre de requête. Description
signedResource sr Obligatoire.

Spécifiez f si la ressource partagée est un fichier. Cela accorde l’accès au contenu et aux métadonnées du fichier.

Spécifiez s si la ressource partagée est un partage. Cela accorde l’accès au contenu et aux métadonnées de n’importe quel fichier dans le partage, ainsi qu’à la liste des répertoires et fichiers du partage.

Spécifier des paramètres de requête pour remplacer les en-têtes de réponse (Stockage Blob et Azure Files uniquement)

Pour définir les valeurs de certains en-têtes de réponse à retourner lorsque la signature d'accès partagé est utilisée dans une demande, spécifiez des en-têtes de réponse dans les paramètres de requête. Cette fonctionnalité est prise en charge à partir de la version 2013-08-15 pour le Stockage Blob et de la version 2015-02-21 pour Azure Files. Les signatures d’accès partagé qui utilisent cette fonctionnalité doivent inclure le sv paramètre défini 2013-08-15 sur ou une version ultérieure pour le Stockage Blob, ou vers 2015-02-21 ou une version ultérieure pour Azure Files.

Les en-têtes de réponse et les paramètres de requête correspondants sont répertoriés dans le tableau suivant :

Nom de l'en-tête de réponse Paramètre de requête SAS correspondant
Cache-Control rscc
Content-Disposition rscd
Content-Encoding rsce
Content-Language rscl
Content-Type rsct

Par exemple, si vous spécifiez le rsct=binary paramètre de requête sur une signature d’accès partagé créée avec la version 2013-08-15 ou ultérieure, l’en-tête Content-Type de réponse est défini sur binary. Cette valeur remplace la Content-Type valeur d’en-tête stockée pour l’objet blob pour une requête qui utilise cette signature d’accès partagé uniquement.

Si vous créez une signature d’accès partagé qui spécifie des en-têtes de réponse comme paramètres de requête, vous devez les inclure dans la chaîne à signer utilisée pour construire la chaîne de signature. Pour plus d’informations, consultez la section « Construire la chaîne de signature » plus loin dans cet article. Pour obtenir d’autres exemples, consultez Exemples sap de service.

Spécifier le nom de la table (Stockage table uniquement)

Le champ tableName spécifie le nom de la table à partager.

Nom du champ Paramètre de requête. Description
tableName tn Obligatoire. Nom de la table à partager.

Spécifier la stratégie d’accès

La partie stratégie d’accès de l’URI indique la période pendant laquelle la signature d’accès partagé est valide et les autorisations à accorder à l’utilisateur. Les parties de l’URI qui composent la stratégie d’accès sont décrites dans le tableau suivant :

Nom du champ Paramètre de requête. Description
signedStart st facultatif. Heure à laquelle la signature d’accès partagé devient valide, exprimée dans l’un des formats UTC ISO 8601 acceptés. Si ce paramètre est omis, l’heure UTC actuelle est utilisée comme heure de début.

Dans les versions antérieures à 2012-02-12, la durée comprise entre signedStart et signedExpiry ne peut pas dépasser une heure, sauf si une stratégie de conteneur est utilisée. Pour plus d’informations sur les formats UTC acceptés, consultez Mettre en forme des valeurs de date/heure.
signedExpiry se Obligatoire. Heure à laquelle la signature d’accès partagé devient non valide, exprimée dans l’un des formats UTC ISO 8601 acceptés. Vous devez omettre ce champ s’il a été spécifié dans une stratégie d’accès stockée associée. Pour plus d’informations sur les formats UTC acceptés, consultez Mettre en forme des valeurs de date/heure.
signedPermissions 1 sp Obligatoire. Autorisations associées à la signature d’accès partagé. L’utilisateur est limité aux opérations autorisées par les autorisations. Vous devez omettre ce champ s’il a été spécifié dans une stratégie d’accès stockée associée.
startPk 2

startRk 2		 spk

srk		 Stockage table uniquement.

Facultatif, mais startPk doit accompagner startRk. Clés de partition et de ligne minimales accessibles avec cette signature d’accès partagé. Les valeurs de clé sont incluses. S’ils sont omis, il n’existe aucune limite inférieure sur les entités de table accessibles.
endPk 2

endRk 2		 epk

erk		 Stockage table uniquement.

Facultatif, mais endPk doit accompagner endRk. Nombre maximal de clés de partition et de ligne accessibles avec cette signature d’accès partagé. Les valeurs de clé sont incluses. S’ils sont omis, il n’existe aucune limite supérieure sur les entités de table accessibles.

1 Le signedPermissions champ est obligatoire sur l’URI, sauf s’il est spécifié dans le cadre d’une stratégie d’accès stockée.
2 Les startPkchamps , startRk, endPket endRk ne peuvent être spécifiés que sur les ressources de stockage Table.

Spécifier des autorisations

Les autorisations spécifiées pour le signedPermissions champ (sp) sur le jeton SAP indiquent les opérations qu’un client peut effectuer sur la ressource.

Vous pouvez combiner des autorisations pour permettre à un client d’effectuer plusieurs opérations avec la même SAP. Lorsque vous construisez la sap, vous devez inclure les autorisations dans l’ordre suivant :

racwdxltmeop

Exemples de paramètres d’autorisations valides pour un conteneur : rw, rd, rl, wd, wlet rl. Exemples de paramètres non valides : wr, dr, lret dw. Vous ne pouvez pas spécifier une désignation d’autorisation plusieurs fois.

Une sap de service ne peut pas accorder l’accès à certaines opérations :

  • Les conteneurs, les files d’attente et les tables ne peuvent pas être créés, supprimés ou répertoriés.
  • Les métadonnées et propriétés du conteneur ne peuvent pas être lues ou écrites.
  • Les files d’attente ne peuvent pas être effacées et leurs métadonnées ne peuvent pas être écrites.
  • Les conteneurs ne peuvent pas être loués.

Pour construire une sap qui accorde l’accès à ces opérations, utilisez une sap de compte. Pour plus d’informations, consultez Créer une signature d’accès partagé de compte.

Important

Les signatures d’accès partagé sont des clés qui accordent des autorisations aux ressources de stockage, et vous devez les protéger comme vous le feriez pour une clé de compte. Effectuez des opérations qui utilisent des signatures d’accès partagé uniquement sur une connexion HTTPS et distribuez des URI de signature d’accès partagé uniquement sur une connexion sécurisée, telle que HTTPS.

Les autorisations prises en charge pour chaque type de ressource sont décrites dans les sections suivantes.

Autorisations pour un répertoire, un conteneur ou un blob

Les autorisations prises en charge pour chaque type de ressource sont décrites dans le tableau suivant :

Autorisation Symbole d'URI Ressource Prise en charge de la version Opérations autorisées
Lire r Conteneur
Répertoire
Objet blob		 Tous Lisez le contenu, la liste de blocs, les propriétés et les métadonnées d’un objet blob dans le conteneur ou le répertoire. Utilisez un objet blob comme source d’une opération de copie.
Ajouter a Conteneur
Répertoire
Objet blob		 Tous Ajouter un bloc à un objet blob d’ajout.
Créer c Conteneur
Répertoire
Objet blob		 Tous Écrivez un nouvel objet blob, instantané un objet blob ou copiez-le dans un nouvel objet blob.
Write w Conteneur
Répertoire
Blob		 Tous Create ou écrire du contenu, des propriétés, des métadonnées ou une liste de blocage. Créer un instantané ou louer l'objet blob. Redimensionner l'objet blob (objet blob de page uniquement). Utilisez l’objet blob comme destination d’une opération de copie.
Supprimer d Conteneur
Répertoire
Blob		 Tous Supprimer un objet blob. Pour les versions 2017-07-29 et ultérieures, l’autorisation Supprimer permet également de rompre un bail sur un objet blob. Pour plus d’informations, consultez l’opération Bail Blob .
Supprimer la version x Conteneur
Objet blob		 2019-12-12 et versions ultérieures Supprimez une version d’objet blob.
Suppression définitive y Blob 2020-02-10 et versions ultérieures Supprimez définitivement un instantané ou une version d’objet blob.
List l Conteneur
Répertoire		 Tous Répertorier les objets blob de manière non récursive.
Étiquettes t Blob 2019-12-12 et versions ultérieures Lire ou écrire les balises sur un objet blob.
Rechercher f Conteneur 2019-12-12 et versions ultérieures Recherchez des objets blob avec des balises d’index.
Déplacer m Conteneur
Répertoire
Blob		 2020-02-10 et versions ultérieures Déplacez un objet blob ou un répertoire et son contenu vers un nouvel emplacement. Cette opération peut éventuellement être limitée au propriétaire de l’objet blob, du répertoire ou du répertoire parent enfant si le saoid paramètre est inclus dans le jeton SAS et que le bit collant est défini sur le répertoire parent.
Execute e Conteneur
Répertoire
Blob		 2020-02-10 et versions ultérieures Obtenez les propriétés système et, si l’espace de noms hiérarchique est activé pour le compte de stockage, obtenez la liste de contrôle d’accès POSIX d’un objet blob. Si l’espace de noms hiérarchique est activé et que l’appelant est le propriétaire d’un objet blob, cette autorisation permet de définir le groupe propriétaire, les autorisations POSIX et la liste de contrôle d’accès POSIX de l’objet blob. ne permet pas à l’appelant de lire les métadonnées définies par l’utilisateur.
Propriété o Conteneur
Répertoire
Blob		 2020-02-10 et versions ultérieures Lorsque l’espace de noms hiérarchique est activé, cette autorisation permet à l’appelant de définir le propriétaire ou le groupe propriétaire, ou d’agir en tant que propriétaire lors du changement de nom ou de la suppression d’un répertoire ou d’un objet blob dans un répertoire dont le bit est défini.
Autorisations p Conteneur
Répertoire
Blob		 2020-02-10 et versions ultérieures Lorsque l’espace de noms hiérarchique est activé, cette autorisation permet à l’appelant de définir des autorisations et des listes de contrôle d’accès POSIX sur les répertoires et les objets blob.
Définir la stratégie d’immuabilité i Conteneur
Objet blob		 2020-06-12 et versions ultérieures Définissez ou supprimez la stratégie d’immuabilité ou la conservation légale sur un objet blob.

Autorisations pour un fichier

Autorisation Symbole d'URI Opérations autorisées
Lire r Lisez le contenu, les propriétés et les métadonnées. Utilisez le fichier comme source d’une opération de copie.
Créer c Create un nouveau fichier ou copier un fichier dans un nouveau fichier.
Write w Create ou écrire du contenu, des propriétés et des métadonnées. Redimensionnez le fichier. Utilisez le fichier comme destination d’une opération de copie.
Supprimer d Supprimer les fichiers.

Autorisations pour un partage

Autorisation Symbole d'URI Opérations autorisées
Lire r Lisez le contenu, les propriétés ou les métadonnées d’un fichier dans le partage. Utilisez n’importe quel fichier dans le partage comme source d’une opération de copie.
Créer c Create un nouveau fichier dans le partage, ou copiez un fichier dans un nouveau fichier dans le partage.
Write w Pour n’importe quel fichier dans le partage, créez ou écrivez du contenu, des propriétés ou des métadonnées. Redimensionnez le fichier. Utilisez le fichier comme destination d’une opération de copie. Remarque : Vous ne pouvez pas accorder d’autorisations pour lire ou écrire des propriétés ou des métadonnées de partage à l’aide d’une sape de service. Utilisez plutôt une SAP de compte.
Supprimer d Supprimez n’importe quel fichier dans le partage. Remarque : Vous ne pouvez pas accorder d’autorisations pour supprimer un partage à l’aide d’une SAP de service. Utilisez plutôt une SAP de compte.
List l Répertorier les fichiers et les répertoires dans le partage.

Autorisations pour une file d'attente

Autorisation Symbole d'URI Opérations autorisées
Lire r Lire les métadonnées et les propriétés, notamment le nombre de messages. Lire les messages.
Ajouter a Ajouter des messages à la file d'attente.
Update u Mettre à jour les messages dans la file d'attente. Remarque : utilisez l’autorisation Traiter avec Update afin d’obtenir d’abord le message que vous souhaitez mettre à jour.
Processus p Recevoir et supprimer les messages de la file d'attente.

Autorisations pour une table

Autorisation Symbole d'URI Opérations autorisées
Requête r Obtenir et interroger des entités.
Ajouter a Ajouter des entités. Remarque : Les autorisations Ajouter et Mettre à jour sont requises pour les opérations d’upsert.
Update u Mettre à jour les entités. Remarque : Les autorisations Ajouter et Mettre à jour sont requises pour les opérations d’upsert.
Supprimer d Supprimer des entités.

Spécifier une adresse IP ou une plage d’adresses IP

À compter de la version 2015-04-05, le champ facultatif signedIp (sip) spécifie une adresse IP publique ou une plage d’adresses IP publiques à partir de laquelle accepter les demandes. Si l’adresse IP à partir de laquelle la demande provient ne correspond pas à l’adresse IP ou à la plage d’adresses spécifiée sur le jeton SAP, la demande n’est pas autorisée. Seules les adresses IPv4 sont prises en charge.

Lorsque vous spécifiez une plage d’adresses IP, notez que la plage est inclusive. Par exemple, la sip=168.1.5.65 spécification ou sip=168.1.5.60-168.1.5.70 sur la signature d’accès partagé limite la demande à ces adresses IP.

Le tableau suivant indique s’il faut inclure le signedIp champ sur un jeton SAP pour un scénario spécifié, en fonction de l’environnement client et de l’emplacement du compte de stockage.

Environnement client Emplacement du compte de stockage Recommandation
Client s’exécutant dans Azure Dans la même région que le client Une signature d’accès partagé fournie au client dans ce scénario ne doit pas inclure d’adresse IP sortante pour le signedIp champ. Les demandes effectuées à partir de la même région qui utilisent une signature d’accès partagé avec une adresse IP sortante spécifiée échouent.

Utilisez plutôt un réseau virtuel Azure pour gérer les restrictions de sécurité réseau. Les demandes adressées au stockage Azure à partir de la même région ont toujours lieu sur une adresse IP privée. Pour plus d’informations, consultez Configurer Pare-feu et réseaux virtuels dans Stockage Azure.
Client s’exécutant dans Azure Dans une région différente du client Une signature d’accès partagé fournie au client dans ce scénario peut inclure une adresse IP publique ou une plage d’adresses pour le signedIp champ. Une requête effectuée avec la signature d’accès partagé doit provenir de l’adresse IP ou de la plage d’adresses spécifiée.
Client s’exécutant localement ou dans un autre environnement cloud Dans n’importe quelle région Azure Une signature d’accès partagé fournie au client dans ce scénario peut inclure une adresse IP publique ou une plage d’adresses pour le signedIp champ. Une requête effectuée avec la signature d’accès partagé doit provenir de l’adresse IP ou de la plage d’adresses spécifiée.

Si la demande passe par un proxy ou une passerelle, fournissez l’adresse IP sortante publique de ce proxy ou passerelle pour le signedIp champ.

Spécifier le protocole HTTP

À compter de la version 2015-04-05, le champ facultatif signedProtocol (spr) spécifie le protocole autorisé pour une requête effectuée avec la signature d’accès partagé. Les valeurs possibles sont à la fois HTTPS et HTTP (https,http) ou uniquement HTTPS (https). La valeur par défaut est https,http. Notez que HTTP seul n’est pas une valeur autorisée.

Spécifier des plages d’accès aux tables

Les startPkchamps , startRk, endPket endRk définissent une plage d’entités de table associées à une signature d’accès partagé. Les requêtes de table retournent uniquement les résultats qui se trouvent dans la plage, et les tentatives d’utilisation de la signature d’accès partagé pour ajouter, mettre à jour ou supprimer des entités en dehors de cette plage échouent.

Si startPk est égal endPkà , la signature d’accès partagé autorise l’accès aux entités dans une seule partition de la table.

Si startPk est endPk égal à et startRk égal endRkà , la signature d’accès partagé ne peut accéder qu’à une seule entité dans une partition.

Pour comprendre comment ces champs limitent l’accès aux entités d’une table, reportez-vous au tableau suivant :

Champs présents Étendue de la contrainte
startPk partitionKey >= startPk
endPk partitionKey <= endPk
startPk, startRk (partitionKey >startPk) || (partitionKey == startPk && rowKey >= startRk)
endPk, endRk (partitionKey <endPk) || (partitionKey == endPk && rowKey <= endRk)

Spécifier la profondeur du répertoire

Lorsqu’un espace de noms hiérarchique est activé et que le signedResource champ spécifie un répertoire (sr=d), vous devez également spécifier le signedDirectoryDepth champ (sdd) pour indiquer le nombre de sous-répertoires sous le répertoire racine. La valeur du sdd champ doit être un entier non négatif.

Par exemple, le répertoire https://{account}.blob.core.windows.net/{container}/ racine a une profondeur de 0. Chaque sous-répertoire dans le répertoire racine ajoute à la profondeur de 1. Le répertoire https://{account}.blob.core.windows.net/{container}/d1/d2 a une profondeur de 2.

Ce champ est pris en charge avec la version 2020-02-10 ou ultérieure.

Spécifier l’identificateur signé

Lorsque vous spécifiez le signedIdentifier champ sur l’URI, vous associez la signature d’accès partagé spécifiée à une stratégie d’accès stockée correspondante. Une stratégie d'accès stockée donne un contrôle supplémentaire sur une ou plusieurs signatures d'accès partagé et permet notamment de les révoquer le cas échéant. Chaque conteneur, file d’attente, table ou partage peut avoir jusqu’à cinq stratégies d’accès stockées.

Le tableau suivant décrit comment faire référence à un identificateur signé sur l’URI :

Nom du champ Paramètre de requête. Description
signedIdentifier si facultatif. Valeur unique allant jusqu’à 64 caractères qui correspond à une stratégie d’accès spécifiée pour le conteneur, la file d’attente ou la table.

Une stratégie d’accès stockée inclut un identificateur signé, une valeur allant jusqu’à 64 caractères qui est unique au sein de la ressource. Vous pouvez spécifier la valeur de cet identificateur signé pour le signedidentifier champ dans l’URI de la signature d’accès partagé. Lorsque vous spécifiez un identificateur signé sur l’URI, vous associez la signature à la stratégie d’accès stockée. Pour établir une stratégie d’accès au niveau du conteneur à l’aide de l’API REST, consultez Déléguer l’accès avec une signature d’accès partagé.

Spécifier l’étendue de chiffrement

En utilisant le signedEncryptionScope champ sur l’URI, vous pouvez spécifier l’étendue de chiffrement que l’application cliente peut utiliser. Il applique le chiffrement côté serveur avec l’étendue de chiffrement spécifiée lorsque vous chargez des objets blob (PUT) avec le jeton SAS. Get et HEAD ne seront pas limités et exécutés comme précédemment.

Le tableau suivant décrit comment faire référence à une étendue de chiffrement signée sur l’URI :

Nom du champ Paramètre de requête. Description
signedEncryptionScope ses facultatif. Indique l’étendue de chiffrement à utiliser pour chiffrer le contenu de la demande.

Ce champ est pris en charge avec la version 2020-12-06 ou ultérieure. Si vous ajoutez avant ses la version prise en charge, le service retourne le code de réponse d’erreur 403 (Interdit).

Si vous définissez l’étendue de chiffrement par défaut pour le conteneur ou le système de fichiers, le ses paramètre de requête respecte la stratégie de chiffrement de conteneur. S’il existe une incompatibilité entre le paramètre de requête et x-ms-default-encryption-scope l’en-têteses, et que l’en-tête x-ms-deny-encryption-scope-override est défini sur true, le service retourne le code de réponse d’erreur 403 (Interdit).

Lorsque vous fournissez l’en-tête x-ms-encryption-scope et le ses paramètre de requête dans la requête PUT, le service retourne le code de réponse d’erreur 400 (requête incorrecte) en cas d’incompatibilité.

Spécifier la signature

Vous utilisez la partie signature de l’URI pour autoriser la demande effectuée avec la signature d’accès partagé. Stockage Azure utilise un schéma d’autorisation de clé partagée pour autoriser une SAP de service.

Le tableau suivant explique comment spécifier la signature sur l’URI :

Nom du champ Paramètre de requête. Description
signature sig La chaîne à signer est une chaîne unique qui est construite à partir des champs et qui doit être vérifiée pour autoriser la demande. La signature est un code d’authentification de message basé sur le hachage (HMAC) que vous calculez sur la chaîne à signer et la clé à l’aide de l’algorithme SHA256, puis encodez à l’aide de l’encodage Base64.

Construction de la chaîne de signature

Pour construire la chaîne de signature d’une signature d’accès partagé, commencez par construire la chaîne à signer à partir des champs qui composent la demande, encodez la chaîne en UTF-8, puis calculez la signature à l’aide de l’algorithme HMAC-SHA256. Les champs inclus dans la chaîne à signer doivent être décodés par URL.

Version 2020-12-06 et ultérieure

La version 2020-12-06 ajoute la prise en charge du champ d’étendue de chiffrement signé. Pour construire la chaîne à signer pour les ressources de Stockage Blob, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               signedResource + "\n" +
               signedSnapshotTime + "\n" +
               signedEncryptionScope + "\n" +
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +
Version 2018-11-09 et ultérieure

La version 2018-11-09 ajoute la prise en charge de la ressource signée et de l’objet blob signé instantané champs de temps. Ces champs doivent être inclus dans la chaîne à signer. Pour construire la chaîne à signer pour les ressources de Stockage Blob, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               signedResource + "\n"
               signedSnapshotTime + "\n" +
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct
Version 2015-04-05 et ultérieures

La version 2015-04-05 ajoute la prise en charge des champs d’adresse IP signée et de protocole signé. Ces champs doivent être inclus dans la chaîne à signer. Pour construire la chaîne à signer pour les ressources Stockage Blob ou Azure Files, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct

Pour construire la chaîne à signer pour les ressources de stockage Table, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               startingPartitionKey + "\n"  
               startingRowKey + "\n"  
               endingPartitionKey + "\n"  
               endingRowKey

Pour construire la chaîne à signer pour les ressources de stockage file d’attente, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion
Version 2013-08-15 à 2015-02-21

Pour construire la chaîne à signer pour le Stockage Blob ou Azure Files ressources à l’aide de la version 2013-08-15 à 2015-02-21, utilisez le format suivant. Pour Azure Files, LA SAP est prise en charge à partir de la version 2015-02-21.

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion + "\n" +  
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct

Pour construire la chaîne de signature d'une table, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion + "\n" +  
               startPk + "\n" +  
               startRk + "\n" +  
               endPk + "\n" +  
               endRk

Pour construire la chaîne à signer pour une file d’attente, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion
Version 2012-02-12

Pour construire la chaîne à signer pour les ressources de Stockage Blob pour la version 2012-02-12, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion
Versions antérieures à 2012-02-12

Pour construire la chaîne à signer pour les ressources de Stockage Blob pour les versions antérieures à 2012-02-12, utilisez le format suivant :

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier

Lorsque vous construisez la chaîne à signer, gardez à l’esprit les points suivants :

  • Si un champ est facultatif et n'est pas spécifié dans le cadre de la demande, spécifiez une chaîne vide pour ce champ. Veillez à inclure le caractère de nouvelle ligne (\n) après la chaîne vide.

  • La chaîne à signer pour une table doit inclure les paramètres supplémentaires, même s’il s’agit de chaînes vides.

  • La signedpermission partie de la chaîne doit inclure les désignations d’autorisation dans un ordre fixe spécifique à chaque type de ressource. Toute combinaison de ces autorisations est acceptable, mais l'ordre des lettres d'autorisation doit correspondre à l'ordre indiqué dans le tableau suivant.

    Type de ressource Ordre des autorisations
    Blob racwd
    Conteneur racwdl
    File d'attente raup
    Fichier rcwd
    Partager rcwdl
    Table de charge de travail raud

    Par exemple, des exemples de paramètres d’autorisations valides pour un conteneur incluent rw, rd, wdrl, , wlet rl. Exemples de paramètres non valides : wr, dr, lret dw. La spécification d’une désignation d’autorisation plusieurs fois n’est pas autorisée.

  • Fournissez une valeur pour la signedIdentifier partie de la chaîne si vous associez la demande à une stratégie d’accès stockée.

  • Une signature d’accès partagé qui spécifie une version de service de stockage antérieure à 2012-02-12 ne peut partager qu’un objet blob ou un conteneur, et elle doit omettre signedVersion et le caractère de ligne avant.

  • La partie canonicalizedResource de la chaîne est un chemin d'accès canonique à la ressource signée. Il doit inclure le nom du service (Stockage Blob, Stockage Table, Stockage File d’attente ou Azure Files) pour la version 2015-02-21 ou ultérieure, le nom du compte de stockage et le nom de la ressource, et il doit être décodé par URL. Les noms des objets blob doivent inclure le conteneur de l'objet blob. Les noms de table doivent être en minuscules.

La chaîne de ressource canonique pour un conteneur, une file d’attente, une table ou un partage de fichiers doit omettre la barre oblique de fin (/) pour une SAP qui fournit l’accès à cet objet.

Les exemples suivants montrent comment construire la canonicalizedResource partie de la chaîne, en fonction du type de ressource.

Containers

Pour les versions 2015-02-21 et ultérieures :

URL = https://myaccount.blob.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"

Pour les versions antérieures à 2015-02-21 :

URL = https://myaccount.blob.core.windows.net/music
canonicalizedResource = "/myaccount/music"

Objets blob

Pour les versions 2015-02-21 et ultérieures :

URL = https://myaccount.blob.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"

Pour les versions antérieures à 2015-02-21 :

URL = https://myaccount.blob.core.windows.net/music/intro.mp3
canonicalizedResource = "/myaccount/music/intro.mp3"

Partages de fichiers

URL = https://myaccount.file.core.windows.net/music
canonicalizedResource = "/file/myaccount/music"

Fichiers

URL = https://myaccount.file.core.windows.net/music/intro.mp3
canonicalizedResource = "/file/myaccount/music/intro.mp3"

Files d’attente

Pour les versions 2015-02-21 et ultérieures :

URL = https://myaccount.queue.core.windows.net/thumbnails  
canonicalizedResource = "/queue/myaccount/thumbnails"

Pour les versions antérieures à 2015-02-21 :

URL = https://myaccount.queue.core.windows.net/thumbnails  
canonicalizedResource = "/myaccount/thumbnails"

Tables

Si la ressource signée est une table, vérifiez que le nom de la table est en minuscules dans le format canonique.

Pour les versions 2015-02-21 et ultérieures :

URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')  
canonicalizedResource = "/table/myaccount/employees"

Pour les versions antérieures à 2015-02-21 :

URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')  
canonicalizedResource = "/myaccount/employees"

Durée de vie et révocation d’une signature d’accès partagé

Les signatures d'accès partagé accordent aux utilisateurs des droits d'accès aux ressources de compte de stockage. Lorsque vous envisagez d’utiliser une signature d’accès partagé, réfléchissez à la durée de vie de la SAP et à la nécessité pour votre application de révoquer les droits d’accès dans certaines circonstances.

Sap ad hoc et stratégie d’accès stockée

Une SAP de service peut prendre l’une des deux formes suivantes :

  • Sap ad hoc : lorsque vous créez une SAP ad hoc, l’heure de début, l’heure d’expiration et les autorisations pour la SAP sont tous spécifiés dans l’URI SAS (ou implicite, si l’heure de début est omise). Tout type de SAP peut être une SAP ad hoc.

    Vous pouvez gérer la durée de vie d’une SAP ad hoc à l’aide du signedExpiry champ . Si vous souhaitez continuer à accorder à un client l’accès à la ressource après le délai d’expiration, vous devez émettre une nouvelle signature. Nous vous recommandons de limiter la durée de vie d’une signature d’accès partagé. Avant la version 2012-02-12, une signature d’accès partagé non associée à une stratégie d’accès stockée ne pouvait pas avoir une période active qui dépassait une heure.

  • SAP avec stratégie d’accès stockée : une stratégie d’accès stockée est définie sur un conteneur de ressources, qui peut être un conteneur d’objets blob, une table, une file d’attente ou un partage de fichiers. Vous pouvez utiliser la stratégie d’accès stockée pour gérer les contraintes d’une ou plusieurs signatures d’accès partagé. Lorsque vous associez une SAP à une stratégie d’accès stockée, celle-ci hérite des contraintes (c’est-à-dire, l’heure de début, l’heure d’expiration et les autorisations) définies pour la stratégie d’accès stockée.

    La stratégie d'accès stockée est représentée par le champ signedIdentifier sur l'URI. Une stratégie d'accès stockée donne un contrôle supplémentaire sur une ou plusieurs signatures d'accès partagé et permet notamment de les révoquer le cas échéant.

Révoquer une signature d’accès partagé

Étant donné qu’un URI SAS est une URL, toute personne qui obtient la signature d’accès partagé peut l’utiliser, quelle que soit la personne qui l’a créée à l’origine. Si une SAP est publiée publiquement, elle peut être utilisée par n’importe qui. Une signature d’accès partagé accorde l’accès aux ressources à toute personne qui en possède jusqu’à ce que l’une des quatre choses se produisent :

  • Le délai d’expiration spécifié sur une signature d’accès partagé ad hoc est atteint.

  • Le délai d’expiration spécifié sur la stratégie d’accès stockée référencée par la signature d’accès partagé est atteint si une stratégie d’accès stockée est référencée et si la stratégie d’accès spécifie un délai d’expiration.

    Le délai d’expiration peut être atteint soit parce que l’intervalle s’écoule, soit parce que vous avez modifié la stratégie d’accès stockée pour avoir un délai d’expiration dans le passé, ce qui est une façon de révoquer la signature d’accès partagé.

  • La stratégie d’accès stockée référencée par la signature d’accès partagé est supprimée, ce qui révoque la signature d’accès partagé. Si stockage Azure ne peut pas localiser la stratégie d’accès stockée spécifiée dans la signature d’accès partagé, le client ne peut pas accéder à la ressource indiquée par l’URI.

    Si vous recréez la stratégie d’accès stockée avec exactement le même nom que la stratégie supprimée, tous les jetons SAS existants seront à nouveau valides, en fonction des autorisations associées à cette stratégie d’accès stockée. Cela suppose que le délai d’expiration sur la signature d’accès partagé n’est pas passé. Si vous envisagez de révoquer la signature d’accès partagé, veillez à utiliser un nom différent lorsque vous recréez la stratégie d’accès avec une date d’expiration ultérieure.

  • La clé de compte qui a été utilisée pour créer la signature d'accès partagé est régénérée. La régénération d’une clé de compte entraîne l’échec de l’autorisation de tous les composants d’application qui utilisent cette clé jusqu’à ce qu’ils soient mis à jour pour utiliser l’autre clé de compte valide ou la clé de compte nouvellement régénérée. La régénération de la clé de compte est le seul moyen de révoquer immédiatement une signature d’accès partagé ad hoc.

Important

Un URI de signature d’accès partagé est associé à la clé de compte utilisée pour créer la signature et à la stratégie d’accès stockée associée, le cas échéant. Si aucune stratégie d’accès stockée n’est spécifiée, la seule façon de révoquer une signature d’accès partagé consiste à modifier la clé du compte.

À titre de bonne pratique, nous vous recommandons d’utiliser une stratégie d’accès stockée avec une SAP de service. Si vous choisissez de ne pas utiliser une stratégie d’accès stockée, veillez à conserver la période de validité de la sape ad hoc courte. Pour plus d’informations sur l’association d’une SAP de service à une stratégie d’accès stockée, consultez Définir une stratégie d’accès stockée.

Exemple de SAP de service

L’exemple suivant montre un URI d’objet blob avec un jeton SAP de service ajouté à celui-ci. Le jeton SAP de service fournit des autorisations de lecture et d’écriture sur l’objet blob.

https://myaccount.blob.core.windows.net/sascontainer/blob1.txt?sp=rw&st=2023-05-24T01:13:55Z&se=2023-05-24T09:13:55Z&sip=168.1.5.60-168.1.5.70&spr=https&sv=2022-11-02&sr=b&sig=<signature>

Chaque partie de l’URI est décrite dans le tableau suivant :

Nom Partie de la SAP Description
URI de ressource https://myaccount.blob.core.windows.net/sascontainer/blob1.txt Adresse de l'objet blob. Nous vous recommandons vivement d’utiliser HTTPS.
Délimiteur ? Délimiteur qui précède la chaîne de requête. Le délimiteur ne fait pas partie du jeton SAS.
Autorisations sp=rw Les autorisations octroyées par la signature d'accès partagé incluent les opérations de lecture (r) et d'écriture (w).
Heure de début st=2023-05-24T01:13:55Z Spécifiée en heure UTC. Si vous voulez que la signature d'accès partagé soit valide immédiatement, omettez l'heure de début.
Heure d’expiration se=2023-05-24T09:13:55Z Spécifiée en heure UTC.
Plage d’adresses IP sip=168.1.5.60-168.1.5.70 Plage d’adresses IP dont les demandes seront acceptées.
Protocol spr=https Seules les demandes qui utilisent HTTPS sont autorisées.
Version de Stockage Azure sv=2023-05-24 Pour la version du Stockage Azure 2012-02-12 et les versions ultérieures, ce paramètre indique la version à utiliser.
Ressource sr=b La ressource est un objet blob.
Signature sig=<signature> Utilisée pour autoriser l’accès à l’objet blob. La signature est un HMAC calculé sur une chaîne à signer et une clé à l’aide de l’algorithme SHA256, puis encodé à l’aide de l’encodage Base64.

Voir aussi