Présentation des URL et cookies signés

Les URL et cookies signés Cloud CDN vous permettent de diffuser des réponses à partir de caches Google Cloud répartis dans le monde entier, même lorsque l'autorisation des requêtes est nécessaire.

Les URL signées et les cookies signés Cloud CDN remplissent des objectifs similaires : ils contrôlent tous deux l'accès à votre contenu mis en cache. Si vous souhaitez diffuser du contenu à partir de caches Google Cloud répartis dans le monde entier et que vous hésitez entre des URL ou des cookies signés, consultez la comparaison de cas d'utilisation suivante.

URL signées

Une URL signée est une URL qui fournit une autorisation et une durée limitées pour effectuer une requête.

Cas d'utilisation

Dans certains cas, il se peut que vous ne vouliez pas forcer vos utilisateurs à posséder un compte Google pour accéder à du contenu Cloud CDN, mais que vous souhaitiez toujours contrôler les accès selon la logique spécifique à votre application.

Le moyen habituel de traiter ce cas d'utilisation consiste à fournir une URL signée à un utilisateur, ce qui lui permet, pendant une durée limitée, de disposer d'un accès en lecture à cette ressource ou de la supprimer. Vous spécifiez un délai d'expiration lors de la création de l'URL signée. Toute personne connaissant l'URL peut accéder à la ressource jusqu'à ce que le délai d'expiration de cette URL soit atteint ou jusqu'à la rotation de la clé utilisée pour signer l'URL.

Utilisez des URL signées dans les scénarios suivants :

  • Vous devez limiter l'accès à des fichiers individuels (tel qu'un fichier de téléchargement d'installation).

  • Vos utilisateurs utilisent des applications clientes n'acceptant pas les cookies.

Fonctionnement des URL signées

Les URL signées permettent à un client d'accéder temporairement à une ressource privée sans autorisation supplémentaire. À cet effet, les éléments sélectionnés d'une requête sont hachés et signés de manière cryptographique à l'aide d'une clé fortement aléatoire que vous générez.

Lorsqu'une requête utilise l'URL signée fournie, elle est considérée comme étant autorisée à recevoir le contenu demandé. Lorsque Cloud CDN reçoit une requête avec une signature incorrecte pour un service activé, la requête est rejetée et n'atteint jamais le backend pour traitement.

Généralement, une URL signée peut être employée par tout utilisateur qui la connaît. Cependant, une URL signée est généralement destinée à être utilisée uniquement par le client auquel l'URL a été fournie. Pour limiter le risque d'utilisation de l'URL par un autre client, les URL signées expirent à la date et à l'heure que vous avez choisies. Pour réduire le risque de partage d'une URL signée, définissez-la avec un délai d'expiration le plus court possible.

Comment signer des URL

Pour signer des URL, vous devez créer au préalable une ou plusieurs clés de chiffrement sur un service de backend et/ou un bucket de backend. Ensuite, vous signez et hachez l'URL de manière cryptographique à l'aide de Google Cloud CLI ou de votre propre code.

Gérer les URL signées

Lorsque la gestion des URL signées est activée sur un backend, Cloud CDN accorde un traitement spécial aux requêtes comportant des URL signées. Plus précisément, les requêtes associées au paramètre de requête Signature sont considérées comme signées. Lorsqu'une requête de ce type est reçue, Cloud CDN vérifie les éléments suivants :

  1. La méthode HTTP est GET, HEAD, OPTIONS ou TRACE.
  2. Le paramètre Expires est défini sur une date future.
  3. La signature de la requête correspond à la signature calculée à l'aide de la clé nommée.

Si l'une de ces vérifications échoue, la réponse 403 Forbidden est émise. Sinon, la requête est soit envoyée par proxy au backend, soit diffusée à partir du cache. (Les requêtes OPTIONS et TRACE sont toujours transmises par proxy au backend directement et ne sont pas diffusées à partir du cache.) Toutes les requêtes signées valides pour une URL de base particulière (partie précédant le paramètre Expires) partagent la même entrée de cache. Les réponses aux requêtes signées et non signées ne partagent pas les entrées de cache. Les réponses sont mises en cache et diffusées jusqu'au délai d'expiration que vous avez défini.

Le contenu nécessitant des requêtes signées est souvent marqué à l'aide de l'en-tête Cache-Control comme ne pouvant pas être mis en cache. Pour rendre de tels objets compatibles avec Cloud CDN sans modification du backend, celui-ci ignore l'en-tête Cache-Control dans la réponse à des requêtes contenant des URL signées valides. Il considère le contenu comme pouvant être mis en cache et utilise le paramètre max-age défini dans la configuration Cloud CDN. La réponse diffusée contient toujours les en-têtes Cache-Control générés par le backend.

L'URL renvoyée par Google Cloud CLI ou produite par votre code personnalisé peut être distribuée selon vos besoins. Nous vous recommandons de ne signer que les URL HTTPS, car ce protocole fournit un transport sécurisé qui empêche le composant Signature de l'URL signée d'être intercepté. De même, vous devez distribuer les URL signées via des protocoles de transport sécurisés tels que TLS/HTTPS.

Cookies signés

Un cookie signé est un cookie qui fournit une autorisation et une durée limitées pour effectuer des requêtes sur un ensemble de fichiers.

Cas d'utilisation

Utilisez des cookies signés dans les scénarios suivants :

  • Vous devez fournir un accès à plusieurs fichiers restreints.

  • Vous souhaitez éviter de modifier vos URL actuelles.

  • Vous souhaitez éviter de mettre à jour les URL chaque fois que vous actualisez l'autorisation d'accès au contenu.

Diffuser des contenus multimédias avec HLS et DASH

Si vous diffusez du contenu vidéo et audio à l'aide des protocoles HTTP Live Streaming (HLS) ou Dynamic Adaptive Streaming over HTTP (DASH), vous générez généralement un fichier manifeste contenant une liste d'URL de segments vidéo et audio. Vous pouvez disposer de plusieurs instances de chaque segment pour fournir différents encodages (codec, débit, résolution) à un client.

Bien que vous puissiez signer et autoriser l'accès à chacune de ces URL à l'aide des URL signées de Cloud CDN, la génération dynamique de toutes les combinaisons possibles par utilisateur est fastidieuse et augmente la charge de l'origine ainsi que la complexité de l'application.

Les cookies signés sont conçus pour remédier à ce problème. Vous pouvez fournir à l'utilisateur un cookie signé qui l'autorise à accéder à tout contenu correspondant à une règle (préfixe d'URL et date d'expiration), sans avoir à générer ni signer individuellement vos fichiers manifestes multimédias. Vous pouvez actualiser régulièrement l'accès des utilisateurs via l'API JavaScript fetch() lors de la navigation sur les pages ou à l'aide d'autres mécanismes d'arrière-plan dans les applications natives. La possibilité d'actualiser l'accès des utilisateurs vous permet également d'utiliser des délais d'expiration courts, ce qui empêche les utilisateurs de partager facilement du contenu protégé.

Vous pouvez envoyer ces cookies aux utilisateurs exploitant plusieurs clients de navigateur et d'autres clients utilisant HTTP (tels qu'ExoPlayer pour Google et AVPlayer pour iOS).

Téléchargements binaires (jeux vidéo)

Comme pour le streaming de contenus multimédias, si vous fournissez des fichiers de téléchargement de clients de jeu, vous pouvez diviser les correctifs volumineux ou les données de jeu en fragments plus petits pour permettre une mise en cache, une invalidation et une simultanéité plus précises.

Ces fragments sont généralement répertoriés dans un fichier manifeste. Les cookies signés vous permettent d'autoriser l'accès à ces téléchargements à des utilisateurs authentifiés, sans que vous n'ayez à modifier le fichier manifeste ni (comme pour les URL signées) à renoncer aux avantages de la mise en cache Cloud CDN.

Fonctionnement des cookies signés

La configuration et l'émission de cookies signés nécessitent trois étapes :

  • Création d'une clé de signature pour le service de backend donné
  • Création d'une valeur de cookie avec le préfixe d'URL, la date d'expiration, le nom de clé et la signature cryptographique autorisés
  • Émission du cookie dans le code de votre application

Cloud CDN valide ces cookies signés lorsqu'ils sont inclus dans des requêtes.

Vous pouvez empêcher les utilisateurs de contourner vos contrôles de cookies signés lorsqu'ils utilisent un bucket Cloud Storage. Pour ce faire, limitez l'accès au bucket sous-jacent en supprimant le rôle allUsers et en accordant au compte de service Cloud CDN un accès en lecture au bucket.

De même, vos instances de machine virtuelle (VM) doivent valider les signatures sur chaque requête signée qu'elles diffusent.

Mises en garde et limites

  • Vous êtes seul responsable de la mise en œuvre des exigences de conformité et d'autorisation pour vos cookies signés. Les cookies signés sont émis et gérés par vous, et non par Google.

  • Si vous utilisez à la fois des URL signées et des cookies signés pour contrôler l'accès aux mêmes fichiers, et qu'un utilisateur se sert d'une URL signée pour demander un fichier, Cloud CDN ne détermine si le fichier doit être renvoyé qu'en fonction de l'URL signée. Cloud CDN ne considère les cookies signés que si l'URL n'est pas signée.

  • Si vous avez configuré votre service pour les requêtes signées et que votre URL inclut Signature en tant que paramètre de requête, Cloud CDN tente d'interpréter votre URL comme une URL signée. Si Cloud CDN tente de traiter votre URL comme une URL signée alors que vous ne souhaitez pas ce comportement, votre URL n'est probablement pas une URL signée valide. Par conséquent, Cloud CDN la rejette.

  • Les navigateurs et autres clients imposent généralement des limites concernant la taille des cookies (4 Ko par cookie) et le nombre maximal de cookies (50 par domaine), conformément à la norme RFC 6265. Tenez compte de la charge utile totale du cookie envoyée depuis son domaine.

  • Cloud CDN applique certaines limites et restrictions, telles qu'un maximum de trois clés de requête signées par backend.

  • Les requêtes signées ne sont pas facturées différemment des requêtes Cloud CDN existantes. Toutefois, les requêtes ayant échoué (rejetées), telles que celles ayant des signatures expirées ou non valides, entraînent toujours des frais de recherche dans le cache.

Étapes suivantes