Authentifier le contenu

Cloud CDN propose trois méthodes pour vous aider à contrôler l'accès à votre contenu mis en cache:

Les URL signées vous permettent de diffuser des réponses à partir de caches Google Cloud répartis dans le monde entier lorsque l'autorisation des requêtes est nécessaire. Toute personne disposant de l'URL signée peut accéder à la ressource pendant une durée limitée.
Les cookies signés vous permettent également d'accéder à une ressource pendant une durée limitée. Ils sont utiles lorsque vous devez signer des dizaines ou des centaines d'URL pour chaque utilisateur.
L'authentification de l'origine privée vous permet de limiter les connexions à vos buckets Amazon Simple Storage Service (Amazon S3) ou à d'autres magasins d'objets compatibles et d'empêcher les utilisateurs d'y accéder directement.

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 :

Pour restreindre l'accès à des fichiers individuels, tels qu'un téléchargement d'installation.
Pour servir les utilisateurs avec des applications clientes qui ne prennent pas en charge 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 :

La méthode HTTP est GET, HEAD, OPTIONS ou TRACE.
Le paramètre Expires est défini sur une date future.
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 directement par proxy au backend et non à 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 ces objets compatibles avec Cloud CDN sans avoir à modifier le backend, Cloud CDN ignore l'en-tête Cache-Control lors de la réponse à des requêtes comportant 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 votre 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 la gcloud CLI ou générée par votre code personnalisé peut être distribuée en fonction de 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.

Pour obtenir des instructions sur l'utilisation d'URL signées avec Cloud CDN, consultez la section Utiliser des URL signées.

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 :

Pour fournir l'accès à plusieurs fichiers restreints.
Pour éviter de modifier vos URL actuelles.
Pour éviter de mettre à jour les URL chaque fois que vous actualisez l'autorisation d'accès au contenu.

Diffuser des contenus multimédias à l'aide de 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 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éez une clé de signature pour le service de backend donné.
Créez une valeur de cookie avec le préfixe d'URL, la date d'expiration, le nom de clé et la signature cryptographique autorisés.
Émettez le 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.

Pour obtenir des instructions sur l'utilisation de cookies signés avec Cloud CDN, consultez la section Utiliser des cookies signés.

Authentification de l'origine privée

L'authentification de l'origine privée donne à Cloud CDN un accès à long terme aux buckets Amazon S3 privés ou aux magasins d'objets compatibles. Cloud CDN peut ensuite diffuser du contenu à partir de ces origines sans utiliser l'accès public en lecture.

L'authentification de l'origine privée est liée à l'origine, tandis que les URL signées et les cookies signés sont côté client. Vous pouvez activer les deux pour le même contenu. L'authentification des origines privées limite l'accès non CDN à vos origines et à votre contenu. Les URL et cookies signés déterminent quels utilisateurs peuvent accéder à Cloud CDN.

L'authentification de l'origine privée est compatible avec Cloud CDN avec un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique.

Pour obtenir des instructions sur l'utilisation de l'authentification de l'origine privée avec Cloud CDN, consultez la page Configurer l'authentification de l'origine privée.

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 comme 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 dont les signatures ont expiré ou ne sont pas valides, continuent d'entraîner des frais de recherche dans le cache.

Étapes suivantes

Pour en savoir plus sur les autres bonnes pratiques, consultez Bonnes pratiques concernant la sécurité Web.