Créer des signatures d’accès partagé

  • 5 minutes

Une signature d’accès partagé (SAP) est un URI (Uniform Resource Identifier) qui accorde des droits d’accès restreints aux ressources stockage Azure. Une signature SAS est un moyen sécurisé de partager vos ressources de stockage sans compromettre vos clés de compte.

Vous pouvez fournir une signature SAS aux clients qui ne doivent pas avoir accès à votre clé de compte de stockage. Quand vous distribuez un URI SAS à ces clients, vous leur accordez l’accès à une ressource pour une période spécifiée. Vous utilisez normalement une signature SAS pour un service dans lequel les utilisateurs lisent et écrivent leurs données dans votre compte de stockage.

  • Une signature d’accès partagé (SAS) de délégation utilisateur est sécurisée avec les informations d’identification Microsoft Entra, ainsi que les autorisations spécifiées pour la SAS. Une SAS de délégation utilisateur est prise en charge pour Stockage Blob et Data Lake Storage,

  • SAP au niveau du compte pour autoriser l’accès à tout ce qu’une SAP au niveau du service peut autoriser, ainsi que d’autres ressources et capacités. Par exemple, vous pouvez utiliser une signature SAS au niveau du compte pour autoriser la création de systèmes de fichiers.

  • SAP au niveau du service pour autoriser l’accès à des ressources spécifiques dans un compte de stockage. Vous utilisez par exemple ce type de signature SAS pour permettre à une application de récupérer la liste des fichiers d’un système de fichiers ou pour télécharger un fichier.

  • Une stratégie d’accès stockée peut fournir un autre niveau de contrôle lorsque vous utilisez une SAP au niveau du service côté serveur. Vous pouvez regrouper des signatures SAS et fournir d’autres restrictions à l’aide d’une stratégie d’accès stockée.

Recommandations concernant la gestion des risques

Examinons quelques recommandations permettant d’atténuer les risques lors de l’utilisation d’une signature SAS.

Recommandation Descriptif
Toujours utiliser le protocole HTTPS pour la création et la distribution Si une signature SAS est transmise via le protocole HTTP et interceptée, un attaquant risque de l’intercepter et de l’utiliser. Ces attaques de l’intercepteur peuvent compromettre des données sensibles ou permettre à l’utilisateur malveillant d’altérer les données.
Référencez si possible les stratégies d'accès stockées Les stratégies d’accès stockées vous donnent la possibilité de révoquer les autorisations sans avoir à régénérer les clés de compte de stockage Azure. Définissez une date d’expiration éloignée dans le futur pour la clé du compte de stockage.
Définir des délais d’expiration à court terme pour une signature SAS non planifiée Si une signature SAS est compromise, vous pouvez atténuer les attaques en limitant la validité de la signature SAS à une période courte. Cette pratique est 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.
Demander aux clients de renouveler automatiquement la signature SAS Demandez aux clients de renouveler la signature SAS bien avant la date d’expiration. En la renouvelant de manière anticipée, vous leur laissez le temps de réessayer si le service fournissant la signature SAS n’est pas disponible.
Planifier soigneusement la date de début de la signature SAS Si vous définissez la date de début d’une signature SAS sur l’heure actuelle, des défaillances peuvent être observées par intermittence pendant les premières minutes en raison des variations d’horloge (différences de l’heure actuelle sur différentes machines). En règle générale, définissez une heure de début située au moins 15 minutes dans le passé. Vous pouvez également ne définir aucune heure de début spécifique, ce qui entraîne la validité immédiate de la signature SAS dans tous les cas. Les mêmes conditions s’appliquent généralement à l’heure d’expiration. Vous pouvez observer jusqu’à 15 minutes de variation d’horloge (dans un sens ou dans l’autre) sur une demande. Pour les clients qui utilisent une version d’API REST antérieure à 2012-02-12, la durée maximale pour une signature SAS qui ne référence pas une stratégie d’accès stockée est d’une heure. Toutes les stratégies spécifiant une période plus longue échouent.
Définissez les autorisations d’accès minimales pour les ressources Une bonne pratique en matière de sécurité consiste à fournir à l’utilisateur les privilèges minimaux requis. Si un utilisateur a besoin d'un accès en lecture à une seule entité, accordez-lui un accès en lecture à cette seule entité, plutôt qu'un accès en lecture/écriture/suppression à toutes les entités. Cette pratique permet également de limiter les dégâts si une signature SAS est compromise, car son pouvoir est moindre si elle tombe entre les mains d’un attaquant.
Valider les données écrites avec une signature SAS Quand une application cliente écrit des données dans votre compte de stockage Azure, n’oubliez pas que ces données peuvent être une source de problèmes. Si votre application nécessite des données validées ou autorisées, validez les données après leur écriture, mais avant leur utilisation. 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.
Ne pas partir du principe qu’une signature SAS est toujours la meilleure option Dans certains scénarios, les risques associés à une opération particulière sur votre compte de stockage Azure sont plus importants que les avantages de l’utilisation d’une signature SAS. 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. Il est également parfois plus simple de gérer l’accès par d’autres moyens. Si vous souhaitez que l’ensemble des objets blob dans un conteneur soient lisibles publiquement, vous pouvez rendre le conteneur public, au lieu de fournir une signature SAS d’accès à chaque client.