Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAP)

Article
06/07/2023

Une signature d’accès partagé (SAS) fournit un accès délégué sécurisé aux ressources de votre compte de stockage. Avec une SAP, vous avez un contrôle granulaire sur la manière dont un client peut accéder à vos données. Par exemple :

Les ressources auxquelles le client peut accéder.
Les autorisations dont les clients disposent pour ces ressources.
Durée de validité de la signature d’accès partagé.

Types de signatures d’accès partagé

Le service Stockage Azure prend en charge trois types de signatures d’accès partagé :

SAP de délégation d’utilisateur
SAP de service
SAP de compte

Important

Pour les scénarios où les signatures d’accès partagé sont utilisées, Microsoft recommande d’utiliser une SAP de délégation d’utilisateur. Une SAP de délégation d’utilisateur est sécurisée avec les informations d’identification Microsoft Entra au lieu de la clé de compte, ce qui offre une sécurité supérieure. Pour plus d’informations sur l’autorisation d’accès aux données, consultez Autoriser l’accès aux données dans Stockage Azure.

SAP de délégation d’utilisateur

Une SAP de délégation d’utilisateur est sécurisée avec les informations d’identification Microsoft Entra ainsi que par les autorisations spécifiées pour la SAP. Une SAP de délégation d’utilisateur s’applique uniquement au stockage d’objets Blob.

Pour plus d’informations sur la SAP de délégation d’utilisateur, consultez Créer une SAP de délégation d’utilisateur (API REST).

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une SAP de service délègue l’accès à une ressource d’un seul des services de stockage Azure : Stockage Blob, Stockage File d'attente, Stockage Table ou Azure Files.

Pour plus d’informations sur la SAP de service, consultez Créer une SAP de service (API REST).

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Vous pouvez également déléguer l’accès aux éléments suivants :

Les opérations de niveau de service (par exemple, les opérations Get/Set Service Properties et Get Service Stats).
Les opérations de lecture, d’écriture et de suppression qui ne sont pas autorisées avec une SAS de service.

Pour plus d’informations sur la SAP de compte, Créez une SAP de compte (API REST).

Une signature d’accès partagé peut prendre l’une des deux formes suivantes :

SAS ad hoc. Quand vous créez une SAS ad hoc, l’heure de début, l’heure d’expiration et les autorisations sont spécifiées sur l’URI de la SAS. Tout type de SAP peut être une SAP ad hoc.
SAS de service avec stratégie d’accès stockée. une stratégie d’accès stockée est définie sur un conteneur de ressources, qui peut être un conteneur d’objets blob, une table, une file d’attente ou un partage de fichiers. La stratégie d'accès stockée et permet de gérer les contraintes d’une ou de plusieurs signatures d’accès partagé de service. Lorsque vous associez une signature d’accès partagé de service à une stratégie d’accès stockée, la signature hérite des contraintes (heure de début, heure d’expiration et autorisations) définies pour la stratégie.

Notes

Une SAP de délégation d’utilisateur ou de compte doit être une SAP ad hoc. Les stratégies d’accès stockées ne sont pas prises en charge pour les SAP de délégation d’utilisateur ou les SAP de compte.

Fonctionnement d’une signature d’accès partagé

Une signature d’accès partagé est un jeton ajouté à l’URI d’une ressource Stockage Azure. Jeton qui contient un ensemble spécial de paramètres de requête qui indiquent comment le client peut accéder aux ressources. L’un des paramètres de requête, la signature, est construit à partir des paramètres de signature d’accès partagé et signé avec la clé utilisée pour créer la SAP. Cette signature est utilisée par le stockage Azure pour autoriser l’accès à la ressource de stockage.

Notes

Il n’est pas possible d’auditer la génération de jetons SAP. Tout utilisateur autorisé à générer un jeton SAS (avec la clé de compte ou au moyen d’une attribution de rôle Azure) peut le faire sans avoir connaissance du propriétaire du compte de stockage. Veillez à limiter les autorisations qui permettent aux utilisateurs de générer des jetons SAP. Pour empêcher les utilisateurs de générer un jeton SAP signée avec la clé de compte pour les charges de travail d’objets blob et de file d’attente, vous pouvez interdire l’accès avec une clé partagée au compte de stockage. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Signature SAP et autorisation

Vous pouvez signer un jeton SAS à l’aide d’une clé de délégation d’utilisateur ou d’une clé de compte de stockage (clé partagée).

Signature d’un jeton SAS avec une clé de délégation d’utilisateur

Vous pouvez signer un jeton avec une clé de délégation d’utilisateur créée à l’aide des informations d’identification de Microsoft Entra. Une SAP de délégation d’utilisateur est signée avec la clé de délégation d’utilisateur.

Pour accéder à la clé, puis créer la SAP, un rôle Azure qui comprend l’action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey doit être attribué à un principal de sécurité Microsoft Entra. Pour en savoir plus, consultez Créer une SAS de délégation d’utilisateur (API REST).

Signature d’un jeton SAS à l’aide d’une clé de compte

Une SAP de service et une SAP de compte sont signées avec la clé du compte de stockage. Pour créer une SAP signée avec la clé de compte, une application doit avoir accès à la clé de compte.

Lorsqu’une requête comprend un jeton SAP, cette requête est autorisée en fonction de la façon dont le jeton SAP est signé. La clé d’accès ou les informations d’identification que vous utilisez pour créer un jeton SAP sont également utilisées par Stockage Azure pour accorder l’accès à un client qui possède la signature d’accès partagé.

Le tableau suivant résume la façon dont chaque type de jeton SAS est autorisé.

Type de SAP	Type d’autorisation
SAP de délégation d’utilisateur (Stockage Blob uniquement)	Microsoft Entra ID
SAP de service	Clé partagée
SAP de compte	Clé partagée

Microsoft recommande d’utiliser une SAP de délégation d’utilisateur dans la mesure du possible pour une plus grande sécurité.

Jeton SAS

Le jeton SAS est une chaîne que vous générez côté client, par exemple à l’aide de l’une des bibliothèques clientes de stockage Azure. Le jeton SAS n’est pas suivi par le stockage Azure de quelque manière que ce soit. Vous pouvez créer un nombre illimité de jetons de SAP côté client. Après avoir créé une SAP, vous pouvez la distribuer aux applications clientes qui requièrent l’accès aux ressources de votre compte de stockage.

Les applications clientes fournissent l’URI SAS au Stockage Azure dans le cadre d’une demande. Ensuite, le service vérifie que les paramètres SAS et la signature sont valides. Si le service vérifie que la signature est valide, la demande est autorisée. Dans le cas contraire, la demande est refusée avec le code d’erreur 403 (Interdit).

Voici un exemple d’URI SAP de service, montrant l’URI de la ressource, le caractère délimiteur ('?') et le jeton SAP.

Diagramme montrant les composants d’une ressource URI avec un jeton SAS.

Notes

Le caractère délimiteur ('?') de la chaîne de requête ne fait pas partie du jeton SAP. Si vous générez un jeton SAP à partir du portail, de PowerShell, d’Azure CLI ou de l’un des SDK Stockage Azure, vous devrez peut-être ajouter le caractère délimiteur à l’URL de ressource.

Quand utiliser une signature d’accès partagé

Utilisez une SAS pour fournir un accès sécurisé aux ressources de votre compte de stockage à tout client qui n’a normalement pas d’autorisations pour ces ressources.

Un service où les utilisateurs lisent et écrivent leurs propres données dans votre compte de stockage correspond à un scénario courant dans lequel une signature d'accès partagé peut s'avérer utile. Dans un scénario où un compte de stockage stocke les données utilisateur, il existe deux modèles de conception types :

Les clients chargent et téléchargent les données par le biais d’un service proxy frontal, qui se charge de l’authentification. Ce service de proxy front-end autorise la validation des règles d’entreprise. Mais pour de grosses quantités de données ou des transactions à haut volume, la création d'un service qui peut être mis à l’échelle en fonction de la demande peut se révéler coûteuse ou difficile.
Un service léger authentifie le client en fonction des besoins, puis génère une signature d’accès partagé. Une fois que l’application cliente reçoit la SAS, elle peut accéder directement aux ressources du compte de stockage. Les autorisations d’accès sont définies par la SAS et pendant l’intervalle autorisé par la SAS. La signature d'accès partagé atténue la nécessité du routage de toutes les données via le service proxy frontal.

De nombreux services réels peuvent utiliser un mélange de ces deux approches. Par exemple, certaines données peuvent être traitées et validées via le proxy front-end. D’autres données sont enregistrées et/ou lues directement à l’aide de la SAS.

En outre, une SAP est requise pour autoriser l’accès à l’objet source d’une opération de copie dans certains cas de figure :

Lorsque vous copiez un objet blob dans un autre objet blob qui réside dans un autre compte de stockage.

Vous pouvez éventuellement utiliser une SAP pour autoriser également l’accès à l’objet blob de destination.
Lorsque vous copiez un fichier dans un autre fichier qui réside dans un autre compte de stockage.

Vous pouvez éventuellement utiliser une SAP pour autoriser également l’accès au fichier de destination.
Lorsque vous copiez un objet blob dans un fichier ou un fichier dans un objet blob.

Vous devez utiliser une signature d’accès partagé même si les objets source et de destination résident dans le même compte de stockage.

Bonnes pratiques lors de l’utilisation de SAP

Lorsque vous utilisez des signatures d'accès partagé dans vos applications, vous devez être conscient de deux risques potentiels :

Si une signature d'accès partagé est divulguée, toute personne qui se la procure peut s'en servir et votre compte de stockage court donc le risque d'être compromis.
Si une signature d'accès partagé fournie à une application cliente expire et que l'application est incapable d'en récupérer une nouvelle à partir de votre service, la fonctionnalité de votre application risque d'être entravée.

Les recommandations suivantes relatives à l’utilisation des signatures d’accès partagé peuvent aider à limiter ces risques :

Utilisez toujours HTTPS pour créer ou distribuer une signature d’accès partagé. Si une signature d’accès partagé est transmise sur HTTP et interceptée, une personne malveillante effectuant une attaque de type « man-in-the-middle » peut la lire. Cette personne peut ensuite utiliser cette SAS comme l’aurait fait l’utilisateur prévu. Cela peut compromettre des données sensibles ou permettre la corruption des données par l’utilisateur malveillant.
Utilisez une SAS de délégation d’utilisateur lorsque c’est possible. Une SAP de délégation d’utilisateur offre une sécurité supérieure à une SAP de service ou à une SAP de compte. Une SAP de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra, ce qui vous permet de ne pas avoir à stocker votre clé de compte avec votre code.
Ayez un plan de révocation pour une SAP. Assurez-vous que vous êtes prêt à répondre si une SAP est compromise.
Configurez une stratégie d’expiration SAP pour le compte de stockage. Une stratégie d’expiration SAP spécifie un intervalle recommandé pour la validité de la signature d’accès partagé. Les stratégies d’expiration SAP s’appliquent à une SAP de service ou à une SAP de compte. Lorsqu’un utilisateur génère une SAP de service ou une SAP de compte dont l’intervalle de validité est supérieur à l’intervalle recommandé, un avertissement s’affiche. Si la connexion de Stockage Azure avec Azure Monitor est activée, une entrée est écrite dans les journaux de Stockage Azure. Pour en savoir plus, consultez Créer une stratégie d’expiration pour les signatures d’accès partagé
Créez une stratégie d’accès stockée pour une SAP de service. Celles-ci vous donnent la possibilité de révoquer les autorisations pour une SAP de service sans avoir à régénérer les clés de compte de stockage. Définissez une échéance très éloignée dans le temps (voire infinie) pour l’expiration de ces dernières et veillez à ce qu’elle soit régulièrement mise à jour et repoussée dans le futur. Il existe une limite de cinq stratégies d’accès stockées par conteneur.
Utilisez des heures d'expiration avec une échéance à court terme sur une SAP de service ou une SAP de compte ad hoc. De cette manière, même si une signature d’accès partagé est compromise, elle n’est valide que pendant une courte durée. Cette pratique est particulièrement importante si vous ne pouvez pas référencer une stratégie d'accès stockée. Des heures d’expiration avec une échéance à court terme permettent également de limiter la quantité de données pouvant être écrites dans un objet blob en limitant le temps disponible pour le chargement vers ce dernier.
Faites en sorte que les clients renouvellent automatiquement la signature d'accès partagé si nécessaire. Les clients doivent renouveler la signature d’accès partagé bien avant l’heure d’expiration afin de laisser suffisamment de temps pour de nouvelles tentatives, si le service qui fournit la signature est indisponible. Cela peut ne pas être nécessaire dans certains cas. Par exemple, vous voulez peut-être utiliser la SAS pour un petit nombre d’opérations immédiates de courte durée. Ces opérations sont censées être terminées pendant la période d’expiration. Par conséquent, vous n’attendez pas que la SAS soit renouvelée. Toutefois, si vous avez un client qui effectue régulièrement des demandes par le biais de signatures d’accès partagé, le risque d’expiration est à prendre en compte.
Faites attention à la date de début de la signature d’accès partagé. Si vous définissez l’heure de début d’une signature d’accès partagé sur l’heure actuelle, des échecs peuvent se produire par intermittence pendant les premières minutes. Cela est dû au fait que des machines différentes ont des heures actuelles légèrement différents (phénomène appelé décalage de l’horloge). En règle générale, définissez une heure de début située au moins 15 minutes avant l’heure courante ou ne la définissez pas du tout, et elle sera alors valide immédiatement dans tous les cas. Cela vaut également d’une manière générale pour l’heure d’expiration. Souvenez-vous que vous pouvez observer jusqu’à 15 minutes de décalage d’horloge (dans l’une ou l’autre direction) sur une demande. Pour les clients qui utilisent une version de REST antérieure à la version 2012-02-12, la durée maximale pour une signature d’accès partagé qui ne renvoie pas à une stratégie d’accès stockée est de 1 heure. Toutes les stratégies spécifiant une période plus longue échouent.
Soyez vigilant avec le format DateHeure SAP. Pour certains utilitaires (tels qu’AzCopy), les valeurs de date/heure doivent être mise en forme de la manière suivante : '+%Y-%m-%dT%H:%M:%SZ'. Ce format comprend spécifiquement les secondes.
Accordez le moins de privilèges possible avec la solution SAP. Une bonne pratique en matière de sécurité consiste à fournir à l’utilisateur les privilèges minimaux demandés, pour le plus petit nombre possible de ressources. Utilisez une SAP en lecture seule lorsque c’est possible. Si un utilisateur n’a besoin que d'un accès en lecture seul à un objet, accordez-lui cet accès à cet objet unique, plutôt qu'un accès en lecture/écriture/suppression à tous les objets. Cela permet également d’atténuer les dégâts si une signature d’accès partagé est compromise, car son pouvoir est moindre entre les mains d’une personne malveillante.

Il n’existe aucun moyen direct d’identifier les clients qui ont accédé à une ressource. Toutefois, vous pouvez utiliser les champs uniques de la SAP, les champs IP signée (sip), début signé (st) et expiration signée (se) pour effectuer le suivi de l’accès. Par exemple, vous pouvez générer un jeton SAP avec une heure d’expiration unique que vous pouvez ensuite mettre en corrélation avec le client auquel il a été émis.
Sachez que toute utilisation de votre compte sera facturée, notamment via une SAP. Si vous fournissez un accès en écriture à un objet blob, un utilisateur peut choisir de charger un objet blob de 200 Go. Si vous lui avez également accordé un accès en lecture, il peut choisir de le télécharger 10 fois, et vous devrez alors acquitter des frais de sortie pour l’équivalent de 2 To. Accordez des autorisations limitées pour atténuer les risques liés aux actions éventuelles d’utilisateurs malveillants. Utilisez des signatures d'accès partagé à durée de vie limitée pour atténuer cette menace (mais pensez au décalage d'horloge pour l'heure de fin).
Validez les données écrites avec une signature d'accès partagé. Lorsqu'une application cliente écrit des données dans votre compte de stockage, n'oubliez pas que ces données peuvent être une source de problèmes. Si vous envisagez de valider des données, effectuez cette validation une fois que les données ont été écrites et avant qu’elles soient utilisées par votre application. Cette pratique assure également une protection contre l'écriture de données endommagées ou malveillantes dans votre compte, soit par un utilisateur qui a acquis correctement la signature d'accès partagé, soit par un utilisateur qui exploite sa divulgation.
Savoir quand ne pas utiliser une SAP. Parfois, les risques associés à une opération particulière sur votre compte de stockage l'emportent sur les avantages de l’utilisation d’une signature d'accès partagé. Pour ces opérations, créez un service de niveau intermédiaire qui écrit dans votre compte de stockage après avoir effectué la validation des règles métier, l'authentification et un audit. Parfois aussi, il est plus simple de gérer l'accès par d'autres moyens. Par exemple, si vous voulez que tous les objets blob dans un conteneur soient publiquement lisibles, vous pouvez rendre le conteneur public, au lieu de fournir une signature d'accès partagé à chaque client.
Utilisez Azure Monitor et les journaux de stockage Azure pour surveiller votre application. Des échecs d’autorisation peuvent survenir en raison d’une panne dans votre service fournisseur SAS. Ils peuvent également provenir d’une suppression accidentelle d’une stratégie d’accès stockée. Vous pouvez utiliser Azure Monitor et la journalisation de l’analytique du stockage pour observer les pics dans ces types d’échecs d’autorisation. Pour plus d’informations, consultez Métriques de stockage Azure dans Azure Monitor et Journalisation Azure Storage Analytics.
Configurez une stratégie d’expiration SAP pour le compte de stockage. Les meilleures pratiques recommandent de limiter l’intervalle d’une signature d’accès partagé au cas où elle serait compromise. En définissant une stratégie d’expiration des signatures d’accès partagé (SAP) pour vos comptes de stockage, vous pouvez fournir une limite d’expiration supérieure recommandée lorsqu’un utilisateur crée un service ou un compte SAP. Pour plus d’informations, consultez Créer une stratégie d’expiration pour les signatures d’accès partagé

Notes

Stockage Azure n’assure pas le suivi du nombre de signatures d’accès partagé qui ont été générées pour un compte de stockage, et aucune API ne peut fournir ce détail. Si vous avez besoin de connaître le nombre de signatures d’accès partagé qui ont été générées pour un compte de stockage, vous devez effectuer ce suivi manuellement.

Prise en main de la SAP

Pour prendre en main les signatures d’accès partagé, consultez les articles suivants pour chaque type de SAP.

Partage via

Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAP)