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

Une URL présignée accorde une autorisation limitée dans le temps pour une opération de stockage précise, comme le téléchargement ou le téléversement d’un seul objet, sans communiquer au destinataire les informations d’identification secrètes du signataire. Sa signature fixe l’opération, l’objet et l’expiration.

Le back-end de l’application signe une requête avec ses informations d’identification de stockage

URL présignée remise au client

Le service de stockage vérifie la signature et l’expiration, puis sert ou accepte l’objet

L’application signe la requête ; le client communique ensuite directement avec le service de stockage.

Un service de présignature calcule une signature pour une requête de stockage à l’aide des informations d’identification qu’il détient, puis place les éléments d’autorisation obtenus dans la chaîne de requête de l’URL. Le service de stockage recalcule la signature lorsque l’URL est utilisée et vérifie la méthode, l’objet, les en-têtes signés et l’expiration. Le secret n’a donc jamais besoin de parvenir au navigateur ou au client de téléchargement. La requête s’exécute avec les droits du signataire : Amazon S3 précise qu’une URL présignée utilise les informations d’identification de l’identité qui l’a générée et est limitée par les autorisations de cette identité. Amazon S3 parle d’URL présignées, Google Cloud Storage d’URL signées, et l’équivalent dans Azure Storage est la Shared Access Signature (SAS). Les détails propres au stockage présentés dans cet article proviennent de la documentation de ces trois services ; pour un service compatible S3 proposé par un autre fournisseur, consultez la documentation de ce fournisseur. Une URL signée de CDN est un mécanisme différent : le CDN la vérifie à l’aide de clés configurées sur le CDN, et le service de stockage ne participe pas à cette vérification. Dans une architecture de diffusion, une URL présignée crée un chemin direct et temporaire entre un client et le stockage d’objets, tandis que l’application décide à qui en fournir une.

Qui peut utiliser une URL présignée ? Toute personne qui détient l’URL complète, jusqu’à ce qu’elle cesse d’être valide. 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, avec ou sans compte. Une URL présignée S3 peut être utilisée plusieurs fois jusqu’à son expiration. Pour mettre fin à l’accès plus tôt, une possibilité consiste à invalider les éléments qui ont servi à signer l’URL, ce qui invalide toutes les URL signées avec ces éléments : une URL S3 cesse de fonctionner lorsque les informations d’identification utilisées pour la signature sont révoquées, supprimées ou désactivées, et une URL signée Google lorsque la clé de signature fait l’objet d’une rotation. Les autres contrôles dépendent du service. Une URL présignée S3 est limitée par les autorisations de son signataire, et AWS cite une politique de bucket qui refuse explicitement l’accès à l’objet parmi les causes d’une réponse 403 Forbidden à une URL présignée. Un tel refus bloque donc les requêtes relevant de cette politique sans invalider les informations d’identification. Azure recommande d’associer une SAS de service à une politique d’accès stockée afin de pouvoir la révoquer sans régénérer les clés du compte.
Pourquoi une URL présignée cesserait-elle de fonctionner avant l’expiration annoncée ? Parce qu’elle n’est valide que tant que les informations d’identification utilisées pour la signer le sont. AWS indique qu’une URL S3 signée avec des informations d’identification temporaires, comme celles d’un rôle endossé ou d’un rôle d’instance ou de conteneur, expire en même temps que ces informations, même si une expiration ultérieure a été demandée. Les requêtes échouent alors avec ExpiredToken. Vérifiez la durée de validité des informations d’identification de signature avant de promettre une durée de validité pour un lien : AWS permet de régler la durée maximale de session d’un rôle IAM endossé via sa console, sa CLI ou son API entre 1 et 12 heures (1 heure si aucune valeur n’est définie) et indique que les informations d’identification des rôles d’instance et de conteneur durent généralement jusqu’à environ 6 heures. En revanche, les informations d’identification d’un utilisateur IAM peuvent signer une URL S3 valide jusqu’à 7 jours avec Signature Version 4. Les solutions proposées par AWS consistent à renouveler les informations d’identification et à générer une nouvelle URL ou, lorsque cela convient, à signer avec des informations d’identification valides plus longtemps. S3 vérifie l’expiration au début d’une requête : un téléchargement commencé avant l’échéance continue, mais une requête qui redémarre après l’échéance échoue.
Pourquoi une URL non expirée échoue-t-elle avec une erreur de signature ? La requête ne correspond plus à ce qui a été signé. Pour S3, la méthode HTTP, les en-têtes signés et la chaîne de requête doivent correspondre exactement entre la génération de l’URL et son utilisation. Une URL S3 signée avec Signature Version 4 énumère ses en-têtes signés dans X-Amz-SignedHeaders, et AWS exige que l’en-tête host ainsi que tous les en-têtes x-amz-* envoyés avec la requête en fassent partie. AWS cite un type de contenu différent de celui indiqué lors de la signature parmi les causes de SignatureDoesNotMatch, ainsi qu’une URL modifiée, une région incorrecte, un décalage de l’horloge de la machine de signature et des proxys qui modifient les en-têtes ou les chaînes de requête. Les URL signées de Google indiquent dans X-Goog-SignedHeaders les en-têtes qu’une requête doit inclure.
Pourquoi une URL présignée valide échoue-t-elle depuis du JavaScript exécuté dans un navigateur ? L’autorisation de stockage et CORS sont deux vérifications distinctes. La configuration CORS du bucket doit autoriser l’origine de la page, la méthode HTTP et les en-têtes de requête ; Amazon S3 précise que les ACL et les politiques continuent de s’appliquer lorsque CORS est activé. Lorsque la configuration n’autorise pas une requête, le navigateur s’arrête après l’échec de la requête préliminaire, avant d’envoyer la requête réelle. Pour une requête ne nécessitant pas de requête préliminaire (ce qui peut être le cas d’un POST avec un type de contenu de formulaire), il l’envoie mais ne transmet pas la réponse au script. Une erreur CORS seule ne prouve donc pas qu’aucun téléversement n’a eu lieu. Puisque CORS restreint les requêtes entre origines effectuées par des scripts dans un navigateur, la même URL peut fonctionner depuis un client côté serveur et échouer depuis une page web.
Une URL présignée de téléversement limite-t-elle ce qui est téléversé ? Uniquement les éléments qui ont été signés. Une URL présignée S3 pour un téléversement est créée à partir d’un bucket, d’une clé d’objet, d’une méthode HTTP et d’une expiration. Un téléversement vers une clé existante remplace l’objet. Azure avertit qu’un client disposant d’un accès en écriture peut téléverser un blob très volumineux (son exemple est de 200 GB) et recommande de valider les données après leur écriture et avant leur utilisation. Lorsque le service de stockage doit imposer une limite de taille, les téléversements POST par formulaire sont l’outil documenté : le document de politique signé accepte une condition content-length-range dans Google Cloud Storage et dans Amazon S3, et le SDK AWS pour Python crée un tel formulaire signé avec generate_presigned_post. La limite propre au service de stockage pour une requête unique s’applique toujours : un téléversement via une URL présignée S3 est un PUT, Amazon S3 indique un maximum de 5 GB pour un PUT unique, et les objets plus volumineux passent par un téléversement en plusieurs parties, dans lequel l’objet est envoyé par parties. La référence POST Object d’Amazon S3 n’indique aucune limite de taille pour un POST unique ; testez donc un téléversement par formulaire avec le plus gros fichier attendu avant de vous appuyer sur cette méthode.

Émettez-en une pour les téléversements directs depuis un navigateur ou les téléchargements privés lorsque le trafic doit contourner le serveur d’application. Une durée de validité excessive, des opérations trop permissives ou la fuite d’une URL peuvent exposer l’objet référencé jusqu’à l’expiration.

Transloadit peut renvoyer des URL présignées de téléchargement pour les fichiers qu’il exporte vers Amazon S3. Définir le paramètre sign_urls_for sur le Robot /s3/store ajoute signed_url et signed_ssl_url au résultat, avec la valeur du paramètre comme délai d’expiration en secondes. Les URL sont signées avec les informations d’identification AWS que vous fournissez au Robot. La documentation exige donc que cette identité dispose d’une autorisation de lecture des objets, en plus de l’autorisation d’écriture utilisée pour le téléversement.

Une URL renvoyée par /s3/store ne rend pas public un objet privé, mais le paramètre acl du Robot a pour valeur par défaut public-read. Pour un bucket privé, la documentation indique de définir acl sur bucket-default, de ne fournir aucun en-tête d’ACL ou d’octroi d’autorisation, et de garder S3 Block Public Access activé. Le Robot ne renouvelle pas les informations d’identification AWS temporaires, et AWS précise qu’une URL présignée expire en même temps que les informations d’identification utilisées pour la signer. Comparez donc leur durée de validité à la valeur de sign_urls_for. Signature Authentication de Transloadit et les URL signées du Smart CDN sont des mécanismes distincts qui utilisent votre Auth Secret Transloadit, et non vos informations d’identification de stockage.

Explorer les capacités de diffusion de Transloadit

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

Fonctionnement des URL présignées

Points clés

Quand les URL présignées sont importantes

Comment Transloadit vous aide avec les URL présignées

Références

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