Créer une SAP de délégation d’utilisateur

Important

Pour une sécurité optimale, Microsoft recommande d’utiliser l’ID Microsoft Entra avec des identités managées pour autoriser les demandes sur les données d’objet blob, de file d’attente et de table, dans la mesure du possible. L’autorisation avec l’ID Microsoft Entra et les identités managées offre une sécurité et une facilité d’utilisation supérieures sur 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 Qu’est-ce que 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 sur des ressources Azure avec des serveurs avec Azure Arc.

Vous pouvez sécuriser un jeton de signature d’accès partagé (SAP) pour l’accès à un conteneur, un répertoire ou un objet blob à l’aide d’informations d’identification Microsoft Entra ou d’une clé de compte. Une SAP sécurisée avec les informations d’identification Microsoft Entra est appelée délégation d’utilisateur SAP. En guise de meilleure pratique de sécurité, nous vous recommandons d’utiliser les informations d’identification Microsoft Entra lorsque cela est possible, plutôt que la clé de compte, qui peut être plus facilement compromise. Lorsque la conception de votre application nécessite des signatures d’accès partagé, utilisez les informations d’identification Microsoft Entra pour créer une SAP de délégation d’utilisateur pour garantir une meilleure sécurité.

Chaque SAP est signée avec une clé. Pour créer une SAP de délégation d’utilisateur, vous devez d’abord demander une clé de délégation d’utilisateur , que vous utilisez ensuite pour signer la SAP. La clé de délégation d’utilisateur est analogue à la clé de compte utilisée pour signer une SAP de service ou une SAP de compte, sauf qu’elle s’appuie sur vos informations d’identification Microsoft Entra. Pour demander la clé de délégation d’utilisateur, appelez l’opération Obtenir la clé de délégation d’utilisateur. Vous pouvez ensuite utiliser la clé de délégation d’utilisateur pour créer la SAP.

Une SAS de délégation utilisateur est prise en charge pour le stockage de blobs, le stockage de lacs de données, le stockage en file d’attente, le stockage de tables ou les fichiers Azure. Les stratégies d’accès stockées ne sont pas prises en charge pour une SAP de délégation d’utilisateur.

Prudence

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 protéger une clé de compte. Il est important de protéger une SAP contre une utilisation malveillante ou involontaire. Utilisez la discrétion pour distribuer une SAP et disposer d’un plan en place pour révoquer une SAP compromise. Les opérations qui utilisent des signatures d’accès partagé doivent être effectuées uniquement sur une connexion HTTPS, et les URI de signature d’accès partagé doivent uniquement être distribués sur une connexion sécurisée telle que HTTPS.

Pour plus d’informations sur l’utilisation de votre clé de compte pour sécuriser une SAP, consultez Créer un SAP de service et Créer une SAP de compte.

Prise en charge SAS de la délégation utilisateur pour l’accès à cahier des répertoires (stockage Blob et stockage sur lac de données uniquement)

Une SAP de délégation d’utilisateur prend en charge l’étendue d’annuaire (sr=d) lorsque la version d’autorisation (sv) est 2020-02-10 ou version ultérieure et qu’un espace de noms hiérarchique (HNS) est activé. La sémantique de l’étendue du répertoire (sr=d) est similaire à 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 requête sdd est également requis.

Le format de chaîne à signer pour l’autorisation version 2020-02-10 n’est pas modifié.

Prise en charge SAS de la délégation utilisateur pour un OID utilisateur (stockage en blob et stockage sur le lac de données uniquement)

La SAP de délégation d’utilisateur prend en charge un identificateur d’objet utilisateur facultatif (OID) qui est transporté dans le paramètre saoid ou suoid lorsque la version d’autorisation (sv) est 2020-02-10 ou version ultérieure. Les paramètres saoid et suoid correspondent au principal de sécurité de l’utilisateur final qui utilise la SAP et fournissent un modèle d’autorisation amélioré pour les charges de travail de cluster multi-utilisateurs telles que Hadoop et Spark.

Les jetons SAP peuvent être limités à une opération de système de fichiers spécifique et à un utilisateur, ce qui fournit un jeton d’accès moins vulnérable qui est plus sûr à distribuer sur un cluster multi-utilisateur. L’un des cas d’usage de ces fonctionnalités est l’intégration du pilote ABFS Hadoop à Apache Ranger.

Pour en savoir plus sur les paramètres facultatifs saoid et suoid, consultez Spécifier un ID d’objet utilisateur signé.

Autoriser une SAP de délégation d’utilisateur

Lorsqu’un client accède à une ressource de stockage Blob avec une SAP de délégation d’utilisateur, la demande adressée au stockage Azure est autorisée avec les informations d’identification Microsoft Entra utilisées pour créer la SAP. L’accès du client à la ressource est déterminé par les autorisations suivantes :

Autorisations de contrôle d’accès en fonction du rôle (RBAC) accordées au principal de sécurité Microsoft Entra qui a demandé la clé de délégation d’utilisateur.
Autorisations de liste de contrôle d’accès POSIX qui sont accordées au principal de sécurité qui a demandé la clé de délégation d’utilisateur. Cette vérification supplémentaire se produit uniquement lorsque les autorisations RBAC ne peuvent pas accorder l’accès, et uniquement lorsque l’espace de noms hiérarchique est activé sur le compte de stockage.
Autorisations explicitement accordées sur le jeton SAP.

Cette approche fournit un niveau de sécurité supplémentaire et vous permet d’éviter d’avoir à stocker votre clé d’accès de compte avec votre code d’application. Pour ces raisons, la création d’une SAP à l’aide des informations d’identification Microsoft Entra est une bonne pratique de sécurité.

Les autorisations accordées à un client qui possède la SAP sont l’intersection des autorisations accordées au principal de sécurité qui a demandé la clé de délégation d’utilisateur et les autorisations qui ont été accordées à la ressource sur le jeton SAP à l’aide du champ signedPermissions (sp). Si une autorisation accordée au principal de sécurité via les ACL RBAC ou POSIX n’est pas également accordée sur le jeton SAP, cette autorisation n’est pas accordée au client qui tente d’utiliser la SAP pour accéder à la ressource. Lorsque vous créez une SAP de délégation d’utilisateur, assurez-vous que les autorisations accordées via les ACL RBAC et POSIX et les autorisations accordées via le jeton SAP s’alignent tous deux sur le niveau d’accès requis par le client.

Pour créer une SAP de délégation d’utilisateur, procédez comme suit :

Utilisez les ACL RBAC ou POSIX pour accorder les autorisations souhaitées au principal de sécurité qui demande la clé de délégation utilisateur.
Acquérir un jeton OAuth 2.0 à partir de l’ID Microsoft Entra.
Utilisez le jeton pour demander la clé de délégation utilisateur en appelant l’opération Obtenir la clé de délégation d’utilisateur.
Utilisez la clé de délégation utilisateur pour construire le jeton SAP avec les champs appropriés.

Attribuer des autorisations avec RBAC

Le principal de sécurité qui demande la clé de délégation d’utilisateur doit disposer des autorisations appropriées pour ce faire. Un principal de sécurité Microsoft Entra ID peut être un utilisateur, un groupe, un principal de service ou une identité managée.

Pour demander la clé de délégation utilisateur, vous devez attribuer à un principal de sécurité l’action Microsoft.Storage/storageAccounts/{serviceType}/generateUserDelegationKey . Les rôles RBAC intégrés suivants incluent l’action Microsoft.Storage/storageAccounts/{serviceType}/generateUserDelegationKey , soit explicitement, soit dans une définition de wildcard :

contributeur
contributeur de compte de stockage
Contributeur aux données Blob de stockage
propriétaire des données blob du stockage
Lecteur de données blob de stockage
Stockage Blob Delegator
Délégué de file d’attente de stockage
Délégué de table de stockage
Délégateur de fichiers de stockage

Étant donné que l’opération Obtenir la clé de délégation d’utilisateur agit au niveau du compte de stockage, l’action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey doit être étendue au niveau du compte de stockage, du groupe de ressources ou de l’abonnement. Si le principal de sécurité est affecté à l’un des rôles prédéfinis, intégrés ou à un rôle personnalisé qui inclut l'Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action, au niveau du compte de stockage, du groupe de ressources ou de l’abonnement, le principal de sécurité peut ensuite demander la clé de délégation utilisateur.

Si le responsable de sécurité se voit attribuer un rôle permettant l’accès aux données mais qui est limité au niveau d’un conteneur, vous pouvez en outre attribuer le rôle de Délégateur de stockage (comme Délégateur de Blob de Stockage) au principal de sécurité au niveau du compte de stockage, du groupe de ressources ou de l’abonnement. Le rôle de Déléguateur de stockage accorde au principal de sécurité les autorisations de demander la clé de délégation utilisateur.

Pour plus d’informations sur les rôles RBAC pour stockage Azure, consultez Autoriser avec Microsoft Entra.

Acquérir un jeton OAuth 2.0

Pour obtenir la clé de délégation d’utilisateur, commencez par demander un jeton OAuth 2.0 à partir de l’ID Microsoft Entra. Fournissez le jeton au schéma du porteur pour autoriser l’appel à l’opération Obtenir la clé de délégation d’utilisateur. Pour plus d’informations sur la demande d’un jeton OAuth à partir de l’ID Microsoft Entra, consultez flux d’authentification et les scénarios d’application.

Demander la clé de délégation d’utilisateur

Un appel à l’opération Obtenir la clé de délégation d’utilisateur retourne la clé sous la forme d’un ensemble de valeurs utilisées comme paramètres sur le jeton SAP de délégation d’utilisateur. Ces paramètres sont décrits dans la référence Get User Delegation Key et dans la section suivante, Construire un SAS de délégation utilisateur.

Lorsqu’un client demande une clé de délégation d’utilisateur à l’aide d’un jeton OAuth 2.0, le stockage Azure retourne la clé de délégation d’utilisateur pour le compte du principal de sécurité. La sape créée avec la clé de délégation d’utilisateur reçoit les autorisations accordées au principal de sécurité.

Une fois que vous avez la clé de délégation d’utilisateur, vous pouvez l’utiliser pour créer un nombre quelconque de signatures d’accès partagé de délégation d’utilisateur au cours de la durée de vie de la clé. La clé de délégation d’utilisateur est indépendante du jeton OAuth 2.0 que vous utilisez pour l’acquérir. Le jeton n’a donc pas besoin d’être renouvelé tant que la clé est toujours valide. Vous pouvez spécifier que la clé est valide pendant une période allant jusqu’à sept jours.

Construire une SAP de délégation d’utilisateur

Le tableau suivant récapitule les champs pris en charge pour un jeton SAP de délégation d’utilisateur. Les sections suivantes fournissent des détails supplémentaires sur la façon de spécifier ces paramètres.

Nom du champ SAP	Paramètre de jeton SAS	Obligatoire ou facultatif	Prise en charge des versions	Descriptif
`signedVersion`	`sv`	Obligatoire	2018-11-09 et versions ultérieures	Indique la version du service utilisé pour construire le champ de signature. Il spécifie également la version du service qui gère les requêtes effectuées avec cette SAP.
`signedResource`	`sr`	Obligatoire	Tout	Stockage blob ou fichiers Azure uniquement. Précise quelles ressources sont accessibles via la signature d’accès partagé.
`signedStart`	`st`	Optionnel	Tout	Optionnel. Heure à laquelle la signature d’accès partagé devient valide, exprimée dans l’un des formats UTC ISO 8601 acceptés. Si cette valeur est omise, l’heure UTC actuelle est utilisée comme heure de début. Pour plus d’informations sur les formats UTC acceptés, consultez Format des valeurs DateTime.
`signedExpiry`	`se`	Obligatoire	Tout	Heure à laquelle la signature d’accès partagé devient non valide, exprimée dans l’un des formats UTC ISO 8601 acceptés. Pour plus d’informations sur les formats UTC acceptés, consultez Format des valeurs DateTime.
`signedPermissions`	`sp`	Obligatoire	Tout	Indique les opérations qu’un client possédant la SAP peut effectuer sur la ressource. Les autorisations peuvent être combinées.
`signedIp`	`sip`	Optionnel	2015-04-05 et versions ultérieures	Spécifie une adresse IP ou une plage inclusive d’adresses IP à partir de laquelle accepter les demandes. Lorsque vous spécifiez une plage, gardez à l’esprit que la plage est inclusive. Seules les adresses IPv4 sont prises en charge. Par exemple, `sip=198.51.100.0` ou `sip=198.51.100.10-198.51.100.20`.
`signedProtocol`	`spr`	Optionnel	2015-04-05 et versions ultérieures	Spécifie le protocole autorisé pour une requête effectuée avec la SAP. Incluez ce champ pour exiger que les demandes effectuées avec le jeton SAP utilisent HTTPS.
`signedObjectId`	`skoid`	Obligatoire	2018-11-09 et versions ultérieures	Spécifie l’ID d’objet d’un principal de sécurité Microsoft Entra. Cet ID d’objet correspond au principal de sécurité qui a demandé la clé de délégation d’utilisateur. Avant d’autoriser l’opération, Stockage Azure vérifie les autorisations RBAC sur l’ID d’objet. Si les autorisations RBAC ne peuvent pas accorder l’accès, Le Stockage Azure vérifie les autorisations ACL POSIX par rapport à l’ID d’objet.
`signedTenantId`	`sktid`	Obligatoire	2018-11-09 et versions ultérieures	Spécifie le locataire Microsoft Entra dans lequel un principal de sécurité est défini.
`signedKeyStartTime`	`skt`	Obligatoire.	2018-11-09 et versions ultérieures	La valeur est retournée par l’opération Obtenir la clé de délégation d’utilisateur. Indique le début de la durée de vie de la clé de délégation utilisateur, exprimée dans l’un des formats UTC ISO 8601 acceptés. Pour plus d’informations sur les formats UTC acceptés, consultez Format des valeurs DateTime.
`signedKeyExpiryTime`	`ske`	Obligatoire	2018-11-09 et versions ultérieures	La valeur est retournée par l’opération Obtenir la clé de délégation d’utilisateur. Indique la fin de la durée de vie de la clé de délégation utilisateur, exprimée dans l’un des formats UTC ISO 8601 acceptés. Pour plus d’informations sur les formats UTC acceptés, consultez Format des valeurs DateTime.
`signedKeyVersion`	`skv`	Obligatoire	2018-11-09 et versions ultérieures	La valeur est retournée par l’opération Obtenir la clé de délégation d’utilisateur. Spécifie la version du service de stockage utilisée pour obtenir la clé de délégation utilisateur. Ce champ doit spécifier la version 2018-11-09 ou ultérieure.
`signedKeyService`	`sks`	Obligatoire	2018-11-09 et versions ultérieures	Indique le service pour lequel la clé de délégation utilisateur est valide. Actuellement, seul le stockage Blob est pris en charge.
`signedAuthorizedObjectId`	`saoid`	Optionnel	2020-02-10 et versions ultérieures	Stockage en blob uniquement. Spécifie l’ID d’objet d’un principal de sécurité Microsoft Entra autorisé par le propriétaire de la clé de délégation utilisateur pour effectuer l’action accordée par le jeton SAP. Cet ID d’objet correspond au principal de sécurité de l’utilisateur final de la SAP. Aucune vérification supplémentaire des autorisations sur les listes de contrôle d’accès POSIX (ACL) n’est effectuée.
`signedUnauthorizedObjectId`	`suoid`	Optionnel	2020-02-10 et versions ultérieures	Stockage en blob uniquement. Spécifie l’ID d’objet d’un principal de sécurité Microsoft Entra lorsqu’un espace de noms hiérarchique est activé. Cet ID d’objet correspond au principal de sécurité de l’utilisateur final de la SAP. Stockage Azure effectue une vérification ACL POSIX par rapport à l’ID d’objet avant d’autoriser l’opération.
`signedCorrelationId`	`scid`	Optionnel	2020-02-10 et versions ultérieures	Stockage en blob uniquement. Mettre en corrélation les journaux d’audit de stockage avec les journaux d’audit utilisés par le principal qui génère et distribue la SAP.
`signedDirectoryDepth`	`sdd`	Obligatoire lorsque `sr=d`	2020-02-10 et versions ultérieures	Stockage en blob uniquement. Indique le nombre de répertoires dans le dossier racine du répertoire spécifié dans le champ `canonicalizedResource` de la chaîne à signer.
`signedEncryptionScope`	`ses`	Optionnel	2020-12-06 et versions ultérieures	Stockage en blob uniquement. Indique l’étendue de chiffrement à utiliser pour chiffrer le contenu de la requête.
`tableName`	`tn`	Obligatoire	2025-07-05 et au-delà	Seule la table. Le nom de la table à partager.
`startPk` ² `startRk` ²	`spk` `srk`	Optionnel	2025-07-05 et au-delà	Stockage de table uniquement. Optionnel, mais `startPk` doit accompagner `startRk`. Les partitions minimales et les clés de ligne accessibles avec cette signature d’accès partagée. Les valeurs clés sont inclusives. S’ils sont omis, il n’y a pas de borne inférieure sur les entités de table accessibles.
`endPk` ² `endRk` ²	`epk` `erk`	Optionnel	2025-07-05 et au-delà	Stockage de table uniquement. Optionnel, mais `endPk` doit accompagner `endRk`. Le nombre maximal de partitions et de lignes de clés accessibles avec cette signature d’accès partagée. Les valeurs clés sont inclusives. S’ils sont omis, il n’y a pas de limite supérieure sur les entités de la table accessibles.
`signature`	`sig`	Obligatoire	Tout	La signature est un code d’authentification de message basé sur le hachage (HMAC) calculé sur la chaîne à signer et la clé à l’aide de l’algorithme SHA256, puis encodé à l’aide de l’encodage Base64.
en-tête de réponse `Cache-Control`	`rscc`	Optionnel	2013-08-15 et versions ultérieures	Stockage blob ou fichiers Azure uniquement. Stockage Azure définit l’en-tête de réponse `Cache-Control` sur la valeur spécifiée sur le jeton SAP.
en-tête de réponse `Content-Disposition`	`rscd`	Optionnel	2013-08-15 et versions ultérieures	Stockage blob ou fichiers Azure uniquement. Stockage Azure définit l’en-tête de réponse `Content-Disposition` sur la valeur spécifiée sur le jeton SAP.
en-tête de réponse `Content-Encoding`	`rsce`	Optionnel	2013-08-15 et versions ultérieures	Stockage blob ou fichiers Azure uniquement. Stockage Azure définit l’en-tête de réponse `Content-Encoding` sur la valeur spécifiée sur le jeton SAP.
en-tête de réponse `Content-Language`	`rscl`	Optionnel	2013-08-15 et versions ultérieures	Stockage blob ou fichiers Azure uniquement. Stockage Azure définit l’en-tête de réponse `Content-Language` sur la valeur spécifiée sur le jeton SAP.
en-tête de réponse `Content-Type`	`rsct`	Optionnel	2013-08-15 et versions ultérieures	Stockage blob ou fichiers Azure uniquement. Stockage Azure définit l’en-tête de réponse `Content-Type` sur la valeur spécifiée sur le jeton SAP.

Spécifier le champ de version signée

Le champ signedVersion requis (sv) spécifie la version du service pour la signature d’accès partagé. Cette valeur indique la version du service utilisé pour construire le champ signature et spécifie la version du service qui gère une demande effectuée avec cette signature d’accès partagé. La valeur du champ sv doit être la version 2018-11-09 ou ultérieure.

Spécifier le champ de ressource signée (stockage de blobs uniquement)

Le champ signedResource requis (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, de conteneur ou de répertoire dans le jeton SAP :

Ressource	Valeur du paramètre	Versions prises en charge	Descriptif
BLOB	b	Tout	Accorde l’accès au contenu et aux métadonnées de l’objet blob.
Version de l’objet blob	Bv	2018-11-09 et versions ultérieures	Accorde 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	Accorde l’accès au contenu et aux métadonnées de l’instantané d’objet blob, mais pas à l’objet blob de base.
Conteneur	c	Tout	Accorde l’accès au contenu et aux métadonnées d’un objet blob dans le conteneur et à la liste des objets blob dans le conteneur.
Répertoire	d	2020-02-10 et versions ultérieures	Accorde l’accès au contenu et aux métadonnées d’un 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 champ `signedResource`, le paramètre `signedDirectoryDepth` (`sdd`) est également requis. Un répertoire se trouve toujours dans un conteneur.

Spécifier le champ de ressource signé (uniquement Azure Files)

Le champ signedResource requis (sr) spécifie les ressources accessibles via la signature d’accès partagé. Le tableau suivant décrit comment se référer à un fichier ou à une ressource de partage sur l’URI.

Nom du champ	Paramètre de requête.	Descriptif
`signedResource`	`sr`	Obligatoire. Précisez `f` si la ressource partagée est un fichier. Cela donne accès au contenu et aux métadonnées du fichier. Précisez `s` si la ressource partagée est un partage. Cela donne accès au contenu et aux métadonnées de tout fichier du partage, ainsi qu’à la liste des répertoires et fichiers du partage.

Spécifier les paramètres de requête pour écraser les en-têtes de réponse (stockage Blob et fichiers Azure uniquement)

Pour définir des valeurs pour certains en-têtes de réponse à renvoyer lorsque la signature d’accès partagé est utilisée dans une requête, vous pouvez spécifier des en-têtes de réponse dans les paramètres de requête. Cette fonctionnalité est prise en charge depuis la version 2013-08-15 pour le stockage Blob et 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 comme 2013-08-15 ou ultérieur pour Blob Storage, ou vers 2015-02-21 ou ultérieur pour Azure Files.

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

Nom de l’en-tête de réponse	Paramètre de requête SAP 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 à binary. Cette valeur supprime la valeur d’en-tête Content-Type stockée pour le blob pour une requête qui utilise uniquement cette signature d’accès partagée.

Si vous créez une signature d’accès partagé qui spécifie les en-têtes de réponse comme paramètres de requête, vous devez les inclure dans la chaîne de signes utilisée pour construire la chaîne de signature. Pour plus d’informations, consultez la section Spécifier la signature plus loin dans cet article. Pour d’autres exemples, voir les exemples de Service SAS.

Spécifier la durée de validité de la signature

Les champs signedStart (st) et signedExpiry (se) indiquent les heures de début et d’expiration de la SAP. Le champ signedExpiry est requis. Le champ signedStart est facultatif. S’il est omis, l’heure UTC actuelle est utilisée comme heure de début.

Pour une SAP de délégation d’utilisateur, les heures de début et d’expiration de la SAP doivent être comprises dans l’intervalle défini pour la clé de délégation d’utilisateur. Si un client tente d’utiliser une SAP après l’expiration de la clé de délégation d’utilisateur, la SAP échoue avec une erreur d’autorisation, que la SAP elle-même soit toujours valide.

Pour plus d’informations sur les formats UTC acceptés, consultez Format des valeurs DateTime.

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

Le tableName champ précise le nom de la table à partager.

Nom du champ	Paramètre de requête.	Descriptif
`tableName`	`tn`	Obligatoire. Le nom de la table à partager.

Spécifier des autorisations

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

Les autorisations peuvent être combinées pour permettre à un client d’effectuer plusieurs opérations avec la même SAP. Lorsque vous construisez la SAP, vous devez inclure des autorisations dans l’ordre suivant :

racwdxltmeop

Des exemples de paramètres d’autorisations valides pour un conteneur incluent rw, rd, rl, wd, wlet rl. Voici quelques 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.

Une SAP de délégation d’utilisateur ne peut pas accorder l’accès à certaines opérations :

Les conteneurs, files d’attente et tables ne peuvent pas être créés, supprimés ou listé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 sape de compte.

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 des versions	Opérations autorisées
Lire	r	Conteneur Répertoire BLOB	Tout	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	un	Conteneur Répertoire BLOB	Tout	Ajoutez un bloc à un objet blob d’ajout.
Créer	c	Conteneur Répertoire BLOB	Tout	Écrivez un nouvel objet blob, capturez un objet blob ou copiez un objet blob dans un nouvel objet blob.
Écrire	w	Conteneur Répertoire BLOB	Tout	Créez ou écrivez du contenu, des propriétés, des métadonnées ou une liste de blocs. Instantané ou bail de l’objet blob. Redimensionnez l’objet blob (objet blob de pages uniquement). Utilisez l’objet blob comme destination d’une opération de copie.
Supprimer	d	Conteneur Répertoire BLOB	Tout	Supprimez un objet blob. Pour la version 2017-07-29 et ultérieure, l’autorisation Delete permet également de rompre un bail sur un objet blob. Pour plus d’informations, consultez l’opération baux d’objet blob.
Supprimer la version	x	Conteneur 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.
Liste	l	Conteneur Répertoire	Tout	Répertorier les objets blob de manière non récursive.
Étiquettes	t	BLOB	2019-12-12 et versions ultérieures	Lisez ou écrivez les balises sur un objet blob.
Bouger	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 paramètre `saoid` est inclus sur le jeton SAP et que le bit sticky est défini sur le répertoire parent.
Exécuter	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 l’ACL 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 accorde la possibilité de définir le groupe propriétaire, les autorisations POSIX et l’ACL POSIX de l’objet blob. Il n’autorise pas l’appelant à 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 lorsque l’appelant renomme ou supprime un répertoire ou un objet blob au sein d’un répertoire dont le bit sticky 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 ACL POSIX sur les répertoires et les objets blob.
Définir une stratégie d’immuabilité	Je	Conteneur 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, les métadonnées. Utilisez le fichier comme source d’une opération de copiage.
Écrire	w	Créez un nouveau fichier ou copiez un fichier dans un nouveau fichier. Créer ou écrire du contenu, des propriétés, des métadonnées. Redimensionnez le fichier. Utilisez le fichier comme destination d’une opération de copie.
Supprimer	d	Supprimez le fichier.

Autorisation	Symbole d’URI	Opérations autorisées
Lire	r	Lisez le contenu, les propriétés ou les métadonnées de n’importe quel fichier du partage. Utilisez n’importe quel fichier du partage comme source d’une opération de copiage.
Écrire	w	Créez un nouveau fichier dans le partage, ou copiez un fichier dans un nouveau fichier du partage. Pour tout fichier du 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. Note : Vous ne pouvez pas accorder d’autorisations pour lire ou écrire des propriétés de partage ou des métadonnées en utilisant un SAS de service. Utilisez plutôt un compte SAS.
Supprimer	d	Supprime tout fichier dans le partage. Remarque : Vous ne pouvez pas accorder d’autorisations pour supprimer un partage en utilisant un service SAS. Utilisez plutôt un compte SAS.
Liste	l	Listez les fichiers et annuaires dans le partage.

Autorisations pour une file d’attente

Autorisation	Symbole d’URI	Opérations autorisées
Lire	r	Métadonnées et propriétés de lecture, y compris le nombre de messages. Jetez un œil aux messages.
Ajouter	un	Ajoutez des messages à la file d’attente.
Update	u	Mettez à jour les messages dans la file d’attente. Note : Utilisez la permission de Traiter avec Mise à jour afin de recevoir d’abord le message que vous souhaitez mettre à jour.
Processus	p	Obtenir et supprimer les messages de la file d’attente.

Autorisations pour une table

Autorisation	Symbole d’URI	Opérations autorisées
Query	r	Obtenez des entités et interrogez les entités.
Ajouter	un	Ajoutez des entités. Note : Les permissions d’ajouter et de mettre à jour sont nécessaires pour les opérations upsert.
Update	u	Mettez à jour les entités. Note : Les permissions d’ajouter et de mettre à jour sont nécessaires pour les opérations upsert.
Supprimer	d	Supprimer les entités.

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

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 requête 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, la plage est inclusive. Par exemple, la spécification de sip=198.51.100.0 ou de sip=198.51.100.10-198.51.100.20 sur la SAP limite la requête à ces adresses IP.

Le tableau suivant décrit s’il faut inclure le champ signedIp sur un jeton SAP pour un scénario donné, 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 SAP fournie au client dans ce scénario ne doit pas inclure d’adresse IP sortante pour le champ `signedIp`. Les demandes que vous effectuez à partir de la même région à l’aide d’une SAP 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 des pare-feu de stockage Azure et des réseaux virtuels.
Client s’exécutant dans Azure	Dans une autre région du client	Une SAP fournie au client dans ce scénario peut inclure une adresse IP publique ou une plage d’adresses pour le champ `signedIp`. Les demandes que vous effectuez avec la SAP doivent provenir de l’adresse IP ou de la plage d’adresses spécifiées.
Client s’exécutant localement ou dans un autre environnement cloud	Dans n’importe quelle région Azure	Une SAP fournie au client dans ce scénario peut inclure une adresse IP publique ou une plage d’adresses pour le champ `signedIp`. Les demandes que vous effectuez avec la SAP doivent provenir de l’adresse IP ou de la plage d’adresses spécifiées. Si la requête passe par un proxy ou une passerelle, fournissez l’adresse IP sortante publique de ce proxy ou passerelle pour le champ `signedIp`.

Spécifier le protocole HTTP

Le champ facultatif signedProtocol (spr) spécifie le protocole autorisé pour les demandes effectuées avec la SAP. Les valeurs possibles sont à la fois HTTPS et HTTP (https,http) ou HTTPS uniquement (https). La valeur par défaut est https,http.

Remarque

Il n’est pas possible de spécifier HTTP pour le champ spr.

Spécifier les plages d’accès à la table

Les champs startPk, startRk, endPk, et endRk définissent une gamme d’entités de table associées à une signature d’accès partagée. Les requêtes de table ne retournent que les résultats qui se trouvent dans cette plage, et les tentatives d’utilisation de la signature d’accès partagée pour ajouter, mettre à jour ou supprimer des entités hors de cette plage échoueront.

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

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

Pour comprendre comment ces champs restreignent l’accès aux entités dans un tableau, référez-vous au tableau suivant :

Champs actuels	Portée de la contrainte
`startPk`	PartitionKey >= `startPk`
`endPk`	PartitionKey <= `endPk`
`startPk`, `startRk`	(Clé >`startPk`de partition) \|\| (partitionKey == `startPk` & & rowKey >= `startRk`)
`endPk`, `endRk`	(Clé <`endPk`de partition) \|\| (partitionKey == `endPk` & & rowKey <= `endRk`)

Spécifier l’ID d’objet signé

Le champ signedObjectId (skoid) est requis pour une SAP de délégation d’utilisateur. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse. L’ID d’objet signé est une valeur GUID qui sert l’identificateur immuable d’un principal de sécurité dans la plateforme d’identités Microsoft.

Spécifier l’ID de locataire signé

Le champ signedTenantId (sktid) est requis pour une SAP de délégation d’utilisateur. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse. L’ID de locataire signé est une valeur GUID qui représente le locataire Microsoft Entra dans lequel un principal de sécurité est défini.

Spécifier l’heure de début de la clé signée

Le champ signedKeyStartTime requis (skt) indique le début de la durée de vie de la clé de délégation utilisateur au format ISO Date. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse.

Spécifier l’heure d’expiration de la clé signée

Le champ signedKeyExpiryTime (ske) est requis pour une SAP de délégation d’utilisateur au format de date ISO. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse. Le délai d’expiration de la clé signée indique la fin de la durée de vie de la clé de délégation d’utilisateur. La valeur de l’heure d’expiration peut être un maximum de sept jours à partir de l’heure de début de la SAP.

Spécifier le service de clé signée

Le champ signedKeyService (sks) est requis pour une SAP de délégation d’utilisateur. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse. Le champ de service de clé signée indique le service pour lequel la clé de délégation d’utilisateur est valide. La valeur du champ de service de clé signée pour le stockage Blob est b.

Spécifier la version de la clé signée

Le champ signedkeyversion (skv) est requis pour une SAP de délégation d’utilisateur. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse. Le champ signedkeyversion spécifie la version du service de stockage utilisée pour obtenir la clé de délégation utilisateur. Ce champ doit spécifier la version 2018-11-09 ou ultérieure.

Spécifier un ID d’objet utilisateur signé pour un principal de sécurité

Les champs facultatifs signedAuthorizedObjectId (saoid) et signedUnauthorizedObjectId (suoid) permettent l’intégration aux charges de travail Apache Hadoop et Apache Ranger pour Azure Data Lake Storage. Utilisez l’un de ces champs sur le jeton SAP pour spécifier l’ID d’objet d’un principal de sécurité :

Le champ saoid spécifie l’ID d’objet d’un principal de sécurité Microsoft Entra autorisé par le propriétaire de la clé de délégation d’utilisateur à effectuer l’action accordée par le jeton SAP. Stockage Azure valide le jeton SAP et garantit que le propriétaire de la clé de délégation d’utilisateur dispose des autorisations requises avant qu’Azure Storage n’accorde l’accès. Aucune vérification d’autorisation supplémentaire sur les listes de contrôle d’accès POSIX n’est effectuée.
Le champ suoid spécifie l’ID d’objet d’un principal de sécurité Microsoft Entra lorsqu’un espace de noms hiérarchique est activé pour un compte de stockage. Le champ suoid est valide uniquement pour les comptes qui ont un espace de noms hiérarchique. Lorsque le champ suoid est inclus sur le jeton SAP, Stockage Azure effectue une vérification ACL POSIX par rapport à l’ID d’objet avant d’autoriser l’opération. Si cette vérification de liste de contrôle d’accès ne réussit pas, l’opération échoue. Un espace de noms hiérarchique doit être activé pour le compte de stockage si le champ suoid est inclus sur le jeton SAP. Sinon, la vérification des autorisations échoue avec une erreur d’autorisation.

L’ID d’objet du principal de sécurité qui demande la clé de délégation d’utilisateur est capturé dans le champ skoid requis. Pour spécifier un ID d’objet sur le jeton SAP avec le champ saoid ou suoid, le principal de sécurité identifié dans le champ skoid doit être affecté à un rôle RBAC qui inclut Microsoft.Storage/storageAccounts/blobServices/blobServices/containers/blobs/runAsSuperUser/action ou Microsoft.Storage/storageAccounts/blobServices/containers/blobServices/runAsSuperShip/action. Pour plus d’informations sur ces actions, consultez opérations du fournisseur de ressources Azure.

En spécifiant l’ID d’objet dans le champ saoid ou suoid, vous limitez également les opérations liées à la propriété d’annuaire ou d’objet blob de la manière suivante :

Si une opération crée un répertoire ou un objet blob, Stockage Azure définit le propriétaire du répertoire ou de l’objet blob sur la valeur spécifiée par l’ID d’objet. Si l’ID d’objet n’est pas spécifié, Stockage Azure définit le propriétaire du répertoire ou de l’objet blob sur la valeur spécifiée par le paramètre skoid.
Si le bit sticky est défini sur le répertoire parent et que l’opération supprime ou renomme un répertoire ou un objet blob, l’ID d’objet du propriétaire du répertoire parent ou le propriétaire de la ressource doit correspondre à la valeur spécifiée par l’ID d’objet.
Si une opération définit le propriétaire d’un répertoire ou d’un objet blob et que l’en-tête x-ms-owner est spécifié, la valeur spécifiée par l’ID d’objet doit correspondre à la valeur spécifiée par l’en-tête x-ms-owner.
Si une opération définit le groupe pour un répertoire ou un objet blob et que l’en-tête x-ms-group est spécifié, la valeur spécifiée par l’ID d’objet doit être membre du groupe spécifié par l’en-tête x-ms-group.
Si une opération définit les autorisations ou la liste de contrôle d’accès pour un répertoire ou un objet blob, l’une des deux conditions suivantes doit également être remplie :
- La valeur spécifiée pour l’ID d’objet doit être le propriétaire du répertoire ou de l’objet blob.
- La valeur du champ signedPermissions (sp) doit inclure l’autorisation Ownership (o) en plus de l’autorisation Permissions (p).

L’ID d’objet spécifié dans le champ saoid ou suoid est inclus dans les journaux de diagnostic lorsque vous effectuez des requêtes à l’aide du jeton SAP.

Le champ saoid ou suoid est pris en charge uniquement si le champ signedVersion (sv) est défini sur la version 2020-02-10 ou ultérieure. Un seul de ces champs peut être inclus sur le jeton SAP.

Spécifier un ID de corrélation

Le champ signedCorrelationId (scid) spécifie un ID de corrélation qui peut être utilisé pour mettre en corrélation les journaux d’audit de stockage avec les journaux d’audit utilisés par le principal qui génère et distribue la SAP. Par exemple, un service d’autorisation approuvé a généralement une identité managée qui authentifie et autorise les utilisateurs, génère une SAP, ajoute une entrée au journal d’audit local et retourne la SAP à un utilisateur, qui peut ensuite utiliser la SAP pour accéder aux ressources stockage Azure. En incluant un ID de corrélation dans le journal d’audit local et le journal d’audit de stockage, vous autorisez ces événements à être corrélés ultérieurement. La valeur est un GUID sans accolades et avec des caractères minuscules.

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

Spécifier la profondeur du répertoire

Si le champ signedResource spécifie un répertoire (sr=d), vous devez également spécifier le champ signedDirectoryDepth (sdd) pour indiquer le nombre de sous-répertoires sous le répertoire racine. La valeur du champ sdd doit être un entier non négatif.

Par exemple, le répertoire racine https://{account}.blob.core.windows.net/{container}/ a une profondeur de 0. Chaque sous-répertoire du répertoire racine ajoute à la profondeur d’ici 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 et ultérieure.

Spécifier les paramètres de requête pour remplacer les en-têtes de réponse

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

Par exemple, si vous spécifiez le paramètre de requête rsct=binary sur un jeton SAP, l’en-tête de réponse Content-Type est défini sur binary. Cette valeur remplace la valeur d’en-tête Content-Type stockée pour l’objet blob pour une requête à l’aide de cette signature d’accès partagé uniquement.

Si vous créez une signature d’accès partagé qui spécifie les en-têtes de réponse en tant que paramètres de requête, vous devez inclure ces en-têtes de réponse dans la chaîne à signer utilisée pour construire la chaîne de signature. Pour plus d’informations, consultez la section «Spécifier la signature».

Spécifier l’étendue de chiffrement

Le champ signed encryption scope (ses) spécifie une étendue de chiffrement utilisée par l’application cliente lorsque vous chargez des objets blob à l’aide du jeton SAP via l’opération Put Blob. Le champ signed encryption scope est pris en charge lorsque le champ version signée (sv) du jeton SAP est la version 2020-12-06 ou ultérieure. Si le champ de version signée spécifie une version antérieure à la version prise en charge, le service retourne le code de réponse d’erreur 403 (Interdit).

Si l’étendue de chiffrement par défaut est définie pour le conteneur ou le système de fichiers, le champ ses respecte la stratégie de chiffrement de conteneur. S’il existe une incompatibilité entre le paramètre de requête ses et l’en-tête x-ms-default-encryption-scope, 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).

Si l’en-tête x-ms-encryption-scope et le paramètre de requête ses sont tous les deux fournis dans la requête PUT et qu’il existe une incompatibilité, le service retourne le code de réponse d’erreur 400 (requête incorrecte).

Spécifier la signature

Le champ signature (sig) est utilisé pour autoriser une demande effectuée par un client avec la signature d’accès partagé. La chaîne à signer est une chaîne unique construite à partir des champs qui doivent être vérifiés pour autoriser la requête. La signature est un HMAC calculé sur la chaîne à signer et la clé à l’aide de l’algorithme SHA256, puis encodé à l’aide de l’encodage Base64.

Pour construire la chaîne de signature d’une SAP de délégation d’utilisateur, créez la chaîne à signer à partir des champs qui composent la requête, 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.

Les champs requis dans la chaîne à signer dépendent de la version du service utilisée pour l’autorisation (champsv). Les sections suivantes décrivent la configuration de chaîne à signer pour les versions qui prennent en charge la SAP de délégation d’utilisateur.

Version 2025-07-05 et versions ultérieures

La chaîne à signer pour le stockage de blobs avec l’autorisation 2025-07-05 et ultérieure a le format suivant :

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                "\n" +
                "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

La chaîne à signer pour le stockage de tables avec la version d’autorisation 2025-07-05 et ultérieure a le format suivant :

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                "\n" +
                "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                startingPartitionKey + "\n"  
                startingRowKey + "\n"  
                endingPartitionKey + "\n"  
                endingRowKey

La chaîne de signes pour le stockage en file d’attente avec l’autorisation version 2025-07-05 et ultérieure a le format suivant :

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                "\n" +
                "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion

La chaîne de signation pour Azure Files avec l’autorisation 2025-07-05 et ultérieure présente le format suivant :

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                "\n" +
                "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Version 2020-12-06 et ultérieure

La chaîne à signer pour l’autorisation version 2020-12-06 et ultérieure a le format suivant :

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Version du 10/02/2020

La chaîne à signer pour l’autorisation version 2020-02-10 a le format suivant :

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Versions antérieures à 2020-02-10

La chaîne à signer pour les versions d’autorisation antérieures à 2020-02-10 a le format suivant :

StringToSign =  signedPermissions + "\n" +  
                signedStart + "\n" +  
                signedExpiry + "\n" +  
                canonicalizedResource + "\n" +  
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +  
                signedProtocol + "\n" +  
                signedVersion + "\n" +  
                signedResource + "\n" +
                rscc + "\n" +
                rscd + "\n" +  
                rsce + "\n" +  
                rscl + "\n" +  
                rsct

Ressource canonique

La partie canonicalizedResource de la chaîne est un chemin canonique vers la ressource signée. Il doit inclure le point de terminaison Stockage Blob (either blob or dfs) et le nom de la ressource, et il doit être décodé en URL. Un chemin d’accès d’objet blob doit inclure son conteneur. Un chemin d’accès au répertoire doit inclure le nombre de sous-répertoires qui correspondent au paramètre sdd.

La chaîne de ressource canonique d’un conteneur doit omettre la barre oblique de fin (/) d’une SAP qui fournit l’accès à ce conteneur.

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

Exemple de conteneur (Stockage Blob Azure)

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

Exemple d’objet blob (Stockage Blob Azure)

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

Exemple de conteneur (Azure Data Lake Storage)

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

Exemple de répertoire (Azure Data Lake Storage)

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

Exemple d’objet blob (Azure Data Lake Storage)

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

Partages de fichiers

Pour la version 2025-07-05 et suivantes :

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

Fichiers

Pour la version 2025-07-05 et suivantes :

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

Files d’attente

Pour la version 2025-07-05 et suivantes :

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

Tables

Si la ressource signée est une table, assurez-vous que le nom de la table est en minuscules dans le format canonisé.

Pour la version 2025-07-05 et suivantes :

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

Champs facultatifs

Si un champ est facultatif et non fourni dans le cadre du jeton SAP, spécifiez une chaîne vide pour le champ. Veillez à inclure le caractère de nouvelle ligne (\n) après la chaîne vide.

Exemple SAS de délégation d’utilisateur

L’exemple suivant montre un URI d’objet blob avec un jeton SAP de délégation d’utilisateur ajouté à celui-ci. Le jeton SAP de délégation d’utilisateur fournit des autorisations de lecture et d’écriture dans 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&skoid=<object-id>&sktid=<tenant-id>&skt=2023-05-24T01:13:55Z&ske=2023-05-24T09:13:55Z&sks=b&skv=2022-11-02&sip=198.51.100.10-198.51.100.20&spr=https&sv=2022-11-02&sr=b&sig=<signature>

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

Nom	Partie SAP	Descriptif
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 SAP.
Autorisations	`sp=rw`	Les autorisations accordées par la SAP incluent lecture (r) et écriture (w).
Heure de début	`st=2023-05-24T01:13:55Z`	Spécifié en heure UTC. Si vous souhaitez que la SAP soit valide immédiatement, omettez l’heure de début.
Délai d’expiration	`se=2023-05-24T09:13:55Z`	Spécifié en heure UTC.
ID d’objet	`skoid=<object-id>`	Un principal de sécurité Microsoft Entra.
ID de locataire	`sktid=<tenant-id>`	Locataire Microsoft Entra où le principal de sécurité est inscrit.
Heure de début de la clé	`skt=2023-05-24T01:13:55Z`	Début de la durée de vie de la clé de délégation utilisateur.
Heure d’expiration de la clé	`ske=2023-05-24T09:13:55Z`	Fin de la durée de vie de la clé de délégation utilisateur.
Service de clé	`sks=b`	Seul le service Blob est pris en charge pour la valeur du service.
Version de clé	`skv=2022-11-02`	Version du service de stockage utilisée pour obtenir la clé de délégation utilisateur.
Plage d’adresses IP	`sip=198.51.100.10-198.51.100.20`	Plage d’adresses IP à partir de laquelle une demande sera acceptée.
Protocole	`spr=https`	Seules les requêtes qui utilisent HTTPS sont autorisées.
Version du service Blob	`sv=2022-11-02`	Pour Stockage Azure version 2012-02-12 et ultérieure, ce paramètre indique la version à utiliser.
Ressource	`sr=b`	La ressource est un objet blob.
Signature	`sig=<signature>`	Permet d’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.

Révoquer une SAP de délégation d’utilisateur

Si vous pensez qu’une SAP a été compromise, vous devez la révoquer. Vous pouvez révoquer une SAP de délégation d’utilisateur en révoquant la clé de délégation d’utilisateur, ou en modifiant ou en supprimant les attributions de rôles RBAC et les ACL POSIX pour le principal de sécurité utilisé pour créer la SAP.

Important

La clé de délégation d’utilisateur et les attributions de rôles RBAC sont mises en cache par stockage Azure. Il peut donc y avoir un délai entre le moment où vous lancez le processus de révocation et quand une SAP de délégation d’utilisateur existante devient non valide.

Révoquer la clé de délégation d’utilisateur

Vous pouvez révoquer la clé de délégation d’utilisateur en appelant le révoquer les clés de délégation d’utilisateur opération. Lorsque vous révoquez la clé de délégation d’utilisateur, toutes les signatures d’accès partagé qui s’appuient sur cette clé deviennent non valides. Vous pouvez ensuite appeler à nouveau l’opération Obtenir la clé de délégation d’utilisateur et utiliser la clé pour créer de nouvelles signatures d’accès partagé. Il s’agit du moyen le plus rapide de révoquer une SAP de délégation d’utilisateur.

Modifier ou supprimer des attributions de rôles ou des listes de contrôle d’accès

Vous pouvez modifier ou supprimer l’attribution de rôle RBAC et les ACL POSIX pour le principal de sécurité utilisé pour créer la SAP. Lorsqu’un client utilise la sape pour accéder à une ressource, Stockage Azure vérifie que le principal de sécurité dont les informations d’identification ont été utilisées pour sécuriser la SAP dispose des autorisations requises pour la ressource.

Voir aussi

Last updated on 2025-11-26

Partager via

Créer une SAP de délégation d’utilisateur

Prise en charge SAS de la délégation utilisateur pour l’accès à cahier des répertoires (stockage Blob et stockage sur lac de données uniquement)

Prise en charge SAS de la délégation utilisateur pour un OID utilisateur (stockage en blob et stockage sur le lac de données uniquement)

Autoriser une SAP de délégation d’utilisateur

Attribuer des autorisations avec RBAC

Acquérir un jeton OAuth 2.0

Demander la clé de délégation d’utilisateur

Construire une SAP de délégation d’utilisateur

Spécifier le champ de version signée

Spécifier le champ de ressource signée (stockage de blobs uniquement)

Spécifier le champ de ressource signé (uniquement Azure Files)

Spécifier les paramètres de requête pour écraser les en-têtes de réponse (stockage Blob et fichiers Azure uniquement)

Spécifier la durée de validité de la signature

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

Spécifier des autorisations

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

Autorisations pour un fichier

Autorisations pour un partage

Autorisations pour une file d’attente

Autorisations pour une table

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

Spécifier le protocole HTTP

Spécifier les plages d’accès à la table

Spécifier l’ID d’objet signé

Spécifier l’ID de locataire signé

Spécifier l’heure de début de la clé signée

Spécifier l’heure d’expiration de la clé signée

Spécifier le service de clé signée

Spécifier la version de la clé signée

Spécifier un ID d’objet utilisateur signé pour un principal de sécurité

Spécifier un ID de corrélation

Spécifier la profondeur du répertoire

Spécifier les paramètres de requête pour remplacer les en-têtes de réponse

Spécifier l’étendue de chiffrement

Spécifier la signature

Version 2025-07-05 et versions ultérieures

Version 2020-12-06 et ultérieure

Version du 10/02/2020

Versions antérieures à 2020-02-10

Ressource canonique

Exemple de conteneur (Stockage Blob Azure)

Exemple d’objet blob (Stockage Blob Azure)

Exemple de conteneur (Azure Data Lake Storage)

Exemple de répertoire (Azure Data Lake Storage)

Exemple d’objet blob (Azure Data Lake Storage)

Partages de fichiers

Fichiers

Files d’attente

Tables

Champs facultatifs

Exemple SAS de délégation d’utilisateur

Révoquer une SAP de délégation d’utilisateur

Révoquer la clé de délégation d’utilisateur

Modifier ou supprimer des attributions de rôles ou des listes de contrôle d’accès

Voir aussi

Ressources supplémentaires