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

  • Article

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 des informations d’identification Microsoft Entra est appelée SAP de délégation d’utilisateur. En guise de meilleure pratique en matière 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 afin de 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 signature d’accès partagé. 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 repose sur vos informations d’identification Microsoft Entra. Pour demander la clé de délégation utilisateur, appelez l’opération Obtenir la clé de délégation utilisateur . Vous pouvez ensuite utiliser la clé de délégation d’utilisateur pour créer la signature d’accès partagé.

Une SAP de délégation d’utilisateur est prise en charge pour Stockage Blob Azure et Azure Data Lake Storage Gen2. Les stratégies d’accès stockées ne sont pas prises en charge pour une SAP de délégation d’utilisateur.

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 de signature d’accès partagé ne doivent être distribués que 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 une SAP de service et Créer une SAP de compte.

Prise en charge des sap de délégation d’utilisateurs pour l’accès étendu à l’annuaire

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 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. Quand sr=d est spécifié, le paramètre de sdd requête est également requis.

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

Prise en charge des SAP de délégation d’utilisateur pour un OID utilisateur

La sap de délégation d’utilisateur prend en charge un identificateur d’objet utilisateur (OID) facultatif qui est porté dans le saoid paramètre ou suoid lorsque la version d’autorisation (sv) est 2020-02-10 ou ultérieure. Ce paramètre facultatif fournit un modèle d’autorisation amélioré pour les charges de travail de cluster multi-utilisateur telles que Hadoop et Spark.

Les jetons SAS peuvent être limités à une opération de système de fichiers et à un utilisateur spécifiques, 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 Hadoop ABFS à Apache Ranger.

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

Lorsqu’un client accède à une ressource De stockage Blob avec une sape de délégation d’utilisateur, la demande au Stockage Azure est autorisée avec les informations d’identification Microsoft Entra qui ont été utilisées pour créer la SAP. Les autorisations de contrôle d’accès en fonction du rôle (RBAC) accordées pour ce compte Microsoft Entra, ainsi que les autorisations explicitement accordées sur la sap, déterminent l’accès du client à la ressource. Cette approche offre 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 d’informations d’identification Microsoft Entra est une bonne pratique de sécurité.

Les autorisations accordées à un client qui possède la signature d’accès partagé correspondent à l’intersection des autorisations qui ont été accordées au principal de sécurité qui a demandé la clé de délégation d’utilisateur et des autorisations qui ont été accordées à la ressource sur le jeton SAP à l’aide du signedPermissions champ (sp). Si une autorisation accordée au principal de sécurité via RBAC 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 RBAC et les autorisations accordées via le jeton SAP s’alignent 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 :

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

Assigner des autorisations avec le RBAC

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

Pour demander la clé de délégation d’utilisateur, vous devez affecter à un principal de sécurité l’action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey . Les rôles RBAC intégrés suivants incluent l’action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey , explicitement ou dans le cadre d’une définition de caractères génériques :

Étant donné que l’opération Obtenir la clé de délégation 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 l’un des rôles intégrés précédemment répertoriés ou un rôle personnalisé incluant l’action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey est affecté au niveau du compte de stockage, du groupe de ressources ou de l’abonnement, le principal de sécurité peut alors demander la clé de délégation utilisateur.

Si le principal de sécurité se voit attribuer un rôle qui autorise l’accès aux données, mais dont l’étendue est limitée au niveau d’un conteneur, vous pouvez également attribuer le rôle Delegator 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 Stockage Blob Delegator accorde au principal de sécurité des autorisations pour demander la clé de délégation d’utilisateur.

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

Acquérir un jeton OAuth 2.0

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

Demander la clé de délégation 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 qui sont utilisées comme paramètres sur le jeton SAS de délégation d’utilisateur. Ces paramètres sont décrits dans la référence Obtenir la clé de délégation utilisateur et dans la section suivante, « Construire une sape de délégation d’utilisateur ».

Lorsqu’un client demande une clé de délégation d’utilisateur à l’aide d’un jeton OAuth 2.0, stockage Azure retourne la clé de délégation utilisateur pour le compte du principal de sécurité. La sap créée avec la clé de délégation d’utilisateur se voit accorder les autorisations qui ont été 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 utilisateur étant indépendante du jeton OAuth 2.0 que vous utilisez pour l’acquérir, le jeton n’a 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 de la version Description
signedVersion sv Obligatoire 2018-11-09 et versions ultérieures Indique la version du service utilisée pour construire le champ de signature. Il spécifie également la version de service qui gère les demandes effectuées avec cette signature d’accès partagé.
signedResource sr Obligatoire Tous Spécifie les ressources d’objet blob qui sont accessibles via la signature d’accès partagé.
signedStart st Facultatif Tous facultatif. 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 Formater les valeurs DateTime.
signedExpiry se Obligatoire Tous 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 Formater les valeurs DateTime.
signedPermissions sp Obligatoire Tous Indique les opérations qu’un client qui possède la signature d’accès partagé peut effectuer sur la ressource. Les autorisations peuvent être combinées.
signedIp sip Facultatif 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=168.1.5.65 ou sip=168.1.5.60-168.1.5.70.
signedProtocol spr Facultatif 2015-04-05 et versions ultérieures Spécifie le protocole autorisé pour une requête effectuée avec la signature d’accès partagé. Incluez ce champ pour exiger que les requêtes effectuées avec le jeton SAS utilisent HTTPS.
signedObjectId skoid Obligatoire 2018-11-09 et versions ultérieures Identifie un principal de sécurité Microsoft Entra.
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 facultatif. 2018-11-09 et versions ultérieures La valeur est retournée par l’opération Obtenir la clé de délégation de l’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. Si la valeur est omise, l’heure actuelle est supposée. Pour plus d’informations sur les formats UTC acceptés, consultez Formater les 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 de l’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 Formater les 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 de l’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 Facultatif 2020-02-10 et versions ultérieures Spécifie l’ID d’objet d’un Microsoft Entra principal de sécurité autorisé par le propriétaire de la clé de délégation utilisateur à effectuer l’action accordée par le jeton SAS. Aucune autorisation supplémentaire case activée sur les listes de contrôle d’accès POSIX (Portable Operating System Interface) n’est effectuée.
signedUnauthorizedObjectId suoid Facultatif 2020-02-10 et versions ultérieures Spécifie l’ID d’objet d’un Microsoft Entra principal de sécurité lorsqu’un espace de noms hiérarchique est activé. Stockage Azure effectue une case activée de liste de contrôle d’accès POSIX par rapport à l’ID d’objet avant d’autoriser l’opération.
signedCorrelationId scid Facultatif 2020-02-10 et versions ultérieures 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 quand sr=d 2020-02-10 et versions ultérieures Indique le nombre de répertoires dans le dossier racine du répertoire spécifié dans le canonicalizedResource champ de la chaîne à signer.
signedEncryptionScope ses Facultatif 2020-12-06 et versions ultérieures Indique l’étendue de chiffrement à utiliser pour chiffrer le contenu de la demande.
signature sig Obligatoire Tous La signature est un code d’authentification de message basé sur le hachage (HMAC) qui est calculé sur la chaîne à signer et la clé à l’aide de l’algorithme SHA256, puis encodé à l’aide de l’encodage Base64.
Cache-Control en-tête de réponse rscc Facultatif 2013-08-15 et versions ultérieures Stockage Azure définit l’en-tête Cache-Control de réponse sur la valeur spécifiée sur le jeton SAP.
Content-Disposition en-tête de réponse rscd Facultatif 2013-08-15 et versions ultérieures Stockage Azure définit l’en-tête Content-Disposition de réponse sur la valeur spécifiée sur le jeton SAP.
Content-Encoding en-tête de réponse rsce Facultatif 2013-08-15 et versions ultérieures Stockage Azure définit l’en-tête Content-Encoding de réponse sur la valeur spécifiée sur le jeton SAP.
Content-Language en-tête de réponse rscl Facultatif 2013-08-15 et versions ultérieures Stockage Azure définit l’en-tête Content-Language de réponse sur la valeur spécifiée sur le jeton SAP.
Content-Type en-tête de réponse rsct Facultatif 2013-08-15 et versions ultérieures Stockage Azure définit l’en-tête Content-Type de réponse sur la valeur spécifiée sur le jeton SAP.

Spécifier le champ de version signée

Le champ obligatoire signedVersion (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 signature champ et spécifie la version du service qui gère une requête effectuée avec cette signature d’accès partagé. La valeur du sv champ doit être la version 2018-11-09 ou ultérieure.

Spécifier le champ de ressource signé

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, de conteneur ou de répertoire dans le jeton SAS :

Ressource Valeur du paramètre Versions prises en charge Description
Objet blob b Tous Accorde 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 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 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 Accorde l’accès au contenu et aux métadonnées de tout 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 n’importe quel 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 se trouve toujours dans un conteneur.

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

Les signedStart champs (st) et signedExpiry (se) indiquent les heures de début et d’expiration de la signature d’accès partagé. Le champ signedExpiry est obligatoire. 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 utilisateur. Si un client tente d’utiliser une signature d’accès partagé après l’expiration de la clé de délégation d’utilisateur, la signature d’accès partagé é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 Formater les valeurs DateTime.

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 qui possède la signature d’accès partagé 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 signature d’accès partagé, vous devez inclure les autorisations dans l’ordre suivant :

racwdxltmeop

Exemples de paramètres d’autorisations valides pour un conteneur : rw, rlrd, wd, , 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.

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

  • Les conteneurs 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 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.

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
Blob		 Tous Lisez le contenu, la liste de blocage, 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
Blob		 Tous Ajoutez un bloc à un objet blob d’ajout.
Créer c Conteneur
Répertoire
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 Créer 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.
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. Il 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 lorsque l’appelant renomme ou supprime un répertoire ou un objet blob dans un répertoire dont le bit collant 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.

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 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, 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 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 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 que vous effectuez à partir de la même région à l’aide d’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. Les demandes que vous effectuez avec la signature d’accès partagé doivent 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. Les demandes que vous effectuez avec la signature d’accès partagé doivent 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

Le champ facultatif signedProtocol (spr) spécifie le protocole autorisé pour les demandes effectuées 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.

Notes

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

Spécifier l’ID d’objet signé

Le signedObjectId champ (skoid) est requis pour une sape de délégation d’utilisateur. L’opération Obtenir la clé de délégation 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 le Plateforme d'identités Microsoft.

Spécifier l’ID de locataire signé

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

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

Le champ facultatif signedKeyStartTime (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 utilisateur retourne cette valeur dans le cadre de la réponse. Si l’heure de début est omise, l’heure de début de la clé signée est supposée être l’heure actuelle.

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

Le signedKeyExpiryTime champ (ske) est requis pour une sape de délégation d’utilisateur au format ISO Date. L’opération Obtenir la clé de délégation 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 utilisateur. La valeur de l’heure d’expiration peut être un maximum de sept jours à partir de l’heure de début de la signature d’accès partagé.

Spécifier le service de clé signée

Le signedKeyService champ (sks) est requis pour une sape de délégation d’utilisateur. L’opération Obtenir la clé de délégation 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 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 signedkeyversion champ (skv) est requis pour une sape de délégation d’utilisateur. L’opération Obtenir la clé de délégation utilisateur retourne cette valeur dans le cadre de la réponse. Le signedkeyversion champ 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 signé pour un principal de sécurité

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

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

L’ID d’objet du principal de sécurité qui demande la clé de délégation utilisateur est capturé dans le champ requis skoid . Pour spécifier un ID d’objet sur le jeton SAS avec le champ ousuoid, le principal de sécurité identifié dans le skoid champ doit se voir attribuer un rôle RBAC qui inclut Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action ou Microsoft.StorageAccounts/blobServices/containers/blobs/manageOwnership/action.saoid Pour plus d’informations sur ces actions, consultez Opérations du fournisseur de ressources Azure.

En spécifiant l’ID d’objet dans le saoid champ ou suoid , vous limitez également les opérations liées à la propriété de répertoire 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 skoid paramètre.
  • Si le bit collant 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 du 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 un 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 signedPermissions champ (sp) doit inclure l’autorisation Ownership (o) en plus de l’autorisation Permissions (p).

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

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

Spécifier un ID de corrélation

Le signedCorrelationId champ (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 de 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 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 et ultérieure.

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

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. Les en-têtes de réponse et les paramètres de requête correspondant sont les suivants :

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 paramètre de rsct=binary requête sur un jeton SAP, l’en-tête de Content-Type réponse est défini sur binary. Cette valeur remplace la valeur d'en-tête Content-Type stockée pour l'objet blob d'une demande en utilisant uniquement cette signature d'accès partagé.

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 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 du chiffrement

Le signed encryption scope champ (ses) spécifie une étendue de chiffrement que l’application cliente utilise lorsque vous chargez des objets blob à l’aide du jeton SAP via l’opération Put Blob . Le signed encryption scope champ est pris en charge lorsque le champ version signée (sv) sur le jeton SAP est la version 2020-12-06 ou ultérieure. Si le champ 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 ses champ 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 si 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 ses paramètre de requête sont tous 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 signature champ (sig) est utilisé pour autoriser une requête effectuée par un client avec la signature d’accès partagé. La chaîne à signer est une chaîne unique qui est construite à partir des champs qui doivent être vérifiés pour autoriser la demande. La signature est un HMAC qui est 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 signature SAP de délégation utilisateur, créez 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.

Les champs requis dans la chaîne à signer dépendent de la version du service utilisée pour l’autorisation (sv champ). 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 2020-12-06 et ultérieures

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 2020-02-10

La chaîne à signer pour la version d’autorisation 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 rendue canonique

La partie canonicalizedResource de la chaîne est un chemin d'accès canonique à la ressource signée. Il doit inclure le point de terminaison stockage Blob et le nom de la ressource, et il doit être décodé par 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 sdd paramètre.

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

Les exemples suivants montrent comment construire la canonicalizedResource partie 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 Gen2)
URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Exemple de répertoire (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"
Exemple d’objet blob (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"

Champs facultatifs

Si un champ est facultatif et n’est pas fourni dans le cadre du jeton SAS, 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 de sap de délégation d’utilisateur

L’exemple suivant montre un URI d’objet blob avec un jeton SAP de délégation utilisateur ajouté. Le jeton SAP de délégation d’utilisateur 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&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=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.
ID de l'objet skoid=<object-id> Un principal de sécurité Microsoft Entra.
ID client 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 la 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=168.1.5.60-168.1.5.70 Plage d’adresses IP dont les demandes seront acceptées.
Protocol spr=https Seules les requêtes qui utilisent HTTPS sont autorisées.
Version du service Blob sv=2022-11-02 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 clé et une chaîne à signer à 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 pour le principal de sécurité utilisé pour créer la sap.

Important

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

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

Vous pouvez révoquer la clé de délégation utilisateur en appelant l’opération Révoquer les clés de délégation utilisateur . 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

Vous pouvez modifier ou supprimer l’attribution de rôle RBAC pour le principal de sécurité utilisé pour créer la sap. Lorsqu’un client utilise la sap 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 sur la ressource.

Voir aussi