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

  • Article
  • 31 minutes de lecture

Vous pouvez sécuriser un jeton de signature d’accès partagé (SAS) pour l’accès à un conteneur, à un répertoire ou à un objet blob à l’aide des informations d’identification Azure Active Directory (Azure AD) ou d’une clé de compte. Une sap sécurisée avec des informations d’identification Azure AD est appelée SAP de délégation d’utilisateur . Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser les informations d’identification Azure AD 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 Azure AD 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 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 Azure AD. 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 utilisateur pour créer la sap.

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 au répertoire

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

Le format 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 signature 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 version ultérieure. Ce paramètre facultatif fournit 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 à un utilisateur et à une opération de système de fichiers 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’intégration du pilote Hadoop ABFS à Apache Ranger est l’un des cas d’usage de ces fonctionnalités.

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

Lorsqu’un client accède à une ressource Stockage Blob avec une sap de délégation d’utilisateur, la demande à Stockage Azure est autorisée avec les informations d’identification Azure AD 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 Azure AD, 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 la clé d’accès de votre compte avec le code de votre application. Pour ces raisons, la création d’une sap à l’aide d’informations d’identification Azure AD est une bonne pratique de sécurité.

Les autorisations accordées à un client qui possède la sap sont l’intersection des autorisations qui ont été accordées au principal de sécurité qui a demandé la clé de délégation 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 utilisateur.
  2. Acquérir un jeton OAuth 2.0 auprès d’Azure AD.
  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 principal de sécurité Azure AD 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é le Microsoft. Action Storage/storageAccounts/blobServices/generateUserDelegationKey. Les rôles RBAC intégrés suivants incluent les Microsoft. Action Storage/storageAccounts/blobServices/generateUserDelegationKey, soit explicitement, soit dans le cadre d’une définition générique :

Étant donné que l’opération Obtenir la clé de délégation d’utilisateur agit au niveau du compte de stockage, le Microsoft. L’action 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 intégrés précédemment répertoriés ou à un rôle personnalisé qui inclut le Microsoft. Action Storage/storageAccounts/blobServices/generateUserDelegationKey, 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 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 De délégant Blob de stockage accorde au principal de sécurité des autorisations pour demander la clé de délégation 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, commencez par demander un jeton OAuth 2.0 auprès d’Azure AD. Fournissez le jeton avec le schéma du porteur pour autoriser l’appel à l’opération Obtenir la clé de délégation de l’utilisateur . Pour plus d’informations sur la demande d’un jeton OAuth auprès d’Azure AD, 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 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 utilisateur. Ces paramètres sont décrits dans la référence Obtenir une clé de délégation utilisateur et dans la section suivante, « Construire une sap 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 au nom du principal de sécurité. La sap créée avec la clé de délégation d’utilisateur reçoit 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 n’importe quel nombre de signatures d’accès partagé de délégation d’utilisateur sur 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 du service qui gère les demandes effectuées avec cette sap.
signedResource sr Obligatoire Tous Spécifie les ressources d’objets blob 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 sap 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 desquelles 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 sap. 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é Azure AD.
signedTenantId sktid Obligatoire 2018-11-09 et versions ultérieures Spécifie le locataire Azure AD 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 utilisateur . Indique le début de la durée de vie de la clé de délégation utilisateur, exprimé 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 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.
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 principal de sécurité Azure AD autorisé par le propriétaire de la clé de délégation utilisateur à effectuer l’action accordée par le jeton SAP. Aucune vérification d’autorisation supplémentaire 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 principal de sécurité Azure AD lorsqu’un espace de noms hiérarchique est activé. Stockage Azure effectue une vérification ACL POSIX par rapport à l’ID d’objet avant d’autoriser l’opération.
signedCorrelationId scid Facultatif 2020-02-10 et versions ultérieures Corrélez 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 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ée pour construire le champ et spécifie la signature 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 à un objet blob, un conteneur ou une ressource de répertoire dans le jeton SAP :

Ressource Valeur du paramètre Versions prises en charge Description
Objet blob b Tous Octroie l’accès au contenu et aux métadonnées de l’objet blob.
Version de blob Bv 2018-11-09 et versions ultérieures Octroie l’accès au contenu et aux métadonnées de la version de l’objet blob, mais pas à l’objet blob de base.
Instantané d’objet blob bs 2018-11-09 et versions ultérieures Octroie l’accès au contenu et aux métadonnées de l’instantané d’objet blob, mais pas à l’objet blob de base.
Conteneur c Tous Octroie l’accès au contenu et aux métadonnées de n’importe quel objet blob dans le conteneur, ainsi qu’à la liste des objets blob dans le conteneur.
Répertoire d 2020-02-10 et versions ultérieures Octroie l’accès au contenu et aux métadonnées de 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
Objet 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
Objet blob		 Tous Ajoutez un bloc à un objet blob d’ajout.
Créer c Conteneur
Répertoire
Objet blob		 Tous Écrivez un nouvel objet blob, capturez un instantané d’un objet blob ou copiez un objet blob dans un nouvel objet blob.
Write w Conteneur
Répertoire
Objet blob		 Tous Créez ou écrivez 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
Objet 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 Objet 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 Objet blob 2019-12-12 et versions ultérieures Lire ou écrire les balises sur un objet blob.
Déplacer m Conteneur
Répertoire
Objet 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 SAP et que le bit collant est défini sur le répertoire parent.
Execute e Conteneur
Répertoire
Objet 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 permet de définir le groupe propriétaire, les autorisations POSIX et la liste de contrôle 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
Objet 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 est défini.
Autorisations p Conteneur
Répertoire
Objet 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 des répertoires et des 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 IP

Le champ facultatif signedIp (sip) spécifie une adresse IP publique ou une plage d’adresses IP publiques à partir desquelles accepter les demandes. Si l’adresse IP d’où provient la demande 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 décrit 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 en cours d’exécution 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 signedIp champ. 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 se produisent toujours via une adresse IP privée. Pour plus d’informations, consultez Configurer Pare-feu et réseaux virtuels dans Stockage Azure.
Client en cours d’exécution dans Azure Dans une région différente du client Une sap 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 sap doivent provenir de l’adresse IP spécifiée ou de la plage d’adresses.
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 signedIp champ. Les demandes que vous effectuez avec la sap doivent provenir de l’adresse IP spécifiée ou de la plage d’adresses.

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

Spécifier le protocole HTTP

Le champ facultatif signedProtocol (spr) spécifie le protocole autorisé pour les requêtes effectuées avec la sap. 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 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 le Plateforme d'identités Microsoft.

Spécifier l’ID de locataire signé

Le signedTenantId champ (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 Azure AD 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 DATE ISO. L’opération Obtenir la clé de délégation d’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 sap de délégation d’utilisateur au format DATE ISO. L’opération Obtenir la clé de délégation d’utilisateur retourne cette valeur dans le cadre de la réponse. L’heure 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 d’un maximum de sept jours à compter de l’heure de début de la SAP.

Spécifier le service de clé signée

Le signedKeyService champ (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 utilisateur est valide. La valeur du champ de service de clé signée pour Stockage Blob est b.

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

Le signedkeyversion champ (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 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 SAP pour spécifier l’ID d’objet d’un principal de sécurité :

  • Le saoid champ spécifie l’ID d’objet d’un principal de sécurité Azure AD 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 vérification d’autorisation supplémentaire 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 principal de sécurité Azure AD 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 SAS, Stockage Azure effectue une vérification de liste de contrôle d’accès POSIX par rapport à l’ID d’objet avant d’autoriser l’opération. Si cette vérification de la liste de contrôle d’accès é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 sur le jeton SAS. 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 obligatoire skoid . Pour spécifier un ID d’objet sur le jeton SAS avec le saoid champ ou suoid , 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. Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/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 saoid champ ou suoid , vous limitez également les opérations liées à la propriété du répertoire ou de l’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 d’un répertoire ou d’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 SAS.

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 signature d’accès partagé, ajoute une entrée au journal d’audit local et retourne la signature d’accès partagé à 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 la mise en corrélation de ces événements 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 rsct=binary paramètre de requête sur un jeton SAS, 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 de signature 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 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 SAS via l’opération Put Blob . Le signed encryption scope champ est pris en charge lorsque le champ de 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 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 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 (demande incorrecte).

Spécifier la signature

Le signature champ (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 qui est construite à partir des champs qui doivent être vérifiés pour autoriser la demande. 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 signature SAP de délégation d’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érieure

La chaîne à signer pour la version d’autorisation 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 pour un conteneur doit omettre la barre oblique de fin (/) pour une sape 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.

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

Si vous pensez qu’une signature d’accès partagé 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 signature d’accès partagé.

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 d’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é ne deviennent plus valides. Vous pouvez ensuite appeler à nouveau l’opération Obtenir la clé de délégation 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 signature d’accès partagé 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