Qu’est-ce qu’une URL signée ?

Une URL signée contient une preuve cryptographique qu’une partie autorisée a accordé l’accès à une ressource ou à une transformation. Sa signature couvre généralement une date d’expiration ainsi que le chemin ou les paramètres de requête propres à la demande.

Un signataire détenant une clé construit une chaîne à partir des éléments de la requête qu’il souhaite autoriser, généralement le chemin, certains paramètres de requête et une date d’expiration, calcule une signature sur cette chaîne et l’ajoute à l’URL. Le service vérifie la signature et la date d’expiration avant de servir quoi que ce soit. Deux modèles de clés sont courants. Avec un HMAC, le signataire et le service détiennent le même secret ; Google Cloud CDN et le Smart CDN de Transloadit fonctionnent ainsi. Avec une paire de clés, le signataire conserve une clé privée et le service n’a besoin que de la clé publique ; Amazon CloudFront vérifie les signatures RSA ou ECDSA à l’aide des clés publiques d’un groupe de clés de confiance. Dans les deux cas, il s’agit d’une autorisation déléguée, pas de chiffrement. AWS décrit les URL présignées comme des jetons porteurs, et Google précise que toute personne en possession d’une URL signée peut l’utiliser tant qu’elle est active. Une URL présignée correspond au cas du stockage d’objets : Amazon S3 utilise ce nom pour une URL qui porte les informations d’identification de son créateur pour un bucket, une clé d’objet et une méthode HTTP, par exemple un téléchargement via GET ou un téléversement via PUT, tandis que Google Cloud Storage appelle son équivalent une URL signée.

Peut-on ajouter ou modifier un paramètre de requête après la signature ? Seulement si le mécanisme l’exclut de la signature ou si la politique signée le permet. CloudFront renvoie HTTP 403 lorsqu’une chaîne de requête est ajoutée à une URL signée après la signature. Une politique personnalisée CloudFront peut élargir cette possibilité : son URL Resource peut contenir des caractères génériques, CloudFront compare l’URL demandée à ce motif, et un astérisque final dans le chemin correspond aussi à la chaîne de requête. imgix renvoie 403 lorsque le chemin ou les paramètres changent après la définition de son paramètre s. Les mécanismes qui signent une requête canonique sont également sensibles à la façon dont la requête est effectuée : les signatures S3 et Google Cloud Storage V4 couvrent la méthode HTTP, le chemin, la chaîne de requête triée et l’en-tête host. Une URL signée pour une méthode ou un nom d’hôte ne passe donc pas la validation pour un autre. Google Cloud CDN fait délibérément exception lorsque vous signez URLPrefix plutôt que l’URL complète : les paramètres de requête ne sont alors pas signés et peuvent être inclus librement, et une signature est valable pour chaque URL commençant par le préfixe.
Pourquoi une URL présignée cesserait-elle de fonctionner avant la date d’expiration définie ? Généralement parce que les informations d’identification sur lesquelles elle repose ont expiré en premier. AWS précise qu’une URL présignée S3 expire à la date configurée ou lorsque les informations d’identification qui l’ont créée expirent, selon ce qui survient en premier. Une URL signée avec des informations d’identification temporaires de rôle cesse donc de fonctionner à la fin de la session du rôle, même si une durée de validité plus longue a été demandée. De même, les URL signées Google Cloud Storage cessent de fonctionner lorsque la clé utilisée pour les signer est remplacée lors d’une rotation. AWS cite également la dérive de l’horloge de la machine de signature et les proxys qui modifient les en-têtes ou les chaînes de requête comme causes de non-concordance des signatures. Signez avec des informations d’identification dont la validité dépasse celle de l’URL, ou émettez des URL dont la durée de validité est plus courte que celle de la session.
Que se passe-t-il pour un téléchargement ou une lecture encore en cours à l’expiration ? L’expiration est vérifiée à l’arrivée de chaque requête HTTP, pas pendant l’envoi d’une réponse. S3 et CloudFront indiquent tous deux qu’un téléchargement commencé juste avant l’expiration se poursuit, et qu’une reconnexion du client après l’expiration échoue. Sur CloudFront, toute requête GET avec Range émise après l’expiration échoue également. Un lecteur qui récupère un gros fichier par plages, ou un gestionnaire de téléchargement qui reprend un transfert, a donc besoin d’une durée de validité couvrant toute la session ou d’un moyen d’obtenir une nouvelle URL.
Exiger des URL signées au niveau du CDN protège-t-il l’origine, et les réponses signées sont-elles toujours mises en cache ? Le CDN vérifie la signature ; l’origine est un point d’entrée distinct. AWS recommande, sans l’exiger, de restreindre un bucket S3 afin qu’il ne puisse être lu que via CloudFront. Google avertit que Cloud CDN ne bloque pas les requêtes sans signature : une origine Cloud Storage placée derrière ce CDN ne doit donc pas être publique. Concernant la mise en cache, CloudFront et Google Cloud CDN retirent les paramètres de signature avant de transmettre une requête à l’origine. Google valide d’abord la signature, puis sert la réponse depuis le cache, en stockant séparément les réponses aux requêtes signées et non signées. Cette séparation ne supprime pas ce qui a été mis en cache lorsque le contenu était public : Cloud CDN sert une requête non signée depuis le cache si la réponse s’y trouve. Après avoir fermé l’accès public à l’origine, invalidez donc les réponses précédemment mises en cache ou attendez leur expiration. Certains services lient la durée de vie du cache à l’expiration : imgix remplace Cache-Control par le temps restant jusqu’à expires.

Utilisez des URL signées pour donner à un navigateur, un lecteur ou un partenaire un accès limité dans le temps à des médias privés, sans communiquer les informations d’identification du stockage ni rendre l’origine publique. Une URL signée autorise quiconque la détient, pas un utilisateur particulier. Choisissez donc une durée de validité que vous accepteriez pour un lien transféré à un tiers, et ajoutez une autre vérification lorsque l’accès doit rester lié à une seule personne.

Le Smart CDN de Transloadit accepte les URL signées. Votre back-end ajoute un horodatage exp en millisecondes et auth_key, trie les paramètres de requête, calcule un HMAC-SHA256 avec l’Auth Secret sur le Workspace, le nom du Template, le chemin du fichier et les paramètres triés, puis ajoute le résultat sous la forme sig. Comme les paramètres de transformation font partie de la chaîne signée, une URL signée ne peut pas être modifiée pour demander une variante différente. L’expiration limite également la durée pendant laquelle une réponse signée peut être mise en cache. Une durée plus courte pour exp restreint donc davantage l’accès et réduit la réutilisation du cache. Pour les fichiers exportés vers votre propre bucket, le Robot /s3/store peut renvoyer des URL signées via son paramètre sign_urls_for.

L’Auth Key utilisée pour la signature doit être activée pour le Smart CDN, et la signature doit être effectuée sur votre back-end, car elle nécessite l’Auth Secret. La documentation indique que exp est facultatif et recommande de toujours le définir. Les pages liées décrivent comment signer une URL, mais pas comment une requête non signée vers le même Template est traitée, ni si une requête par plage arrivant après exp est refusée. Testez donc ces deux cas sur votre propre Workspace avant de considérer la signature comme un contrôle d’accès ou de choisir une durée de validité plus courte qu’une session de lecture.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce qu’une URL signée ?

Fonctionnement des URL signées

Points clés

Quand les URL signées sont utiles

Comment Transloadit vous aide à utiliser les URL signées

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle