Aller au contenu

AWS Mis à jour le 2026-09-21

URL signées et cookies signés CloudFront : bien protéger le contenu payant

Apprenez à protéger vos téléchargements payants et vos vidéos pour membres avec les URL signées et les cookies signés CloudFront. Ce guide vous montre comment configurer les clés de signature, choisir entre les deux et verrouiller votre origine pour que personne ne contourne CloudFront.

Ce guide s’adresse à vous si vous vendez des fichiers ou des vidéos par CloudFront, le réseau de diffusion de contenu (CDN) d’Amazon, et voulez les réserver aux clients payants. Sans protection, quiconque trouve le lien d’un fichier peut le partager ou le récupérer gratuitement. CloudFront règle ce problème avec les URL signées et les cookies signés, qui portent une signature à durée limitée que votre application crée avec une clé privée. Signez une URL pour un seul fichier, comme un PDF acheté, et signez des cookies pour plusieurs fichiers sous un même chemin, comme les segments d’une vidéo en continu. Vous devez aussi verrouiller votre origine, soit le compartiment S3 ou le serveur qui contient les fichiers, pour que personne ne puisse contourner CloudFront.

Ce qui se passe

Quand un comportement de cache a Restrict viewer access activé, CloudFront refuse toute requête qui ne porte pas une signature valide — soit dans les paramètres de requête de l’URL (Expires/Policy, Signature, Key-Pair-Id), soit dans trois cookies (CloudFront-Expires ou CloudFront-Policy, CloudFront-Signature, CloudFront-Key-Pair-Id). Votre application génère ces signatures avec une clé privée RSA; CloudFront les vérifie contre des clés publiques téléversées sous CloudFront > Key management > Public keys, regroupées en groupes de clés attachés à la distribution.

Utilisez les groupes de clés. Le mécanisme plus ancien — les paires de clés CloudFront créées avec l’utilisateur racine du compte — existe encore dans de vieux déploiements, mais il exige les identifiants racine pour la rotation et ne se gère pas avec IAM. Les groupes de clés sont de simples objets d’API : n’importe quel rôle correctement permissionné peut ajouter et retirer des clés publiques, ce qui fait de la rotation une opération plutôt qu’un événement.

Les politiques ont deux formes. Une politique prédéfinie encode une URL de ressource et une expiration — compacte, idéale pour les URL à fichier unique. Une politique personnalisée ajoute une heure de début optionnelle, une restriction d’IP source optionnelle, et des ressources à joker (https://media.example.com/course-42/*) — obligatoire pour que des cookies signés couvrent un chemin, et la raison pour laquelle un cookie peut déverrouiller tout un flux vidéo.

La partie que les équipes oublient : la signature contrôle la porte d’entrée CloudFront, point. Si le compartiment S3 est public, ou si l’origine ALB accepte du trafic direct, le contenu payant est à un curl vers l’origine d’être gratuit. Le verrouillage de l’origine — origin access control pour S3, un en-tête secret ou la liste de préfixes gérée de CloudFront pour les origines personnalisées — est la moitié de la conception, pas une étape de durcissement optionnelle.

Quoi vérifier en premier

  • Restrict viewer access est-il activé sur le bon comportement? Du code de signature sans le drapeau signifie que tout est public; le drapeau sans code de signature fonctionnel signifie que tout est 403.
  • La clé publique est-elle dans un groupe attaché à la distribution? Une clé téléversée mais absente d’un groupe de confiance ne valide rien.
  • Les horloges concordent-elles? L’expiration des signatures est en temps epoch; un serveur d’application avec une dérive d’horloge frappe des URL mortes à l’arrivée.
  • L’origine est-elle joignable directement? Testez l’URL S3 et le nom d’hôte de l’origine depuis l’extérieur — les deux doivent refuser.

Comment vérifier

# Signer une URL pour un fichier avec une politique prédéfinie (le CLI le supporte directement)
aws cloudfront sign \
  --url "https://media.example.com/downloads/report.pdf" \
  --key-pair-id K2JCJMDEHXQW5F \
  --private-key file://private_key.pem \
  --date-less-than 2026-07-05T12:00:00Z

# Une URL signée valide retourne 200; la même URL sans paramètres doit retourner 403
curl -s -o /dev/null -w '%{http_code}\n' "https://media.example.com/downloads/report.pdf"

# Confirmer le câblage du groupe de clés sur la distribution
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 \
  --query 'DistributionConfig.DefaultCacheBehavior.TrustedKeyGroups'

Une page d’erreur MissingKey ou Malformed Policy nomme le paramètre manquant; un 403 Forbidden sec avec x-cache: Error from cloudfront sur une requête signée signifie habituellement expiration dépassée, mauvais ID de paire de clés, ou une URL réencodée en transit (les clients courriel adorent mutiler les longues chaînes de requête — encapsulez les liens de téléchargement).

Le runbook

  1. Générez une paire RSA 2048 bits et téléversez la clé publique. openssl genrsa -out private_key.pem 2048, extrayez la moitié publique, téléversez-la à CloudFront > Key management > Public keys, ajoutez-la à un groupe de clés, attachez le groupe au comportement. La clé privée va dans Secrets Manager ou Parameter Store — jamais dans le dépôt.
  2. Activez Restrict viewer access par comportement, pas globalement. Les comportements /downloads/* et /streams/* reçoivent la signature; les actifs marketing et la page du lecteur restent publics. Les distributions mixtes sont normales.
  3. Signez les URL côté serveur au moment de la requête, avec des expirations courtes. Des minutes pour un lien de téléchargement cliqué immédiatement; ne frappez pas des URL d’une semaine, elles finissent dans les forums. Pour les gros téléchargements reprenables, dimensionnez l’expiration sur le temps de téléchargement d’un lien lent, pas sur le clic.
  4. Utilisez les cookies signés avec politique personnalisée pour la diffusion et les chemins multi-fichiers. Posez les trois cookies sur le domaine de votre application, portés vers le nom d’hôte média, avec la ressource de la politique correspondant au joker de chemin. Le lecteur récupère ensuite les segments avec zéro travail applicatif par segment.
  5. Verrouillez l’origine. Les origines S3 reçoivent origin access control pour que seule la distribution lise le compartiment. Les origines personnalisées vérifient un en-tête secret ajouté par CloudFront, ou restreignent au pare-feu à la liste de préfixes de CloudFront côté origine — la même logique de verrouillage que le motif WAF sur ALB où la périphérie doit être la seule porte.
  6. Planifiez la rotation avant d’en avoir besoin. Ajoutez la nouvelle clé publique au groupe, déployez l’application signant avec la nouvelle clé privée, puis retirez l’ancienne clé publique une fois les expirations en vol passées. Les groupes de clés acceptent plusieurs clés précisément pour rendre ce chevauchement indolore.

Quand c’est la mauvaise approche

Les URL signées authentifient la possession d’un lien, pas une personne : quiconque détient une URL vivante dans sa fenêtre peut l’utiliser, alors c’est le mauvais outil pour l’autorisation par usager sur des ressources longue durée. Si l’exigence est une vérification par requête, faites-la dans l’application ou dans du code de périphérie — une vérification JWT légère en périphérie est un des cas légitimes de la décision CloudFront Functions vs Lambda@Edge. La signature n’est pas non plus du DRM : un usager payant peut toujours sauvegarder les octets. Et pour une poignée de fichiers internes, les URL présignées S3 directement du compartiment sont plus simples quand aucun comportement CDN n’est nécessaire.

Erreurs fréquentes

  • Laisser l’origine ouverte, de sorte que tout le mécanisme protège la copie du contenu que personne n’allait chercher de toute façon.
  • Frapper les URL avec la paire de clés héritée du compte racine, transformant la rotation en cérémonie d’identifiants racine.
  • Mal régler la portée des cookies (domaine ou chemin) : le lecteur n’envoie aucun cookie et chaque segment fait 403 — le flux joue pour le développeur qui teste sur le même domaine, puis échoue en production.
  • Oublier que les 403 en cache et la dérive d’horloge se ressemblent dans les rapports de bogue : vérifiez Expires contre l’heure du serveur d’abord.

Prévention

  • Stockez la clé privée dans Secrets Manager avec l’accès limité au rôle du service de signature, et journalisez son usage.
  • Créez une alarme sur le taux de 403 de la distribution; une pointe est soit une attaque, soit un bogue d’expiration, soit un déploiement brisé du code de signature.
  • Gardez deux clés dans le groupe pendant toute fenêtre de rotation, et mettez le retrait au calendrier.
  • Testez le chemin direct vers l’origine depuis un réseau externe chaque trimestre; les verrouillages pourrissent quand des compartiments s’ouvrent « temporairement ».

Le format des politiques et le détail des cookies sont spécifiés dans la documentation CloudFront. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.