URL présignées S3 : accès temporaire aux fichiers privés

Une URL présignée S3 accorde un accès temporaire à une requête Amazon S3 précise, par exemple pour télécharger un fichier privé ou envoyer un objet. Le destinataire utilise le lien signé sans recevoir vos identifiants AWS. Votre application reste responsable de décider qui peut demander ce lien et à quel objet cette personne peut accéder.

Ce guide présente les téléchargements GET et les envois PUT pour les compartiments à usage général Amazon S3. Il propose des exemples Python, les règles d'expiration et des vérifications à effectuer. Le guide du stockage cloud Amazon explique les différences entre S3, EBS, EFS et FSx. Les liens vers la documentation technique renvoient aux sources en anglais.

Comment fonctionne une URL présignée S3 ?

La requête signée désigne une opération, un compartiment, une clé d'objet et une durée de validité. S3 évalue la signature et les autorisations du signataire à la réception de la requête. Produire une URL sans erreur ne prouve donc pas que S3 autorisera son utilisation.

Prenons une application permettant à un client de télécharger une facture :

1. Le client se connecte à l'application et demande une facture.
2. Le serveur vérifie que ce client peut accéder à cette facture.
3. Le serveur sélectionne la clé de l'objet conservé et génère une URL GET de courte durée.
4. Le client télécharge directement le fichier depuis S3.

Ne laissez pas le client substituer un compartiment ou une clé arbitraire sans contrôle d'autorisation. Une connexion valide à l'application ne donne pas accès aux fichiers de tous les clients. Notre guide du stockage pour applications présente les choix de services et la conception des accès.

Préparer un objet privé et une identité de test

Utilisez un compartiment privé de test et un petit fichier sans données sensibles. Maintenez le blocage des accès publics. Configurez une identité AWS avec les seules autorisations nécessaires sur les objets de l'exercice. Les principes de moindre privilège s'appliquent aussi aux requêtes présignées.

Pour l'exemple de téléchargement, l'identité signataire doit pouvoir accéder à l'objet par s3:GetObject. Une requête visant une version précise utilise s3:GetObjectVersion. Les objets chiffrés avec AWS KMS demandent aussi les autorisations applicables sur la clé. Consultez les exigences de GetObject pour votre configuration.

Installez Boto3 dans votre environnement Python. Configurez les identifiants au moyen d'un rôle, d'une session ou d'un profil approuvé dans la chaîne d'identifiants du SDK. N'intégrez pas de clés d'accès au script ni au code du navigateur. Les exemples imposent explicitement Signature Version 4.

Créer une URL présignée pour télécharger un fichier

Enregistrez ce code dans presigned_demo.py. Remplacez le compartiment fictif, la région et la clé par vos valeurs de test. La clé doit désigner un objet existant. ExpiresIn=300 demande une validité de cinq minutes ; des identifiants temporaires ou des règles d'accès peuvent la raccourcir.

import boto3
from botocore.config import Config

s3 = boto3.client(
    "s3",
    region_name="us-east-1",
    config=Config(signature_version="s3v4"),
)

download_url = s3.generate_presigned_url(
    "get_object",
    Params={
        "Bucket": "YOUR_PRIVATE_TEST_BUCKET",
        "Key": "presigned-demo/sample.txt",
    },
    ExpiresIn=300,
)
print(download_url)

La méthode de signature Boto3 reçoit la méthode du client, ses paramètres et une durée en secondes. Exécutez le script dans un terminal privé, puis ouvrez l'URL obtenue dans un navigateur. Écartez cette sortie des journaux partagés et des captures d'écran. En production, renvoyez-la uniquement au client autorisé au lieu de l'afficher.

Dans la console S3, vous pouvez aussi sélectionner l'objet et choisir Share with a presigned URL. Cette action crée un lien de téléchargement sans rendre le compartiment public.

Créer une URL présignée pour envoyer un fichier

Pour un envoi PUT, l'identité signataire doit disposer de s3:PutObject sur la destination. Choisissez la clé côté serveur. Ajoutez cet exemple au même script pour réutiliser le client s3 configuré. Il attribue une nouvelle clé et signe le type de contenu attendu ainsi qu'un en-tête d'écriture conditionnelle.

from uuid import uuid4

# Reuse the configured s3 client from the download example.
upload_key = f"presigned-demo/uploads/{uuid4()}.txt"
upload_url = s3.generate_presigned_url(
    "put_object",
    Params={
        "Bucket": "YOUR_PRIVATE_TEST_BUCKET",
        "Key": upload_key,
        "ContentType": "text/plain",
        "IfNoneMatch": "*",
    },
    ExpiresIn=300,
)
print(upload_url)
print("Required headers: Content-Type: text/plain; If-None-Match: *")

Envoyez le fichier avec un client HTTP PUT et les deux en-têtes. Cette commande curl fonctionne dans un shell POSIX ; sous Windows PowerShell, utilisez curl.exe si curl désigne une autre commande. Remplacez localement l'URL fictive en conservant les guillemets :

curl --fail-with-body --request PUT --upload-file sample.txt --header "Content-Type: text/plain" --header "If-None-Match: *" "YOUR_PRESIGNED_PUT_URL"

Le corps de la requête doit contenir le fichier brut, sans formulaire multipart autour. Conservez le même type de contenu que dans la signature, conformément aux instructions d'envoi S3. Ne modifiez ni la méthode, ni le chemin, ni les paramètres de l'URL après signature.

Éviter le remplacement d'un objet existant

Une requête PutObject ordinaire peut remplacer l'objet associé à la même clé. Avec le versionnage activé, elle peut créer une nouvelle version courante. Une clé unique choisie par le serveur réduit les collisions accidentelles.

L'exemple signe aussi If-None-Match: *. Cette écriture conditionnelle échoue avec HTTP 412 si un objet courant existe déjà à cette clé. Dans un compartiment versionné, le contrôle porte sur la version courante. Il ne crée pas un lien à usage unique permanent : une suppression ultérieure ou un marqueur de suppression peut changer le résultat.

Un type de contenu signé ne prouve ni l'innocuité du fichier ni son format réel. Avant de rendre les envois accessibles, validez leur contenu et appliquez les règles de taille, d'appartenance et de traitement des logiciels malveillants de votre application. Conservez les fichiers dans une zone d'envoi distincte pendant ces vérifications.

Comprendre l'expiration, la réutilisation et les interruptions

Les règles S3 prévoient jusqu'à 12 heures pour un lien créé dans la console et sept jours via la CLI ou les SDK avec des identifiants adaptés. Un lien signé avec des identifiants temporaires expire au plus tard avec eux, même si la durée demandée est supérieure.

Ces liens sont réutilisables par leur détenteur. Un téléchargement commencé avant l'expiration peut se poursuivre ensuite, mais sa reprise après expiration peut échouer. Choisissez une durée courte compatible avec la tâche. L'expiration n'efface pas un fichier déjà téléchargé.

Pour un téléchargement réellement unique, prévoyez une autorisation et un suivi d'utilisation dans l'application. Générer une URL puis marquer une ligne de base de données « utilisée » n'empêche pas le destinataire de réemployer le lien tant que S3 l'accepte.

Séparer les besoins du navigateur des autorisations

Une application web appelant S3 depuis une autre origine peut nécessiter une configuration CORS. Autorisez l'origine, la méthode HTTP et les en-têtes nécessaires. Pour l'exemple PUT, tenez compte de Content-Type et If-None-Match. Un succès en ligne de commande ne valide pas le comportement du navigateur.

CORS ne remplace pas l'autorisation. Un destinataire utilisant un client hors navigateur n'est pas soumis aux contrôles interorigines du navigateur. Testez l'origine réelle et les permissions S3.

Protégez aussi le service qui signe les liens : authentifiez les demandeurs, contrôlez leur accès à l'objet, limitez la fréquence des requêtes et évitez de révéler des informations sur d'autres objets. Consignez le demandeur, l'opération, l'objet autorisé et la durée demandée sans copier l'URL signée complète.

Réagir à la divulgation d'un lien

Se déconnecter de l'application n'invalide pas à lui seul une URL S3 existante. En cas de divulgation, examinez l'accès à l'objet et l'identité signataire avec le responsable de la sécurité. Modifier des permissions ou révoquer des identifiants peut toucher d'autres clients. Vérifiez le refus obtenu : créer un nouveau lien n'annule pas l'ancien.

Diagnostiquer une requête refusée

• SignatureDoesNotMatch : comparez méthode HTTP, région, clé, en-têtes et paramètres avec la requête signée. Vérifiez l'horloge et les éventuels proxys qui réécrivent la requête.
• ExpiredToken : renouvelez la session de signature par le mécanisme approuvé, puis émettez un nouveau lien. Allonger la durée demandée ne réactive pas des identifiants expirés.
• AccessDenied : examinez les permissions du signataire, les refus explicites, les autorisations KMS applicables et les restrictions réseau.
• HTTP 412 pour le PUT de l'exemple : vérifiez si un objet courant existe déjà à cette clé. Ne supprimez pas la protection contre le remplacement pour masquer l'erreur.
• Échec limité au navigateur : examinez la requête CORS préalable et les en-têtes requis avant de modifier les permissions du compartiment.

Conservez le code d'erreur et l'identifiant de requête pour le diagnostic, en masquant identifiants et signatures. Reproduisez le problème avec un petit fichier de test avant de changer le comportement de l'application. Évaluez les effets d'une modification de politique sur les clients existants autant que sur le nouveau lien.

Tester le parcours complet avant la production

Les exemples Python ont été vérifiés localement avec Python 3.12.14 et Boto3/Botocore 1.43.121, à l'aide d'identifiants fictifs. Le contrôle a confirmé la signature SigV4, les méthodes GET et PUT, les paramètres d'expiration et les en-têtes signés requis. Il n'a contacté aucun service AWS et ne prouve pas qu'un compartiment réel accepterait les requêtes.

Effectuez ces vérifications dans votre environnement de test :

1. Confirmez que le destinataire prévu télécharge le bon fichier et qu'un utilisateur non autorisé de l'application ne peut pas obtenir le lien.
2. Envoyez un petit fichier avec les en-têtes requis, puis vérifiez sa clé, son contenu et son propriétaire depuis un compte autorisé.
3. Répétez le PUT conditionnel tant que cet objet existe et confirmez le refus attendu.
4. Essayez une nouvelle requête après expiration et testez la durée réelle des identifiants temporaires utilisés par l'application.
5. Testez l'origine du navigateur, le chemin réseau, les interruptions et les nouvelles tentatives.
6. Recherchez les URL signées dans les journaux de l'application et supprimez les données de test jetables par le processus habituel.

Prévoyez les frais S3 de stockage, requêtes, récupération éventuelle et transfert, ainsi que ceux de l'application et de sa supervision. Réutiliser un lien valide peut multiplier les requêtes et les transferts. Une URL signée modifie l'accès, pas le modèle de facturation du service.

Quand choisir un autre mode de partage ?

Les URL présignées conviennent lorsqu'une application doit déléguer un accès limité à un objet sans fournir d'identifiants AWS au destinataire. Pour une diffusion publique permanente, un contrôle nominatif à chaque téléchargement ou un service de partage de fichiers prêt à l'emploi, examinez une solution de diffusion ou une couche applicative adaptée.

Avec un service compatible S3, vérifiez les opérations, la signature, l'expiration, les en-têtes et les écritures conditionnelles dans sa propre documentation. Ce guide Amazon S3 ne démontre pas la prise en charge de ces fonctions par un autre fournisseur.