Découvrir les signatures d’accès partagé
Une signature d’accès partagé (SAS) est un URI signé qui pointe vers une ou plusieurs ressources de stockage et inclut un jeton qui contient un ensemble spécial de paramètres de requête. Le jeton indique 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.
Types de signatures d’accès partagé
Le service Stockage Azure prend en charge trois types de signatures d’accès partagé :
SAS de délégation utilisateur : 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 SAP de délégation d’utilisateur s’applique uniquement au stockage d’objets Blob.
SAS de service : une signature SAS de service est sécurisée avec la clé de compte de stockage. Une signature SAS de service délègue l’accès à une ressource dans les services de stockage Azure suivants : stockage Blob, stockage File d’attente, stockage Table ou Azure Files.
SAS de compte : une signature SAS de compte est sécurisée avec 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.
Remarque
Comme meilleure pratique de sécurité, Microsoft vous recommande d’utiliser si possible les informations d’identification Microsoft Entra, plutôt que d’utiliser la clé de compte qui peut être plus facilement compromise. Lorsque la conception de votre application nécessite des signatures d’accès partagé pour pouvoir accéder au stockage Blob, utilisez les informations d’identification Microsoft Entra pour créer, si possible, une SAP de délégation d’utilisateur pour profiter d’une sécurité supérieure
Comment fonctionnent les signatures d’accès partagé
Quand vous utilisez une signature d’accès partagé pour accéder aux données stockées dans le Stockage Azure, vous avez besoin de deux composants. Le premier est un URI vers la ressource à laquelle vous souhaitez accéder. Le second est un jeton SAS que vous avez créé pour autoriser l’accès à cette ressource.
Dans un URI unique, comme https://medicalrecords.blob.core.windows.net/patient-images/patient-116139-nq8z7f.jpg?sp=r&st=2020-01-20T11:42:32Z&se=2020-01-20T19:42:32Z&spr=https&sv=2019-02-02&sr=b&sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D
, vous pouvez séparer l’URI du jeton SAS comme ceci :
- URI :
https://medicalrecords.blob.core.windows.net/patient-images/patient-116139-nq8z7f.jpg?
- Jeton SAS :
sp=r&st=2020-01-20T11:42:32Z&se=2020-01-20T19:42:32Z&spr=https&sv=2019-02-02&sr=b&sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D
Le jeton SAS est lui-même constitué de plusieurs composants.
Composant | Description |
---|---|
sp=r |
Contrôle les droits d’accès. Les valeurs peuvent être a pour ajouter, c pour créer, d pour supprimer, l pour lister, r pour lire ou w pour écrire. Cet exemple est en lecture seule. L’exemple sp=acdlrw accorde tous les droits disponibles. |
st=2020-01-20T11:42:32Z |
Date/heure du début d’accès. |
se=2020-01-20T19:42:32Z |
Date/heure de la fin d’accès. Cet exemple accorde huit heures d’accès. |
sv=2019-02-02 |
Version de l’API Stockage à utiliser. |
sr=b |
Type du stockage auquel accéder. Dans cet exemple, b est pour blob. |
sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D |
Signature de chiffrement. |
Bonnes pratiques
Dans le but de réduire les risques potentiels liés à l’utilisation d’une signature d’accès partagé, Microsoft donne quelques conseils :
- Pour distribuer de manière sécurisée une signature d’accès partagé et empêcher les attaques de type intercepteur (man-in-the-middle), choisissez toujours le protocole HTTPS.
- La signature SAS la plus sûre est une signature SAS de délégation utilisateur. Utilisez-la dans la mesure du possible parce qu’elle vous évite d’avoir à enregistrer votre clé de compte de stockage dans le code. Vous devez utiliser Microsoft Entra ID pour gérer les informations d’identification. Cette option peut ne pas être possible pour votre solution.
- Essayez de définir votre heure d’expiration à la plus petite valeur utile. Si une clé SAS devient compromise, elle peut continuer à être utilisée pendant un temp court seulement.
- Appliquez la règle du privilège minimum requis. Accordez seulement l’accès qui est strictement nécessaire. Par exemple, dans votre application, l’accès en lecture seule est suffisant.
- Dans certaines situations, l’emploi d’une signature d’accès partagé n’est pas la solution adéquate. Si l’utilisation d’une signature d’accès partagé présente un risque inacceptable, créez un service de niveau intermédiaire pour gérer les utilisateurs et leur accès au stockage.