Téléchargement et chargement d’objets à l’aide d’URL présignées - Amazon Simple Storage Service

Téléchargement et chargement d’objets à l’aide d’URL présignées

Vous pouvez utiliser des URL présignées pour accorder un accès limité dans le temps aux objets dans Amazon S3 sans mettre à jour votre stratégie de compartiment. Une URL présignée peut être saisie dans un navigateur ou utilisée par un programme pour charger un objet. Les informations d’identification utilisées par l’URL présignée sont celles du principal AWS Identity and Access Management (IAM) qui a généré l’URL.

Vous pouvez également utiliser des URL présignées pour permettre à quelqu’un de charger un objet spécifique dans votre compartiment Amazon S3. Cela permet d’effectuer un chargement sans qu’une autre partie ait besoin d’informations d’identification ou d’autorisations de sécurité AWS. Si un objet avec la même clé que celle spécifiée dans l’URL présignée existe déjà dans le compartiment, Amazon S3 remplace l’objet existant par l’objet chargé.

Vous pouvez utiliser l’URL présignée plusieurs fois, jusqu’à la date et l’heure d’expiration.

Lorsque vous créez une URL présignée, vous devez fournir vos informations d’identification de sécurité, puis spécifier les éléments suivants :

  • Un compartiment Amazon S3

  • Une clé d’objet (si le téléchargement de cet objet se fait dans votre compartiment Amazon S3, s’il s’agit du nom du fichier à charger)

  • Une méthode HTTP (GET pour le téléchargement des objets, PUT pour le chargement, HEAD pour la lecture des métadonnées des objets, etc.)

  • Un intervalle de temps d’expiration

Lorsque vous utilisez des URL présignées pour charger des objets, vous pouvez vérifier l’intégrité des objets à l’aide de sommes de contrôle. Les URL présignées créées avec AWS Signature Version 2 ne prennent en charge que les sommes de contrôle MD5, tandis que les URL présignées créées avec AWS Signature Version 4 prennent en charge des algorithmes de somme de contrôle supplémentaires, notamment CRC-64/NVME, CRC32, CRC32C, SHA-1 et SHA-256. Pour utiliser ces algorithmes de somme de contrôle supplémentaires, assurez-vous d’utiliser AWS Signature Version 4 et d’inclure l’en-tête de somme de contrôle approprié dans votre demande de chargement. Pour en savoir plus sur l’intégrité des objets, consultez Vérification de l’intégrité des objets dans Amazon S3.

Utilisateurs habilités à créer une URL présignée

Toute personne qui possède des autorisations de sécurité valides peut créer une URL présignée. Mais pour que l’utilisateur puisse accéder correctement à un objet, l’URL présignée doit être créée par une personne qui possède l’autorisation d’effectuer l’opération sur laquelle l’URL présignée est basée.

Les informations d’identification que vous pouvez utiliser pour créer une URL présignée sont les suivantes :

  • Utilisateur IAM : valide pendant 7 jours en cas d’utilisation d’AWS Signature Version 4.

    Afin de créer une URL présignée valide pendant 7 jours maximum, commencez par déléguer des informations d’identification d’utilisateur IAM (clé d’accès et clé secrète) à la méthode que vous utilisez pour créer l’URL présignée.

  • Informations d’identification de sécurité temporaires : elles ne peuvent pas être valides plus longtemps que les informations d’identification elles-mêmes. Ces informations d’identification incluent :

    • Informations d’identification du rôle IAM : l’URL présignée expire à l’expiration de la session de rôle, même si vous spécifiez un délai d’expiration plus long.

    • Informations d’identification du rôle IAM utilisées par les instances Amazon EC2 : elles sont valides pendant la durée de validité des informations d’identification du rôle (généralement 6 heures).

    • Informations d’identification AWS Security Token Service : elles sont valides uniquement pendant la durée de validité des informations d’identification temporaires.

Note

Si vous avez créé une URL présignée à l’aide d’informations d’identification temporaires, l’URL expire quand les informations d’identification expirent. En général, une URL présignée expire lorsque les informations d’identification que vous avez utilisées pour la créer sont révoquées, supprimées ou désactivées. Cela est vrai même si l’URL a été créée avec une date d’expiration ultérieure. Pour connaître la durée de vie des informations d’identification de sécurité temporaires, consultez Comparaison des opérations d’API AWS STS dans le Guide de l’utilisateur IAM.

Délai d’expiration pour les URL présignées

Une URL présignée reste valide pendant la période spécifiée lors de sa génération. Si vous créez une URL présignée à l’aide de la console Amazon S3, le délai d’expiration peut être défini entre 1 minute et 12 heures. Si vous utilisez l’AWS CLI ou les kits AWS SDK, le délai d’expiration peut être fixé à 7 jours.

Si vous avez créé une URL présignée à l’aide d’un jeton temporaire, cette URL expirera quand le jeton expirera. En général, une URL présignée expire lorsque les informations d’identification que vous avez utilisées pour la créer sont révoquées, supprimées ou désactivées. Cela est vrai même si l’URL a été créée avec une date d’expiration ultérieure. Pour plus d’informations sur la manière dont les informations d’identification que vous utilisez affectent le délai d’expiration, consultez Utilisateurs habilités à créer une URL présignée.

Amazon S3 vérifie la date et l’heure d’expiration d’une URL signée au moment de la requête HTTP. Par exemple, si un client commence à télécharger un fichier volumineux immédiatement avant la date d’expiration, le téléchargement continue même si la date d’expiration intervient pendant le téléchargement. Cependant, si la connexion est perdue et que le client essaie de redémarrer le téléchargement une fois la date d’expiration passée, le téléchargement échoue.

Limitation des capacités des URL présignées

Les capacités d’une URL présignée sont limitées par les autorisations de l’utilisateur qui l’a créée. En résumé, les URL présignées correspondent à des jetons porteurs qui donnent accès à ceux qui les possèdent. À ce titre, nous vous recommandons de les protéger de manière appropriée. Voici quelques méthodes que vous pouvez utiliser pour restreindre l’utilisation de vos URL présignées.

AWS Signature Version 4 (SigV4)

Pour imposer un comportement spécifique lorsque les requêtes d’URL présignées sont authentifiées à l’aide d’AWS Signature Version 4 (SigV4), vous pouvez utiliser les clés de condition dans les stratégies de compartiment et les stratégies de point d’accès. Par exemple, la stratégie de compartiment suivante utilise la condition s3:signatureAge pour refuser toute demande d’URL présignée Amazon S3 sur les objets du compartiment amzn-s3-demo-bucket si la signature date de plus de 10 minutes. Pour utiliser cet exemple, remplacez les user input placeholders par vos propres informations.

JSON
{ "Version":"2012-10-17", "Statement": [ { "Sid": "Deny a presigned URL request if the signature is more than 10 min old", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "600000" } } } ] }

Pour plus d’informations sur les clés de politique AWS associées à Signature Version 4, consultez Authentification AWS Signature Version 4 dans la Référence des API Amazon Simple Storage Service.

Restriction de chemin réseau

Si vous souhaitez restreindre l’utilisation des URL présignées et de tous les accès Amazon S3 à des chemins réseau particuliers, vous pouvez écrire des politiques AWS Identity and Access Management (IAM). Vous pouvez définir ces politiques sur le principal IAM qui effectue l’appel, le compartiment Simple Storage Service (Amazon S3) ou les deux.

Une restriction de chemin réseau sur le principal IAM exige que l’utilisateur de ces informations d’identification effectue des requêtes à partir du réseau spécifié. Une restriction sur le compartiment ou le point d’accès nécessite que toutes les requêtes adressées à cette ressource proviennent du réseau spécifié. Ces restrictions s’appliquent également hors du scénario des URL présignées.

La clé de condition globale IAM que vous utilisez dépend du type de point de terminaison. Si vous utilisez le point de terminaison public pour Amazon S3, utilisez aws:SourceIp. Si vous utilisez un point de terminaison de cloud privé virtuel (VPC) pour Amazon S3, utilisez aws:SourceVpc ou aws:SourceVpce.

La déclaration de politique IAM suivante nécessite que le principal accède à AWS uniquement à partir de la plage réseau spécifiée. Avec cette déclaration de stratégie, tous les accès doivent provenir de cette plage. Cela inclut lorsqu’une personne utilise une URL présignée pour Amazon S3. Pour utiliser cet exemple, remplacez les user input placeholders par vos propres informations.

{ "Sid": "NetworkRestrictionForIAMPrincipal", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NotIpAddressIfExists": {"aws:SourceIp": "IP-address-range"}, "BoolIfExists": {"aws:ViaAWSService": "false"} } }

Questions fréquentes (FAQ) sur les URL présignées

Q : pourquoi mes URL présignées expirent-elles avant la date d’expiration configurée ?

Les URL présignées restent valides tant que leurs informations d’identification sous-jacentes le sont. Une URL présignée expire soit à l’heure d’expiration configurée, soit à l’expiration des informations d’identification associées, selon la première éventualité. Pour les tâches ou les conteneurs Amazon Elastic Container Service, les informations d’identification des rôles changent généralement toutes les 1 à 6 heures. Lorsque vous utilisez AWS Security Token Service (AWS STS) AssumeRole, l’URL présignée expire à la fin de la session de rôle, qui est par défaut d’une heure. Pour les profils d’instance Amazon EC2, les informations d’identification des métadonnées changent périodiquement, avec une durée de validité maximale d’environ 6 heures.

Q : pourquoi est-ce que le message d’erreur 403 Forbidden s’affiche quand j’accède à une URL présignée ?

Avant de générer une URL présignée, vérifiez que vous avez configuré les autorisations appropriées. L’utilisateur ou le rôle IAM qui génère l’URL doit disposer des autorisations requises, par exemple s3:GetObject, pour l’opération en question. Vérifiez également que la stratégie de compartiment Amazon S3 ne refuse pas explicitement l’accès à l’objet.

Q : je reçois des erreurs SignatureDoesNotMatch. Comment puis-je résoudre le problème ?

Si vous rencontrez des erreurs SignatureDoesNotMatch lors de l’utilisation d’URL présignées Amazon S3, vérifiez plusieurs points. Tout d’abord, assurez-vous que l’horloge de votre système est synchronisée avec un serveur NTP (Network Time Protocol), car même de petits décalages temporels peuvent invalider les signatures. Sachez ensuite que certains proxys d’entreprise peuvent modifier les en-têtes ou les chaînes de requête, ce qui peut entraîner des incohérences de signature. Pour résoudre le problème, essayez sans le proxy. Enfin, vérifiez que tous les paramètres de la demande, y compris la méthode HTTP, les en-têtes et la chaîne de la requête, sont identiques entre la génération et l’utilisation de l’URL. La vérification de ces points permet souvent de résoudre les erreurs SignatureDoesNotMatch.

Q : je reçois des erreurs ExpiredToken. Que dois-je faire ?

Si vous recevez des erreurs ExpiredToken lors de l’utilisation d’URL présignées, cela signifie que les informations d’identification AWS utilisées pour générer l’URL ne sont plus valides. Pour résoudre ce problème, actualisez vos informations d’identification AWS avant de générer de nouvelles URL présignées. Pour les applications de longue durée, nous recommandons d’implémenter une logique d’actualisation des informations d’identification afin de garantir un accès continu. Le cas échéant, vous pouvez utiliser des informations d’identification de plus longue durée ou mettre en œuvre des mécanismes d’actualisation des jetons. Si vous utilisez AWS Security Token Service (AWS STS) AssumeRole, vérifiez que la durée de session configurée répond aux exigences de votre cas d’utilisation. N’oubliez pas que les URL présignées ne restent valides que pendant la durée de validité de leurs informations d’identification sous-jacentes. Il est donc essentiel de mettre en œuvre une gestion appropriée des informations d’identification.