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 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 :
- Utilisez RBAC pour accorder les autorisations souhaitées au principal de sécurité qui demandera la clé de délégation de l’utilisateur.
- Acquérir un jeton OAuth 2.0 à partir de Microsoft Entra ID.
- 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 .
- 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 :
- Contributeur
- Contributeur de compte de stockage
- Contributeur aux données Blob du stockage
- Propriétaire des données Blob du stockage
- Lecteur des données blob du stockage
- Délégation du Stockage Blob
É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
, rl
rd
, wd
, , wl
et rl
. Exemples de paramètres non valides : wr
, dr
, lr
et 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. Lesuoid
champ est valide uniquement pour les comptes qui ont un espace de noms hiérarchique. Lorsque lesuoid
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 lesuoid
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êtex-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êtex-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’autorisationOwnership
(o
) en plus de l’autorisationPermissions
(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.