Autoriser avec une clé partagée

  • Article

Chaque demande adressée à un service de stockage doit être autorisée, sauf si la demande concerne une ressource d’objet blob ou de conteneur qui a été rendue disponible pour un accès public ou signé. L’une des options permettant d’autoriser une requête consiste à utiliser la clé partagée, décrite dans cet article.

Conseil

Stockage Azure fournit l’intégration à Microsoft Entra ID pour l’autorisation basée sur l’identité des demandes adressées aux services Blob, File, Queue et Table. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle (RBAC) pour accorder l’accès aux ressources d’objets blob, de fichiers, de file d’attente et de table aux utilisateurs, groupes ou applications. Microsoft Entra ID pouvez autoriser l’accès aux ressources de stockage sans stocker les clés d’accès de votre compte dans vos applications, comme vous le faites avec la clé partagée. Pour plus d’informations, consultez Autoriser avec Microsoft Entra ID.

Les services Blob, File d’attente, Table et File prennent en charge les schémas d’autorisation de clé partagée suivants pour la version 2009-09-19 et ultérieure (pour le service Blob, File d’attente et Table) et la version 2014-02-14 et ultérieure (pour le service De fichiers) :

  • Shared Key pour les services BLOB, de File d'attente et de Fichier. Utilisez le schéma d’autorisation de clé partagée pour effectuer des requêtes sur les services Blob, File d’attente et File. L’autorisation de clé partagée dans la version 2009-09-19 et ultérieure prend en charge une chaîne de signature augmentée pour une sécurité renforcée et vous oblige à mettre à jour votre service pour autoriser l’utilisation de cette signature augmentée.

  • Shared Key pour le service de Table. Utilisez le schéma d’autorisation de clé partagée pour effectuer des requêtes auprès du service Table à l’aide de l’API REST. L’autorisation de clé partagée pour le service Table dans les versions 2009-09-19 et ultérieures utilise la même chaîne de signature que dans les versions précédentes du service Table.

  • Shared Key Lite. Utilisez le schéma d’autorisation Shared Key Lite pour effectuer des requêtes sur les services Blob, File d’attente, Table et Fichier.

    Pour les versions 2009-09-19 et ultérieures des services Blob et File d’attente, l’autorisation De clé partagée Lite prend en charge l’utilisation d’une chaîne de signature identique à celle prise en charge par clé partagée dans les versions précédentes des services Blob et File d’attente. Vous pouvez donc utiliser Shared Key Lite pour effectuer des demandes auprès des services BLOB et de File d'attente sans mettre à jour votre chaîne de signature.

Une demande autorisée nécessite deux en-têtes : l’en-tête Date ou x-ms-date et l’en-tête Authorization . Les sections suivantes décrivent comment construire ces en-têtes.

Important

Stockage Azure prend en charge à la fois HTTP et HTTPS, mais l’utilisation de HTTPS est fortement recommandée.

Notes

Un conteneur ou un objet blob peut être mis à la disposition du public en définissant les autorisations d’un conteneur. Pour plus d’informations, consultez Gérer l’accès aux ressources de stockage Azure. Un conteneur, un objet blob, une file d’attente ou une table peut être mis à disposition pour l’accès signé via une signature d’accès partagé ; une signature d’accès partagé est autorisée via un autre mécanisme. Pour plus d’informations, consultez Déléguer l’accès avec une signature d’accès partagé .

Spécification de l’en-tête Date

Toutes les demandes autorisées doivent inclure l’horodatage UTC (Temps universel coordonné) pour la demande. Vous pouvez spécifier l'horodatage dans l'en-tête x-ms-date ou dans l'en-tête HTTP/HTTPS standard Date. Si les deux en-têtes sont spécifiés dans la demande, la valeur x-ms-date est utilisée comme heure de création de la demande.

Les services de stockage vérifient qu'une demande n'a pas plus de 15 minutes avant qu'elle n'atteigne le service. Cela protège contre certaines attaques de sécurité, notamment les attaques par relecture. Lorsque ce contrôle échoue, le serveur renvoie un code de réponse 403 (Interdit).

Notes

L’en-tête x-ms-date est fourni, car certaines bibliothèques et proxys de client HTTP définissent automatiquement l’en-tête Date et ne donnent pas au développeur la possibilité de lire sa valeur afin de l’inclure dans la demande autorisée. Si vous définissez x-ms-date, construisez la signature avec une valeur vide pour l'en-tête Date.

Spécification de l’en-tête d’autorisation

Une demande autorisée doit inclure l’en-tête Authorization . Si cet en-tête n’est pas inclus, la demande est anonyme et réussit uniquement sur un conteneur ou un objet blob marqué pour l’accès public, ou sur un conteneur, un objet blob, une file d’attente ou une table pour lequel une signature d’accès partagé a été fournie pour l’accès délégué.

Pour autoriser une demande, vous devez signer la demande avec la clé du compte qui effectue la demande et passer cette signature dans le cadre de la demande.

Le format de l'en-tête Authorization est le suivant :

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

où SharedKey ou SharedKeyLite est le nom du schéma d'autorisation, AccountName est le nom du compte demandant la ressource, et Signature est le HMAC (Hash-based Message Authentication Code) construit à partir de la demande et calculé en utilisant l'algorithme SHA256, puis encodé en Base64.

Notes

Il est possible de demander une ressource qui réside sous un autre compte, si cette ressource est accessible publiquement.

Les sections suivantes décrivent comment construire l'en-tête Authorization.

Construction de la chaîne de signature

La façon dont vous construisez la chaîne de signature dépend du service et de la version que vous autorisez et du schéma d’autorisation que vous utilisez. Lors de la construction de la chaîne de signature, n'oubliez pas les points suivants :

  • La partie VERB de la chaîne est le verbe HTTP, par exemple GET ou PUT, et doit être en majuscule.

  • Pour l’autorisation de clé partagée pour les services Blob, File d’attente et File, chaque en-tête inclus dans la chaîne de signature ne peut apparaître qu’une seule fois. Si un en-tête est en double, le service renvoie le code d'état 400 (Demande incorrecte).

  • Les valeurs de tous les en-têtes standard HTTP doivent être incluses dans la chaîne dans l'ordre indiqué dans le format de signature, sans les noms d'en-tête. Ces en-têtes peuvent être vides s’ils ne sont pas spécifiés dans le cadre de la demande ; dans ce cas, seul le caractère de nouvelle ligne est requis.

  • Si l’en-tête x-ms-date est spécifié, vous pouvez ignorer l’en-tête Date , qu’il soit ou non spécifié dans la demande, et spécifier simplement une ligne vide pour la Date partie de la chaîne de signature. Dans ce cas, suivez les instructions de la section Construction de la chaîne d’en-têtes canonicalisées pour ajouter l’en-tête x-ms-date .

    Il est acceptable de spécifier à la fois x-ms-date et Date; dans ce cas, le service utilise la valeur de x-ms-date.

  • Si l'en-tête x-ms-date n'est pas spécifié, spécifiez l'en-tête Date dans la chaîne de signature, sans inclure le nom d'en-tête.

  • Tous les caractères de nouvelle ligne (\n) affichés sont nécessaires dans la chaîne de signature.

  • La chaîne de signature inclut des en-têtes au format canonique et des chaînes de ressource au format canonique. La mise au format canonique de ces chaînes les place dans un format standard reconnu par Azure Storage. Pour plus d'informations sur la construction de chaînes CanonicalizedHeaders et CanonicalizedResource qui composent une partie de la chaîne de signature, consultez les sections appropriées plus loin dans cette rubrique.

Services d’objets blob, de file d’attente et de fichiers (autorisation de clé partagée)

Pour encoder la chaîne de signature Shared Key dans une demande, dans les versions 2009-09-19 et ultérieures des services BLOB ou File d'attente, et dans les versions 2014-02-14 et ultérieures du service Fichier, utilisez le format suivant :

StringToSign = VERB + "\n" +  
               Content-Encoding + "\n" +  
               Content-Language + "\n" +  
               Content-Length + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               If-Modified-Since + "\n" +  
               If-Match + "\n" +  
               If-None-Match + "\n" +  
               If-Unmodified-Since + "\n" +  
               Range + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

Important

Dans la version actuelle, le champ Content-Length doit être une chaîne vide si la longueur de contenu de la demande est égale à zéro. Dans les versions 2014-02-2014 et antérieures, la longueur du contenu était incluse même si zéro. Pour plus d’informations sur l’ancien comportement, consultez ci-dessous.

L’exemple suivant montre une chaîne de signature pour une opération Get Blob . Lorsqu’il n’existe aucune valeur d’en-tête, le caractère de nouvelle ligne uniquement est spécifié.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

La décomposition ligne par ligne montre chaque portion de la même chaîne :

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\n    /*Content-MD5*/  
\n    /*Content-Type*/  
\n    /*Date*/  
\n    /*If-Modified-Since */  
\n    /*If-Match*/  
\n    /*If-None-Match*/  
\n    /*If-Unmodified-Since*/  
\n    /*Range*/  
x-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

Ensuite, encodez cette chaîne à l'aide de l'algorithme HMAC-SHA256 dans la chaîne de signature encodée en UTF-8, construisez l'en-tête Authorization, et ajoutez l'en-tête à la demande. L'exemple suivant montre l'en-tête Authorization pour la même opération :

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Pour utiliser l’autorisation de clé partagée avec la version 2009-09-19 et ultérieure des services Blob et File d’attente, vous devez mettre à jour votre code pour utiliser cette chaîne de signature augmentée.

Si vous préférez migrer votre code vers la version 2009-09-19 ou ultérieure des services Blob et File d’attente avec le moins de modifications possible, vous pouvez modifier vos en-têtes existants Authorization pour utiliser la clé partagée Lite au lieu de la clé partagée. Le format de signature requis par Shared Key Lite est le même que celui pour Shared Key par les versions des services BLOB et de File d'attente antérieurs au 19/09/2009.

Important

Si vous accédez à l'emplacement secondaire dans un compte de stockage pour lequel la géo-réplication avec accès en lecture (RA-GRS) est activée, n'incluez pas la désignation -secondary dans l'en-tête d'autorisation. À des fins d'autorisation, le nom du compte est toujours celui de l'emplacement principal, même pour un accès secondaire.

En-tête Content-Length dans les versions 2014-02-14 et antérieures

Lorsque vous utilisez la version 2014-02-14 ou antérieure, si Content-Length est zéro, définissez la Content-Length partie de sur StringToSign0. Normalement, il s’agit d’une chaîne vide.

Par exemple, pour la requête suivante, la valeur de l’en-tête Content-Length est incluse dans le StringToSign même quand il est égal à zéro.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

Le StringToSign est construit comme suit :

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Alors que dans les versions postérieures à 2014-02-2014, le StringToSign doit contenir une chaîne vide pour Content-Length:

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Service de table (autorisation par clé partagée)

Vous devez utiliser l’autorisation de clé partagée pour autoriser une requête adressée au service Table si votre service utilise l’API REST pour effectuer la demande. Le format de la chaîne de signature pour Shared Key auprès du service de Table est identique pour toutes les versions.

La chaîne de signature de clé partagée pour une requête auprès du service Table diffère légèrement de celle d’une requête sur le service Blob ou File d’attente, en ce qu’elle n’inclut pas la CanonicalizedHeaders partie de la chaîne. En outre, l'en-tête Date n'est jamais vide même si la demande définit l'en-tête x-ms-date. Si la demande définit x-ms-date, cette valeur est également utilisée pour la valeur de l'en-tête Date.

Pour encoder la chaîne de signature pour une demande du service de Table effectuée à l'aide de l'API REST, utilisez le format suivant :

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;

Notes

À partir de la version du 19/09/2009, le service de Table requiert que tous les appels REST comprennent les en-têtes DataServiceVersion et MaxDataServiceVersion. Pour plus d’informations, consultez Définition des en-têtes de version du service de données OData .

Services d’objets blob, de file d’attente et de fichiers (autorisation De clé partagée Lite)

Vous pouvez utiliser l’autorisation Shared Key Lite pour autoriser une requête effectuée sur la version 2009-09-19 et ultérieure des services Blob et File d’attente, et la version 2014-02-14 et ultérieure des services de fichiers.

La chaîne de signature pour Shared Key Lite est identique à la chaîne de signature requise pour l’autorisation de clé partagée dans les versions des services Blob et File d’attente antérieures à 2009-09-19. Par conséquent, si vous souhaitez migrer votre code avec le moins de modifications apportées à la version 2009-09-19 des services Blob et File d’attente, vous pouvez modifier votre code pour utiliser Shared Key Lite, sans modifier la chaîne de signature elle-même. En utilisant Shared Key Lite, vous n’obtiendrez pas la fonctionnalité de sécurité renforcée fournie par l’utilisation de la clé partagée avec la version 2009-09-19 et ultérieure.

Pour encoder la chaîne de signature pour une demande effectuée auprès du service BLOB ou de File d'attente, utilisez le format suivant :

StringToSign = VERB + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

L’exemple suivant montre une chaîne de signature pour une opération Put Blob . Notez que la ligne d'en-tête Content-MD5 est vide. Les en-têtes affichés dans la chaîne sont des paires nom-valeur qui spécifient les valeurs personnalisées de métadonnées du nouvel objet blob.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

Ensuite, encodez cette chaîne à l'aide de l'algorithme HMAC-SHA256 dans la chaîne de signature encodée en UTF-8, construisez l'en-tête Authorization, et ajoutez l'en-tête à la demande. L'exemple suivant montre l'en-tête Authorization pour la même opération :

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Service de table (autorisation Shared Key Lite)

Vous pouvez utiliser l’autorisation Shared Key Lite pour autoriser une demande effectuée sur n’importe quelle version du service Table.

Pour encoder la chaîne de signature pour une demande du service de Table effectuée à l'aide de Shared Key Lite, utilisez le format suivant :

StringToSign = Date + "\n"
               CanonicalizedResource

L’exemple suivant montre une chaîne de signature pour une opération Créer une table .

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

Ensuite, encodez cette chaîne à l'aide de l'algorithme HMAC-SHA256, construisez l'en-tête Authorization et ajoutez l'en-tête à la demande. L'exemple suivant montre l'en-tête Authorization pour la même opération :

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

Construction de la chaîne d’en-têtes canoniques

Pour construire la partie CanonicalizedHeaders de la chaîne de signature, procédez comme suit :

  1. Récupérez tous les en-têtes pour la ressource qui commencent par x-ms-, notamment l'en-tête x-ms-date.

  2. Convertissez chaque nom d'en-tête HTTP en minuscule.

  3. Triez les en-têtes de façon lexicographique par nom d'en-tête, en ordre croissant. Chaque en-tête ne peut apparaître qu’une seule fois dans la chaîne.

    Notes

    L’ordre lexicographique peut ne pas toujours coïncider avec l’ordre alphabétique conventionnel.

  4. Remplacez tout espace blanc linéaire dans la valeur d’en-tête par un espace unique.

Les espaces blancs linéaires incluent le retour chariot/saut de ligne (CRLF), les espaces et les onglets. Pour plus d’informations , voir RFC 2616, section 4.2 . Ne remplacez aucun espace blanc à l’intérieur d’une chaîne entre guillemets.

  1. Supprimez tout espace blanc autour du signe deux-points dans l’en-tête.

  2. Enfin, ajoutez un caractère de nouvelle ligne à chaque en-tête au format canonique dans la liste résultante. Construisez la chaîne CanonicalizedHeaders en concaténant tous les en-têtes de cette liste en une chaîne unique.

L'exemple suivant illustre une chaîne d'en-tête au format canonique :

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

Notes

Avant la version de service 2016-05-31, les en-têtes avec des valeurs vides étaient omis de la chaîne de signature. Celles-ci sont désormais représentées dans CanonicalizedHeaders en suivant immédiatement le caractère deux-points avec la nouvelle ligne de fin.

Construction de la chaîne de ressource canonique

La partie CanonicalizedResource de la chaîne de signature représente la ressource de services de stockage ciblée par la demande. N'importe quelle partie de la chaîne CanonicalizedResource qui est dérivée de l'URI de la ressource doit être encodée exactement comme dans l'URI.

Il existe deux formats pris en charge pour la chaîne CanonicalizedResource :

  • Format qui prend en charge l’autorisation de clé partagée pour les versions 2009-09-19 et ultérieures des services Blob et File d’attente, et pour les versions 2014-02-14 et ultérieures du service De fichiers.

  • Un format qui prend en charge Shared Key et Shared Key Lite pour toutes les versions du service Table, et Shared Key Lite pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente. Ce format est le même que celui utilisé avec les versions précédentes des services de stockage.

Pour obtenir de l'aide sur la construction de l'URI pour la ressource à laquelle vous accédez, consultez l'une des rubriques suivantes :

Important

Si votre compte de stockage est répliqué à l'aide d'une géo-réplication avec accès en lecture (RA-GRS), et si vous accédez à une ressource dans l'emplacement secondaire, n'incluez pas la désignation –secondary dans la chaîne CanonicalizedResource. L'URI de ressource utilisé dans l'URI de chaîne CanonicalizedResource doit être l'URI de la ressource à l'emplacement principal.

Notes

Si vous autorisez l’émulateur de stockage, le nom du compte apparaît deux fois dans la CanonicalizedResource chaîne. Ceci est normal. Si vous autorisez les services de stockage Azure, le nom du compte n’apparaîtra qu’une seule fois dans la CanonicalizedResource chaîne.

Format de clé partagée pour 2009-09-19 et versions ultérieures

Ce format prend en charge l’autorisation de clé partagée pour la version 2009-09-19 et les versions ultérieures des services Blob et File d’attente, ainsi que la version 2014-02-14 et ultérieure des services de fichiers. Construisez la chaîne CanonicalizedResource dans ce format comme suit :

  1. En commençant avec une chaîne vide (""), ajoutez une barre oblique (/), suivie du nom du compte propriétaire de la ressource à laquelle vous accédez.

  2. Ajoutez le chemin URI encodé de la ressource, sans aucun paramètre de requête.

  3. Récupérez tous les paramètres de requête de l'URI de ressource, notamment le paramètre comp s'il existe.

  4. Convertissez tous les noms de paramètre en minuscule.

  5. Triez les paramètres de requête de façon lexicographique par nom de paramètre, en ordre croissant.

  6. Décodez par URL chaque nom et valeur de paramètre de requête.

  7. Incluez un caractère de nouvelle ligne (\n) avant chaque paire nom-valeur.

  8. Ajoutez chaque nom et valeur de paramètre de requête à la chaîne dans le format suivant, en veillant à inclure les deux-points (:) entre le nom et la valeur :

    parameter-name:parameter-value

  9. Si un paramètre de requête a plusieurs valeurs, triez toutes les valeurs par ordre lexicographique, puis incluez-les dans une liste séparée par des virgules :

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

Gardez à l'esprit les règles suivantes pour construire la chaîne de ressource rendue canonique :

  • Évitez d'utiliser le caractère de nouvelle ligne (\n) dans les valeurs pour les paramètres de requête. S'il doit être utilisé, vérifiez qu'il n'affecte pas le format de la chaîne de ressource rendue canonique.

  • Évitez d'utiliser des virgules dans les valeurs de paramètre de requête.

Voici quelques exemples qui montrent la CanonicalizedResource partie de la chaîne de signature, car elle peut être construite à partir d’un URI de requête donné :

Get Container Metadata  
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:metadata\nrestype:container  
  
List Blobs operation:  
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs  
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

Format de service de clé partagée Lite et de table pour 2009-09-19 et versions ultérieures

Ce format prend en charge Shared Key et Shared Key Lite pour toutes les versions du service Table, et Shared Key Lite pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, et pour les versions 2014-02-14 et ultérieures du service Fichier. Ce format est le même que celui utilisé avec les versions précédentes des services de stockage. Construisez la chaîne CanonicalizedResource dans ce format comme suit :

  1. En commençant avec une chaîne vide (""), ajoutez une barre oblique (/), suivie du nom du compte propriétaire de la ressource à laquelle vous accédez.

  2. Ajoutez le chemin URI encodé de la ressource. Si l'URI de demande adresse un composant de la ressource, ajoutez la chaîne de requête appropriée. La chaîne de requête doit inclure le point d'interrogation et le paramètre comp (par exemple, ?comp=metadata). Aucun autre paramètre ne doit être inclus dans la chaîne de requête.

Encodage de la signature

Pour encoder la signature, appelez l'algorithme HMAC-SHA256 dans la chaîne de signature encodée en UTF-8 et encodez le résultat en Base64. Notez que vous devez également décoder la clé de votre compte de stockage en base64. Utilisez le format suivant (affiché comme pseudocode) :

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))

Voir aussi