Cette page présente les URL signées et décrit comment les utiliser avec Cloud CDN. Les URL signées fournissent un accès aux ressources limité dans le temps à toute personne en possession de l'URL, qu'elle ait ou non un compte Google.
Une URL signée est une URL qui fournit une autorisation et une durée limitées pour effectuer une requête. Les URL signées contiennent des informations d'authentification dans leur chaîne de requête, ce qui permet aux utilisateurs sans identifiants d'effectuer des actions spécifiques sur une ressource. Lorsque vous générez une URL signée, vous spécifiez un utilisateur ou un compte de service qui doit disposer d'autorisations suffisantes pour effectuer la requête associée à l'URL.
Une fois l'URL signée générée, toute personne qui en dispose peut l'utiliser pour effectuer des actions spécifiées, telles que la lecture d'un objet, dans un délai spécifié.
Les URL signées acceptent également un paramètre URLPrefix
facultatif, qui vous permet d'accorder un accès à plusieurs URL en fonction d'un préfixe commun.
Si vous souhaitez limiter l'accès à un préfixe d'URL spécifique, envisagez d'utiliser des cookies signés.
Avant de commencer
Avant d'utiliser des URL signées, procédez comme suit :
Assurez-vous que Cloud CDN est activé. Pour obtenir des instructions, consultez la page Utiliser Cloud CDN. Vous pouvez configurer des URL signées sur un backend avant d'activer Cloud CDN, mais elles sont sans effet jusqu'à l'activation de Cloud CDN.
Si nécessaire, installez la dernière version de Google Cloud CLI :
gcloud components update
Pour en savoir plus, consultez la page Cookies et URL signés.
Configurer des clés de requête signées
La création de clés pour vos URL ou cookies signés nécessite plusieurs étapes, décrites dans les sections suivantes.
Points à noter concernant la sécurité
Cloud CDN ne valide pas les requêtes dans les cas suivants :
- La requête n'est pas signée.
- Cloud CDN n'est pas activé sur le service de backend ou le bucket backend de la requête.
Les requêtes signées doivent toujours être validées à l'origine avant de diffuser la réponse. Ceci est dû au fait que les origines peuvent servir à diffuser un mélange de contenu signé et non signé, et qu'un client peut accéder directement à l'origine.
- Cloud CDN ne bloque pas les requêtes n'utilisant ni le paramètre de requête
Signature
, ni le cookie HTTPCloud-CDN-Cookie
. Cloud CDN rejette les requêtes dont les paramètres sont incorrects (ou ne sont pas rédigés correctement). - Lorsque votre application détecte une signature non valide, assurez-vous qu'elle répond avec un code de réponse
HTTP 403 (Unauthorized)
. Les codes de réponseHTTP 403
ne peuvent pas être mis en cache. - Les réponses aux requêtes signées et non signées sont mises en cache séparément. Par conséquent, une réponse réussie à une requête signée valide n'est jamais utilisée pour diffuser une requête non signée.
- Si votre application envoie un code de réponse pouvant être mis en cache à une requête non valide, les futures requêtes valides risquent d'être rejetées par erreur.
Pour les backends Cloud Storage, assurez-vous de supprimer l'accès public afin que Cloud Storage puisse rejeter les requêtes ne contenant pas de signature valide.
Le tableau suivant récapitule le comportement.
La requête comporte une signature | Succès de cache (hit) | Comportement |
---|---|---|
Non | Non | La requête est transférée vers l'origine du backend. |
Non | Oui | La requête est diffusée à partir du cache. |
Oui | Non | La signature est validée. Si la requête est valide, elle est transférée vers l'origine du backend. |
Oui | Oui | La signature est validée. Si la requête est valide, elle est diffusée à partir du cache. |
Créer des clés de requête signées
Pour pouvoir exploiter les URL et cookies signés Cloud CDN, vous devez créer une ou plusieurs clés sur un service de backend et/ou un bucket backend compatibles avec Cloud CDN.
Pour chaque service de backend ou bucket backend, vous pouvez créer et supprimer des clés selon vos besoins en termes de sécurité. Chaque backend peut comporter jusqu'à trois clés configurées à la fois. Nous vous suggérons d'effectuer régulièrement une rotation des clés : supprimez la clé la plus ancienne, ajoutez-en une nouvelle et utilisez-la pour la signature des URL ou cookies.
Vous pouvez utiliser le même nom de clé dans plusieurs services de backend et buckets backend, car chaque ensemble de clés est indépendant des autres. Les noms de clé peuvent comporter jusqu'à 63 caractères. Pour nommer vos clés, utilisez les caractères A-Z, a-z, 0-9, _ (trait de soulignement) et - (trait d'union).
Lorsque vous créez des clés, veillez à les sécuriser, car toute personne qui en possède une peut créer des URL ou cookies signés acceptés par Cloud CDN jusqu'à ce que la clé soit supprimée du réseau de diffusion de contenu. Les clés sont stockées sur l'ordinateur sur lequel vous générez les URL ou cookies signés. Cloud CDN stocke également les clés pour valider les signatures de requête.
Pour garder les clés secrètes, les valeurs de clé ne sont pas incluses dans les réponses aux requêtes API. Si vous perdez une clé, vous devez en créer une nouvelle.
Pour créer une clé de requête signée, procédez comme suit :
Console
- Dans Google Cloud Console, accédez à la page Cloud CDN.
- Cliquez sur le nom de l'origine à laquelle vous souhaitez ajouter la clé.
- Sur la page Détails de l'origine, cliquez sur le bouton Modifier.
- Dans la section Paramètres de base de l'origine, cliquez sur Suivant pour ouvrir la section Règles d'hôte et de chemin d'accès.
- Dans la section Règles d'hôte et de chemin d'accès, cliquez sur Suivant pour ouvrir la section Performances du cache.
- Dans la section Contenu limité, sélectionnez Restreindre l'accès à l'aide des URL et des cookies signés.
Cliquez sur Ajouter une clé de signature.
- Spécifiez un nom unique pour la nouvelle clé de signature.
Dans la section Méthode de création de clé, sélectionnez Générer automatiquement. Vous pouvez également cliquer sur Me laisser saisir, puis spécifier une valeur de clé de signature.
Pour la première option, copiez la valeur de la clé de signature générée automatiquement dans un fichier privé, que vous pouvez utiliser pour créer des URL signées.
Cliquez sur OK.
Dans la section Âge maximal de l'entrée de cache, saisissez une valeur, puis sélectionnez une unité de temps.
Cliquez sur OK.
gcloud
L'outil de ligne de commande gcloud
lit les clés à partir d'un fichier local que vous spécifiez. Le fichier de clé doit être créé en générant une valeur de 128 bits fortement aléatoire, en l'encodant en base64, puis en remplaçant le caractère +
par -
et le caractère /
par _
. Pour plus d'informations, consultez la norme RFC 4648.
Il est essentiel que la clé soit fortement aléatoire. Sur un système de type UNIX, vous pouvez générer une clé fortement aléatoire et la stocker dans le fichier de clés à l'aide de la commande suivante :
head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME
Pour ajouter la clé à un service de backend, utilisez la commande suivante :
gcloud compute backend-services \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Pour ajouter la clé à un bucket backend, utilisez la commande ci-dessous :
gcloud compute backend-buckets \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Configurer les autorisations Cloud Storage
Si vous utilisez Cloud Storage et que vous avez restreint l'accès en lecture aux objets, vous devez autoriser Cloud CDN à lire les objets en ajoutant le compte de service Cloud CDN aux listes de contrôle d'accès Cloud Storage.
Vous n'avez pas besoin de créer le compte de service. Il est créé automatiquement la première fois que vous ajoutez une clé à un bucket backend d'un projet.
Avant d'exécuter la commande suivante, ajoutez au moins une clé à un bucket backend de votre projet. Si vous ne respectez pas cette condition, la commande échoue et renvoie une erreur, car le compte de service du remplissage du cache Cloud CDN n'est pas créé tant que vous n'avez pas ajouté au moins une clé pour le projet.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
Remplacez PROJECT_NUM
par le numéro de votre projet et BUCKET
par votre bucket de stockage.
Le compte de service Cloud CDN, service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com
, ne figure pas dans la liste des comptes de service de votre projet. Ceci est dû au fait qu'il appartient à Cloud CDN, et non à votre projet.
Pour plus d'informations sur les numéros de projet, consultez la section Localiser l'ID et le numéro de projet dans la documentation d'aide de Google Cloud Console.
Personnaliser le délai de cache maximal
Cloud CDN met en cache les réponses aux requêtes signées, quel que soit l'en-tête Cache-Control
du backend. Le délai maximal de mise en cache des réponses sans revalidation est défini par l'option signed-url-cache-max-age
, qui prend la valeur par défaut d'une heure, et peut être modifié comme indiqué ici.
Pour définir la durée maximale de mise en cache d'un service de backend ou d'un bucket backend, exécutez l'une des commandes suivantes :
gcloud compute backend-services update BACKEND_NAME --signed-url-cache-max-age MAX_AGE
gcloud compute backend-buckets update BACKEND_NAME --signed-url-cache-max-age MAX_AGE
Répertorier les noms des clés de requête signées
Pour répertorier les clés d'un service de backend ou d'un bucket backend, exécutez l'une des commandes suivantes :
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
Supprimer des clés de requête signées
Lorsque les URL signées par une clé spécifique ne doivent plus être honorées, exécutez l'une des commandes suivantes pour supprimer cette clé du service de backend ou du bucket backend :
gcloud compute backend-services \ delete-signed-url-key BACKEND_NAME --key-name KEY_NAME
gcloud compute backend-buckets \ delete-signed-url-key BACKEND_NAME --key-name KEY_NAME
Signer les URL
La dernière étape consiste à signer les URL et à les distribuer. Vous pouvez signer des URL à l'aide de la commande gcloud compute sign-url
ou d'un code que vous écrivez vous-même.
Si vous avez besoin d'un grand nombre d'URL signées, le code personnalisé offre de meilleures performances.
Créer des URL signées
Suivez ces instructions pour créer des URL signées à l'aide de la commande gcloud compute sign-url
. Pour cette étape, nous partons du principe que vous avez déjà créé les clés.
Console
Vous ne pouvez pas créer d'URL signées à l'aide de la console Google Cloud. Vous pouvez utiliser Google Cloud CLI ou écrire du code personnalisé à partir des exemples suivants.
gcloud
Google Cloud CLI inclut une commande pour la signature d'URL. La commande met en œuvre l'algorithme décrit dans la section sur l'écriture de votre code.
gcloud compute sign-url \ "URL" \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME \ --expires-in TIME_UNTIL_EXPIRATION \ [--validate]
Cette commande lit et décode la valeur de clé encodée en base64url de KEY_FILE_NAME
, puis génère une URL signée utilisable pour les requêtes GET
ou HEAD
pour l'URL donnée.
Exemple :
gcloud compute sign-url \ "https://example.com/media/video.mp4" \ --key-name my-test-key \ --expires-in 30m \ --key-file sign-url-key-file
L'URL URL
doit être valide et posséder un composant de chemin. Par exemple, https://example.com/
et https://example.com/whatever
sont deux URL valides, contrairement à http://example.com
.
Si l'option --validate
facultative est spécifiée, cette commande envoie une requête HEAD
avec l'URL générée et affiche le code de réponse HTTP. Si l'URL signée est correcte, le code de réponse est le même que le code de résultat envoyé par le backend. Si le code de réponse diffère, revérifiez KEY_NAME
et le contenu du fichier spécifié, puis assurez-vous que la valeur de TIME_UNTIL_EXPIRATION
est d'au moins plusieurs secondes.
Si l'option --validate
n'est pas précisée, les éléments suivants ne sont pas vérifiés :
- Les entrées
- L'URL générée
- L'URL signée générée
Créer des URL signées par programmation
Les exemples de code suivants montrent comment créer des URL signées par programmation.
Go
Ruby
.NET
Java
Python
PHP
Créer des URL signées par programmation avec un préfixe d'URL
Les exemples de code suivants montrent comment créer des URL signées par programmation avec un préfixe d'URL.
Go
Java
Python
Générer des URL signées personnalisées
Lorsque vous écrivez votre propre code pour générer des URL signées, votre objectif est de créer des URL présentant le format ou l'algorithme suivant. Tous les paramètres d'URL sont sensibles à la casse et doivent être dans l'ordre indiqué :
https://example.com/foo?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Pour générer des URL signées, procédez comme suit :
Assurez-vous que l'URL de signature ne comporte pas le paramètre de requête
Signature
.Déterminez la date et l'heure d'expiration de l'URL, et ajoutez le paramètre de requête
Expires
avec le délai d'expiration requis au format de fuseau horaire UTC (nombre de secondes écoulées depuis le 01/01/1970 à 00:00:00 UTC). Pour plus de sécurité, définissez la valeur sur la période la plus courte possible pour votre cas d'utilisation. Plus la période de validité de l'URL signée est longue, plus le risque de partage accidentel ou intentionnel est élevé.Définissez le nom de la clé. L'URL doit être signée avec une clé du service de backend ou du bucket backend qui diffuse cette URL. Il est préférable d'utiliser la clé la plus récente pour le renouvellement de la clé. Ajoutez la clé à l'URL en incluant
&KeyName=KEY_NAME
. RemplacezKEY_NAME
par le nom de la clé choisie créée à la section Créer des clés de requête signées.Signez l'URL. Créez l'URL signée en procédant comme suit. Assurez-vous que les paramètres de requête sont dans l'ordre indiqué immédiatement avant l'étape 1 et qu'aucun élément de l'URL signée ne change de casse.
a. Hachez l'URL entière (y compris
http://
ouhttps://
au début et&KeyName...
à la fin) à l'aide de HMAC-SHA1, avec la clé secrète correspondant au nom de clé choisi auparavant. Utilisez la clé secrète brute de 16 octets, et non la clé encodée en base64url. Décodez-la si nécessaire.b. Utilisez l'encodage base64url pour encoder le résultat.
c. Ajoutez
&Signature=
à l'URL, suivi de la signature encodée.
Utiliser des préfixes d'URL pour les URL signées
Au lieu de signer l'URL de requête complète avec les paramètres de requête Expires
et KeyName
, vous pouvez ne signer que les paramètres de requête URLPrefix
, Expires
et KeyName
. Cela vous permet de réutiliser une combinaison donnée de paramètres de requête URLPrefix
, Expires
, KeyName
et Signature
tels quels sur plusieurs URL qui correspondent à URLPrefix
, vous évitant ainsi d'avoir à créer une signature pour chaque URL.
Dans l'exemple suivant, le texte en surbrillance indique les paramètres que vous signez. Le paramètre Signature
est ajouté comme paramètre de requête final, comme d'habitude.
https://media.example.com/videos/id/master.m3u8?userID=abc123&starting_profile=1&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=
Contrairement à la signature d'une URL de requête complète, lorsque vous signez avec URLPrefix
, vous ne signez aucun paramètre de requête. Les paramètres de requête peuvent donc être inclus gratuitement dans l'URL. Contrairement aux signatures d'URL de requête complète, ces paramètres de requête supplémentaires peuvent apparaître avant et après les paramètres de requête qui constituent la signature. Par conséquent, l'URL suivante est également valide : elle comporte un préfixe d'URL signée :
https://media.example.com/videos/id/master.m3u8?userID=abc123&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=&starting_profile=1
URLPrefix
désigne un préfixe d'URL encodé en base64 et sécurisé pour les URL qui englobe tous les chemins pour lesquels la signature doit être valide.
Un préfixe URLPrefix
encode un schéma (http://
ou https://
), un nom de domaine complet et un chemin d'accès facultatif. Vous n'avez pas besoin de terminer l'URL par le signe /
, mais cette pratique est recommandée. Le préfixe ne doit pas inclure de paramètres de requête ni de fragments tels que ?
ou #
.
Par exemple, https://media.example.com/videos
correspond aux requêtes vers les deux éléments suivants :
https://media.example.com/videos?video_id=138183&user_id=138138
https://media.example.com/videos/137138595?quality=low
Le chemin du préfixe est utilisé en tant que sous-chaîne de texte, et non en tant que chemin de répertoire strict.
Par exemple, le préfixe https://example.com/data
accorde l'accès à ces deux éléments :
/data/file1
/database
Pour éviter cette erreur, nous vous recommandons de terminer tous les préfixes par /
, sauf si vous choisissez de terminer intentionnellement un préfixe par un nom de fichier partiel tel que https://media.example.com/videos/123
pour accorder l'accès aux éléments suivants :
/videos/123_chunk1
/videos/123_chunk2
/videos/123_chunkN
Si l'URL demandée ne correspond pas à URLPrefix
, Cloud CDN rejette la requête et renvoie une erreur HTTP 403
au client.
Valider des URL signées
Le processus de validation d'une URL signée est, pour l'essentiel, identique à la génération d'une URL signée. Par exemple, supposons que vous souhaitiez valider l'URL signée suivante :
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Vous pouvez utiliser la clé secrète nommée KEY_NAME
pour générer indépendamment la signature de l'URL suivante :
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME
Vous pouvez ensuite vérifier qu'elle correspond à SIGNATURE
.
Supposons que vous souhaitiez valider une URL signée avec un élément URLPrefix
, comme indiqué ci-dessous :
https://example.com/PATH?URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Tout d'abord, vérifiez que la valeur décodée en base64 de URL_PREFIX
est un préfixe de https://example.com/PATH
. Si tel est le cas, vous pouvez calculer la signature pour les éléments suivants :
URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME
Vous pouvez ensuite vérifier qu'elle correspond à SIGNATURE
.
Pour les méthodes de signature basées sur l'URL, lorsque la signature fait partie des paramètres de requête ou est intégrée en tant que composant de chemin d'URL, la signature et les paramètres associés sont supprimés de l'URL avant que la requête ne soit envoyée à l'origine. Cela évite que la signature ne provoque des problèmes de routage lorsque l'origine gère la requête. Pour valider ces requêtes, vous pouvez inspecter l'en-tête de requête x-client-request-url
, qui inclut l'URL de requête client d'origine (signée) avant la suppression des composants signés.
Supprimer l'accès public au bucket Cloud Storage
Pour que les URL signées fournissent une bonne protection au contenu, celui-ci ne doit pas disposer d'un accès public, généralement accordé par le serveur d'origine. Lorsque vous utilisez un bucket Cloud Storage, une méthode courante consiste à rendre les objets publics de manière temporaire pour effectuer des tests. Une fois les URL signées activées, vous devez supprimer les accès en lecture de allUsers
(et de allAuthenticatedUsers
, le cas échéant), autrement dit le rôle Identity and Access Management Lecteur des objets de l'espace de stockage sur le bucket.
Après avoir désactivé l'accès public sur le bucket, les utilisateurs individuels peuvent toujours accéder à Cloud Storage sans les URL signées s'ils disposent d'autorisations d'accès, telles que l'autorisation Propriétaire.
Pour supprimer l'accès en lecture de allUsers
sur un bucket Cloud Storage, inversez le processus décrit dans la section Rendre des groupes d'objets lisibles publiquement.
Distribuer et utiliser des URL signées
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.