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

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 SAP de délégation d’utilisateur est prise en charge pour stockage Blob Azure et Azure Data Lake Storage. Les stratégies d’accès stockées ne sont pas prises en charge pour une SAP de délégation d’utilisateur.

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 de SAP de délégation d’utilisateur pour l’accès à l’étendue de 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 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 d’une 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 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 :

1. 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.
2. Acquérir un jeton OAuth 2.0 à partir de l’ID Microsoft Entra.
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 d’utilisateur.
4. 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 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 générique :

• 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

É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 principal de sécurité est affecté à un rôle qui autorise l’accès aux données, mais qu’il est limité au niveau d’un conteneur, vous pouvez également affecter le rôle Délegator d’objets blob de stockage au principal de sécurité au niveau du compte de stockage, du groupe de ressources ou de l’abonnement. Le délégateur d’objets blob de stockage accorde les autorisations du principal de sécurité 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 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 Obtenir la clé de délégation d’utilisateur référence 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, 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.

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é

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 :

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 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 ne peuvent pas être créés, supprimés ou répertoriés.
• Les métadonnées et propriétés du conteneur ne peuvent pas être lues ou écrites.
• Les 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.

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

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.

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.

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

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

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

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 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 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"  

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 :

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.

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

• Déléguer l’accès avec une signature d’accès partagé
• Créer une SAP de service
• Créer un SAP de compte
• codes d’erreur SAP